atlas-api

Example: Atlas API

A small, fictional project used to demonstrate every CM-Stack skill without needing your own client data first. All ten skills' "Example output" sections in skills/*/SKILL.md are written against this same fictional project -- so running a skill against these fixtures should produce something close to what's already shown there.

This is not a working codebase. It's a folder of realistic inputs (PR lists, defect logs, incident notes, a throughput export, team notes, a client proposal, and prior scorecard history) that stand in for the "real" sources each skill's ## Inputs section lists (tracker exports, gh commands, pasted docs, etc.).

Try it

Point any CM-Stack-installed agent at this folder and ask it to run a skill, e.g.:

"Load CM-Stack. Run /clarity on the project described in examples/atlas-api/."

Which fixture feeds which skill

Skill	Fixture(s)	What's in it
/clarity	vision.md	A partial strategy doc -- vision exists informally, no written plan below the PM, a real (if new) measurement scorecard. Expect a Yellow/Red/Green mix.
/quality	prs.json, defects.json	5 merged PRs (one via an unreviewed hotfix branch) and 3 escaped defects traced back to that path.
/stability	incidents.md	4 incidents in 90 days, only 1 with a written postmortem, no load-test record.
/postmortem	incidents.md (incident 4)	The one incident in the log that never got a postmortem -- feed just that entry in for a fast-path single-incident writeup.
/speed	throughput.csv	12 weeks of closed-issue exports: throughput, cycle time, and one oversized epic-tagged item.
/decompose	throughput.csv (the bulk-export epic row)	One undersized-ticket, oversized-scope epic ready to be broken down.
/team	team-notes.md	Retro notes, review-style conflict, and a new hire routing every question through the tech lead.
/onboarding	team-notes.md (new-hire section)	The same new hire, reframed as a ramp-up-plan request instead of a health check.
/values-check	client-proposal.md	A proposal to bill bug fixes as a new feature -- a values tension baked in on purpose.
/scorecard	All of the above, plus scorecard-history.jsonl	Runs all five pillar checks and demonstrates the Trend column against two prior recorded runs.

Why the data looks the way it does

Every fixture has at least one deliberate finding baked in (an unreviewed hotfix path, a missing postmortem, an overloaded tech lead, a values tension) so a skill run against it has something concrete to report -- instead of a bland "everything's fine." That mirrors how these skills are meant to be used: pointed at real, messy project data, not a clean demo.

Extending this example

Feel free to edit these fixtures to try edge cases -- e.g., delete scorecard-history.jsonl to see how /scorecard behaves with no prior history, or add a second incident to incidents.md to see /postmortem flag a repeat failure mode.