Kumu / Reference / Portfolio repo

The portfolio repo standard

One public repository, named for you, holding every engagement you complete. It is organized the way a working consultant's practice is organized — capabilities you can do, and engagements that prove you did them — rather than by class, semester, or assignment.

Course-shaped folders are a school concept and they stop meaning anything at graduation. This shape does not: the same skeleton holds a class project, a consulting engagement, and a work sample you send an employer.

Reference — course-independent Set up once, used by every engagement

The structure

Create the repository under your own account, name it firstname-lastname, and set visibility to public. A portfolio nobody can open is not a portfolio.

firstname-lastname/
  README.md            who you are + the index of engagements
  RESUME.md            Markdown resume
  AGENTS.md            your AI conventions — the canonical file
  CLAUDE.md            one line pointing to AGENTS.md
  prompt-log.md        the running record of AI sessions that mattered
  .gitignore           what must never enter the history
  .claude/skills/      personal sandbox — yours to experiment with
  capabilities/        one folder per capability
    marginal-analysis/
      README.md        what the capability is + which engagements exercised it
      spec.md          the method: model design, named ranges, formula logic
      model.xlsx       starts as a template, becomes your model
  docs/
    briefs/            BEFORE the work: scope + hypothesis
    decisions/         AFTER the work: the recommendation, to an audience
  data/                sourced inputs, with provenance
  analysis/            the findings
    figures/           charts the findings refer to

Git does not track empty folders. Create each directory with a one-line README.md inside it, or create it in the stage that first puts something there.

Three distinctions that carry the structure

Briefs ask; memos answer. A brief is written before the work: the scope, and a hypothesis you can be wrong about. A memo is what the reader gets at the end. A brief written after the analysis is a summary of the answer, which is worth nothing to you and obvious to anyone reading in order.
Capabilities are what you can do; engagements are evidence. capabilities/marginal-analysis/ is something you can do. docs/, data/, and analysis/ hold the work that proves it. Each capability's README.md names the engagements that exercised it, and that link — claim to proof — is the line a reader follows.
The spec and the model live with the capability. A method and the workbook implementing it are one object. Splitting them into a specs/ folder creates structure with no payoff and two places to look.

capabilities/ feeds .claude/skills/

Top-level capabilities/ names what you can do in your own terms, for human readers — it is the folder a resume line points at. .claude/skills/ is a tool-specific directory some AI tools load automatically. The two are deliberately compatible: a capability you build here — the spec, the method notes, the model — can be copied into .claude/skills/ almost unchanged to become a personal AI skill that follows you to every project. Build the capability first; the skill falls out of it. Nothing in any course grades what you put in the sandbox.

The four starter files

These live at the repository root and evolve all term. Drafting them with an LLM is expected; committing generic filler is not.

File	What goes in it, minimally
`README.md`	Three to six sentences on who you are and what you are working toward, then an engagement index: a short list linking each piece of work to its brief, analysis, and memo. This is the by-subject view of the repository. It lives here, never in the folder paths.
`RESUME.md`	A Markdown resume. Rough is acceptable on the first day. The Start Here page covers drafting and reviewing it.
`AGENTS.md`	Your AI conventions, and the file most tools read before answering: how you want explanations, what an AI may and may not draft for you, and what must never be pasted into a model. See AI conventions.
`CLAUDE.md`	A single line directing the reader to `AGENTS.md`. One source of truth, two filenames — explained on the same page.

What each engagement produces

The same three artifacts every time. By the second engagement the structure is automatic and your attention goes to the analysis instead of the filing.

Stage of the work	Artifact	Where it lives
Brief	The problem in your own words, and a hypothesis you can be wrong about, committed before you model anything	`docs/briefs/`
Build	The workbook, and the spec that lets somebody else reproduce it	`capabilities/<capability>/`
Report	The evidence with figures, the memo with the recommendation, and the prompt log	`analysis/` · `docs/decisions/`

Templates for the brief and the memo, and the naming rules that apply to all of them, are on Deliverable templates.

Naming

The repository is named for the person — firstname-lastname, or firstname-lastname-portfolio if that is taken. Not for a course.
Files are named for the engagement, not the week. perfect-competition-brief.md still makes sense to a stranger in three years; week1.md does not.
Slugs are lowercase and hyphen-separated, three to six words, no spaces or underscores.
Dated documents lead with the ISO date — YYYY-MM-DD-slug.md — so a folder listing sorts chronologically on its own.

Build it with an LLM

Creating directories and stub files is a mechanical task, which makes it exactly the kind of work to hand to a model and verify rather than type by hand. Paste the following into whichever surface you use — the differences between chat, desktop, and command line are covered in the AI Tools Lab.

Starter prompt — the skeleton

I am setting up a public GitHub portfolio repository named firstname-lastname.
Create this structure, with a one-line README.md inside every directory that would
otherwise be empty, so git will track it:

  README.md, RESUME.md, AGENTS.md, CLAUDE.md, prompt-log.md, .gitignore
  .claude/skills/
  capabilities/
  docs/briefs/  docs/decisions/
  data/
  analysis/figures/

Rules: capabilities/ holds one folder per capability, each containing README.md, spec.md,
and the model file. docs/briefs/ holds documents written BEFORE work begins;
docs/decisions/ holds recommendations written after. Do not create any folder named
after a course, a semester, or a week. Do not write my bio or resume content —
leave those files with a single placeholder line I will replace.

Before you accept the output, check three things: no folder is named after a course or a term; every directory contains something, or git will silently drop it; and the placeholder files are actually placeholders rather than invented biography. If you are working in a chat window rather than a tool with file access, ask for the terminal commands or create the files on github.com directly — typing a slash in the filename box creates the folder.

AI conventions — what goes in AGENTS.md, how a model reads it, and the draft-order rule
Deliverable templates — the brief, the memo, the prompt log, and why they carry frontmatter
Git mechanics — local versus remote, committing, pushing, .gitignore, and how work is submitted