Project Ops

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.

Rules for the contract, each with its why:

• id is unique and stable — depends_on references it, so renaming breaks the graph.
• owner is exactly one person, with an @handle — "accountability without a named owner defaults to no accountability." Never a team (@marketing) or two people.
• target is an ISO date (YYYY-MM-DD) — so "trending late" is arithmetic, not opinion.
• status is one of {green, amber, red, done} — a closed set the report and the linter both trust.
• done_test is binary and verifiable — you can point at it and say yes/no, no "improve" or "work on".
• depends_on is a comma-separated list of real ids — the dependency edges that reveal the critical path.

Milestone discipline

A milestone is a checkpoint that marks a significant achievement — it has a target date but no duration. The smaller actionable steps that get you there are tasks; track milestones at the project level, not every task. Each milestone proves a SMART-shaped goal (the done-test is the "Measurable").

Bad → Good, because most plans fail right here:

Bad:  "Marketing improvements"          (no owner, no date, not testable)
Good: | M7 | Landing page live | @ana | 2026-06-15 | green | prod URL returns 200 with new hero | M6 |

Bad:  "Ben & Ana own the launch"        (accountability split = no accountability)
Good: owner @ben on M2; @ana is named in done_test as reviewer if needed — still one A.

Bad:  done_test = "page is better"       (not binary — never finishable)
Good: done_test = "Lighthouse perf >= 90 on /pricing, checked in CI"

If the operator hands you a loose goal, decompose it into 3–8 milestones with one owner and a binary done-test each, then draw depends_on edges. More than ~10 milestones means you are tracking tasks — push those down to ../tasks/SKILL.md.

RAG status from rules, not vibes

Set status by the table below and write the reason next to any non-green item. Re-evaluate every milestone at each update.

Two rules that do the real work:

• Amber is an early warning, not a soft red. Flag amber before the due date passes — the whole point is to course-correct while there is still time. A milestone that only turns red on its due date was mis-tracked.
• All-green is a smell. A board that is always green means you are either not tracking closely or not being honest. On any real project at least one item is usually amber. If everything is genuinely green, say so explicitly so it is a claim, not a default.

Slippage and the critical path

The critical path is the longest chain of depends_on edges that sets the finish date — its milestones have zero buffer, so any slip there slips the whole project. Mark which milestones are on it. Watch near-critical paths too: a small slip there can promote them onto the critical path.

At every update: re-confirm which milestones are critical (the path moves as dates change), track days of slip per milestone (today minus target for anything late), and surface any milestone whose amber rule just tripped. The full early-warning decision table and a worked slippage example live in references/raid-and-rag.md.