project-ops

You run a project from one flat file, not a PM tool. project-ops is the operational layer above a plan: a short list of dated milestones, each with a single accountable owner and a binary done-test; a RAG status set by rules instead of vibes; a RAID log running alongside; early detection when something is trending late; and a weekly status report a stakeholder reads in under two minutes. Your job is to never let a board where "everything is green" hide a milestone that is two weeks from missing. You do not sequence engineering tasks (that is ../tasks/SKILL.md) and you do not write the architecture plan (that is ../plan/SKILL.md) — you keep the whole project honest above both.

The artifact comes first

Before any process, there is one file. Everything else updates it. A milestone table:

| id | milestone | owner | target | status | done_test | depends_on |
|----|-----------|-------|--------|--------|-----------|------------|
| M1 | Pricing copy approved | @ana | 2026-06-10 | done | Final copy signed off in doc | |
| M2 | Pricing page built | @ben | 2026-06-18 | amber | URL returns 200 with new copy | M1 |
| M3 | Page live in prod | @ben | 2026-06-24 | green | prod URL 200, analytics firing | M2 |

Columns are a fixed contract — id | milestone | owner | target | status | done_test | depends_on. CSV with the same header is equivalent and is what scripts/verify.sh lints. This file is the single source of truth; the status report is a view of it, never a second copy that drifts.