@evolvehq/docflow 0.7.1 → 0.9.0
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/README.md +49 -30
- package/USAGE.md +10 -9
- package/package.json +3 -3
- package/plugins/docflow/skills/add-convention/agents/openai.yaml +4 -0
- package/plugins/docflow/skills/agent-wave/agents/openai.yaml +4 -0
- package/{skills → plugins/docflow/skills}/audit/SKILL.md +22 -1
- package/plugins/docflow/skills/audit/agents/openai.yaml +4 -0
- package/{skills → plugins/docflow/skills}/bootstrap/SKILL.md +65 -3
- package/plugins/docflow/skills/bootstrap/agents/openai.yaml +4 -0
- package/{skills → plugins/docflow/skills}/bootstrap/templates/CONVENTIONS.md +26 -0
- package/plugins/docflow/skills/bootstrap/templates/federation-config.md +17 -0
- package/plugins/docflow/skills/bootstrap/templates/federation-index.md +17 -0
- package/plugins/docflow/skills/brainstorm/agents/openai.yaml +4 -0
- package/{skills → plugins/docflow/skills}/new-adr/SKILL.md +11 -0
- package/plugins/docflow/skills/new-adr/agents/openai.yaml +4 -0
- package/plugins/docflow/skills/new-plan/agents/openai.yaml +4 -0
- package/plugins/docflow/skills/rollup/SKILL.md +65 -0
- package/plugins/docflow/skills/rollup/agents/openai.yaml +4 -0
- package/plugins/docflow/skills/ship-item/agents/openai.yaml +4 -0
- /package/{skills → plugins/docflow/skills}/add-convention/SKILL.md +0 -0
- /package/{skills → plugins/docflow/skills}/agent-wave/SKILL.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/AGENTS.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/CLAUDE.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-CURRENT_FOCUS.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-HANDOFF.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-IN_FLIGHT.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-LOCKS.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-ROLES.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-WORKLOG.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/_agent-prompts-autonomous.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/adr-capability.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/adr-technology.md +0 -0
- /package/{skills → plugins/docflow/skills}/bootstrap/templates/plan-README.md +0 -0
- /package/{skills → plugins/docflow/skills}/brainstorm/SKILL.md +0 -0
- /package/{skills → plugins/docflow/skills}/new-plan/SKILL.md +0 -0
- /package/{skills → plugins/docflow/skills}/ship-item/SKILL.md +0 -0
package/README.md
CHANGED
|
@@ -10,7 +10,9 @@ It installs a `bootstrap` skill that scaffolds (or retrofits) an
|
|
|
10
10
|
`AGENTS.md` conventions into any repository, plus a set of **lifecycle
|
|
11
11
|
skills** that author, queue, ship, and audit ADRs — so the project can
|
|
12
12
|
be driven by both humans and coding agents from a small set of canonical
|
|
13
|
-
files.
|
|
13
|
+
files. For the formal definition of the conventions — why they help and
|
|
14
|
+
where they fall short — see the
|
|
15
|
+
[methodology](https://evolvehq.github.io/docflow/methodology/).
|
|
14
16
|
|
|
15
17
|
## Skills
|
|
16
18
|
|
|
@@ -28,6 +30,7 @@ agent the same skills are invoked as `/skill:<name>` (e.g.
|
|
|
28
30
|
| audit | `/audit` | Lint the repo against its own conventions — numbering, INDEX sync, plan coverage, **ADR-privacy leaks**, more. |
|
|
29
31
|
| brainstorm | `/brainstorm` | Decompose a problem into candidate ADRs + plan items (proposes drafts; writes nothing until approved). |
|
|
30
32
|
| agent-wave | `/agent-wave` | Orchestrate a wave of parallel worktree subagents over the queue, with checkpoint or continuous supervision. |
|
|
33
|
+
| rollup | `/rollup` | For a multi-repo product: aggregate every member repo's ADRs into one derived, product-wide roll-up (run from the home repo). |
|
|
31
34
|
|
|
32
35
|
The lifecycle skills all **read `CONVENTIONS.md` first** and honour the
|
|
33
36
|
choices the bootstrap recorded (ADR shape, status lifecycle, integration
|
|
@@ -65,10 +68,27 @@ It works equally well on **fresh repos** (scaffolds from zero) and on
|
|
|
65
68
|
**existing repos** (retrofits, preserving and merging existing files
|
|
66
69
|
rather than overwriting them).
|
|
67
70
|
|
|
71
|
+
## Multi-repo products
|
|
72
|
+
|
|
73
|
+
A single product spread across several repositories can run as a
|
|
74
|
+
**federation**. At bootstrap a repo declares whether it is standalone or
|
|
75
|
+
part of a multi-repo product, and whether it is **establishing** a new
|
|
76
|
+
federation or **joining** one — a joining repo only ever writes its own
|
|
77
|
+
back-pointer, never into another repo. You pick a **topology** (central
|
|
78
|
+
decisions repo · distributed · home-repo-plus-local), and the convention
|
|
79
|
+
set keeps numbering contiguous **per repo** while a federation-wide
|
|
80
|
+
identity is the cross-repo key. The `rollup` skill aggregates every
|
|
81
|
+
member's catalogue into one product-wide view, and `audit` gains
|
|
82
|
+
cross-repo checks (membership, identity collisions, dangling references,
|
|
83
|
+
roll-up drift). No tool writes across a repo boundary; consistency is
|
|
84
|
+
declared at the edges and enforced by audit. See the
|
|
85
|
+
[methodology](https://evolvehq.github.io/docflow/methodology/#5-scaling-to-many-repositories)
|
|
86
|
+
for the full model.
|
|
87
|
+
|
|
68
88
|
## Install
|
|
69
89
|
|
|
70
|
-
docflow ships from **one `skills/`
|
|
71
|
-
the packaging differs. Two surfaces: the scaffolded **output**
|
|
90
|
+
docflow ships from **one skill source** (`plugins/docflow/skills/`) to
|
|
91
|
+
five coding agents — only the packaging differs. Two surfaces: the scaffolded **output**
|
|
72
92
|
(`AGENTS.md`, the ADR catalogue, `plan/`, `_agent/`) is plain Markdown
|
|
73
93
|
read natively by any agent that loads `AGENTS.md`; the **skills** are
|
|
74
94
|
`SKILL.md` files the host discovers.
|
|
@@ -108,7 +128,7 @@ pi install git:github.com/EvolveHQ/docflow
|
|
|
108
128
|
```
|
|
109
129
|
|
|
110
130
|
or, once published to npm, `pi install npm:@evolvehq/docflow`. Pi
|
|
111
|
-
auto-discovers the
|
|
131
|
+
auto-discovers the skills via the `pi.skills` key in
|
|
112
132
|
`package.json`. Invoke with `/skill:bootstrap`, `/skill:new-adr`,
|
|
113
133
|
`/skill:ship-item`, … Pi does **not** auto-trigger skills from their
|
|
114
134
|
descriptions the way Claude Code does — invoke them explicitly (the
|
|
@@ -125,7 +145,7 @@ install from this repo's marketplace:
|
|
|
125
145
|
|
|
126
146
|
```
|
|
127
147
|
codex plugin marketplace add EvolveHQ/docflow
|
|
128
|
-
codex plugin
|
|
148
|
+
codex plugin add docflow@evolvehq
|
|
129
149
|
```
|
|
130
150
|
|
|
131
151
|
Codex reads the scaffolded `AGENTS.md` natively. Invoke with `$bootstrap`
|
|
@@ -144,7 +164,7 @@ OpenCode's global directory (one command, stays in sync with the clone):
|
|
|
144
164
|
|
|
145
165
|
```
|
|
146
166
|
git clone https://github.com/EvolveHQ/docflow ~/.docflow-src
|
|
147
|
-
ln -s ~/.docflow-src/skills/* ~/.config/opencode/skills/
|
|
167
|
+
ln -s ~/.docflow-src/plugins/docflow/skills/* ~/.config/opencode/skills/
|
|
148
168
|
```
|
|
149
169
|
|
|
150
170
|
OpenCode has no marketplace command for `SKILL.md` skills (its plugin
|
|
@@ -160,12 +180,12 @@ claude --plugin-dir <path-to-this-repo>
|
|
|
160
180
|
### Direct skill clone (no plugin lifecycle)
|
|
161
181
|
|
|
162
182
|
```
|
|
163
|
-
git clone https://github.com/EvolveHQ/docflow ~/.
|
|
164
|
-
ln -s ~/.
|
|
183
|
+
git clone https://github.com/EvolveHQ/docflow ~/.docflow-src
|
|
184
|
+
ln -s ~/.docflow-src/plugins/docflow/skills/* ~/.claude/skills/
|
|
165
185
|
```
|
|
166
186
|
|
|
167
|
-
On Windows, copy `skills
|
|
168
|
-
|
|
187
|
+
On Windows, copy `plugins\docflow\skills\*` into
|
|
188
|
+
`%USERPROFILE%\.claude\skills\` instead of symlinking.
|
|
169
189
|
|
|
170
190
|
## Quick start
|
|
171
191
|
|
|
@@ -214,30 +234,29 @@ to extend or override the templates.
|
|
|
214
234
|
|
|
215
235
|
```
|
|
216
236
|
docflow/
|
|
217
|
-
.claude-plugin/
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
plugin.json
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
SKILL.md
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
agent-wave/SKILL.md
|
|
237
|
+
.claude-plugin/marketplace.json # Claude Code / Cowork marketplace (-> ./plugins/docflow)
|
|
238
|
+
.agents/plugins/marketplace.json # Codex marketplace (-> ./plugins/docflow)
|
|
239
|
+
package.json # pi manifest (pi.skills -> ./plugins/docflow/skills) + npm
|
|
240
|
+
plugins/docflow/ # the plugin — one source, every target
|
|
241
|
+
.claude-plugin/plugin.json # Claude Code / Cowork plugin manifest
|
|
242
|
+
.codex-plugin/plugin.json # Codex plugin manifest (skills -> ./skills)
|
|
243
|
+
skills/ # the one skill source
|
|
244
|
+
bootstrap/
|
|
245
|
+
SKILL.md # bootstrap: assessment + output sequence + backfill
|
|
246
|
+
templates/ # files the bootstrap reads and writes into target repos
|
|
247
|
+
new-adr/SKILL.md # lifecycle skills — operate on a bootstrapped repo,
|
|
248
|
+
new-plan/SKILL.md # read CONVENTIONS.md, honour its choices
|
|
249
|
+
ship-item/SKILL.md
|
|
250
|
+
add-convention/SKILL.md
|
|
251
|
+
audit/SKILL.md
|
|
252
|
+
brainstorm/SKILL.md
|
|
253
|
+
agent-wave/SKILL.md
|
|
254
|
+
rollup/SKILL.md
|
|
236
255
|
README.md
|
|
237
256
|
USAGE.md
|
|
238
257
|
```
|
|
239
258
|
|
|
240
|
-
Only the `bootstrap` skill uses `skills/bootstrap/templates/`. The
|
|
259
|
+
Only the `bootstrap` skill uses `plugins/docflow/skills/bootstrap/templates/`. The
|
|
241
260
|
lifecycle skills act on the copies the bootstrap wrote into the target
|
|
242
261
|
repo (e.g. its `adr/0000-template.md`), so they carry no templates of
|
|
243
262
|
their own.
|
package/USAGE.md
CHANGED
|
@@ -7,7 +7,8 @@ skills are covered in §5a.
|
|
|
7
7
|
|
|
8
8
|
## Install (per platform)
|
|
9
9
|
|
|
10
|
-
docflow runs from **one `skills/`
|
|
10
|
+
docflow runs from **one skill source** (`plugins/docflow/skills/`) on
|
|
11
|
+
five coding agents. The
|
|
11
12
|
scaffolded **output** (`AGENTS.md`, the ADR catalogue, `plan/`, `_agent/`)
|
|
12
13
|
is plain Markdown read natively by any agent that loads `AGENTS.md`; the
|
|
13
14
|
**skills** are `SKILL.md` files the host discovers.
|
|
@@ -17,7 +18,7 @@ is plain Markdown read natively by any agent that loads `AGENTS.md`; the
|
|
|
17
18
|
| **Claude Code** | `/plugin marketplace add EvolveHQ/docflow` then `/plugin install docflow@evolvehq` | `/bootstrap` |
|
|
18
19
|
| **Claude Cowork** | the **same** Claude Code plugin (`/plugin marketplace add …`) — Cowork shares the plugin system | `/bootstrap` |
|
|
19
20
|
| **pi** | `pi install npm:@evolvehq/docflow` (or `pi install git:github.com/EvolveHQ/docflow`) | `/skill:bootstrap` |
|
|
20
|
-
| **Codex** | `codex plugin marketplace add EvolveHQ/docflow` then `codex plugin
|
|
21
|
+
| **Codex** | `codex plugin marketplace add EvolveHQ/docflow` then `codex plugin add docflow@evolvehq` (native plugin) | `$bootstrap` / `/skills` |
|
|
21
22
|
| **OpenCode** | auto-discovers `.claude`/`.agents`/`.opencode` skills (so a Claude Code / Codex install is picked up), or symlink into `~/.config/opencode/skills` | auto, by description |
|
|
22
23
|
|
|
23
24
|
Notes:
|
|
@@ -321,11 +322,11 @@ blocks up front, so G2/G3 rarely fire.)
|
|
|
321
322
|
|
|
322
323
|
The templates are deliberately small and self-contained. To customise:
|
|
323
324
|
|
|
324
|
-
- **Edit a template.** Files in `skills/bootstrap/templates/` are read
|
|
325
|
+
- **Edit a template.** Files in `plugins/docflow/skills/bootstrap/templates/` are read
|
|
325
326
|
verbatim by the `bootstrap` skill, then placeholders are filled from
|
|
326
327
|
the assessment answers. Change the template, the next bootstrap
|
|
327
328
|
reflects it.
|
|
328
|
-
- **Add a new template.** Put it in `skills/bootstrap/templates/` and
|
|
329
|
+
- **Add a new template.** Put it in `plugins/docflow/skills/bootstrap/templates/` and
|
|
329
330
|
reference it from `bootstrap/SKILL.md` §Step 5 (Output sequence).
|
|
330
331
|
- **Tighten a skill's auto-trigger.** Edit the `description:`
|
|
331
332
|
frontmatter in that skill's `SKILL.md`. Skills match user requests
|
|
@@ -333,7 +334,7 @@ The templates are deliberately small and self-contained. To customise:
|
|
|
333
334
|
scope. With several skills in one plugin, watch for trigger collision
|
|
334
335
|
(e.g. "add a convention" vs. "add an ADR") and keep descriptions
|
|
335
336
|
distinct; the slash commands are the unambiguous entry point.
|
|
336
|
-
- **Add a new lifecycle skill.** Create `skills/<name>/SKILL.md`. Follow
|
|
337
|
+
- **Add a new lifecycle skill.** Create `plugins/docflow/skills/<name>/SKILL.md`. Follow
|
|
337
338
|
the shared pattern: a Step 0 that checks the repo is bootstrapped and
|
|
338
339
|
reads `CONVENTIONS.md`, then act in a way that honours the recorded
|
|
339
340
|
choices. Lifecycle skills act on the target repo's own files (e.g. its
|
|
@@ -382,15 +383,15 @@ To remove the plugin entirely:
|
|
|
382
383
|
- **Cowork** — same as Claude Code (`/plugin marketplace update` →
|
|
383
384
|
install).
|
|
384
385
|
- **pi** — re-run `pi install npm:@evolvehq/docflow` (or the `git:` form).
|
|
385
|
-
- **Codex** — `codex plugin marketplace upgrade
|
|
386
|
-
|
|
386
|
+
- **Codex** — `codex plugin marketplace upgrade`, then re-add with
|
|
387
|
+
`codex plugin add docflow@evolvehq`.
|
|
387
388
|
- **OpenCode** — if installed via a clone/symlink, `git pull` the clone;
|
|
388
389
|
skills reload on the next session.
|
|
389
390
|
|
|
390
391
|
### As the author (you, maintaining this repo)
|
|
391
392
|
|
|
392
|
-
1. Edit a skill body (`skills/<name>/SKILL.md`), the bootstrap templates
|
|
393
|
-
(`skills/bootstrap/templates/*.md`), or supporting docs.
|
|
393
|
+
1. Edit a skill body (`plugins/docflow/skills/<name>/SKILL.md`), the bootstrap templates
|
|
394
|
+
(`plugins/docflow/skills/bootstrap/templates/*.md`), or supporting docs.
|
|
394
395
|
2. Bump the `version` field in `.claude-plugin/plugin.json` following
|
|
395
396
|
semver — patch for fixes, minor for new questions / templates,
|
|
396
397
|
major for breaking changes to the skill flow.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@evolvehq/docflow",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.9.0",
|
|
4
4
|
"description": "ADR-driven documentation workflow: scaffold an Architecture Decision Record (ADR) catalogue, a plan/ queue, and AGENTS.md conventions into any repo, then author, queue, ship, and audit ADRs with lifecycle skills. Works with the pi coding agent and Claude Code.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"pi-package",
|
|
@@ -21,7 +21,7 @@
|
|
|
21
21
|
"evals": "node evals/run.mjs"
|
|
22
22
|
},
|
|
23
23
|
"files": [
|
|
24
|
-
"skills/",
|
|
24
|
+
"plugins/docflow/skills/",
|
|
25
25
|
"docs/preview.png",
|
|
26
26
|
"README.md",
|
|
27
27
|
"USAGE.md",
|
|
@@ -31,7 +31,7 @@
|
|
|
31
31
|
"access": "public"
|
|
32
32
|
},
|
|
33
33
|
"pi": {
|
|
34
|
-
"skills": ["./skills"],
|
|
34
|
+
"skills": ["./plugins/docflow/skills"],
|
|
35
35
|
"image": "https://raw.githubusercontent.com/EvolveHQ/docflow/main/docs/preview.png"
|
|
36
36
|
}
|
|
37
37
|
}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: audit
|
|
3
|
-
description: Audit a documentation-led repo against its own conventions — contiguous ADR numbering, INDEX sync, plan/ coverage, required sections, status validity, cross-reference resolution, language mandate, ADR-privacy leaks into user-visible code,
|
|
3
|
+
description: Audit a documentation-led repo against its own conventions — contiguous ADR numbering, INDEX sync, plan/ coverage, required sections, status validity, cross-reference resolution, language mandate, ADR-privacy leaks into user-visible code, cross-worktree collisions (duplicate numbers, duplicate plan ownership, same ADR edited on two branches), and — for a multi-repo product — cross-repo federation checks (bidirectional membership, identity collisions, dangling cross-repo references, roll-up drift). Reports a punch list and offers to fix the mechanical issues. Use when the user says "audit the ADRs", "lint the conventions", "check repo consistency", "are the ADRs in sync", or invokes /audit.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# audit
|
|
@@ -15,6 +15,10 @@ This is the enforcement `AGENTS.md` cannot guarantee on its own.
|
|
|
15
15
|
cutoff, status lifecycle, integration model, multi-agent mode,
|
|
16
16
|
language mandate, optional artefacts present (GLOSSARY, domains/),
|
|
17
17
|
and any Q10 domain hard rules.
|
|
18
|
+
3. If a `federation.md` exists, this repo is part of a multi-repo
|
|
19
|
+
product. Note whether it is the **home** or a **member** and read the
|
|
20
|
+
recorded identity scheme; the cross-repo checks (check 12) run from
|
|
21
|
+
the home repo.
|
|
18
22
|
|
|
19
23
|
## Step 1 — Run the checks (read-only)
|
|
20
24
|
|
|
@@ -62,6 +66,23 @@ relevant):
|
|
|
62
66
|
more than one. A `merge=union` would concatenate them silently.
|
|
63
67
|
Cross-check against `_agent/IN_FLIGHT.md`: every collision should
|
|
64
68
|
correspond to a reservation/ownership violation recorded there.
|
|
69
|
+
12. **Cross-repo (federation) checks** — only when a `federation.md`
|
|
70
|
+
exists; run from the **home** repo. Reach each member through the
|
|
71
|
+
local checkout named in `federation-index.md`. A member not checked
|
|
72
|
+
out locally is reported **"unverified this run"** — never silently
|
|
73
|
+
passed, never a hard failure.
|
|
74
|
+
- **Bidirectional membership.** Every repo listed in the member index
|
|
75
|
+
carries a `federation.md` back-pointer to this home, and every repo
|
|
76
|
+
whose back-pointer names this home is listed in the index. Flag
|
|
77
|
+
either half-edge (in-index-without-back-pointer, or
|
|
78
|
+
points-home-but-unlisted).
|
|
79
|
+
- **Identity collisions.** No two ADRs across the federation resolve
|
|
80
|
+
to the same identity under the recorded identity scheme.
|
|
81
|
+
- **Dangling cross-repo references.** Every cross-repo link resolves
|
|
82
|
+
to a real ADR in the named member; flag a target that does not
|
|
83
|
+
exist. (Same-repo relative links are check 7.)
|
|
84
|
+
- **Roll-up drift.** The roll-up agrees with each member's `INDEX.md`
|
|
85
|
+
metadata; flag rows that are stale, missing, or extra.
|
|
65
86
|
|
|
66
87
|
## Step 2 — Report
|
|
67
88
|
|
|
@@ -53,8 +53,16 @@ questions.
|
|
|
53
53
|
CURRENT_FOCUS.md # slim live snapshot
|
|
54
54
|
HANDOFF.md # fresh-agent entry point
|
|
55
55
|
prompts/autonomous.md # only if a verify gate exists (see Q8)
|
|
56
|
+
federation.md # multi-repo only (Q11): this repo's back-pointer
|
|
57
|
+
federation-index.md # multi-repo only (Q11): member index — home repo only
|
|
56
58
|
```
|
|
57
59
|
|
|
60
|
+
For a **multi-repo product** (one product spread across several repos —
|
|
61
|
+
see Q11), two extra files appear: `federation.md`, a small back-pointer
|
|
62
|
+
every member repo carries, and `federation-index.md`, the authoritative
|
|
63
|
+
member list that lives only in the home/establishing repo. A standalone
|
|
64
|
+
repo has neither.
|
|
65
|
+
|
|
58
66
|
## Step 3 — Conventions to install
|
|
59
67
|
|
|
60
68
|
1. **ADRs are the source of truth.** One decision per ADR. Splits become
|
|
@@ -112,7 +120,7 @@ questions.
|
|
|
112
120
|
doubt, ask whether a non-builder would ever see this string — if
|
|
113
121
|
yes, the ADR reference comes out.
|
|
114
122
|
|
|
115
|
-
## Step 4 — Assessment (10 questions)
|
|
123
|
+
## Step 4 — Assessment (10 questions, plus an optional federation question)
|
|
116
124
|
|
|
117
125
|
**Ask the questions one at a time, not in a batch.** For each question,
|
|
118
126
|
state a **recommended** option (label it "Recommended") with one short
|
|
@@ -125,7 +133,7 @@ option with the literal "(Recommended)" suffix in its label. Otherwise
|
|
|
125
133
|
ask in plain text, listing options as A/B/C and naming the recommended
|
|
126
134
|
one.
|
|
127
135
|
|
|
128
|
-
After
|
|
136
|
+
After the answers are in, summarise the resulting plan in 5–10
|
|
129
137
|
lines and ask for sign-off before writing any files.
|
|
130
138
|
|
|
131
139
|
1. **Project identity.** Name, one-line description, doc language
|
|
@@ -214,6 +222,39 @@ lines and ask for sign-off before writing any files.
|
|
|
214
222
|
mandatory user-story personas, separated audit streams?
|
|
215
223
|
**Recommended: none from day one** — add later when a concrete
|
|
216
224
|
requirement appears; pre-emptive hard rules accumulate as cruft.
|
|
225
|
+
11. **Multi-repo product (optional).** Is this repo part of a product
|
|
226
|
+
that spans several repos? **Recommended: No** — most repos are
|
|
227
|
+
standalone; skip the federation setup entirely. If **yes**, two
|
|
228
|
+
sub-answers:
|
|
229
|
+
|
|
230
|
+
**Q11a — Establish or join?** Are you **establishing** a new
|
|
231
|
+
federation (this is the first repo) or **joining** an existing one?
|
|
232
|
+
|
|
233
|
+
**Q11b — Topology (establish only).** Where do product-wide
|
|
234
|
+
decisions live?
|
|
235
|
+
- **A — central decisions repo:** a dedicated repo holds all
|
|
236
|
+
product-wide decisions; code repos reference it, never duplicate.
|
|
237
|
+
- **B — distributed + federation:** each repo owns its own
|
|
238
|
+
decisions; a roll-up aggregates them.
|
|
239
|
+
- **(Recommended) C — home repo + local:** one repo is the home for
|
|
240
|
+
product-wide decisions; each repo also keeps purely-local ones.
|
|
241
|
+
|
|
242
|
+
**Q11c — Identity scheme (establish only).** How are ADRs identified
|
|
243
|
+
across the federation? **(Recommended) repo-prefixed slug**
|
|
244
|
+
`<repo-id>/NNNN-slug` — each repo keeps local contiguous numbering
|
|
245
|
+
with no central coordinator; the slug is the cross-federation key.
|
|
246
|
+
The scheme is recorded in the federation config and applied by the
|
|
247
|
+
authoring skills.
|
|
248
|
+
|
|
249
|
+
**Establish** designates this repo as the home/central repo, writes
|
|
250
|
+
the member index here, and records the topology **and identity
|
|
251
|
+
scheme** in the federation config. **Join** asks for the home pointer — **you confirm it; the
|
|
252
|
+
skill performs no cross-repo read and no host API call** — then
|
|
253
|
+
writes **only this repo's** back-pointer config and inherits the
|
|
254
|
+
topology without re-asking it. Joining never writes into any other
|
|
255
|
+
repo; adding this repo to the member index is a deliberate edit in
|
|
256
|
+
the home repo. A standalone repo (Q11 = No) writes none of these
|
|
257
|
+
files and behaves exactly as a single-repo bootstrap.
|
|
217
258
|
|
|
218
259
|
## Step 4.5 — Cross-check before sign-off
|
|
219
260
|
|
|
@@ -232,6 +273,9 @@ plan summary. Surface each, take the correction, then proceed:
|
|
|
232
273
|
runs, or downgrade the completion event.
|
|
233
274
|
- **Q2 single ADR shape + Q7 technology-ADR template requested.**
|
|
234
275
|
Contradiction — pick one.
|
|
276
|
+
- **Q11 = join but no confirmable home pointer.** Joining needs a
|
|
277
|
+
home/federation pointer you can confirm. If none exists yet, you are
|
|
278
|
+
really *establishing* — switch Q11a to establish.
|
|
235
279
|
|
|
236
280
|
## Step 5 — Output sequence (after sign-off)
|
|
237
281
|
|
|
@@ -242,7 +286,9 @@ write it into the repo.
|
|
|
242
286
|
1. `CONVENTIONS.md` — from `templates/CONVENTIONS.md`. Spec other files
|
|
243
287
|
reference. Include the **§Concurrency Guardrails** section only if Q5
|
|
244
288
|
is mode 2/3 **or** Q4b is PR-based; omit it for single-agent
|
|
245
|
-
direct-to-main repos (no numbering race).
|
|
289
|
+
direct-to-main repos (no numbering race). Include the **§Federation
|
|
290
|
+
(multi-repo)** section only if Q11 = yes; fill `<product>` and state
|
|
291
|
+
the chosen identity scheme. Omit it for standalone repos.
|
|
246
292
|
2. `AGENTS.md` — from `templates/AGENTS.md`. Include the concurrency
|
|
247
293
|
guardrails hard-rule bullet (G2/G3) under the same condition as the
|
|
248
294
|
CONVENTIONS section above; omit otherwise.
|
|
@@ -276,6 +322,22 @@ write it into the repo.
|
|
|
276
322
|
**direct-to-main** variant (`git merge --ff-only` then push) or
|
|
277
323
|
the **PR-based** variant (`gh pr create --draft` → wait for CI →
|
|
278
324
|
mark ready → `gh pr merge`). Drop the unused variant.
|
|
325
|
+
14. **Federation files** — **only if Q11 = yes.** Place both at the
|
|
326
|
+
configured artefact root (repository root by default).
|
|
327
|
+
- **Establish:** write `federation-index.md` (the member index, a
|
|
328
|
+
Markdown table) from `templates/federation-index.md` into this
|
|
329
|
+
repo, seeded with this repo as the home member; and write
|
|
330
|
+
`federation.md` from `templates/federation-config.md` with
|
|
331
|
+
`Role: home`, the chosen topology, and the chosen identity scheme
|
|
332
|
+
(default repo-prefixed slug). Record the identity scheme in both
|
|
333
|
+
files so it is the same on every read.
|
|
334
|
+
- **Join:** write **only** `federation.md` from
|
|
335
|
+
`templates/federation-config.md` with `Role: member`, the
|
|
336
|
+
confirmed home pointer, and the topology **and identity scheme**
|
|
337
|
+
inherited from the federation (read them from the home, do not
|
|
338
|
+
re-ask). Write nothing into any other repo, and do **not** create a
|
|
339
|
+
member index. Tell the user to add this repo to the home repo's
|
|
340
|
+
`federation-index.md` (a deliberate edit there).
|
|
279
341
|
|
|
280
342
|
Commit each file (or logical group) with a Conventional Commit message;
|
|
281
343
|
no `Co-Authored-By` trailer unless Q6 asked for one.
|
|
@@ -0,0 +1,4 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "docflow: bootstrap"
|
|
3
|
+
short_description: "Scaffold (or retrofit) ADR-driven documentation conventions — an ADR catalogue, a plan/ queue, AGENTS.md, and _agent/ coordination — into a repo."
|
|
4
|
+
default_prompt: "Set up documentation-led ADR conventions in this repository."
|
|
@@ -167,6 +167,32 @@ once merged:
|
|
|
167
167
|
renumbers.
|
|
168
168
|
-->
|
|
169
169
|
|
|
170
|
+
<!-- Federation (multi-repo) — bootstrap INCLUDES this section
|
|
171
|
+
(uncommented) ONLY when this repo is part of a multi-repo product (Q11).
|
|
172
|
+
Standalone repos OMIT it entirely.
|
|
173
|
+
|
|
174
|
+
## Federation (multi-repo)
|
|
175
|
+
|
|
176
|
+
This repo belongs to the **<product>** federation. Topology and the
|
|
177
|
+
identity scheme are recorded in `federation.md`; the home repo's
|
|
178
|
+
`federation-index.md` is the authoritative member list.
|
|
179
|
+
|
|
180
|
+
- **Numbering is per-repo contiguous.** Each member repo numbers its own
|
|
181
|
+
ADRs contiguously from `0001`; numbers are **not** unique across the
|
|
182
|
+
federation. The cross-federation key is the **identity scheme** recorded
|
|
183
|
+
in `federation.md` — default repo-prefixed slug `<repo-id>/NNNN-slug`.
|
|
184
|
+
- **Cross-repo references use the logical identity**, resolved through the
|
|
185
|
+
member index (`repo-id → location`); they survive a target repo move
|
|
186
|
+
(edit one index row, not the references). **Same-repo references stay
|
|
187
|
+
relative paths** (`adr/NNNN-*.md`).
|
|
188
|
+
- `supersedes:` / `superseded-by:` may point across repos using the
|
|
189
|
+
logical identity.
|
|
190
|
+
- **Membership is declared, not discovered.** A member repo carries a
|
|
191
|
+
`federation.md` back-pointer; adding it to the home's
|
|
192
|
+
`federation-index.md` is a deliberate edit there. The two must agree —
|
|
193
|
+
audit cross-checks both directions.
|
|
194
|
+
-->
|
|
195
|
+
|
|
170
196
|
## Audit Trail Policy
|
|
171
197
|
|
|
172
198
|
Every substantive change to an Accepted ADR appends a new row to its
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Federation
|
|
2
|
+
|
|
3
|
+
This repo is part of a multi-repo product. Lifecycle skills read this
|
|
4
|
+
back-pointer to resolve cross-repo behaviour. It is the answer to "what
|
|
5
|
+
is my home?"; the home repo's `federation-index.md` is the answer to
|
|
6
|
+
"which repos are in this product?".
|
|
7
|
+
|
|
8
|
+
- **Product:** <product-name>
|
|
9
|
+
- **Topology:** <A — central decisions repo | B — distributed + federation | C — home repo + local>
|
|
10
|
+
- **Identity scheme:** <repo-prefixed slug `<repo-id>/NNNN-slug` (default) | other scheme chosen at establishment>
|
|
11
|
+
- **Home:** <pointer to the home/central repo — URL or path; for the home repo itself, `this repo`>
|
|
12
|
+
- **Role:** <home | member>
|
|
13
|
+
- **Repo id:** <short identifier for this repo, used to qualify its records across the federation>
|
|
14
|
+
|
|
15
|
+
<!-- Hand-maintained. Membership is declared, not auto-discovered: a
|
|
16
|
+
member's bootstrap writes only this file in its own repo; adding the
|
|
17
|
+
repo to the home's federation-index.md is a deliberate edit there. -->
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Federation member index
|
|
2
|
+
|
|
3
|
+
Authoritative list of the repos in this product. Lives only in the
|
|
4
|
+
home/central repo. **Hand-maintained:** adding a member is a deliberate
|
|
5
|
+
edit here — no lifecycle skill writes across repos to update it. Lifecycle
|
|
6
|
+
skills read this to enumerate the product's repos.
|
|
7
|
+
|
|
8
|
+
- **Product:** <product-name>
|
|
9
|
+
- **Topology:** <A — central decisions repo | B — distributed + federation | C — home repo + local>
|
|
10
|
+
- **Identity scheme:** <repo-prefixed slug `<repo-id>/NNNN-slug` (default) | other scheme chosen at establishment>
|
|
11
|
+
|
|
12
|
+
| Repo id | Repo | Role | Pointer |
|
|
13
|
+
|---------|------|------|---------|
|
|
14
|
+
| <id> | <this repo> | home | this repo |
|
|
15
|
+
|
|
16
|
+
<!-- Each row should have a matching federation.md back-pointer in the
|
|
17
|
+
named repo, and vice versa. The audit step cross-checks both directions. -->
|
|
@@ -17,6 +17,9 @@ Author one new ADR, consistent with this repo's conventions.
|
|
|
17
17
|
status lifecycle, language mandate (if any), whether `domains/`
|
|
18
18
|
groupings exist, and the multi-agent mode.
|
|
19
19
|
3. Read `INDEX.md` and `ls adr/` to learn existing numbers and titles.
|
|
20
|
+
4. If a `federation.md` exists, this repo is part of a multi-repo
|
|
21
|
+
product. Note the **identity scheme** and the **home** it records —
|
|
22
|
+
they govern numbering and cross-repo references below.
|
|
20
23
|
|
|
21
24
|
## Step 0.5 — Assessment (run first)
|
|
22
25
|
|
|
@@ -56,6 +59,10 @@ Questions (skip any the request already answers):
|
|
|
56
59
|
- **Number.** Next contiguous integer after the highest existing ADR,
|
|
57
60
|
zero-padded to 4 digits. No gaps, no reuse. For a split repo, keep
|
|
58
61
|
capability ADRs below the cutoff and technology ADRs at/above it.
|
|
62
|
+
**In a federation** (a `federation.md` exists), number contiguously
|
|
63
|
+
**within this repo** — numbers are not unique across the federation.
|
|
64
|
+
The ADR's federation identity is the recorded scheme applied to this
|
|
65
|
+
number (default repo-prefixed slug `<repo-id>/NNNN-slug`).
|
|
59
66
|
|
|
60
67
|
## Step 2 — Gather content
|
|
61
68
|
|
|
@@ -75,6 +82,10 @@ If this ADR replaces an existing one:
|
|
|
75
82
|
- Set `supersedes:` on the new ADR and `superseded-by:` on the old.
|
|
76
83
|
- Advance the old ADR's `status:` to `Superseded`, append a Revision
|
|
77
84
|
History row noting the successor.
|
|
85
|
+
- **Same-repo** links use relative paths (`adr/NNNN-*.md`). **In a
|
|
86
|
+
federation**, a link to an ADR in another repo uses the logical
|
|
87
|
+
identity (`<repo-id>/NNNN-slug`), resolved via the member index — not
|
|
88
|
+
a relative path.
|
|
78
89
|
- A pure deprecation (no successor) sets the target to `Deprecated`
|
|
79
90
|
with a Revision History row — and is usually done directly, not via
|
|
80
91
|
this skill.
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rollup
|
|
3
|
+
description: Generate the federation roll-up catalogue for a multi-repo product — aggregate every member repo's ADR metadata into one derived, product-wide view, run from the home repo. Use when the user says "roll up the federation", "generate the product-wide ADR view", "aggregate ADRs across the repos", "refresh the roll-up", or invokes /rollup. NOT for regenerating a single repo's own INDEX (that happens in place during authoring/ship) and NOT for linting consistency (use the audit skill).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# rollup
|
|
7
|
+
|
|
8
|
+
Aggregate the ADR catalogues of every repo in a multi-repo product into
|
|
9
|
+
one **derived, read-only** product-wide view. The roll-up is regenerated
|
|
10
|
+
from source, never hand-edited — treat it exactly like a repo's own
|
|
11
|
+
`INDEX.md`.
|
|
12
|
+
|
|
13
|
+
## Step 0 — Preconditions
|
|
14
|
+
|
|
15
|
+
1. This skill runs in the **home repo** of a federation. Confirm a
|
|
16
|
+
`federation-index.md` (the authoritative member list) and a
|
|
17
|
+
`federation.md` with `Role: home` exist. If they do not, stop: either
|
|
18
|
+
this repo is standalone (nothing to roll up) or it is a member, not the
|
|
19
|
+
home — point the user at the home repo.
|
|
20
|
+
2. Read `federation.md` to learn the **identity scheme** (default
|
|
21
|
+
repo-prefixed slug `<repo-id>/NNNN-slug`); roll-up rows use it.
|
|
22
|
+
|
|
23
|
+
## Step 1 — Enumerate members
|
|
24
|
+
|
|
25
|
+
Read `federation-index.md`. For each row, take the `Repo id` and the
|
|
26
|
+
`Pointer` (the path/URL of that member's checkout). The member index is
|
|
27
|
+
the **only** source of membership — do not auto-discover repos.
|
|
28
|
+
|
|
29
|
+
## Step 2 — Collect each member's catalogue
|
|
30
|
+
|
|
31
|
+
For every member whose checkout is **locally available** at its pointer:
|
|
32
|
+
|
|
33
|
+
- Read that member's `INDEX.md` (its authoritative local catalogue).
|
|
34
|
+
- For each ADR row, capture the number, title, status, date, and
|
|
35
|
+
dependencies, and attach the **owning repo id** and the **federation
|
|
36
|
+
identity** (the scheme from Step 0 applied to the local number).
|
|
37
|
+
|
|
38
|
+
A member's own `INDEX.md` stays authoritative for that member; this skill
|
|
39
|
+
only reads it.
|
|
40
|
+
|
|
41
|
+
## Step 3 — Handle unreachable members
|
|
42
|
+
|
|
43
|
+
A member named in the index whose checkout is **not locally available** is
|
|
44
|
+
**not** dropped and **not** a failure. Record it in a clearly separated
|
|
45
|
+
"Not aggregated this run" list with its repo id and pointer, so the gap is
|
|
46
|
+
visible rather than silent.
|
|
47
|
+
|
|
48
|
+
## Step 4 — Write the roll-up
|
|
49
|
+
|
|
50
|
+
Write the aggregate to a derived file in the home repo (e.g. `ROLLUP.md`):
|
|
51
|
+
|
|
52
|
+
- A header stating it is **generated — do not hand-edit**, with the run
|
|
53
|
+
date and the set of members aggregated.
|
|
54
|
+
- One table across the whole product: federation identity, title, status,
|
|
55
|
+
owning repo, date. Group or sort by owning repo for readability.
|
|
56
|
+
- The "Not aggregated this run" list from Step 3.
|
|
57
|
+
|
|
58
|
+
Do not alter any member's `INDEX.md` and do not write into any other repo.
|
|
59
|
+
|
|
60
|
+
## Step 5 — Report
|
|
61
|
+
|
|
62
|
+
Tell the user how many members were aggregated, how many were skipped as
|
|
63
|
+
unreachable (and which), and the total ADR count in the roll-up. Remind
|
|
64
|
+
them the file is derived: re-run this skill to refresh it rather than
|
|
65
|
+
editing it by hand.
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|