@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.
- package/LICENSE +21 -0
- package/README.md +188 -0
- package/USAGE.md +289 -0
- package/package.json +31 -0
- package/skills/add-convention/SKILL.md +61 -0
- package/skills/agent-wave/SKILL.md +89 -0
- package/skills/audit/SKILL.md +65 -0
- package/skills/bootstrap/SKILL.md +347 -0
- package/skills/bootstrap/templates/AGENTS.md +157 -0
- package/skills/bootstrap/templates/CLAUDE.md +1 -0
- package/skills/bootstrap/templates/CONVENTIONS.md +165 -0
- package/skills/bootstrap/templates/_agent-CURRENT_FOCUS.md +32 -0
- package/skills/bootstrap/templates/_agent-HANDOFF.md +28 -0
- package/skills/bootstrap/templates/_agent-IN_FLIGHT.md +16 -0
- package/skills/bootstrap/templates/_agent-LOCKS.md +17 -0
- package/skills/bootstrap/templates/_agent-ROLES.md +23 -0
- package/skills/bootstrap/templates/_agent-WORKLOG.md +16 -0
- package/skills/bootstrap/templates/_agent-prompts-autonomous.md +100 -0
- package/skills/bootstrap/templates/adr-capability.md +58 -0
- package/skills/bootstrap/templates/adr-technology.md +67 -0
- package/skills/bootstrap/templates/plan-README.md +37 -0
- package/skills/brainstorm/SKILL.md +56 -0
- package/skills/new-adr/SKILL.md +82 -0
- package/skills/new-plan/SKILL.md +47 -0
- package/skills/ship-item/SKILL.md +66 -0
|
@@ -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.
|