The portfolio repo standard

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            your bio + the index of engagements
  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
  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
  models/              Performance Ratios only: templates/ and builds/

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.

GitHub warns on any file over 50 MB and refuses one over 100 MB, so link large data to its source rather than committing it.

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.

The four starter files

These live at the repository root and evolve all term. An LLM may draft the mechanical ones; the bio in README.md you write yourself, and generic filler belongs in none of them.

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.

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. 2026-08-24-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 and end with their type — YYYY-MM-DD-{slug}-{type}.md, where the type is brief, spec, memo, analysis or log — so a folder listing sorts chronologically on its own and says what each file is.
• No last name in a file name. The repository is already named for you.
• The folder follows the type: briefs in docs/briefs/, decision memos in docs/decisions/, analyses in analysis/, data memos beside the data in data/, and the prompt log in prompt-log.md at the root. A capability's own files keep fixed names — capabilities/<capability>/spec.md and model.xlsx. Performance Ratios is the one project that also uses models/; its spec is capabilities/performance-ratios/spec.md like any other.
• Old names still count. A file already committed under an earlier convention (with a last name, or undated) is found by Kumu and graded as it is — no rename needed, no deduction. The full table is on deliverable templates.

Build it with an LLM

Everything at this stage except your bio is a means to the work rather than the work itself — the skeleton, .gitignore, an AGENTS.md that already knows your field, the one-line CLAUDE.md, and a prompt log the assistant keeps for you. That makes it exactly the kind of work to hand to a model and verify rather than type by hand. Paste the following into Claude or ChatGPT, then paste your resume under the line — the differences between chat, desktop, and command line are covered in the AI Tools Lab.

I am setting up a public GitHub portfolio repository named firstname-lastname for a
graduate business course. My resume is below the line. Do five things, then show me
every file before I commit anything.

1. SKELETON. Create this structure, with a one-line README.md inside every directory
   that would otherwise be empty, so git will track it:
     README.md (already holds my bio - see 5), RESUME.md, AGENTS.md, CLAUDE.md,
     prompt-log.md, .gitignore
     capabilities/
     docs/briefs/  docs/decisions/
     data/
     analysis/figures/
   capabilities/ holds one folder per capability, each with 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.

2. AGENTS.md. Start from the baseline at
   https://adamwstauffer.github.io/ai-lms/ai-conventions.html and tailor it to me from
   my resume: name my field; list the kinds of data from my work that must never be
   pasted into a model (be specific to me - client records, patient data, government
   asset data, whatever applies); say how I want things explained; and keep the rule
   that you may not write my briefs, analyses, memos or reflections. Keep the Naming
   section word for word. Include this standing rule exactly:
     "At the end of every session that changed a file, append one entry to
      prompt-log.md: the date, what I asked, what you produced, what was wrong and how
      it was caught. Never backfill earlier sessions and never edit a past entry."

3. CLAUDE.md. One line: "Read AGENTS.md - it is the canonical file."

4. prompt-log.md. Write its first entry now, for this session, in that format.

5. RESUME.md and README.md. Put my resume into RESUME.md as clean Markdown without
   changing what it says. Do not change README.md - my bio is already in it. If
   README.md does not exist yet, create it with one line: "My bio goes here."

.gitignore, one pattern per line: ~$*.xlsx  ~$*.xlsm  ~$*.docx  ~$*.pptx  .DS_Store
Thumbs.db

If you are a chat window without file access, give me each file in its own code
block and the github.com steps to create it.
--- my resume ---

Before you accept the output, read every line and check three things: no folder is named after a course or a term; every directory contains something, or git will silently drop it; and README.md still holds your bio, word for word as you wrote it (Start Here, the bio step). Then read AGENTS.md: its data rule should name your data, not "sensitive information". If you are working in a chat window rather than a tool with file access, create the files on github.com directly — typing a slash in the filename box creates the folder.

The prompt log is the one file that cannot honestly be written after the fact, which is why the standing rule lives in AGENTS.md: every session appends its own entry, and the commit history shows the entries arriving alongside the work. A log that appears in one commit the night before a deadline is not a log.

Related

• 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