@evolvehq/docflow 0.4.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,165 @@
1
+ # Conventions
2
+
3
+ ## Project
4
+
5
+ Project name: <name>.
6
+
7
+ <!-- Q1 language: if a language mandate is set, state it here.
8
+ Example: "Language: en-GB throughout. Use forms such as organisation,
9
+ behaviour, prioritise, catalogue, authorisation consistently across all
10
+ files." -->
11
+
12
+ ## ADR Files
13
+
14
+ ADR filenames use `NNNN-kebab-case-slug.md`, zero-padded to 4 digits,
15
+ with contiguous numbering and no reserved gaps.
16
+
17
+ Each ADR describes one decision. If a decision splits, supersede the
18
+ original ADR and create new ADRs rather than expanding scope inside a
19
+ single document.
20
+
21
+ Status lifecycle: `<from Q3>`.
22
+
23
+ | Status | Meaning |
24
+ |---|---|
25
+ | Proposed | Draft. Decision authored but not yet approved. |
26
+ | Accepted | Decision approved; implementation authorised. Work item lives in `plan/todo/`. |
27
+ | Implemented | Code shipped per Q4 completion event. Work item moved to `plan/done/`. ADR is the authoritative spec the running system matches. |
28
+ | Superseded | Replaced by another ADR. The successor is named in `superseded-by:` metadata. |
29
+ | Deprecated | Was real; the world moved on; no successor. Capability is not being rebuilt. |
30
+
31
+ Terminal states (Superseded / Deprecated) are reachable from any prior
32
+ state.
33
+
34
+ Cross-references link by relative path to `adr/NNNN-*.md`.
35
+
36
+ ## ADR Shapes
37
+
38
+ <!-- Single shape (Q2): -->
39
+ This project uses a single ADR shape. ADRs use `adr/0000-template.md`
40
+ and contain these sections in order: Context, Capability statement,
41
+ User stories / scenarios, Acceptance criteria, Out of scope, Open
42
+ questions, References, Revision History, Approvals.
43
+
44
+ <!-- Split (Q2): -->
45
+ <!--
46
+ Capability ADRs (`0001`-`NNNN`) describe what the system must do. They
47
+ use `adr/0000-template.md` with sections: Context, Capability
48
+ statement, User stories / scenarios, Acceptance criteria, Out of
49
+ scope, Open questions, References, Revision History, Approvals.
50
+
51
+ Technology ADRs (`NNNN+1` onwards) describe how the system is built.
52
+ They use `adr/NNNN-template.md` with sections: Context, Decision,
53
+ Rationale, Consequences, Acceptance criteria, Out of scope, Open
54
+ questions, References, Revision History, Approvals.
55
+
56
+ Technology ADR Rationale must name alternatives considered and give
57
+ specific reasons they were rejected. Generic rationale such as
58
+ "simpler" or "more idiomatic" is not sufficient.
59
+ -->
60
+
61
+ <!-- Q10 domain-specific rules go here, each as its own section.
62
+ Examples:
63
+ ## Vendor Name Rule
64
+ ## Audit-Plane Distinction
65
+ ## Regulated Evidence
66
+ ## Mandatory user-story personas
67
+ -->
68
+
69
+ ## ADR Privacy
70
+
71
+ ADRs are internal artefacts. ADR numbers, ADR titles, and the
72
+ existence of the ADR catalogue must never appear in any string the
73
+ product emits to users: UI copy, API response bodies, error messages,
74
+ customer-visible log lines, public documentation, release notes,
75
+ marketing copy, or support communications.
76
+
77
+ Allowed references:
78
+ - Inline code comments tying a non-obvious choice to its ADR
79
+ (`// see adr/0042-foo.md`).
80
+ - Commit messages and PR descriptions.
81
+ - Internal documents: `AGENTS.md`, `INDEX.md`, the `plan/` queue,
82
+ `_agent/` files, internal runbooks.
83
+
84
+ Rule of thumb: if a non-builder could ever read the string, the ADR
85
+ reference comes out. Refer to the behaviour by its product-level name
86
+ instead.
87
+
88
+ ## Multi-Agent Rules
89
+
90
+ <!-- Mode 1 — single agent. Keep this line, drop the alternatives. -->
91
+ A single agent owns this repo. The `_agent/` directory tracks live
92
+ state and history; no LOCKS discipline.
93
+
94
+ <!-- Mode 2 — multi-agent, shared checkout. Replace with:
95
+ Work is partitioned across named agents (see `_agent/ROLES.md`).
96
+ Claim a file in `_agent/LOCKS.md` before editing; remove the line on
97
+ commit. Append to `_agent/WORKLOG.md` on commit.
98
+ `_agent/CURRENT_FOCUS.md` is the single in-flight snapshot.
99
+ Regenerate `INDEX.md` after any ADR status change or new ADR.
100
+ -->
101
+
102
+ <!-- Mode 3 — multi-agent, separate worktrees / PR branches. Replace
103
+ with:
104
+ Work is partitioned across named agents (see `_agent/ROLES.md`).
105
+ Each agent works in its own worktree / PR branch.
106
+ - GitHub draft PRs are the authoritative lock; `_agent/LOCKS.md` is
107
+ advisory only.
108
+ - `_agent/WORKLOG.md` is `merge=union` (see `.gitattributes`);
109
+ append on every commit.
110
+ - `_agent/CURRENT_FOCUS.md` is gitignored (local-only per worktree);
111
+ the committed cross-worktree dashboard is `_agent/IN_FLIGHT.md` —
112
+ one row per active worktree.
113
+ - Regenerate `INDEX.md` after any ADR status change or new ADR.
114
+ -->
115
+
116
+ ## Plan Folder
117
+
118
+ Pending and shipped work live in `plan/` at the repository root:
119
+
120
+ - `plan/todo/NNNN-<slug>.md` — pending work, lower numbers run first.
121
+ Each file names the owning ADR(s), scope, and exit criteria.
122
+ - `plan/done/<YYYY-MM-DD>-<slug>.md` — shipped work, chronological. A
123
+ `git mv` from `todo/` to `done/` is the completion event.
124
+
125
+ The completion event is: `<from Q4>`.
126
+
127
+ When a `plan/todo/` item ships, the file moves to `plan/done/` AND the
128
+ owning ADR(s)' `status:` advances from `Accepted` to `Implemented`.
129
+ `INDEX.md` is regenerated to match.
130
+
131
+ ## Audit Trail Policy
132
+
133
+ Every substantive change to an Accepted ADR appends a new row to its
134
+ Revision History table.
135
+
136
+ Editorial changes — typos, formatting, link fixes — are excluded from
137
+ Revision History but must be flagged "editorial" in the commit message.
138
+
139
+ The Approvals table is populated when an ADR transitions to Accepted
140
+ and updated on every subsequent substantive revision.
141
+
142
+ ## Git Contract
143
+
144
+ Commit messages follow Conventional Commits with a mandatory
145
+ `Rationale:` footer for any commit that touches an ADR.
146
+
147
+ <!-- Per Q6:
148
+ - Signed commits: <yes/no>
149
+ - ADR-revision tags `adr-NNNN-rN`: <yes/no>
150
+ - Co-Authored-By trailer on agent commits: <yes/no>
151
+ -->
152
+
153
+ <!-- Integration model per Q4b — keep one paragraph.
154
+
155
+ Direct-to-main:
156
+ Changes are fast-forwarded onto `main`; no merge commits. The verify
157
+ gate runs locally and must pass before push. A change is "shipped"
158
+ when it is on `main` and pushed.
159
+
160
+ PR-based:
161
+ Every change ships via a pull request with required CI. The verify
162
+ gate runs in CI on the PR. Merge strategy is <squash | merge |
163
+ rebase>. A change is "shipped" when its PR is merged to `main` with
164
+ CI green.
165
+ -->
@@ -0,0 +1,32 @@
1
+ # Current Focus
2
+
3
+ This file is the LIVE SNAPSHOT of any in-flight session. It is short on
4
+ purpose — the durable record lives in git (`git log`),
5
+ `_agent/WORKLOG.md`, and `plan/done/`. The queued work lives in
6
+ `plan/todo/`.
7
+
8
+ <!-- Mode 3 (worktree) note — the skill adds this file to
9
+ `.gitignore` and leaves this comment in place:
10
+
11
+ Under separate-worktree mode, this file is gitignored and stays local
12
+ to each worktree. The cross-worktree dashboard is `_agent/IN_FLIGHT.md`
13
+ (committed). Update freely; this file never merges.
14
+ -->
15
+
16
+ If status files and git disagree, git is authoritative; correct this
17
+ file.
18
+
19
+ ## Active state
20
+
21
+ - **Branch:** main
22
+ - **Active item:** none — no work in flight.
23
+ - **Blockers:** none.
24
+ - **Uncommitted work:** none.
25
+
26
+ ## Last shipped
27
+
28
+ <commit-sha> — <one-line description>.
29
+
30
+ ## Next item
31
+
32
+ `ls plan/todo/` for the queue; the lowest-numbered file runs next.
@@ -0,0 +1,28 @@
1
+ # Handoff
2
+
3
+ Entry point for a fresh agent picking up this repo. Read these files
4
+ in order before any tool calls:
5
+
6
+ 1. `AGENTS.md` — hard rules. Read in full.
7
+ 2. `CONVENTIONS.md` — authoring rules + ADR status semantics + plan
8
+ folder convention.
9
+ 3. `plan/README.md` — the queue's own README.
10
+ 4. `_agent/CURRENT_FOCUS.md` — short live snapshot of any in-flight
11
+ session: active branch, active queue item, blockers, uncommitted
12
+ work.
13
+ 5. `INDEX.md` — the ADR catalogue. Look up an ADR's filename and
14
+ dependency chain. Sorted by ADR number, not by work order.
15
+ 6. Tail of `_agent/WORKLOG.md` (last 30 lines) — confirms what landed.
16
+ 7. The next queue item at `plan/todo/NNNN-*.md` — and the ADR(s) it
17
+ names — read in full before implementing.
18
+
19
+ ## Stop conditions
20
+
21
+ Stop and surface the issue rather than guessing if:
22
+
23
+ - The verify gate fails.
24
+ - The queue is empty.
25
+ - A `plan/todo/` item references an ADR whose status is not Accepted.
26
+ - An ADR's acceptance criteria are ambiguous or untestable as written.
27
+ - Two `plan/todo/` items at the same priority both target the same
28
+ files (lock contention).
@@ -0,0 +1,16 @@
1
+ # In Flight
2
+
3
+ Cross-worktree dashboard. One row per active worktree. Updated by the
4
+ agent owning the worktree when it opens, and removed when the worktree
5
+ closes (PR merged or abandoned).
6
+
7
+ Useful when several agents work in separate worktrees / PR branches —
8
+ this file replaces the single-checkout `_agent/CURRENT_FOCUS.md` as
9
+ the shared "what's happening right now" view. `CURRENT_FOCUS.md` is
10
+ gitignored under this mode and stays local to each worktree.
11
+
12
+ If this file disagrees with reality, reality wins — check
13
+ `git worktree list` and the live PRs, then correct here.
14
+
15
+ | Agent | Worktree branch | Queue item | Started (ISO-8601) | PR link |
16
+ |-------|-----------------|------------|---------------------|---------|
@@ -0,0 +1,17 @@
1
+ # Agent Locks
2
+
3
+ Append a row before editing a file. Remove the row on commit.
4
+
5
+ Format: `<agent-id> | <path> | <ISO-8601 timestamp>`
6
+
7
+ <!-- Mode 3 (worktree) advisory header — the skill leaves this in
8
+ place when Q5 selected separate-worktrees mode:
9
+
10
+ **Advisory only under separate-worktree mode.** GitHub draft PRs and
11
+ branch assignment are the authoritative lock; LOCKS rows are an
12
+ intent declaration to help coordinate before a PR exists. Do not
13
+ rely on this file as a filesystem mutex — the filesystem can't
14
+ conflict across worktrees in the first place.
15
+ -->
16
+
17
+ ---
@@ -0,0 +1,23 @@
1
+ # Agent Roles
2
+
3
+ <!-- Single agent (Q5 default): -->
4
+ ## default-agent
5
+
6
+ The default agent owns all ADRs and implementation work until the
7
+ project splits into named domains.
8
+
9
+ <!-- Multi-agent — replace the block above with one section per agent.
10
+ Example:
11
+
12
+ ## frontend-agent
13
+ The frontend agent owns UI, components, design tokens, and front-end
14
+ build pipeline ADRs.
15
+
16
+ ## backend-agent
17
+ The backend agent owns API surface, data model, persistence, and
18
+ backend infrastructure ADRs.
19
+
20
+ ## docs-agent
21
+ The docs agent owns README, GLOSSARY, INDEX regeneration, and external
22
+ documentation outputs.
23
+ -->
@@ -0,0 +1,16 @@
1
+ # Agent Worklog
2
+
3
+ Append one row per commit. Newest at the bottom.
4
+
5
+ <!-- Mode 3 (worktree) note — the skill leaves this comment in place
6
+ when Q5 selected separate-worktrees mode:
7
+
8
+ This file uses `merge=union` via the repo's `.gitattributes` so
9
+ concurrent appends from multiple worktrees concatenate cleanly rather
10
+ than conflicting. Row ordering reflects merge order, not commit order
11
+ — include the commit SHA in the row so the true sequence is
12
+ recoverable.
13
+ -->
14
+
15
+ | Date | Commit | Branch | Item | Notes |
16
+ |------|--------|--------|------|-------|
@@ -0,0 +1,100 @@
1
+ # Autonomous-completion prompt
2
+
3
+ You are this project's autonomous agent. Your task: drive the
4
+ implementation queue in `plan/todo/` to completion, unsupervised,
5
+ committing per-item with the verify gate green, until the queue is
6
+ empty or a documented stop condition fires.
7
+
8
+ ## Step 1 — Orient
9
+
10
+ Read these files IN ORDER, in full, before any tool calls:
11
+
12
+ 1. `AGENTS.md` — hard rules.
13
+ 2. `CONVENTIONS.md` — authoring rules + ADR status semantics + plan
14
+ folder convention.
15
+ 3. `plan/README.md` — the queue convention.
16
+ 4. `_agent/CURRENT_FOCUS.md` — live session snapshot.
17
+ 5. `INDEX.md` — ADR catalogue.
18
+ 6. Tail of `_agent/WORKLOG.md` (last 30 lines).
19
+ 7. The queue item file at `plan/todo/NNNN-*.md` you are about to work,
20
+ and the ADR(s) it names.
21
+
22
+ ## Step 2 — Pick the next item
23
+
24
+ `ls plan/todo/` and pick the lowest-numbered file (priority order).
25
+
26
+ ## Step 3 — Implement
27
+
28
+ Implement against the ADR's numbered acceptance criteria. Add or
29
+ update tests that map back to those criteria.
30
+
31
+ ## Step 4 — Verify
32
+
33
+ Run the project's verify gate: `<command from Q8>`.
34
+
35
+ Do not proceed if the gate fails. Surface the failure, fix the root
36
+ cause, re-run. Do not bypass with `--no-verify` or equivalent.
37
+
38
+ ## Step 5 — Commit
39
+
40
+ Conventional Commits per `AGENTS.md` §Git contract. `Rationale:`
41
+ footer required on any commit touching an ADR.
42
+
43
+ ## Step 6 — Integrate
44
+
45
+ <!-- Integration model per Q4b — keep ONE of the two blocks below,
46
+ delete the other. -->
47
+
48
+ <!-- Direct-to-main (fast-forward only). Keep this block for mode 1 /
49
+ direct-to-main projects:
50
+
51
+ - Fast-forward the work branch onto `main`:
52
+ `git merge --ff-only <work-branch>` (or commit directly on `main`
53
+ if that is the project's flow).
54
+ - Push: `git push origin main`.
55
+ - The verify gate has already passed locally (Step 4); no CI wait.
56
+ -->
57
+
58
+ <!-- PR-based (required CI green). Keep this block for mode 2/3 /
59
+ PR-based projects:
60
+
61
+ - Push the work branch: `git push -u origin <work-branch>`.
62
+ - Open a draft PR: `gh pr create --draft --fill`.
63
+ - Wait for CI: `gh pr checks --watch`. The verify gate runs in CI;
64
+ do not proceed until it is green.
65
+ - Mark ready: `gh pr ready`.
66
+ - Merge with the project's strategy:
67
+ `gh pr merge --squash --auto` (or `--merge` / `--rebase`).
68
+ - Confirm the merge landed on `main` before treating the item as
69
+ shipped.
70
+ -->
71
+
72
+ ## Step 7 — Ship the queue item
73
+
74
+ Once the change is on `main` (fast-forwarded or PR-merged):
75
+
76
+ - `git mv plan/todo/NNNN-<slug>.md plan/done/<YYYY-MM-DD>-<slug>.md`.
77
+ - Amend the moved file with a "Shipped at HEAD `<sha>`" footer (and
78
+ any artefact id, image tag, deploy id, PR link).
79
+ - Advance the owning ADR(s)' `status:` from `Accepted` to
80
+ `Implemented`; regenerate `INDEX.md`.
81
+
82
+ ## Step 8 — Record
83
+
84
+ - Append a one-line `_agent/WORKLOG.md` entry naming the branch, the
85
+ HEAD, the verify result, any deferral.
86
+ - Update `_agent/CURRENT_FOCUS.md` so the slim live snapshot reads
87
+ the new state. (In worktree mode this file is local-only; update
88
+ `_agent/IN_FLIGHT.md` to remove your worktree's row instead.)
89
+
90
+ ## Stop conditions
91
+
92
+ - Verify gate fails and the cause is not understood.
93
+ - Queue empty.
94
+ - A queue item references an ADR whose status is not Accepted.
95
+ - Acceptance criteria are ambiguous or untestable as written.
96
+ - Lock contention on the same files between two same-priority items.
97
+
98
+ When a stop condition fires, stop cleanly: leave the repo in a
99
+ committed state, record the reason in `_agent/CURRENT_FOCUS.md`, and
100
+ surface to the human.
@@ -0,0 +1,58 @@
1
+ ---
2
+ adr: NNNN
3
+ title: <Title in sentence case>
4
+ status: Proposed
5
+ date: YYYY-MM-DD
6
+ owner: <agent-id or human>
7
+ supersedes:
8
+ superseded-by:
9
+ depends-on: []
10
+ tags: []
11
+ ---
12
+
13
+ # ADR NNNN — <Title>
14
+
15
+ ## Context
16
+
17
+ <Why this decision exists. Forces at play. What problem are we solving
18
+ and what constraints shape the answer.>
19
+
20
+ ## Capability statement
21
+
22
+ <One paragraph. What the system must do. Stated as capability, not
23
+ implementation.>
24
+
25
+ ## User stories / scenarios
26
+
27
+ - As a <role>, I want <capability>, so that <outcome>.
28
+ - As a <role>, I want <capability>, so that <outcome>.
29
+
30
+ ## Acceptance criteria
31
+
32
+ 1. <Testable, observable criterion.>
33
+ 2. <Testable, observable criterion.>
34
+ 3. ...
35
+
36
+ ## Out of scope
37
+
38
+ - <Explicit non-goals — what this ADR does not cover.>
39
+
40
+ ## Open questions
41
+
42
+ - <Unresolved items. Empty when ADR transitions to Accepted.>
43
+
44
+ ## References / cross-links
45
+
46
+ - adr/NNNN-<other>.md
47
+ - <External links, specs, prior art.>
48
+
49
+ ## Revision History
50
+
51
+ | Date | Revision | Author | Change |
52
+ |------|----------|--------|--------|
53
+ | YYYY-MM-DD | r1 | <id> | Initial draft. |
54
+
55
+ ## Approvals
56
+
57
+ | Role | Name | Date | Signature |
58
+ |------|------|------|-----------|
@@ -0,0 +1,67 @@
1
+ ---
2
+ adr: NNNN
3
+ title: <Title in sentence case>
4
+ status: Proposed
5
+ date: YYYY-MM-DD
6
+ owner: <agent-id or human>
7
+ supersedes:
8
+ superseded-by:
9
+ depends-on: []
10
+ tags: []
11
+ ---
12
+
13
+ # ADR NNNN — <Title>
14
+
15
+ ## Context
16
+
17
+ <Why this decision exists. Constraints, forces, and the surface area of
18
+ the choice.>
19
+
20
+ ## Decision
21
+
22
+ <One paragraph stating the choice in plain terms. What is being adopted
23
+ and at what scope.>
24
+
25
+ ## Rationale
26
+
27
+ <Why this choice over the alternatives. List alternatives considered
28
+ with specific rejection reasons. Generic rationale ("simpler", "more
29
+ idiomatic") is not sufficient.>
30
+
31
+ - Alternative A — rejected because <specific reason>.
32
+ - Alternative B — rejected because <specific reason>.
33
+
34
+ ## Consequences
35
+
36
+ - Positive: <what this enables.>
37
+ - Negative: <what this costs or constrains.>
38
+ - Follow-up work implied by this decision: <list.>
39
+
40
+ ## Acceptance criteria
41
+
42
+ 1. <Testable criterion that confirms the decision is in effect.>
43
+ 2. ...
44
+
45
+ ## Out of scope
46
+
47
+ - <What this ADR deliberately does not decide.>
48
+
49
+ ## Open questions
50
+
51
+ - <Unresolved items. Empty when ADR transitions to Accepted.>
52
+
53
+ ## References
54
+
55
+ - adr/NNNN-<other>.md
56
+ - <External specs, RFCs, vendor docs.>
57
+
58
+ ## Revision History
59
+
60
+ | Date | Revision | Author | Change |
61
+ |------|----------|--------|--------|
62
+ | YYYY-MM-DD | r1 | <id> | Initial draft. |
63
+
64
+ ## Approvals
65
+
66
+ | Role | Name | Date | Signature |
67
+ |------|------|------|-----------|
@@ -0,0 +1,37 @@
1
+ # Plan
2
+
3
+ This folder holds the project's implementation queue — one file per
4
+ unit of work. The queue mirrors the ADR catalogue (`INDEX.md`) but
5
+ tracks the human ordering of work, not the ADR catalogue ordering.
6
+
7
+ ## Layout
8
+
9
+ - `plan/todo/NNNN-<slug>.md` — pending work, ordered by priority
10
+ (lower numbers run first). Each file names the owning ADR(s), the
11
+ scope, the exit criteria, and any dependencies.
12
+ - `plan/done/<YYYY-MM-DD>-<slug>.md` — shipped work, ordered
13
+ chronologically. The `git mv` from `todo/` to `done/` is the
14
+ completion event; the file's body is amended with a "Shipped"
15
+ footer naming the HEAD SHA and any artefact id.
16
+
17
+ ## Convention
18
+
19
+ - A pending item gets a `plan/todo/` file BEFORE work starts.
20
+ - When work ships, the file is `git mv`'d to `plan/done/` with a new
21
+ date prefix and the body amended with the shipped footer.
22
+ - A small fix that doesn't justify a plan file (a typo, a one-line
23
+ tweak, a dependency bump) skips the ceremony. Use judgement.
24
+ - The status of the owning ADR(s) advances when the work ships:
25
+ `Accepted` → `Implemented`.
26
+
27
+ ## Status semantics on the owning ADRs
28
+
29
+ | ADR status | Meaning |
30
+ |---|---|
31
+ | Proposed | Draft; decision authored but not yet approved. |
32
+ | Accepted | Decision approved; implementation authorised. Sits in `plan/todo/`. |
33
+ | Implemented | Shipped per the project's completion event. Sits in `plan/done/`. |
34
+ | Superseded | Replaced by another ADR (named in `superseded-by:`). |
35
+ | Deprecated | Was real; the world moved on; no successor. |
36
+
37
+ See `CONVENTIONS.md` §Status lifecycle for the canonical definition.
@@ -0,0 +1,56 @@
1
+ ---
2
+ name: brainstorm
3
+ description: Decompose a problem, feature, or goal into candidate ADRs and plan items for a documentation-led repo — one decision per ADR, dependency edges, suggested ordering. Proposes drafts for review and writes nothing until approved. Use when the user says "brainstorm ADRs", "break this down into decisions", "what ADRs do we need for X", "plan out the work", or invokes /brainstorm.
4
+ ---
5
+
6
+ # brainstorm
7
+
8
+ Turn a fuzzy problem into a structured set of candidate ADRs and plan
9
+ items. This skill is **generative and read/propose-only** — it never
10
+ writes ADRs or plan files directly. On approval it hands each candidate
11
+ to the **new-adr** and **new-plan** skills.
12
+
13
+ ## Step 0 — Preconditions and context
14
+
15
+ 1. Confirm the repo is bootstrapped (or note that the output can seed a
16
+ fresh run of the **bootstrap** skill).
17
+ 2. Read `CONVENTIONS.md` for ADR shape and lifecycle, and skim
18
+ `INDEX.md` + existing ADRs so candidates don't duplicate or
19
+ contradict what already exists, and so dependencies point at real
20
+ ADRs.
21
+
22
+ ## Step 1 — Understand the problem
23
+
24
+ Ask for the goal/feature/problem if not given. Probe for scope
25
+ boundaries, constraints, and the regulatory/quality concerns that
26
+ matter for this repo. Do not start decomposing until the goal is clear.
27
+
28
+ ## Step 2 — Decompose
29
+
30
+ Produce a candidate list. For each candidate ADR:
31
+ - Proposed number (next available, contiguous), working title, shape
32
+ (capability vs. technology if the repo splits).
33
+ - One-line scope — the single decision it captures.
34
+ - Dependencies on other candidates or existing ADRs.
35
+
36
+ **One decision per ADR.** If a candidate bundles several decisions,
37
+ split it and say why. If a candidate is really an existing ADR needing
38
+ revision, say that instead of proposing a new number.
39
+
40
+ ## Step 3 — Order the work
41
+
42
+ Propose a plan ordering (which `plan/todo/` items, in what sequence)
43
+ respecting the dependency edges. Note where work can parallelise (useful
44
+ input for the **agent-wave** skill).
45
+
46
+ ## Step 4 — Review and hand off
47
+
48
+ Present the full set as a reviewable outline (candidates + dependencies
49
+ + ordering). Take edits. **Write nothing yet.** Once the user approves,
50
+ create them by invoking the **new-adr** skill per candidate and the
51
+ **new-plan** skill per
52
+ queued item — or hand the approved outline to those skills.
53
+
54
+ Guardrail: if the problem is too vague to decompose without inventing
55
+ requirements, say so and ask for more, rather than producing
56
+ speculative ADRs.