Projects — one operating model, from onboarding to completion
Almost every phase of a project's life already has an owner. This skill is the routing table
over those owners, plus the two things that have no owner today: the project-switch ritual and
the per-project artifact checklist.
There is no engine here, and no state anybody sets by hand. A project's state is read from its
tree — see state-transitions.md.
What this is not for
| The task |
Its owner |
Why not this skill |
| Which item to work on next, what is left to build |
roadmap |
A project's remaining work is items in that project's own roadmap. This skill never ranks or picks. |
| Understanding an unfamiliar codebase |
codebase-onboarding, repo-scan |
Those own how to read a codebase. This skill only says that phase comes first and names them. |
| Planning before source is edited |
superplan, blueprint |
Plan depth is a shipped standard with its own gate. Nothing here relaxes or restates it. |
| Handing work to another session |
/relay, successor |
A handoff is a session-level act. A project switch inside one session is not a handoff. |
| The project's vocabulary |
domain-modeling |
Terms live in the project's own CONTEXT.md, written by that skill. |
| Continuing past the item in hand |
endless |
Continuation is about the loop, not about the project. |
| Applying this model to a specific project subtree |
that project's own docs |
This skill describes the model; it never writes into anybody's project. |
The project-switch ritual
Run this on starting a project and on switching to one, before any other action. The failure
it prevents is silent: nothing errors when the previous project's scope is carried into a new one —
the work is simply aimed at the wrong target, and reads as correct all the way to the commit.
Each step is an assertion about this project. State the answer; do not assume it carried over.
- Name the subtree.
projects/<slug>/, and whether it is a nested repository of its own — the
harness enumerates such a project, skips it, and says so on every run. Its git state is not the
harness's git state.
- Read the project's own goal and scope, in its own words, from its init card or README. The
previous project's goal is not evidence about this one.
- Assert the memory namespace —
task:<slug>. Operational records are read-only context
inside a project and are never merged into project memory.
- Assert the id sequences are the project's own. Roadmap ids and decision ids are per-file
counters, so the same number names different work in every project. Outside the project, cite
them qualified:
<slug>:RM-0007.
- Assert the project's own gate — the command that is this project's CI — and run it once
before changing anything, so a later red is attributable to your change.
- Walk the artifact checklist in operating-model.md, and read
its warning about silence.
Red flags
| Thought |
What it means |
| "Same repo, I already know the setup" |
A subtree is not the harness. Step 1 has not been answered. |
| "The tests were passing earlier" |
Earlier, in a different project's gate. Step 5 has not been run. |
| "I'll record this decision in the ADR set" |
Which ADR set? A project's decisions never enter the harness sequence. |
| "The guard found nothing, so it is clean" |
Or it is not configured. Read the checklist's warning. |
| "This project has no roadmap, so I'll just start" |
A project with more than one unit of remaining work owes one. Absence is a finding. |
Reference
- operating-model.md — every lifecycle phase and the skill that
owns it; the per-project artifact checklist.
- state-transitions.md — the four states, and the evidence each
transition requires.
1---2name: projects3description: Use when starting or switching to a project subtree, when a project's own README, changelog, ADR set, decision ledger, roadmap or data-provenance manifest may be missing, or when deciding whether a project is initialized, active, dormant or completed.4---56# Projects — one operating model, from onboarding to completion78Almost every phase of a project's life already has an owner. This skill is the **routing table**9over those owners, plus the two things that have no owner today: the **project-switch ritual** and10the **per-project artifact checklist**.1112There is no engine here, and no state anybody sets by hand. A project's state is *read* from its13tree — see [state-transitions.md](references/state-transitions.md).1415## What this is not for1617| The task | Its owner | Why not this skill |18|---|---|---|19| Which item to work on next, what is left to build | `roadmap` | A project's remaining work is items in that project's own roadmap. This skill never ranks or picks. |20| Understanding an unfamiliar codebase | `codebase-onboarding`, `repo-scan` | Those own *how* to read a codebase. This skill only says that phase comes first and names them. |21| Planning before source is edited | `superplan`, `blueprint` | Plan depth is a shipped standard with its own gate. Nothing here relaxes or restates it. |22| Handing work to another session | `/relay`, `successor` | A handoff is a session-level act. A project switch inside one session is not a handoff. |23| The project's vocabulary | `domain-modeling` | Terms live in the project's own `CONTEXT.md`, written by that skill. |24| Continuing past the item in hand | `endless` | Continuation is about the loop, not about the project. |25| Applying this model to a specific project subtree | that project's own docs | This skill describes the model; it never writes into anybody's project. |2627## The project-switch ritual2829Run this on **starting** a project and on **switching** to one, before any other action. The failure30it prevents is silent: nothing errors when the previous project's scope is carried into a new one —31the work is simply aimed at the wrong target, and reads as correct all the way to the commit.3233Each step is an assertion about *this* project. State the answer; do not assume it carried over.34351. **Name the subtree.** `projects/<slug>/`, and whether it is a nested repository of its own — the36 harness enumerates such a project, skips it, and says so on every run. Its git state is not the37 harness's git state.382. **Read the project's own goal and scope**, in its own words, from its init card or README. The39 previous project's goal is not evidence about this one.403. **Assert the memory namespace** — `task:<slug>`. Operational records are read-only context41 inside a project and are never merged into project memory.424. **Assert the id sequences are the project's own.** Roadmap ids and decision ids are per-file43 counters, so the same number names different work in every project. Outside the project, cite44 them qualified: `<slug>:RM-0007`.455. **Assert the project's own gate** — the command that is *this* project's CI — and run it once46 before changing anything, so a later red is attributable to your change.476. **Walk the artifact checklist** in [operating-model.md](references/operating-model.md), and read48 its warning about silence.4950## Red flags5152| Thought | What it means |53|---|---|54| "Same repo, I already know the setup" | A subtree is not the harness. Step 1 has not been answered. |55| "The tests were passing earlier" | Earlier, in a different project's gate. Step 5 has not been run. |56| "I'll record this decision in the ADR set" | Which ADR set? A project's decisions never enter the harness sequence. |57| "The guard found nothing, so it is clean" | Or it is not configured. Read the checklist's warning. |58| "This project has no roadmap, so I'll just start" | A project with more than one unit of remaining work owes one. Absence is a finding. |5960## Reference6162- [operating-model.md](references/operating-model.md) — every lifecycle phase and the skill that63 owns it; the per-project artifact checklist.64- [state-transitions.md](references/state-transitions.md) — the four states, and the evidence each65 transition requires.
RubyEyedReaper