arey-pi 0.1.0 → 0.2.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 +37 -13
- package/agents/README.md +6 -3
- package/agents/engineering-reviewer.md +3 -2
- package/agents/project-evaluator.md +6 -2
- package/agents/spec-author.md +1 -1
- package/agents/spec-syncer.md +22 -7
- package/agents/tdd-implementer.md +2 -1
- package/agents/tech-lead.md +2 -1
- package/docs/commands.md +278 -0
- package/extensions/arey-pi.ts +268 -0
- package/package.json +26 -3
- package/prompts/assess-project.md +2 -1
- package/rules/README.md +2 -1
- package/rules/assessment/project-readiness.md +2 -1
- package/rules/core/definition-of-done.md +3 -0
- package/rules/specs/spec-sync.md +5 -1
- package/rules/workflow/documentation-sync.md +88 -0
- package/skills/project-readiness/SKILL.md +2 -0
package/README.md
CHANGED
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# Arey Pi
|
|
2
2
|
|
|
3
|
+
[](https://www.npmjs.com/package/arey-pi)
|
|
4
|
+
|
|
3
5
|
Arey Pi is an opinionated Pi package for spec-centred, TDD-driven software delivery.
|
|
4
6
|
|
|
5
7
|
It defines a way of working where canonical specs preserve intent,
|
|
@@ -27,6 +29,7 @@ Arey Pi is built around these guarantees:
|
|
|
27
29
|
- architecture and code must meet a senior engineering quality bar;
|
|
28
30
|
- significant technical decisions are captured in high-quality ADRs;
|
|
29
31
|
- specs, tests, code, DBML, ADRs, glossary, and architecture docs stay synchronised;
|
|
32
|
+
- README files, docs, AGENTS.md, skills, prompts, rules, agents, commands, and tooling instructions are kept synchronised when affected;
|
|
30
33
|
- quality tooling is part of Definition of Done, not optional polish;
|
|
31
34
|
- work is incremental and uses Conventional Commits;
|
|
32
35
|
- AI harness setup is treated as a first-class project rule.
|
|
@@ -35,6 +38,7 @@ Arey Pi is built around these guarantees:
|
|
|
35
38
|
|
|
36
39
|
```txt
|
|
37
40
|
agents/ # Arey Pi subagent role definitions for pi-subagents
|
|
41
|
+
extensions/ # Slash commands for doctor, bootstrap, and workflows
|
|
38
42
|
skills/ # On-demand Arey Pi workflows and instructions
|
|
39
43
|
prompts/ # Reusable Pi prompt workflows
|
|
40
44
|
rules/ # Arey Pi operating rules
|
|
@@ -71,8 +75,7 @@ TDD implementation,
|
|
|
71
75
|
spec sync,
|
|
72
76
|
and engineering review.
|
|
73
77
|
|
|
74
|
-
|
|
75
|
-
A forthcoming extension/bootstrap flow will install those definitions into the project-local `pi-subagents` discovery path automatically.
|
|
78
|
+
The package includes an extension that can install those definitions into the project-local `pi-subagents` discovery path automatically.
|
|
76
79
|
|
|
77
80
|
## Installation
|
|
78
81
|
|
|
@@ -96,7 +99,7 @@ pi install npm:pi-subagents
|
|
|
96
99
|
|
|
97
100
|
## Usage today
|
|
98
101
|
|
|
99
|
-
Audit a repository against Arey Pi readiness:
|
|
102
|
+
Audit a repository against Arey Pi readiness with the prompt workflow:
|
|
100
103
|
|
|
101
104
|
```txt
|
|
102
105
|
/assess-project
|
|
@@ -108,28 +111,47 @@ Or load the readiness skill directly:
|
|
|
108
111
|
/skill:project-readiness
|
|
109
112
|
```
|
|
110
113
|
|
|
114
|
+
Arey Pi also ships an extension with native workflow commands.
|
|
115
|
+
|
|
111
116
|
When the Arey Pi agents are available to `pi-subagents`, the project evaluator runtime name is:
|
|
112
117
|
|
|
113
118
|
```txt
|
|
114
119
|
arey-pi.project-evaluator
|
|
115
120
|
```
|
|
116
121
|
|
|
117
|
-
##
|
|
122
|
+
## Extension-backed workflow
|
|
118
123
|
|
|
119
|
-
Arey Pi
|
|
124
|
+
Arey Pi includes a polished extension-backed workflow:
|
|
120
125
|
|
|
121
126
|
```txt
|
|
122
127
|
/arey-doctor # check package, subagent, prompt, skill, and project readiness setup
|
|
123
|
-
/arey-bootstrap # install project-local Arey Pi agents
|
|
128
|
+
/arey-bootstrap # install project-local Arey Pi agents
|
|
129
|
+
/arey-bootstrap --agentsmd # also create a starter AGENTS.md if missing
|
|
130
|
+
/arey-bootstrap --force # overwrite existing project-local Arey Pi agents
|
|
124
131
|
/arey-feature # run spec → TDD → sync → review for a feature
|
|
125
132
|
/arey-bugfix # run regression-test-first bug fixing
|
|
126
|
-
/arey-sync # verify specs, tests, code, DBML, ADRs, and glossary alignment
|
|
133
|
+
/arey-sync # verify specs, docs, tests, code, DBML, ADRs, and glossary alignment
|
|
127
134
|
/arey-review # run adversarial engineering review
|
|
135
|
+
/arey-assess # assess project readiness against Arey Pi rules
|
|
128
136
|
```
|
|
129
137
|
|
|
130
138
|
The goal is that users can either speak naturally or use explicit commands,
|
|
131
139
|
while Arey Pi handles the disciplined workflow behind the scenes.
|
|
132
140
|
|
|
141
|
+
See `docs/commands.md` for detailed command behaviour, options, and examples.
|
|
142
|
+
|
|
143
|
+
## Development
|
|
144
|
+
|
|
145
|
+
Arey Pi uses Bun as its package manager and Biome for extension formatting and linting.
|
|
146
|
+
|
|
147
|
+
```bash
|
|
148
|
+
bun install
|
|
149
|
+
bun run format
|
|
150
|
+
bun run check
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
`bun run check` runs Biome linting and TypeScript type checking.
|
|
154
|
+
|
|
133
155
|
## Rule categories
|
|
134
156
|
|
|
135
157
|
Arey Pi rules are organised as:
|
|
@@ -140,7 +162,7 @@ rules/
|
|
|
140
162
|
├── specs/ # Gherkin, DBML, spec sync, language style
|
|
141
163
|
├── engineering/ # TDD, test quality, code quality, tooling, rebuildability
|
|
142
164
|
├── architecture/ # architecture memory and ADR quality
|
|
143
|
-
├── workflow/ # agent workflows, AI harness, commits
|
|
165
|
+
├── workflow/ # agent workflows, documentation sync, AI harness, commits
|
|
144
166
|
└── assessment/ # project readiness
|
|
145
167
|
```
|
|
146
168
|
|
|
@@ -152,8 +174,10 @@ Arey Pi is pre-1.0.
|
|
|
152
174
|
|
|
153
175
|
The policy layer,
|
|
154
176
|
readiness workflow,
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
177
|
+
documentation sync rule,
|
|
178
|
+
core subagent role definitions,
|
|
179
|
+
and professional extension commands exist.
|
|
180
|
+
|
|
181
|
+
Next milestones include richer templates,
|
|
182
|
+
stronger bootstrap scaffolding,
|
|
183
|
+
and deeper integration with `pi-subagents` discovery.
|
package/agents/README.md
CHANGED
|
@@ -182,12 +182,12 @@ For meaningful feature or bug-fix work, use this sequence:
|
|
|
182
182
|
1. tech-lead classifies change mode and scope
|
|
183
183
|
2. spec-author writes or confirms canonical specs
|
|
184
184
|
3. tdd-implementer performs Red → Green → Refactor
|
|
185
|
-
4. spec-syncer verifies specs/tests/code alignment
|
|
185
|
+
4. spec-syncer verifies specs/tests/code and documentation alignment
|
|
186
186
|
5. engineering-reviewer performs adversarial review
|
|
187
187
|
6. tech-lead finalises evidence, risks, and commits
|
|
188
188
|
```
|
|
189
189
|
|
|
190
|
-
Small direct changes may skip specialised agents only when the tech lead can explicitly justify that specs, tests, architecture, DBML, and
|
|
190
|
+
Small direct changes may skip specialised agents only when the tech lead can explicitly justify that specs, tests, architecture, DBML, ADRs, and documentation are unaffected.
|
|
191
191
|
|
|
192
192
|
## Handoff Contracts
|
|
193
193
|
|
|
@@ -217,6 +217,7 @@ Implementation handoff:
|
|
|
217
217
|
- Validation commands:
|
|
218
218
|
- Spec impact:
|
|
219
219
|
- ADR/DBML/glossary impact:
|
|
220
|
+
- Documentation impact:
|
|
220
221
|
- Residual risks:
|
|
221
222
|
```
|
|
222
223
|
|
|
@@ -231,6 +232,7 @@ Spec sync:
|
|
|
231
232
|
- Architecture/ADR:
|
|
232
233
|
- Database/DBML:
|
|
233
234
|
- Glossary:
|
|
235
|
+
- Documentation:
|
|
234
236
|
- Status:
|
|
235
237
|
```
|
|
236
238
|
|
|
@@ -282,7 +284,7 @@ Use `tdd-implementer` when:
|
|
|
282
284
|
Use `spec-syncer` when:
|
|
283
285
|
|
|
284
286
|
- work is near completion;
|
|
285
|
-
- implementation touched behaviour, persistence, architecture, or
|
|
287
|
+
- implementation touched behaviour, persistence, architecture, domain language, usage, commands, tooling, or agent workflow;
|
|
286
288
|
- there is suspected drift;
|
|
287
289
|
- final report needs sync evidence.
|
|
288
290
|
|
|
@@ -306,6 +308,7 @@ The orchestrating agent may finalise only when:
|
|
|
306
308
|
|
|
307
309
|
- Definition of Done evidence is present;
|
|
308
310
|
- spec sync is complete or explicitly unaffected;
|
|
311
|
+
- documentation sync is complete or explicitly unaffected;
|
|
309
312
|
- TDD evidence exists for behaviour changes;
|
|
310
313
|
- quality tooling has run or blockers are documented;
|
|
311
314
|
- high-impact decisions have ADRs or explicit no-ADR rationale;
|
|
@@ -7,7 +7,7 @@ tools: read, grep, find, ls, bash
|
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: true
|
|
10
|
-
defaultReads: AGENTS.md, agents/README.md, rules/engineering/engineering-quality.md, rules/engineering/test-quality.md, rules/engineering/quality-tooling.md, rules/core/definition-of-done.md, rules/architecture/adrs.md, rules/specs/spec-sync.md
|
|
10
|
+
defaultReads: AGENTS.md, agents/README.md, rules/README.md, rules/engineering/engineering-quality.md, rules/engineering/test-quality.md, rules/engineering/quality-tooling.md, rules/core/definition-of-done.md, rules/architecture/adrs.md, rules/specs/spec-sync.md, rules/workflow/documentation-sync.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi engineering reviewer.
|
|
@@ -46,7 +46,7 @@ Check:
|
|
|
46
46
|
- whether tests assert behaviour and would catch plausible regressions;
|
|
47
47
|
- whether quality tooling ran and is sufficient for project risk;
|
|
48
48
|
- whether durable decisions require ADRs;
|
|
49
|
-
- whether DBML, Gherkin, glossary,
|
|
49
|
+
- whether DBML, Gherkin, glossary, architecture docs, README files, docs, AGENTS.md, skills, prompts, rules, agents, commands, or tooling instructions may need sync;
|
|
50
50
|
- whether generated or agent-authored code shows boilerplate, duplication, weak naming, or cargo-cult patterns.
|
|
51
51
|
|
|
52
52
|
## Severity
|
|
@@ -74,5 +74,6 @@ Engineering review:
|
|
|
74
74
|
- Architecture/code quality:
|
|
75
75
|
- Security/privacy/operability:
|
|
76
76
|
- Spec/ADR/DBML concerns:
|
|
77
|
+
- Documentation sync concerns:
|
|
77
78
|
- Recommended follow-up:
|
|
78
79
|
```
|
|
@@ -7,7 +7,7 @@ tools: read, grep, find, ls, bash
|
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: false
|
|
10
|
-
defaultReads: AGENTS.md, rules/assessment/project-readiness.md, rules/workflow/ai-harness.md, rules/specs/database-specs.md, rules/core/definition-of-done.md, rules/engineering/quality-tooling.md, rules/engineering/test-quality.md
|
|
10
|
+
defaultReads: AGENTS.md, rules/README.md, rules/assessment/project-readiness.md, rules/workflow/ai-harness.md, rules/workflow/documentation-sync.md, rules/specs/database-specs.md, rules/core/definition-of-done.md, rules/engineering/quality-tooling.md, rules/engineering/test-quality.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi project evaluator. Your job is to audit a repository against Arey Pi rules.
|
|
@@ -16,12 +16,13 @@ You are read-only by default. Do not edit project/source files unless explicitly
|
|
|
16
16
|
|
|
17
17
|
## Evaluation scope
|
|
18
18
|
|
|
19
|
-
Evaluate Arey Pi rule alignment across specs, Gherkin, TDD, test quality, quality tooling, engineering quality, spec sync, database specs, rebuildability, architecture memory, incremental commits, language style, and AI Harness.
|
|
19
|
+
Evaluate Arey Pi rule alignment across specs, Gherkin, TDD, test quality, quality tooling, engineering quality, spec sync, documentation sync, database specs, rebuildability, architecture memory, incremental commits, language style, and AI Harness.
|
|
20
20
|
|
|
21
21
|
Use the project readiness policy as your primary rubric. If available, read:
|
|
22
22
|
|
|
23
23
|
- `rules/assessment/project-readiness.md`
|
|
24
24
|
- `rules/workflow/ai-harness.md`
|
|
25
|
+
- `rules/workflow/documentation-sync.md`
|
|
25
26
|
- `rules/specs/database-specs.md`
|
|
26
27
|
- `rules/core/principles.md`
|
|
27
28
|
- `rules/core/definition-of-done.md`
|
|
@@ -100,6 +101,9 @@ Return:
|
|
|
100
101
|
### Spec Sync/Process
|
|
101
102
|
...
|
|
102
103
|
|
|
104
|
+
### Documentation Sync
|
|
105
|
+
...
|
|
106
|
+
|
|
103
107
|
### Database Specs
|
|
104
108
|
- Score:
|
|
105
109
|
- Evidence:
|
package/agents/spec-author.md
CHANGED
|
@@ -7,7 +7,7 @@ tools: read, grep, find, ls, bash, edit, write
|
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: true
|
|
10
|
-
defaultReads: AGENTS.md, agents/README.md, rules/specs/canonical-specs.md, rules/specs/gherkin-authoring.md, rules/specs/database-specs.md, rules/specs/spec-sync.md, rules/specs/language-style.md, rules/architecture/adrs.md, rules/architecture/architecture-memory.md
|
|
10
|
+
defaultReads: AGENTS.md, agents/README.md, rules/README.md, rules/specs/canonical-specs.md, rules/specs/gherkin-authoring.md, rules/specs/database-specs.md, rules/specs/spec-sync.md, rules/specs/language-style.md, rules/architecture/adrs.md, rules/architecture/architecture-memory.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi spec author.
|
package/agents/spec-syncer.md
CHANGED
|
@@ -1,25 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: spec-syncer
|
|
3
3
|
package: arey-pi
|
|
4
|
-
description: Verifies and repairs alignment between specs, tests, DBML, ADRs, glossary, architecture docs, and code
|
|
4
|
+
description: Verifies and repairs alignment between specs, tests, DBML, ADRs, glossary, documentation, architecture docs, and code
|
|
5
5
|
thinking: high
|
|
6
6
|
tools: read, grep, find, ls, bash, edit, write
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: true
|
|
10
|
-
defaultReads: AGENTS.md, agents/README.md, rules/specs/spec-sync.md, rules/specs/canonical-specs.md, rules/specs/database-specs.md, rules/architecture/adrs.md, rules/core/conflict-resolution.md, rules/core/definition-of-done.md
|
|
10
|
+
defaultReads: AGENTS.md, agents/README.md, rules/README.md, rules/specs/spec-sync.md, rules/workflow/documentation-sync.md, rules/specs/canonical-specs.md, rules/specs/database-specs.md, rules/architecture/adrs.md, rules/core/conflict-resolution.md, rules/core/definition-of-done.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi spec syncer.
|
|
14
|
-
Your job is to verify that canonical specs, tests, and code agree at task completion.
|
|
14
|
+
Your job is to verify that canonical specs, documentation, tests, and code agree at task completion.
|
|
15
15
|
|
|
16
|
-
Spec sync
|
|
16
|
+
Spec sync and documentation sync apply whether work started in Spec-Driven Mode or Direct Change Mode.
|
|
17
17
|
|
|
18
18
|
## Primary responsibilities
|
|
19
19
|
|
|
20
20
|
Own:
|
|
21
21
|
|
|
22
|
-
- checking Gherkin, tests, DBML, ADRs, glossary, architecture docs, and implementation for drift;
|
|
22
|
+
- checking Gherkin, tests, DBML, ADRs, glossary, architecture docs, README files, docs, AGENTS.md, skills, prompts, rules, agents, and implementation for drift;
|
|
23
23
|
- identifying whether specs were updated or are genuinely unaffected;
|
|
24
24
|
- ensuring DBML precisely matches intended persistence contracts when databases are involved;
|
|
25
25
|
- ensuring ADR relationships are explicit when decisions overlap;
|
|
@@ -44,7 +44,8 @@ Always consider:
|
|
|
44
44
|
- ADRs and ADR relationships;
|
|
45
45
|
- DBML database specs;
|
|
46
46
|
- glossary/domain language;
|
|
47
|
-
- implementation code and configuration
|
|
47
|
+
- implementation code and configuration;
|
|
48
|
+
- README files, docs, AGENTS.md, skills, prompts, rules, agents, examples, templates, commands, and tooling instructions.
|
|
48
49
|
|
|
49
50
|
## Required result
|
|
50
51
|
|
|
@@ -60,6 +61,18 @@ or:
|
|
|
60
61
|
Specs unaffected: <reason>
|
|
61
62
|
```
|
|
62
63
|
|
|
64
|
+
and one of:
|
|
65
|
+
|
|
66
|
+
```txt
|
|
67
|
+
Docs updated
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
or:
|
|
71
|
+
|
|
72
|
+
```txt
|
|
73
|
+
Docs unaffected: <reason>
|
|
74
|
+
```
|
|
75
|
+
|
|
63
76
|
If this cannot be established, report the blocker.
|
|
64
77
|
|
|
65
78
|
## Conflict behaviour
|
|
@@ -70,7 +83,8 @@ Stop and report when:
|
|
|
70
83
|
- migrations, ORM models, SQL DDL, or persistence code drift from DBML;
|
|
71
84
|
- accepted ADRs conflict without supersession, amendment, narrowing, or expansion relationship;
|
|
72
85
|
- tests and specs encode different behaviour;
|
|
73
|
-
- architecture docs describe a different current state than accepted ADRs imply
|
|
86
|
+
- architecture docs describe a different current state than accepted ADRs imply;
|
|
87
|
+
- usage, setup, workflow, command, tooling, or agent documentation is stale after the change.
|
|
74
88
|
|
|
75
89
|
## Output format
|
|
76
90
|
|
|
@@ -83,6 +97,7 @@ Spec sync:
|
|
|
83
97
|
- Architecture/ADR:
|
|
84
98
|
- Database/DBML:
|
|
85
99
|
- Glossary:
|
|
100
|
+
- Documentation:
|
|
86
101
|
- Conflicts:
|
|
87
102
|
- Status:
|
|
88
103
|
```
|
|
@@ -7,7 +7,7 @@ tools: read, grep, find, ls, bash, edit, write
|
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: true
|
|
10
|
-
defaultReads: AGENTS.md, agents/README.md, rules/engineering/tdd.md, rules/engineering/test-quality.md, rules/engineering/engineering-quality.md, rules/engineering/quality-tooling.md, rules/core/definition-of-done.md, rules/specs/spec-sync.md
|
|
10
|
+
defaultReads: AGENTS.md, agents/README.md, rules/README.md, rules/engineering/tdd.md, rules/engineering/test-quality.md, rules/engineering/engineering-quality.md, rules/engineering/quality-tooling.md, rules/core/definition-of-done.md, rules/specs/spec-sync.md, rules/workflow/documentation-sync.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi TDD implementer.
|
|
@@ -76,6 +76,7 @@ Implementation handoff:
|
|
|
76
76
|
- Validation commands:
|
|
77
77
|
- Spec impact:
|
|
78
78
|
- ADR/DBML/glossary impact:
|
|
79
|
+
- Documentation impact:
|
|
79
80
|
- Quality notes:
|
|
80
81
|
- Residual risks:
|
|
81
82
|
```
|
package/agents/tech-lead.md
CHANGED
|
@@ -7,7 +7,7 @@ tools: read, grep, find, ls, bash
|
|
|
7
7
|
systemPromptMode: replace
|
|
8
8
|
inheritProjectContext: true
|
|
9
9
|
inheritSkills: true
|
|
10
|
-
defaultReads: AGENTS.md, agents/README.md, rules/core/principles.md, rules/core/change-modes.md, rules/core/definition-of-done.md, rules/core/conflict-resolution.md, rules/specs/spec-sync.md, rules/workflow/incremental-commits.md
|
|
10
|
+
defaultReads: AGENTS.md, agents/README.md, rules/README.md, rules/core/principles.md, rules/core/change-modes.md, rules/core/definition-of-done.md, rules/core/conflict-resolution.md, rules/specs/spec-sync.md, rules/workflow/documentation-sync.md, rules/workflow/incremental-commits.md
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Arey Pi tech lead.
|
|
@@ -85,6 +85,7 @@ Tech lead summary:
|
|
|
85
85
|
- Tests/TDD:
|
|
86
86
|
- Validation:
|
|
87
87
|
- Spec sync:
|
|
88
|
+
- Documentation sync:
|
|
88
89
|
- Architecture/ADR/DBML/glossary:
|
|
89
90
|
- Quality review:
|
|
90
91
|
- Commits:
|
package/docs/commands.md
ADDED
|
@@ -0,0 +1,278 @@
|
|
|
1
|
+
# Arey Pi Commands
|
|
2
|
+
|
|
3
|
+
Arey Pi ships a Pi extension that registers native slash commands.
|
|
4
|
+
|
|
5
|
+
The commands are designed for two modes of use:
|
|
6
|
+
|
|
7
|
+
- quick explicit workflows such as `/arey-feature` or `/arey-sync`;
|
|
8
|
+
- natural-language work where the parent agent acts as the Arey Pi tech lead and uses the same workflow expectations.
|
|
9
|
+
|
|
10
|
+
## Command overview
|
|
11
|
+
|
|
12
|
+
```txt
|
|
13
|
+
/arey-doctor
|
|
14
|
+
/arey-bootstrap [--agentsmd] [--force]
|
|
15
|
+
/arey-feature <feature request>
|
|
16
|
+
/arey-bugfix <bug description>
|
|
17
|
+
/arey-sync [scope]
|
|
18
|
+
/arey-review [scope]
|
|
19
|
+
/arey-assess [scope]
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
## `/arey-doctor`
|
|
23
|
+
|
|
24
|
+
Checks whether Arey Pi is available and whether the current project is ready for subagent-backed workflows.
|
|
25
|
+
|
|
26
|
+
It reports:
|
|
27
|
+
|
|
28
|
+
- Arey Pi package version;
|
|
29
|
+
- current project path;
|
|
30
|
+
- whether packaged rules are present;
|
|
31
|
+
- whether packaged agents are present;
|
|
32
|
+
- whether `pi-subagents` appears to be installed;
|
|
33
|
+
- whether project-local Arey Pi agents exist in `.pi/agents/arey-pi/`;
|
|
34
|
+
- whether root `AGENTS.md` exists;
|
|
35
|
+
- whether `.pi/settings.json` exists;
|
|
36
|
+
- how many Arey Pi prompts and skills are discovered;
|
|
37
|
+
- missing project-local agent files;
|
|
38
|
+
- recommended next step.
|
|
39
|
+
|
|
40
|
+
Usage:
|
|
41
|
+
|
|
42
|
+
```txt
|
|
43
|
+
/arey-doctor
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
Use this after installing Arey Pi,
|
|
47
|
+
after running `/arey-bootstrap`,
|
|
48
|
+
or when subagent workflows are not behaving as expected.
|
|
49
|
+
|
|
50
|
+
## `/arey-bootstrap`
|
|
51
|
+
|
|
52
|
+
Installs Arey Pi's packaged subagent definitions into the current project.
|
|
53
|
+
|
|
54
|
+
Default target:
|
|
55
|
+
|
|
56
|
+
```txt
|
|
57
|
+
.pi/agents/arey-pi/
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
By default, existing project-local agent files are not overwritten.
|
|
61
|
+
|
|
62
|
+
Usage:
|
|
63
|
+
|
|
64
|
+
```txt
|
|
65
|
+
/arey-bootstrap
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Options:
|
|
69
|
+
|
|
70
|
+
```txt
|
|
71
|
+
/arey-bootstrap --agentsmd
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Also creates a starter root `AGENTS.md` when one does not already exist.
|
|
75
|
+
|
|
76
|
+
```txt
|
|
77
|
+
/arey-bootstrap --force
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Overwrites existing project-local Arey Pi agent files.
|
|
81
|
+
It also creates a starter `AGENTS.md` when one does not already exist.
|
|
82
|
+
|
|
83
|
+
Use this command after installing Arey Pi and `pi-subagents` in a repository where you want the Arey Pi agents to be discoverable by `pi-subagents`.
|
|
84
|
+
|
|
85
|
+
## `/arey-feature`
|
|
86
|
+
|
|
87
|
+
Starts the Arey Pi feature delivery workflow.
|
|
88
|
+
|
|
89
|
+
Usage:
|
|
90
|
+
|
|
91
|
+
```txt
|
|
92
|
+
/arey-feature <feature request>
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Example:
|
|
96
|
+
|
|
97
|
+
```txt
|
|
98
|
+
/arey-feature Add password reset with expiring email links
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
The command sends a structured request to the parent agent to act as the Arey Pi tech lead.
|
|
102
|
+
The expected workflow is:
|
|
103
|
+
|
|
104
|
+
```txt
|
|
105
|
+
spec-author → tdd-implementer → spec-syncer → engineering-reviewer
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
The workflow should:
|
|
109
|
+
|
|
110
|
+
- confirm or update canonical specs;
|
|
111
|
+
- preserve TDD through Red → Green → Refactor;
|
|
112
|
+
- synchronise specs, docs, tests, code, DBML, ADRs, glossary, and architecture docs;
|
|
113
|
+
- run engineering review when risk warrants it;
|
|
114
|
+
- report validation evidence and residual risks.
|
|
115
|
+
|
|
116
|
+
## `/arey-bugfix`
|
|
117
|
+
|
|
118
|
+
Starts the Arey Pi regression-test-first bugfix workflow.
|
|
119
|
+
|
|
120
|
+
Usage:
|
|
121
|
+
|
|
122
|
+
```txt
|
|
123
|
+
/arey-bugfix <bug description>
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
Example:
|
|
127
|
+
|
|
128
|
+
```txt
|
|
129
|
+
/arey-bugfix Users can bypass email verification by refreshing the session
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
The workflow should:
|
|
133
|
+
|
|
134
|
+
- reproduce the bug with a failing regression test;
|
|
135
|
+
- implement the smallest high-quality fix;
|
|
136
|
+
- keep TDD evidence visible;
|
|
137
|
+
- update Gherkin, docs, DBML, ADRs, glossary, or architecture docs when affected;
|
|
138
|
+
- run validation and report residual risks.
|
|
139
|
+
|
|
140
|
+
## `/arey-sync`
|
|
141
|
+
|
|
142
|
+
Runs Arey Pi sync review for the current repository or a specific scope.
|
|
143
|
+
|
|
144
|
+
Usage:
|
|
145
|
+
|
|
146
|
+
```txt
|
|
147
|
+
/arey-sync
|
|
148
|
+
/arey-sync <scope>
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Examples:
|
|
152
|
+
|
|
153
|
+
```txt
|
|
154
|
+
/arey-sync
|
|
155
|
+
/arey-sync authentication flow
|
|
156
|
+
/arey-sync current diff
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
The command asks the parent agent to verify alignment across:
|
|
160
|
+
|
|
161
|
+
- Gherkin specs;
|
|
162
|
+
- tests;
|
|
163
|
+
- code;
|
|
164
|
+
- DBML;
|
|
165
|
+
- ADRs;
|
|
166
|
+
- glossary;
|
|
167
|
+
- architecture docs;
|
|
168
|
+
- README files;
|
|
169
|
+
- `docs/`;
|
|
170
|
+
- `AGENTS.md`;
|
|
171
|
+
- skills, prompts, rules, agents, examples, templates;
|
|
172
|
+
- command and tooling instructions.
|
|
173
|
+
|
|
174
|
+
The final report should include both:
|
|
175
|
+
|
|
176
|
+
```txt
|
|
177
|
+
Specs updated
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
or:
|
|
181
|
+
|
|
182
|
+
```txt
|
|
183
|
+
Specs unaffected: <reason>
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
and:
|
|
187
|
+
|
|
188
|
+
```txt
|
|
189
|
+
Docs updated
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
or:
|
|
193
|
+
|
|
194
|
+
```txt
|
|
195
|
+
Docs unaffected: <reason>
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
## `/arey-review`
|
|
199
|
+
|
|
200
|
+
Runs an adversarial Arey Pi engineering review.
|
|
201
|
+
|
|
202
|
+
Usage:
|
|
203
|
+
|
|
204
|
+
```txt
|
|
205
|
+
/arey-review
|
|
206
|
+
/arey-review <scope>
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
Examples:
|
|
210
|
+
|
|
211
|
+
```txt
|
|
212
|
+
/arey-review
|
|
213
|
+
/arey-review current diff
|
|
214
|
+
/arey-review persistence layer
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
The review should examine:
|
|
218
|
+
|
|
219
|
+
- architecture and code quality;
|
|
220
|
+
- test quality;
|
|
221
|
+
- quality tooling and validation evidence;
|
|
222
|
+
- security and privacy;
|
|
223
|
+
- reliability and operability;
|
|
224
|
+
- maintainability;
|
|
225
|
+
- spec, ADR, DBML, glossary, and documentation sync concerns;
|
|
226
|
+
- generated-code or agent-authored-code slop.
|
|
227
|
+
|
|
228
|
+
Findings should be classified by severity.
|
|
229
|
+
|
|
230
|
+
## `/arey-assess`
|
|
231
|
+
|
|
232
|
+
Runs Arey Pi project readiness assessment.
|
|
233
|
+
|
|
234
|
+
Usage:
|
|
235
|
+
|
|
236
|
+
```txt
|
|
237
|
+
/arey-assess
|
|
238
|
+
/arey-assess <scope>
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
Examples:
|
|
242
|
+
|
|
243
|
+
```txt
|
|
244
|
+
/arey-assess
|
|
245
|
+
/arey-assess backend package only
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
The assessment is read-only by default.
|
|
249
|
+
It should score the repository against Arey Pi rules,
|
|
250
|
+
provide evidence with file paths,
|
|
251
|
+
identify blockers and quick wins,
|
|
252
|
+
and propose a prioritised improvement plan.
|
|
253
|
+
|
|
254
|
+
Use this when adopting Arey Pi in an existing repository or checking whether a project remains aligned.
|
|
255
|
+
|
|
256
|
+
## Busy agent behaviour
|
|
257
|
+
|
|
258
|
+
Workflow commands send a user message to the current Pi session.
|
|
259
|
+
|
|
260
|
+
If the agent is idle,
|
|
261
|
+
the workflow starts immediately.
|
|
262
|
+
|
|
263
|
+
If the agent is already working,
|
|
264
|
+
the workflow is queued as a follow-up message.
|
|
265
|
+
|
|
266
|
+
## Relationship to natural language
|
|
267
|
+
|
|
268
|
+
Commands are optional.
|
|
269
|
+
|
|
270
|
+
Users can also work naturally:
|
|
271
|
+
|
|
272
|
+
```txt
|
|
273
|
+
Implement magic links following Arey Pi.
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
The commands exist to make common workflows explicit,
|
|
277
|
+
repeatable,
|
|
278
|
+
and easier to discover.
|
|
@@ -0,0 +1,268 @@
|
|
|
1
|
+
import { copyFileSync, existsSync, mkdirSync, readFileSync, statSync, writeFileSync } from "node:fs";
|
|
2
|
+
import { dirname, join, relative } from "node:path";
|
|
3
|
+
import { fileURLToPath } from "node:url";
|
|
4
|
+
import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
|
|
5
|
+
|
|
6
|
+
const packageRoot = dirname(dirname(fileURLToPath(import.meta.url)));
|
|
7
|
+
const agentSourceDir = join(packageRoot, "agents");
|
|
8
|
+
const rulesDir = join(packageRoot, "rules");
|
|
9
|
+
const requiredAgents = [
|
|
10
|
+
"tech-lead.md",
|
|
11
|
+
"spec-author.md",
|
|
12
|
+
"tdd-implementer.md",
|
|
13
|
+
"spec-syncer.md",
|
|
14
|
+
"engineering-reviewer.md",
|
|
15
|
+
"project-evaluator.md",
|
|
16
|
+
];
|
|
17
|
+
|
|
18
|
+
function cwdFrom(ctx: unknown): string {
|
|
19
|
+
const maybe = ctx as { cwd?: string };
|
|
20
|
+
return maybe.cwd ?? process.cwd();
|
|
21
|
+
}
|
|
22
|
+
|
|
23
|
+
function fileExists(path: string): boolean {
|
|
24
|
+
try {
|
|
25
|
+
return existsSync(path) && statSync(path).isFile();
|
|
26
|
+
} catch {
|
|
27
|
+
return false;
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
function dirExists(path: string): boolean {
|
|
32
|
+
try {
|
|
33
|
+
return existsSync(path) && statSync(path).isDirectory();
|
|
34
|
+
} catch {
|
|
35
|
+
return false;
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
|
|
39
|
+
function copyAgents(targetDir: string, force: boolean): { copied: string[]; skipped: string[]; missing: string[] } {
|
|
40
|
+
mkdirSync(targetDir, { recursive: true });
|
|
41
|
+
|
|
42
|
+
const copied: string[] = [];
|
|
43
|
+
const skipped: string[] = [];
|
|
44
|
+
const missing: string[] = [];
|
|
45
|
+
|
|
46
|
+
for (const agent of requiredAgents) {
|
|
47
|
+
const source = join(agentSourceDir, agent);
|
|
48
|
+
const target = join(targetDir, agent);
|
|
49
|
+
|
|
50
|
+
if (!fileExists(source)) {
|
|
51
|
+
missing.push(agent);
|
|
52
|
+
continue;
|
|
53
|
+
}
|
|
54
|
+
|
|
55
|
+
if (fileExists(target) && !force) {
|
|
56
|
+
skipped.push(agent);
|
|
57
|
+
continue;
|
|
58
|
+
}
|
|
59
|
+
|
|
60
|
+
copyFileSync(source, target);
|
|
61
|
+
copied.push(agent);
|
|
62
|
+
}
|
|
63
|
+
|
|
64
|
+
return { copied, skipped, missing };
|
|
65
|
+
}
|
|
66
|
+
|
|
67
|
+
function starterAgentsMd(): string {
|
|
68
|
+
return `# Agent Instructions
|
|
69
|
+
|
|
70
|
+
This project uses Arey Pi.
|
|
71
|
+
|
|
72
|
+
## Delivery rules
|
|
73
|
+
|
|
74
|
+
- Treat canonical specs as the source of truth.
|
|
75
|
+
- Use Gherkin for behaviour specs.
|
|
76
|
+
- Use DBML for database specs when the project has persistence.
|
|
77
|
+
- Follow TDD for production behaviour changes.
|
|
78
|
+
- Keep specs, tests, code, DBML, ADRs, glossary, and architecture docs synchronised.
|
|
79
|
+
- Capture significant technical decisions in high-quality ADRs.
|
|
80
|
+
- Run formatter, lint/static analysis, typecheck, tests, and relevant dynamic analysis where available.
|
|
81
|
+
- Use incremental Conventional Commits for meaningful steps.
|
|
82
|
+
|
|
83
|
+
## Subagents
|
|
84
|
+
|
|
85
|
+
Project-local Arey Pi subagents live in:
|
|
86
|
+
|
|
87
|
+
\`\`\`txt
|
|
88
|
+
.pi/agents/arey-pi/
|
|
89
|
+
\`\`\`
|
|
90
|
+
|
|
91
|
+
Use them through pi-subagents when available.
|
|
92
|
+
`;
|
|
93
|
+
}
|
|
94
|
+
|
|
95
|
+
function workflowMessage(kind: string, args: string): string {
|
|
96
|
+
const target = args.trim() || "the current repository/task";
|
|
97
|
+
const common = `Act as the Arey Pi tech lead. Use pi-subagents when available and appropriate. Keep orchestration authority in the parent session. Follow Arey Pi rules, preserve TDD, and report evidence clearly.`;
|
|
98
|
+
|
|
99
|
+
switch (kind) {
|
|
100
|
+
case "feature":
|
|
101
|
+
return `${common}\n\nRun the Arey Pi feature workflow for: ${target}\n\nExpected flow: spec-author for canonical specs, tdd-implementer for Red-Green-Refactor, spec-syncer for final alignment, and engineering-reviewer for adversarial quality review when risk warrants it.`;
|
|
102
|
+
case "bugfix":
|
|
103
|
+
return `${common}\n\nRun the Arey Pi bugfix workflow for: ${target}\n\nStart with a regression test that fails for the bug, then implement the minimal high-quality fix, synchronise specs, and review engineering quality.`;
|
|
104
|
+
case "sync":
|
|
105
|
+
return `${common}\n\nRun Arey Pi spec and documentation sync for: ${target}\n\nVerify Gherkin, tests, code, DBML, ADRs, glossary, architecture docs, README files, docs, AGENTS.md, skills, prompts, rules, agents, commands, and tooling instructions. End with both a spec status and a documentation status.`;
|
|
106
|
+
case "review":
|
|
107
|
+
return `${common}\n\nRun an Arey Pi engineering review for: ${target}\n\nReview architecture, code quality, test quality, quality tooling, security, privacy, operability, maintainability, and spec/ADR/DBML concerns. Classify findings by severity.`;
|
|
108
|
+
case "assess":
|
|
109
|
+
return `${common}\n\nAssess this repository against Arey Pi Project Readiness. Audit only by default. Produce scores, evidence, blockers, quick wins, and a prioritised improvement plan.`;
|
|
110
|
+
default:
|
|
111
|
+
return `${common}\n\nWork on: ${target}`;
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
|
|
115
|
+
function sendWorkflow(
|
|
116
|
+
pi: ExtensionAPI,
|
|
117
|
+
args: string,
|
|
118
|
+
ctx: {
|
|
119
|
+
ui: { notify(message: string, level?: string): void };
|
|
120
|
+
isIdle(): boolean;
|
|
121
|
+
},
|
|
122
|
+
kind: string,
|
|
123
|
+
usage: string,
|
|
124
|
+
) {
|
|
125
|
+
if (!args.trim()) {
|
|
126
|
+
ctx.ui.notify(usage, "warning");
|
|
127
|
+
return;
|
|
128
|
+
}
|
|
129
|
+
|
|
130
|
+
const message = workflowMessage(kind, args);
|
|
131
|
+
if (ctx.isIdle()) {
|
|
132
|
+
pi.sendUserMessage(message);
|
|
133
|
+
} else {
|
|
134
|
+
pi.sendUserMessage(message, { deliverAs: "followUp" });
|
|
135
|
+
ctx.ui.notify("Arey Pi workflow queued as follow-up", "info");
|
|
136
|
+
}
|
|
137
|
+
}
|
|
138
|
+
|
|
139
|
+
function packageVersion(): string {
|
|
140
|
+
try {
|
|
141
|
+
const pkg = JSON.parse(readFileSync(join(packageRoot, "package.json"), "utf8")) as { version?: string };
|
|
142
|
+
return pkg.version ?? "unknown";
|
|
143
|
+
} catch {
|
|
144
|
+
return "unknown";
|
|
145
|
+
}
|
|
146
|
+
}
|
|
147
|
+
|
|
148
|
+
export default function areyPi(pi: ExtensionAPI) {
|
|
149
|
+
pi.registerCommand("arey-doctor", {
|
|
150
|
+
description: "Check Arey Pi package, project bootstrap, and subagent readiness",
|
|
151
|
+
handler: async (_args, ctx) => {
|
|
152
|
+
const cwd = cwdFrom(ctx);
|
|
153
|
+
const projectAgentDir = join(cwd, ".pi", "agents", "arey-pi");
|
|
154
|
+
const commands = pi.getCommands();
|
|
155
|
+
const hasSubagentsCommand = commands.some((command) => command.name.startsWith("subagents-doctor"));
|
|
156
|
+
const installedAgents = requiredAgents.filter((agent) => fileExists(join(projectAgentDir, agent)));
|
|
157
|
+
const missingAgents = requiredAgents.filter((agent) => !fileExists(join(projectAgentDir, agent)));
|
|
158
|
+
const packageAgents = requiredAgents.filter((agent) => fileExists(join(agentSourceDir, agent)));
|
|
159
|
+
const prompts = commands.filter(
|
|
160
|
+
(command) => command.source === "prompt" && command.sourceInfo?.source?.includes("arey-pi"),
|
|
161
|
+
);
|
|
162
|
+
const skills = commands.filter(
|
|
163
|
+
(command) => command.source === "skill" && command.sourceInfo?.source?.includes("arey-pi"),
|
|
164
|
+
);
|
|
165
|
+
|
|
166
|
+
const report = [
|
|
167
|
+
"# Arey Pi Doctor",
|
|
168
|
+
"",
|
|
169
|
+
`- Package: arey-pi@${packageVersion()}`,
|
|
170
|
+
`- Project: ${cwd}`,
|
|
171
|
+
`- Package rules present: ${dirExists(rulesDir) ? "yes" : "no"}`,
|
|
172
|
+
`- Package agents present: ${packageAgents.length}/${requiredAgents.length}`,
|
|
173
|
+
`- pi-subagents command detected: ${hasSubagentsCommand ? "yes" : "no"}`,
|
|
174
|
+
`- Project-local Arey Pi agents: ${installedAgents.length}/${requiredAgents.length}`,
|
|
175
|
+
`- Root AGENTS.md: ${fileExists(join(cwd, "AGENTS.md")) ? "yes" : "no"}`,
|
|
176
|
+
`- .pi/settings.json: ${fileExists(join(cwd, ".pi", "settings.json")) ? "yes" : "no"}`,
|
|
177
|
+
`- Arey Pi prompts discovered: ${prompts.length}`,
|
|
178
|
+
`- Arey Pi skills discovered: ${skills.length}`,
|
|
179
|
+
"",
|
|
180
|
+
"## Missing project agents",
|
|
181
|
+
missingAgents.length ? missingAgents.map((agent) => `- ${agent}`).join("\n") : "- none",
|
|
182
|
+
"",
|
|
183
|
+
"## Recommended next step",
|
|
184
|
+
installedAgents.length === requiredAgents.length
|
|
185
|
+
? "- Project-local Arey Pi subagents are installed. Use `/arey-feature`, `/arey-bugfix`, `/arey-sync`, `/arey-review`, or natural language."
|
|
186
|
+
: "- Run `/arey-bootstrap` to install project-local Arey Pi subagents.",
|
|
187
|
+
].join("\n");
|
|
188
|
+
|
|
189
|
+
pi.sendMessage({
|
|
190
|
+
customType: "arey-pi-doctor",
|
|
191
|
+
content: report,
|
|
192
|
+
display: true,
|
|
193
|
+
details: {},
|
|
194
|
+
});
|
|
195
|
+
},
|
|
196
|
+
});
|
|
197
|
+
|
|
198
|
+
pi.registerCommand("arey-bootstrap", {
|
|
199
|
+
description: "Install Arey Pi project-local subagents and optional starter AGENTS.md",
|
|
200
|
+
handler: async (args, ctx) => {
|
|
201
|
+
const cwd = cwdFrom(ctx);
|
|
202
|
+
const force = args.split(/\s+/).includes("--force");
|
|
203
|
+
const createAgentsMd = args.split(/\s+/).includes("--agentsmd");
|
|
204
|
+
const targetDir = join(cwd, ".pi", "agents", "arey-pi");
|
|
205
|
+
const result = copyAgents(targetDir, force);
|
|
206
|
+
const agentsMdPath = join(cwd, "AGENTS.md");
|
|
207
|
+
let agentsMdStatus = "unchanged";
|
|
208
|
+
|
|
209
|
+
if (!fileExists(agentsMdPath) && (createAgentsMd || force)) {
|
|
210
|
+
writeFileSync(agentsMdPath, starterAgentsMd());
|
|
211
|
+
agentsMdStatus = "created";
|
|
212
|
+
}
|
|
213
|
+
|
|
214
|
+
const report = [
|
|
215
|
+
"# Arey Pi Bootstrap",
|
|
216
|
+
"",
|
|
217
|
+
`- Target: ${relative(cwd, targetDir)}`,
|
|
218
|
+
`- Copied agents: ${result.copied.length}`,
|
|
219
|
+
`- Skipped existing agents: ${result.skipped.length}`,
|
|
220
|
+
`- Missing package agents: ${result.missing.length}`,
|
|
221
|
+
`- AGENTS.md: ${agentsMdStatus}`,
|
|
222
|
+
"",
|
|
223
|
+
"## Copied",
|
|
224
|
+
result.copied.length ? result.copied.map((agent) => `- ${agent}`).join("\n") : "- none",
|
|
225
|
+
"",
|
|
226
|
+
"## Skipped",
|
|
227
|
+
result.skipped.length ? result.skipped.map((agent) => `- ${agent}`).join("\n") : "- none",
|
|
228
|
+
"",
|
|
229
|
+
"Run `/arey-doctor` to verify setup.",
|
|
230
|
+
].join("\n");
|
|
231
|
+
|
|
232
|
+
pi.sendMessage({
|
|
233
|
+
customType: "arey-pi-bootstrap",
|
|
234
|
+
content: report,
|
|
235
|
+
display: true,
|
|
236
|
+
details: result,
|
|
237
|
+
});
|
|
238
|
+
},
|
|
239
|
+
});
|
|
240
|
+
|
|
241
|
+
pi.registerCommand("arey-feature", {
|
|
242
|
+
description: "Run an Arey Pi spec-to-TDD feature workflow",
|
|
243
|
+
handler: async (args, ctx) => sendWorkflow(pi, args, ctx, "feature", "Usage: /arey-feature <feature request>"),
|
|
244
|
+
});
|
|
245
|
+
|
|
246
|
+
pi.registerCommand("arey-bugfix", {
|
|
247
|
+
description: "Run an Arey Pi regression-test-first bugfix workflow",
|
|
248
|
+
handler: async (args, ctx) => sendWorkflow(pi, args, ctx, "bugfix", "Usage: /arey-bugfix <bug description>"),
|
|
249
|
+
});
|
|
250
|
+
|
|
251
|
+
pi.registerCommand("arey-sync", {
|
|
252
|
+
description: "Run Arey Pi spec, test, code, DBML, ADR, and glossary sync",
|
|
253
|
+
handler: async (args, ctx) =>
|
|
254
|
+
sendWorkflow(pi, args || "the current repository", ctx, "sync", "Usage: /arey-sync [scope]"),
|
|
255
|
+
});
|
|
256
|
+
|
|
257
|
+
pi.registerCommand("arey-review", {
|
|
258
|
+
description: "Run an Arey Pi adversarial engineering review",
|
|
259
|
+
handler: async (args, ctx) =>
|
|
260
|
+
sendWorkflow(pi, args || "the current diff", ctx, "review", "Usage: /arey-review [scope]"),
|
|
261
|
+
});
|
|
262
|
+
|
|
263
|
+
pi.registerCommand("arey-assess", {
|
|
264
|
+
description: "Assess project readiness against Arey Pi rules",
|
|
265
|
+
handler: async (args, ctx) =>
|
|
266
|
+
sendWorkflow(pi, args || "the current repository", ctx, "assess", "Usage: /arey-assess [scope]"),
|
|
267
|
+
});
|
|
268
|
+
}
|
package/package.json
CHANGED
|
@@ -1,10 +1,11 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "arey-pi",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.2.0",
|
|
4
4
|
"description": "A Pi package for canonical Gherkin specs, non-negotiable TDD, spec synchronisation, AI harness readiness, and senior-quality software delivery.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Alejandro Rey Leyva",
|
|
7
7
|
"type": "module",
|
|
8
|
+
"packageManager": "bun@1.3.10",
|
|
8
9
|
"repository": {
|
|
9
10
|
"type": "git",
|
|
10
11
|
"url": "git+ssh://git@github.com/alereyleyva/arey-pi.git"
|
|
@@ -23,6 +24,8 @@
|
|
|
23
24
|
],
|
|
24
25
|
"files": [
|
|
25
26
|
"agents/",
|
|
27
|
+
"extensions/",
|
|
28
|
+
"docs/",
|
|
26
29
|
"skills/",
|
|
27
30
|
"prompts/",
|
|
28
31
|
"rules/",
|
|
@@ -31,6 +34,9 @@
|
|
|
31
34
|
"LICENSE"
|
|
32
35
|
],
|
|
33
36
|
"pi": {
|
|
37
|
+
"extensions": [
|
|
38
|
+
"./extensions/arey-pi.ts"
|
|
39
|
+
],
|
|
34
40
|
"skills": [
|
|
35
41
|
"./skills"
|
|
36
42
|
],
|
|
@@ -39,10 +45,27 @@
|
|
|
39
45
|
]
|
|
40
46
|
},
|
|
41
47
|
"scripts": {
|
|
42
|
-
"
|
|
43
|
-
"
|
|
48
|
+
"format": "biome format --write .",
|
|
49
|
+
"lint": "biome lint .",
|
|
50
|
+
"typecheck": "tsc --noEmit",
|
|
51
|
+
"check": "bun run lint && bun run typecheck",
|
|
52
|
+
"prepublishOnly": "bun run check && npm pack --dry-run"
|
|
53
|
+
},
|
|
54
|
+
"peerDependencies": {
|
|
55
|
+
"@earendil-works/pi-coding-agent": "*"
|
|
56
|
+
},
|
|
57
|
+
"peerDependenciesMeta": {
|
|
58
|
+
"@earendil-works/pi-coding-agent": {
|
|
59
|
+
"optional": true
|
|
60
|
+
}
|
|
44
61
|
},
|
|
45
62
|
"publishConfig": {
|
|
46
63
|
"access": "public"
|
|
64
|
+
},
|
|
65
|
+
"devDependencies": {
|
|
66
|
+
"@biomejs/biome": "^2.4.16",
|
|
67
|
+
"@earendil-works/pi-coding-agent": "^0.78.1",
|
|
68
|
+
"@types/node": "^25.9.2",
|
|
69
|
+
"typescript": "^6.0.3"
|
|
47
70
|
}
|
|
48
71
|
}
|
|
@@ -17,7 +17,7 @@ Evaluate alignment with Arey Pi rules:
|
|
|
17
17
|
- test quality, coverage, mutation testing readiness
|
|
18
18
|
- formatter/linter/static analysis/typecheck/dynamic validation
|
|
19
19
|
- architecture and code quality signals
|
|
20
|
-
- spec sync and Definition of Done
|
|
20
|
+
- spec sync, documentation sync, and Definition of Done
|
|
21
21
|
- DBML database specs when the project uses a database
|
|
22
22
|
- rebuildability and architecture memory
|
|
23
23
|
- Conventional Commits / incremental process
|
|
@@ -29,6 +29,7 @@ Read and apply these policies when present:
|
|
|
29
29
|
|
|
30
30
|
- `rules/assessment/project-readiness.md`
|
|
31
31
|
- `rules/workflow/ai-harness.md`
|
|
32
|
+
- `rules/workflow/documentation-sync.md`
|
|
32
33
|
- `rules/specs/database-specs.md`
|
|
33
34
|
- `rules/core/definition-of-done.md`
|
|
34
35
|
- `rules/engineering/test-quality.md`
|
package/rules/README.md
CHANGED
|
@@ -12,7 +12,7 @@ rules/
|
|
|
12
12
|
├── specs/ # canonical specs, Gherkin, DBML, spec sync, language style
|
|
13
13
|
├── engineering/ # TDD, test quality, code/architecture quality, tooling, rebuildability
|
|
14
14
|
├── architecture/ # architecture memory and ADR expectations
|
|
15
|
-
├── workflow/ # agent workflows, AI harness, commits
|
|
15
|
+
├── workflow/ # agent workflows, documentation sync, AI harness, commits
|
|
16
16
|
└── assessment/ # project readiness evaluation
|
|
17
17
|
```
|
|
18
18
|
|
|
@@ -49,6 +49,7 @@ rules/
|
|
|
49
49
|
### Workflow
|
|
50
50
|
|
|
51
51
|
- `workflow/agent-workflows.md`
|
|
52
|
+
- `workflow/documentation-sync.md`
|
|
52
53
|
- `workflow/incremental-commits.md`
|
|
53
54
|
- `workflow/ai-harness.md`
|
|
54
55
|
|
|
@@ -81,7 +81,7 @@ Check whether:
|
|
|
81
81
|
- the implementation reflects senior engineering standards;
|
|
82
82
|
- generated or agent-authored code has been reviewed for quality.
|
|
83
83
|
|
|
84
|
-
### Spec Sync
|
|
84
|
+
### Spec and Documentation Sync
|
|
85
85
|
|
|
86
86
|
Check whether:
|
|
87
87
|
|
|
@@ -89,6 +89,7 @@ Check whether:
|
|
|
89
89
|
- behaviour changes have corresponding Gherkin updates or no-impact reasoning;
|
|
90
90
|
- database changes have precise DBML updates or no-impact reasoning;
|
|
91
91
|
- architecture/ADR/glossary updates exist when durable knowledge changed;
|
|
92
|
+
- README files, docs, AGENTS.md, skills, prompts, rules, agents, examples, templates, commands, and tooling instructions are updated when affected;
|
|
92
93
|
- Definition of Done expectations are documented.
|
|
93
94
|
|
|
94
95
|
### Database Specs
|
|
@@ -24,6 +24,7 @@ A change is complete when:
|
|
|
24
24
|
- architecture docs or high-quality ADRs are updated when durable decisions changed;
|
|
25
25
|
- DBML database specs exist and are precisely synchronised when the project has a database and the change touches schema, migrations, ORM models, or persistence contracts;
|
|
26
26
|
- glossary is updated when domain language changed;
|
|
27
|
+
- README files, docs, AGENTS.md, skills, prompts, rules, agents, examples, templates, commands, and tooling instructions are updated when affected or explicitly confirmed unaffected;
|
|
27
28
|
- code changes are scoped and minimal for the intended behaviour;
|
|
28
29
|
- project-facing prose follows the configured language style, UK English by default;
|
|
29
30
|
- specs use semantic line breaks, and touched documentation preserves or improves semantic line breaks;
|
|
@@ -45,6 +46,7 @@ A change is not done if:
|
|
|
45
46
|
- the project lacks quality tooling and the gap has not been surfaced to the user;
|
|
46
47
|
- significant technical decisions exist only in chat, implementation comments, or low-value ADRs that do not explain context, options, tradeoffs, and consequences;
|
|
47
48
|
- project-facing prose mixes language styles without reason;
|
|
49
|
+
- usage, setup, workflow, command, tooling, or agent documentation is stale after the change;
|
|
48
50
|
- specs or touched docs ignore semantic line break conventions;
|
|
49
51
|
- unrelated cleanup is mixed into the change without approval.
|
|
50
52
|
|
|
@@ -59,6 +61,7 @@ Done summary:
|
|
|
59
61
|
- Validation:
|
|
60
62
|
- Quality tooling:
|
|
61
63
|
- Spec sync:
|
|
64
|
+
- Documentation sync:
|
|
62
65
|
- Architecture/code quality:
|
|
63
66
|
- Architecture/ADR/glossary:
|
|
64
67
|
- Database/DBML:
|
package/rules/specs/spec-sync.md
CHANGED
|
@@ -32,6 +32,7 @@ At task completion, agents must consider each canonical dimension:
|
|
|
32
32
|
- **Database/DBML:** Did migrations, ORM models, SQL DDL, schema definitions, indexes, constraints, relationships, or persistence contracts change?
|
|
33
33
|
- **ADRs:** Was a meaningful technical decision made that future agents/developers need to understand, and is it important enough for a high-quality ADR rather than process noise?
|
|
34
34
|
- **Glossary:** Was a new domain term introduced or an existing meaning changed?
|
|
35
|
+
- **Documentation:** Did README files, docs, AGENTS.md, skills, prompts, rules, agents, examples, templates, commands, or tooling instructions change or need to change?
|
|
35
36
|
|
|
36
37
|
## Required Behaviour
|
|
37
38
|
|
|
@@ -43,7 +44,9 @@ If database structure changed, update the canonical DBML spec precisely.
|
|
|
43
44
|
|
|
44
45
|
If durable domain language changed, update the glossary.
|
|
45
46
|
|
|
46
|
-
If
|
|
47
|
+
If usage, setup, commands, agent instructions, tooling, or project workflow changed, update documentation or explicitly confirm docs are unaffected.
|
|
48
|
+
|
|
49
|
+
If only implementation changed and behaviour stayed the same, explain why specs and docs are unaffected and name the coverage relied on where practical.
|
|
47
50
|
|
|
48
51
|
## Conflict Handling
|
|
49
52
|
|
|
@@ -66,5 +69,6 @@ Spec sync:
|
|
|
66
69
|
- Architecture/ADR:
|
|
67
70
|
- Database/DBML:
|
|
68
71
|
- Glossary:
|
|
72
|
+
- Documentation:
|
|
69
73
|
- Status:
|
|
70
74
|
```
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
# Documentation Sync
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Documentation sync ensures that project-facing instructions and operational knowledge stay aligned with the change that was made.
|
|
6
|
+
|
|
7
|
+
It complements spec sync.
|
|
8
|
+
Specs preserve canonical product and system intent.
|
|
9
|
+
Documentation sync preserves how humans and agents understand, use, operate, and extend the project.
|
|
10
|
+
|
|
11
|
+
## Core Rule
|
|
12
|
+
|
|
13
|
+
Every completed change must consider whether documentation needs to be updated.
|
|
14
|
+
|
|
15
|
+
The final result must include one of:
|
|
16
|
+
|
|
17
|
+
```txt
|
|
18
|
+
Docs updated
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
or:
|
|
22
|
+
|
|
23
|
+
```txt
|
|
24
|
+
Docs unaffected: <reason>
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Do not leave users, maintainers, or future agents with stale instructions.
|
|
28
|
+
|
|
29
|
+
## Documentation Dimensions
|
|
30
|
+
|
|
31
|
+
At task completion, agents must consider whether the change affects:
|
|
32
|
+
|
|
33
|
+
- `README.md` files;
|
|
34
|
+
- `docs/` content;
|
|
35
|
+
- root or nested `AGENTS.md` files;
|
|
36
|
+
- Pi prompts, skills, rules, agents, or extension docs;
|
|
37
|
+
- developer setup, commands, package manager, tooling, or validation instructions;
|
|
38
|
+
- public API, CLI, configuration, environment variables, or deployment instructions;
|
|
39
|
+
- architecture overview docs;
|
|
40
|
+
- ADR indexes or decision references;
|
|
41
|
+
- troubleshooting, operational runbooks, or release notes;
|
|
42
|
+
- examples, templates, or onboarding material.
|
|
43
|
+
|
|
44
|
+
## Required Behaviour
|
|
45
|
+
|
|
46
|
+
If user-facing usage changes, update README or docs.
|
|
47
|
+
|
|
48
|
+
If agent behaviour, commands, safety rules, or project workflow changes, update `AGENTS.md`, skills, prompts, rules, or agent docs as appropriate.
|
|
49
|
+
|
|
50
|
+
If development commands, package manager, tooling, validation, or release process changes, update developer documentation.
|
|
51
|
+
|
|
52
|
+
If architecture or operational expectations change, update architecture docs, runbooks, or ADR references where appropriate.
|
|
53
|
+
|
|
54
|
+
If docs are unaffected, explain why in the final report.
|
|
55
|
+
|
|
56
|
+
## Quality Bar
|
|
57
|
+
|
|
58
|
+
Documentation updates must be accurate, minimal, and useful.
|
|
59
|
+
|
|
60
|
+
Agents must avoid:
|
|
61
|
+
|
|
62
|
+
- stale command examples;
|
|
63
|
+
- documenting features that do not exist;
|
|
64
|
+
- copying policy text into multiple places when a link or reference is better;
|
|
65
|
+
- broad doc rewrites unrelated to the change;
|
|
66
|
+
- mixing language styles;
|
|
67
|
+
- ignoring semantic line breaks in specs or touched docs.
|
|
68
|
+
|
|
69
|
+
## Relationship to Spec Sync
|
|
70
|
+
|
|
71
|
+
Spec sync answers whether canonical behaviour and durable project knowledge are aligned.
|
|
72
|
+
|
|
73
|
+
Documentation sync answers whether users, maintainers, and agents have the correct operational instructions.
|
|
74
|
+
|
|
75
|
+
Both checks are required before completion.
|
|
76
|
+
|
|
77
|
+
## Final Report Format
|
|
78
|
+
|
|
79
|
+
Agents should include documentation sync in final reports:
|
|
80
|
+
|
|
81
|
+
```txt
|
|
82
|
+
Documentation sync:
|
|
83
|
+
- README/docs:
|
|
84
|
+
- AGENTS.md/AI harness:
|
|
85
|
+
- Skills/prompts/rules/agents:
|
|
86
|
+
- Developer commands/tooling:
|
|
87
|
+
- Status:
|
|
88
|
+
```
|
|
@@ -68,6 +68,7 @@ Produce:
|
|
|
68
68
|
- Quality Tooling
|
|
69
69
|
- Engineering Quality
|
|
70
70
|
- Spec Sync
|
|
71
|
+
- Documentation Sync
|
|
71
72
|
- Database Specs, when applicable
|
|
72
73
|
- Rebuildability
|
|
73
74
|
- Architecture Memory
|
|
@@ -90,6 +91,7 @@ Only after user approval, implement selected improvements such as:
|
|
|
90
91
|
- adding spec directory skeletons;
|
|
91
92
|
- adding initial DBML skeletons for database projects;
|
|
92
93
|
- adding Arey Pi prompts or skills;
|
|
94
|
+
- updating stale README/docs/AGENTS.md instructions;
|
|
93
95
|
- documenting quality tooling;
|
|
94
96
|
- adding ADR/glossary structure.
|
|
95
97
|
|