Stage 8 — Valuation Memo & Repo Polish

The three moves

1. Write the valuation memo. Is the market price of your company's shares above or below what the company is worth, by how much, and what does that verdict hang on? Draft it yourself first, commit the draft, then ask an LLM to review it.
2. Polish the repository so the whole project, ratios and valuation, stands as a professional artifact you would link from your LinkedIn. Budget 2–3 hours; don't leave it for the night before.
3. Submit the repo URL on the course LMS. The repo itself is the artifact.

Part A — the valuation memo

File: docs/decisions/YYYY-MM-DD-{company-slug}-valuation-memo.md — all lowercase, hyphen-separated, no last name. Use the repo memo template and keep its YAML frontmatter intact. One to two pages, written to the company's board: concise, decision-oriented, evidence-tight. The verdict is yours, not the model's and not an LLM's.

Required content

1. Intrinsic value against market price. Your model's value per share beside the market price, and the gap as a percentage of the market price. State the date and source of the price, in the currency the shares trade in. You may use share_price from your workbook (the fiscal-year-end close) or a more recent close; if you use a recent one, say why and give the fiscal-year-end figure beside it.
2. The beta × terminal growth sensitivity table. Beta on one axis, terminal growth rate (g) on the other, an odd number of rows and columns so there is a true center. Every cell holds value per share, in the same unit as the market price. The center cell equals your model's value per share — highlight it. If it does not, the table is wrong.
3. The flip point, as a number. At what beta (holding g at your base case), or what g (holding beta), does your value per share equal the market price? Give the number, not "somewhat higher". Interpolate between cells if you have to, and say so.
4. The one input the verdict hangs on. Name it, say where its value came from, how confident you are in it, and what the board should find out before acting.
5. What the skill got wrong — and what you would never let it decide alone. One paragraph drawing on your Stage 6 annotated diff and your Stage 7 audit and verification: where the published skill would have mis-valued your company, and which decision in a valuation you would keep for a human no matter how good the agent gets.

Draft first, then use an LLM to review

Draft the memo yourself and commit the draft — that commit is your evidence of the first draft. Then ask an LLM to review it, not rewrite it:

Here is my valuation memo and the sensitivity table from my DCF. Review the memo
against these requirements: value per share against a dated, sourced market
price, with the gap as a percentage; an odd-sized beta × terminal growth table
whose center equals the model's value; the flip point stated as a number; one
named input the verdict hangs on, with its source; a paragraph on what the skill
got wrong. For each problem, quote the line and say what is wrong. Check every
number in the memo against the table. Don't rewrite the memo.

[PASTE MEMO AND TABLE HERE]

Work through the review one point at a time and revise the memo yourself; reject points you disagree with. Log the sessions in prompt-log.md at the repo root.

Part B — repo polish

By now your repo should look like a professional portfolio artifact. This is the target hierarchy; filenames reflect your own company.

firstname-lastname/
├── README.md        project overview, status, "what you'll find here"
├── RESUME.md        from Stage 0
├── LICENSE          MIT or Apache-2.0
├── .gitignore       excludes .DS_Store, ~$*.xlsx, *.tmp, etc.
├── .claude/skills/
│   ├── README.md
│   ├── performance-ratios/SKILL.md    Stage 1 (unmodified)
│   ├── dcf-model/                     Stage 6 (baseline + your edits, LICENSE)
│   └── audit-xls/                     Stage 6 (unmodified, LICENSE)
├── docs/decisions/
│   ├── README.md
│   ├── …-selection-memo.md            Stage 2
│   ├── …-spec-iteration-memo.md       (optional) Stage 4
│   ├── …-feedback-response-memo.md    (optional) Stage 5
│   └── …-valuation-memo.md            Stage 8
├── capabilities/
│   ├── performance-ratios/            README.md, spec.md (Stage 4)
│   └── valuation/                     README.md, spec.md (Stage 6), model.xlsx (Stage 7)
├── models/
│   ├── templates/                     Stage 1 (unmodified)
│   └── builds/                        Stage 3
├── analysis/
│   ├── README.md
│   ├── …-llm-raw-log.md, …-verification-analysis.md, …-analysis.md,
│   │   …-spec-retrospective-analysis.md                 Stage 5
│   ├── …-dcf-skill-diff-analysis.md                     Stage 6
│   ├── …-dcf-raw-log.md, …-dcf-audit-analysis.md,
│   │   …-dcf-verification-analysis.md                   Stage 7
│   └── validation/                    README.md, …-identity-checks-log.md (Stage 3)
└── prompt-log.md    all AI sessions logged

• Top-level README.md: a project status section listing every stage (0 through 8) and its commit hash, and a "what you'll find here" paragraph orienting a manager, reviewer, or peer who just clicked the link.
• One-line repo description in the GitHub repo page header (the field at the top of the repo page, not in the README).
• LICENSE at the repo root (MIT or Apache-2.0).
• .gitignore excluding common scratch files (.DS_Store, ~$*.xlsx, *.tmp).
• A README.md in every directory, filenames on convention (older names already submitted still count), no orphan files, dead links or _temp/ directories, a clean commit history, and the repo still public.
• Update capabilities/valuation/README.md so a visitor can tell, in four sentences, what the valuation is, how it was built, and how it was checked.

Use an LLM to reorganize and clean up

The polish pass is exactly the routine reorganization an LLM is good at. In Claude Code or Codex, opened in your repo folder:

Read every file in this repo. Compare the current structure against the Stage 8
target hierarchy on the Kumu Stage 8 page
(https://adamwstauffer.github.io/ai-lms/performance-ratios-stage8.html).

Identify:
1. Misnamed files (not following YYYY-MM-DD-{company-slug}-{type}; older names with my last name are fine to leave)
2. Files in the wrong directory
3. Missing per-directory READMEs (every folder should have one)
4. Orphan or temp files that should be deleted

For each issue, say exactly what to rename, move or delete. Do NOT change
anything yourself. After that list, draft per-directory README.md files for any
directory missing one: 4-6 sentences each on what is in the directory, the
naming conventions used, and how it relates to the project stages.

No AI tool installed? Zip the repo, upload it to Claude.ai or ChatGPT, and ask for a table of every file with columns current path | correct path | action, drafts of the missing READMEs, and a list of any missing artifacts such as LICENSE or .gitignore.

What the LLM should not do at Stage 8: generate the analysis content for you, or rewrite your final analysis or valuation memo to "improve" it. The polish pass is about file organization and presentation. Log the cleanup prompt in prompt-log.md too.

Submission checklist

• docs/decisions/YYYY-MM-DD-{company-slug}-valuation-memo.md — committed first draft, then revisions
• Memo has all five required parts: value against a dated, sourced price; odd-sized beta × terminal growth table with the center equal to the model; the flip point as a number; the hinge input; what the skill got wrong
• Top-level README.md with a project status section (stages 0 through 8, with commit hashes) and a "what you'll find here" paragraph
• LICENSE at the repo root (MIT or Apache-2.0)
• .gitignore excluding common scratch files
• One-line repo description set in the GitHub repo header
• A README.md in every directory, including an updated capabilities/valuation/README.md
• All dated filenames follow YYYY-MM-DD-{company-slug}-{type}.{ext}; no orphan files, dead links or _temp/ directories
• Commit history is clean (descriptive messages; no wip or asdf commits)
• prompt-log.md updated with the memo review and the repo-cleanup sessions
• Repo is public and opens without login; URL submitted on the course LMS

Rubric

The headings below are what the work is read for. Weights and due dates are in your course schedule.

Tips

• Lead with the verdict. The memo's first sentence says whether the shares trade above or below your value, and by how much.
• The table is the argument. A verdict that survives every plausible cell is strong; a verdict that flips one cell from the center is a different memo. Say which one you have.
• Polish the repo last — but not last-night. Allocate a dedicated commit pass for READMEs, naming, license, and repo description.

Check yourself