Onboard
Goal: read the codebase, produce living documentation. No code changes. No plans. No gap analysis.
living documentation
README.md : project overview, what it is, who it's for, how to use it.docs/tech-spec.md : main technical specification (core backbone, ≤300 lines).docs/specs/*.md : modular subsystem details split out when bulky (>15 lines). Referenced by path.
Technical specification is declarations only: current ground truth facts (atemporal, no narrative, no history, no plans).
Steps
- Explore entry points, public interfaces, key dependencies, test patterns, file structure. Read, don't guess.
- Ask the user about anything ambiguous — never invent architecture.
- Write
docs/tech-spec.md using the canonical format (field meanings: archive skill, "tech-spec format"):
purpose / user / use-case / architecture / stack / entry /
contract / flow / invariant / constraint / convention
- Omit
milestone — onboard makes no plans.
- Details >15 lines (schemas, algorithms, protocol states) go to
docs/specs/<topic>.md.
- Keep declarations atomic (≤25 words/sentence) with structured lists/tables; no text walls.
- Confirm with user.
docs/tech-spec.md must contain: stack + at least one contract + at least one convention (covering quality baseline — lint/format/typecheck tools, error-handling, security — read from code; see ../references/quality.md) before done.
Don't
- Invent facts not found in code or README.
- Add gap analysis, temporal/historical narratives, plans, or code changes.
- Paste large code blocks or schemas — reference by path or modularize into
docs/specs/.
After
docs/tech-spec.md on disk → user continues with normal design → plan → tdd.
1---2name: onboard3description: Use when taking over an existing codebase that has no living document. Produces a factual record of what already exists.4---5# Onboard67Goal: read the codebase, produce living documentation. No code changes. No plans. No gap analysis.89## living documentation1011- `README.md` : project overview, what it is, who it's for, how to use it.12- `docs/tech-spec.md` : main technical specification (core backbone, ≤300 lines).13- `docs/specs/*.md` : modular subsystem details split out when bulky (>15 lines). Referenced by path.1415Technical specification is declarations only: current ground truth facts (atemporal, no narrative, no history, no plans).1617## Steps18191. **Explore** entry points, public interfaces, key dependencies, test patterns, file structure. Read, don't guess.202. **Ask the user** about anything ambiguous — never invent architecture.213. **Write** `docs/tech-spec.md` using the canonical format (field meanings: `archive` skill, "tech-spec format"):2223```24purpose / user / use-case / architecture / stack / entry /25contract / flow / invariant / constraint / convention26```2728 - Omit `milestone` — onboard makes no plans.29 - Details >15 lines (schemas, algorithms, protocol states) go to `docs/specs/<topic>.md`.30 - Keep declarations atomic (≤25 words/sentence) with structured lists/tables; no text walls.31324. **Confirm** with user.3334<gate>`docs/tech-spec.md` must contain: `stack` + at least one `contract` + at least one `convention` (covering quality baseline — lint/format/typecheck tools, error-handling, security — read from code; see `../references/quality.md`) before done.</gate>3536## Don't37- Invent facts not found in code or README.38- Add gap analysis, temporal/historical narratives, plans, or code changes.39- Paste large code blocks or schemas — reference by path or modularize into `docs/specs/`.4041## After42`docs/tech-spec.md` on disk → user continues with normal `design → plan → tdd`.
hashgraph-online