agent-context-store 0.2.9 → 0.2.11
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
CHANGED
|
@@ -6,6 +6,8 @@ Agent Context Store (`acs`) is a Git-backed, schema-validated handoff toolkit th
|
|
|
6
6
|
|
|
7
7
|
Each role agent writes schema-validated documents — SRS, design docs, ADRs, API specs, test plans — with structured frontmatter into a Git-tracked store. A validated handoff record acts as the contract between agents; the receiving agent packages and reads it before starting work. Works with Cursor, Claude Code, Codex, CI pipelines, and any custom agent runtime.
|
|
8
8
|
|
|
9
|
+
`acs` is built on the same handoff principles formalized by the [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/), the [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/handoff) handoff orchestration, and Google's [Agent2Agent (A2A) protocol](https://github.com/a2aproject/A2A) — applied to the SDLC roles BA, SA, Dev, QA, and persisted to Git so handoffs survive across runtimes, sessions, and CI.
|
|
10
|
+
|
|
9
11
|
## Architecture
|
|
10
12
|
|
|
11
13
|
```mermaid
|
|
@@ -83,6 +85,21 @@ Run `acs init` in your project directory. When stdin is a terminal, an interacti
|
|
|
83
85
|
|
|
84
86
|
A summary is shown before anything is written, and you can abort with `n`.
|
|
85
87
|
|
|
88
|
+
Pass `--mode` to skip the wizard entirely:
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
acs init # wizard (TTY only)
|
|
92
|
+
acs init --mode in-repo # silent, creates .acs/ in current dir
|
|
93
|
+
acs init --mode local # silent, stores in OS user-data dir
|
|
94
|
+
acs init --mode dedicated . # silent, current dir is the store root
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
| Mode | Where context is stored | Best for |
|
|
98
|
+
|------|------------------------|----------|
|
|
99
|
+
| **in-repo** _(default)_ | `.acs/` inside your project | Most projects — context stays with code |
|
|
100
|
+
| **local** | OS user-data dir | Personal workflows, no repo changes |
|
|
101
|
+
| **dedicated** | This folder IS the store root | Multi-project teams, CI governance |
|
|
102
|
+
|
|
86
103
|
## Step 3: Run Your First Workflow
|
|
87
104
|
|
|
88
105
|
After setup, each team member opens their AI agent (Cursor or Claude Code) and invokes the matching role skill by name. The skill tells the agent exactly which `acs` commands to run — the human never types `acs` directly.
|
|
@@ -179,46 +196,9 @@ acs index
|
|
|
179
196
|
|
|
180
197
|
All four role artifacts and handoff records are now persisted in the store.
|
|
181
198
|
|
|
182
|
-
## How Agents Should Use It
|
|
183
|
-
|
|
184
|
-
Give each agent access to the same project (in-repo mode) or context store repository (dedicated mode) and instruct it to use `acs` for durable handoffs.
|
|
185
|
-
|
|
186
|
-
Suggested agent instruction:
|
|
187
|
-
|
|
188
|
-
```text
|
|
189
|
-
Use Agent Context Store for durable project context.
|
|
190
|
-
Before creating or handing off work, run acs status and acs validate.
|
|
191
|
-
Use acs roles, acs role explain, and acs next to follow the configured workflow.
|
|
192
|
-
Create task artifacts with acs new or acs <role> new.
|
|
193
|
-
Create role handoffs with acs handoff create.
|
|
194
|
-
Generate the next role package with acs package.
|
|
195
|
-
Commit context store changes to the configured Git repository.
|
|
196
|
-
```
|
|
197
|
-
|
|
198
199
|
## Context Store Layout
|
|
199
200
|
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
```text
|
|
203
|
-
.acs/
|
|
204
|
-
config.yaml
|
|
205
|
-
acs.yaml
|
|
206
|
-
index.json
|
|
207
|
-
audit/
|
|
208
|
-
artifacts/
|
|
209
|
-
<artifact-type>/
|
|
210
|
-
handoffs/
|
|
211
|
-
summaries/
|
|
212
|
-
packages/
|
|
213
|
-
roles/
|
|
214
|
-
artifact-types/
|
|
215
|
-
workflows/
|
|
216
|
-
schemas/
|
|
217
|
-
templates/
|
|
218
|
-
docs/
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
### Dedicated mode
|
|
201
|
+
The store root is `.acs/` in **in-repo** mode and `<store-root>/` in **dedicated** mode. Both use the same structure:
|
|
222
202
|
|
|
223
203
|
```text
|
|
224
204
|
<store-root>/
|
|
@@ -227,6 +207,7 @@ Commit context store changes to the configured Git repository.
|
|
|
227
207
|
index.json
|
|
228
208
|
audit/
|
|
229
209
|
artifacts/
|
|
210
|
+
<artifact-type>/
|
|
230
211
|
handoffs/
|
|
231
212
|
summaries/
|
|
232
213
|
packages/
|
|
@@ -238,37 +219,33 @@ Commit context store changes to the configured Git repository.
|
|
|
238
219
|
docs/
|
|
239
220
|
```
|
|
240
221
|
|
|
241
|
-
Important outputs:
|
|
242
|
-
|
|
243
222
|
- `artifacts/`: durable SDLC artifacts such as requirements, designs, ADRs, API notes, and test plans.
|
|
244
223
|
- `handoffs/`: explicit role-to-role handoff records.
|
|
245
224
|
- `packages/`: role-specific context bundles for the next agent.
|
|
246
225
|
- `index.json`: generated artifact and handoff index.
|
|
247
226
|
- `audit/`: local audit log for CLI-created changes.
|
|
248
227
|
|
|
249
|
-
In **in-repo mode** all paths above are inside `.acs/`.
|
|
250
|
-
|
|
251
228
|
## Commands
|
|
252
229
|
|
|
253
|
-
| Command | What it does |
|
|
254
|
-
| -------------------- | ------------------------------------------------------------------------------------------------------- |
|
|
255
|
-
| `acs --version` | Prints the installed CLI version. |
|
|
256
|
-
| `acs init` | Initializes the context store. Runs an interactive wizard on a TTY; pass `--mode` to skip it. |
|
|
257
|
-
| `acs status` | Shows current mode, store path, initialized state, and artifact/handoff counts. |
|
|
258
|
-
| `acs install-skills` | Installs agent-specific skill and instruction files for Cursor, Claude, Codex, or all supported agents. |
|
|
259
|
-
| `acs roles` | Lists configured role profiles
|
|
260
|
-
| `acs role explain` | Explains what a role can create/read and suggests task commands. |
|
|
261
|
-
| `acs next` | Shows missing inputs, suggested outputs, and next workflow commands. |
|
|
262
|
-
| `acs new` | Creates a configured SDLC artifact. |
|
|
263
|
-
| `acs validate` | Validates the context store structure, artifact metadata, schemas, and handoff records. |
|
|
264
|
-
| `acs handoff create` | Creates a role-to-role handoff record for a task. |
|
|
265
|
-
| `acs handoff check` | Validates a specific handoff before another agent relies on it. |
|
|
266
|
-
| `acs handoff list` | Lists handoff records, optionally filtered by task or role. |
|
|
267
|
-
| `acs package` | Builds a role-specific context package for the next agent or automation step. |
|
|
268
|
-
| `acs index` | Rebuilds `index.json` from artifacts and handoffs. |
|
|
269
|
-
| `acs doctor` | Runs the same validation checks as `acs validate` for quick health checks. |
|
|
270
|
-
|
|
271
|
-
###
|
|
230
|
+
| Command | What it does |
|
|
231
|
+
| -------------------- | ------------------------------------------------------------------------------------------------------- |
|
|
232
|
+
| `acs --version` | Prints the installed CLI version. |
|
|
233
|
+
| `acs init` | Initializes the context store. Runs an interactive wizard on a TTY; pass `--mode` to skip it. |
|
|
234
|
+
| `acs status` | Shows current mode, store path, initialized state, and artifact/handoff counts. |
|
|
235
|
+
| `acs install-skills` | Installs agent-specific skill and instruction files for Cursor, Claude, Codex, or all supported agents. |
|
|
236
|
+
| `acs roles` | Lists configured role profiles (`ba`, `sa`, `dev`, `qa`). |
|
|
237
|
+
| `acs role explain` | Explains what a role can create/read and suggests task commands. |
|
|
238
|
+
| `acs next` | Shows missing inputs, suggested outputs, and next workflow commands. |
|
|
239
|
+
| `acs new` | Creates a configured SDLC artifact. |
|
|
240
|
+
| `acs validate` | Validates the context store structure, artifact metadata, schemas, and handoff records. |
|
|
241
|
+
| `acs handoff create` | Creates a role-to-role handoff record for a task. |
|
|
242
|
+
| `acs handoff check` | Validates a specific handoff before another agent relies on it. |
|
|
243
|
+
| `acs handoff list` | Lists handoff records, optionally filtered by task or role. |
|
|
244
|
+
| `acs package` | Builds a role-specific context package for the next agent or automation step. |
|
|
245
|
+
| `acs index` | Rebuilds `index.json` from artifacts and handoffs. |
|
|
246
|
+
| `acs doctor` | Runs the same validation checks as `acs validate` for quick health checks. |
|
|
247
|
+
|
|
248
|
+
### Full syntax
|
|
272
249
|
|
|
273
250
|
```bash
|
|
274
251
|
acs --version
|
|
@@ -291,35 +268,6 @@ acs index
|
|
|
291
268
|
acs doctor
|
|
292
269
|
```
|
|
293
270
|
|
|
294
|
-
Common roles:
|
|
295
|
-
|
|
296
|
-
- `ba`
|
|
297
|
-
- `sa`
|
|
298
|
-
- `dev`
|
|
299
|
-
- `developer`
|
|
300
|
-
- `qa`
|
|
301
|
-
- `reviewer`
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
### Command - init
|
|
305
|
-
|
|
306
|
-
Pass `--mode` to skip the wizard entirely:
|
|
307
|
-
|
|
308
|
-
```bash
|
|
309
|
-
acs init # wizard (TTY only)
|
|
310
|
-
acs init --mode in-repo # silent, creates .acs/ in current dir
|
|
311
|
-
acs init --mode local # silent, stores in OS user-data dir
|
|
312
|
-
acs init --mode dedicated . # silent, current dir is the store root
|
|
313
|
-
```
|
|
314
|
-
|
|
315
|
-
`acs` supports three storage modes:
|
|
316
|
-
|
|
317
|
-
| Mode | Where context is stored | Best for |
|
|
318
|
-
|------|------------------------|----------|
|
|
319
|
-
| **in-repo** _(default)_ | `.acs/` inside your project | Most projects — context stays with code |
|
|
320
|
-
| **local** | OS user-data dir | Personal workflows, no repo changes |
|
|
321
|
-
| **dedicated** | This folder IS the store root | Multi-project teams, CI governance |
|
|
322
|
-
|
|
323
271
|
### Command - install-skills
|
|
324
272
|
|
|
325
273
|
The wizard offers to install skill files during `acs init`. You can also run this separately at any time:
|
|
@@ -342,6 +290,33 @@ acs install-skills --agent all --path /path/to/repo
|
|
|
342
290
|
|
|
343
291
|
Skill files are always replaced with the bundled version. If `AGENTS.md` or `CLAUDE.md` already exists, the installer appends to it.
|
|
344
292
|
|
|
293
|
+
|
|
294
|
+
## Aligned with Industry Handoff Standards
|
|
295
|
+
|
|
296
|
+
`acs` adopts the same handoff vocabulary used by the major agent frameworks — typed handoff records, dynamic role-to-role routing, full task ownership transfer, capability advertisement, and durable checkpointing — and grounds them in a Git-tracked store so the handoff itself becomes an auditable, reviewable artifact rather than an in-memory tool call.
|
|
297
|
+
|
|
298
|
+
| Concept | Industry definition | `acs` equivalent |
|
|
299
|
+
|---------|--------------------|------------------|
|
|
300
|
+
| **Typed handoff contract** | OpenAI's `handoff()` with `input_type` schema, `handoff_description`, and `on_handoff` callback validates the data passed between agents. [[#1]](#references) | `acs handoff create --from <ROLE> --to <ROLE> --task <TASK_ID>` writes a YAML record validated against a JSON schema; `acs handoff check` is the receiver-side guard equivalent to `on_handoff` validation. |
|
|
301
|
+
| **Context filtering on handoff** | OpenAI `input_filter` and Microsoft's `HandoffAgentExecutor` strip handoff tool calls before forwarding to the next agent. [[#1]](#references) [[#2]](#references) | `acs package --task <TASK_ID> --role <ROLE>` builds a role-scoped context bundle so the receiving agent reads only what is relevant to its job. |
|
|
302
|
+
| **Full task ownership transfer** | Microsoft Agent Framework: "the agent receiving the handoff takes full ownership of the task" (vs. agent-as-tools, where control returns). [[#2]](#references) | BA → SA → Dev → QA each take complete ownership of the task in their phase; control does not return to the previous role. |
|
|
303
|
+
| **Mesh topology, no central orchestrator** | Microsoft: agents are connected directly; each decides when to hand off. [[#2]](#references) | No orchestrator process — each role agent independently decides when its artifacts are complete and issues a handoff. The store is the shared substrate. |
|
|
304
|
+
| **Dynamic routing rules** | Microsoft `HandoffBuilder.add_handoff(...)` / `WithHandoffs(...)` declares which agents may route to which. [[#2]](#references) | `workflows/` and `roles/` in the store define the legal BA→SA→Dev→QA edges; `acs validate` rejects out-of-policy handoffs. |
|
|
305
|
+
| **Capability discovery (Agent Cards)** | A2A: agents advertise abilities via JSON Agent Cards so peers know what they can do. [[#3]](#references) | `acs roles` and `acs role explain <ROLE>` expose each role's inputs, outputs, and allowed artifact types — the role profile is the Agent Card. |
|
|
306
|
+
| **Tasks & artifacts as the unit of exchange** | A2A: communication centers on tasks with lifecycles; artifacts are the task outputs. [[#4]](#references) | Every `acs` operation is keyed by `--task <TASK_ID>`; `artifacts/` holds the schema-validated outputs of each role's task phase. |
|
|
307
|
+
| **Durable, resumable workflows** | Microsoft `checkpoint_storage` / `FileCheckpointStorage` lets workflows pause and resume hours or days later. [[#2]](#references) | The Git-tracked store *is* the checkpoint. Any agent on any machine can `git pull` and resume from the last validated handoff. |
|
|
308
|
+
| **Runtime-agnostic interoperability** | A2A: opaque agents on different frameworks collaborate without sharing memory or internal state. [[#4]](#references) | Cursor, Claude Code, Codex, and CI agents collaborate purely through validated artifacts and handoff records — no shared runtime, no shared memory. |
|
|
309
|
+
| **Auditable handoff history** | A2A emphasizes observability and auditability for enterprise use. [[#4]](#references) | `audit/`, `index.json`, `acs handoff list`, and Git history give a complete, reviewable trail of every handoff. |
|
|
310
|
+
|
|
311
|
+
In short: industry handoff frameworks model handoffs as in-process tool calls between live agent instances. `acs` models them as **persisted, schema-validated, Git-reviewable contracts** — making the same pattern work across role boundaries, agent runtimes, machines, and time.
|
|
312
|
+
|
|
313
|
+
### References
|
|
314
|
+
|
|
315
|
+
1. OpenAI Agents SDK — Handoffs: <https://openai.github.io/openai-agents-python/handoffs/>
|
|
316
|
+
2. Microsoft Agent Framework — Handoff Orchestration: <https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/handoff?pivots=programming-language-csharp>
|
|
317
|
+
3. Google Developers Blog — A2A: A new era of agent interoperability: <https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/>
|
|
318
|
+
4. A2A Project — Agent2Agent protocol repository: <https://github.com/a2aproject/A2A>
|
|
319
|
+
|
|
345
320
|
## Developing This Repository
|
|
346
321
|
|
|
347
322
|
If you want to modify or test the toolkit itself, see [DEVELOPMENT.md](DEVELOPMENT.md).
|
|
@@ -32,7 +32,27 @@ acs validate --role ba --task TASK-123
|
|
|
32
32
|
|
|
33
33
|
Do not proceed until validation passes.
|
|
34
34
|
|
|
35
|
-
## 4.
|
|
35
|
+
## 4. Request Approval
|
|
36
|
+
|
|
37
|
+
Ask the user or responsible stakeholder to review and approve the BA artifacts before handoff.
|
|
38
|
+
|
|
39
|
+
Do not create the SA handoff until all required BA artifacts are approved:
|
|
40
|
+
|
|
41
|
+
- SRS
|
|
42
|
+
- User story
|
|
43
|
+
- Acceptance criteria
|
|
44
|
+
|
|
45
|
+
If approval is granted, update each BA artifact frontmatter so `status: approved` and `approval_status: approved`.
|
|
46
|
+
|
|
47
|
+
Then re-run validation:
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
acs validate --role ba --task TASK-123
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
If approval is not granted, capture the requested changes in the artifacts and repeat validation before asking again.
|
|
54
|
+
|
|
55
|
+
## 5. Hand Off to SA
|
|
36
56
|
|
|
37
57
|
```bash
|
|
38
58
|
acs handoff create --from ba --to sa --task TASK-123
|
|
@@ -40,14 +60,14 @@ acs package --task TASK-123 --role sa
|
|
|
40
60
|
acs index
|
|
41
61
|
```
|
|
42
62
|
|
|
43
|
-
##
|
|
63
|
+
## 6. Output Handoff Prompt
|
|
44
64
|
|
|
45
|
-
|
|
65
|
+
Only after approval and handoff creation succeed, end your response with this prompt for the SA agent:
|
|
46
66
|
|
|
47
67
|
```
|
|
48
68
|
[HANDOFF: BA → SA | TASK-123]
|
|
49
69
|
|
|
50
|
-
The BA role has completed requirements for TASK-123.
|
|
70
|
+
The BA role has completed and received approval for requirements for TASK-123.
|
|
51
71
|
|
|
52
72
|
Artifacts ready for you:
|
|
53
73
|
- <path to SRS artifact>
|
|
@@ -19,13 +19,14 @@ acs handoff check --from sa --to dev --task TASK-123
|
|
|
19
19
|
acs package --task TASK-123 --role dev
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
## 2. Create
|
|
22
|
+
## 2. Create DEV Artifacts
|
|
23
23
|
|
|
24
24
|
```bash
|
|
25
25
|
acs dev new implementation-note --task TASK-123
|
|
26
|
+
acs dev new unit-test-note --task TASK-123
|
|
26
27
|
```
|
|
27
28
|
|
|
28
|
-
**Fill every section immediately** — document implementation decisions, deviations from the design, and any constraints discovered during development. List consulted files under `source_refs`. Complete the Validation Checklist at the end of
|
|
29
|
+
**Fill every section immediately** — document implementation decisions, deviations from the design, unit test coverage, and any constraints discovered during development. List consulted files under `source_refs`. Complete the Validation Checklist at the end of each file.
|
|
29
30
|
|
|
30
31
|
## 3. Validate
|
|
31
32
|
|
|
@@ -35,7 +36,24 @@ acs validate --role dev --task TASK-123
|
|
|
35
36
|
|
|
36
37
|
Do not proceed until validation passes.
|
|
37
38
|
|
|
38
|
-
## 4.
|
|
39
|
+
## 4. Mark Ready for Review
|
|
40
|
+
|
|
41
|
+
Do not create the QA handoff until all required DEV artifacts are ready for review:
|
|
42
|
+
|
|
43
|
+
- Implementation note
|
|
44
|
+
- Unit test note
|
|
45
|
+
|
|
46
|
+
Update each DEV artifact frontmatter so `status: ready_for_review`. Keep `approval_status: pending` unless a reviewer explicitly changes it.
|
|
47
|
+
|
|
48
|
+
Then re-run validation:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
acs validate --role dev --task TASK-123
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
If the work is not ready for review, capture the remaining tasks or blockers in the artifacts and repeat validation before handoff.
|
|
55
|
+
|
|
56
|
+
## 5. Hand Off to QA
|
|
39
57
|
|
|
40
58
|
```bash
|
|
41
59
|
acs handoff create --from dev --to qa --task TASK-123
|
|
@@ -43,9 +61,9 @@ acs package --task TASK-123 --role qa
|
|
|
43
61
|
acs index
|
|
44
62
|
```
|
|
45
63
|
|
|
46
|
-
##
|
|
64
|
+
## 6. Output Handoff Prompt
|
|
47
65
|
|
|
48
|
-
|
|
66
|
+
Only after the artifacts are marked ready for review and handoff creation succeeds, end your response with this prompt for the QA agent:
|
|
49
67
|
|
|
50
68
|
```
|
|
51
69
|
[HANDOFF: DEV → QA | TASK-123]
|
|
@@ -54,14 +72,16 @@ The DEV role has completed implementation for TASK-123.
|
|
|
54
72
|
|
|
55
73
|
Artifacts ready for you:
|
|
56
74
|
- <path to implementation note>
|
|
75
|
+
- <path to unit test note>
|
|
57
76
|
|
|
58
77
|
Context package: <path printed by acs package>
|
|
59
78
|
|
|
60
79
|
Your next steps (QA role):
|
|
61
80
|
1. Read the context package above.
|
|
62
81
|
2. Run: acs role explain qa --task TASK-123
|
|
63
|
-
3. Create
|
|
82
|
+
3. Create QA artifacts: acs qa new test-plan --task TASK-123 --title "<title>" and acs qa new qa-signoff --task TASK-123 --title "<title>"
|
|
64
83
|
4. Fill all sections, then validate: acs validate --role qa --task TASK-123
|
|
84
|
+
5. After approval, mark QA artifacts approved and hand off to SA: acs handoff create --from qa --to sa --task TASK-123
|
|
65
85
|
|
|
66
86
|
Open questions from DEV (resolve before or during testing):
|
|
67
87
|
- <list any open questions from the implementation note>
|
|
@@ -19,34 +19,70 @@ acs handoff check --from dev --to qa --task TASK-123
|
|
|
19
19
|
acs package --task TASK-123 --role qa
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
## 2. Create
|
|
22
|
+
## 2. Create QA Artifacts
|
|
23
23
|
|
|
24
24
|
```bash
|
|
25
25
|
acs qa new test-plan --task TASK-123 --title "Feature test plan"
|
|
26
|
+
acs qa new qa-signoff --task TASK-123 --title "Feature QA signoff"
|
|
26
27
|
```
|
|
27
28
|
|
|
28
|
-
**Fill every section immediately** — document test scope, test cases, acceptance criteria, and any risks. List consulted files under `source_refs`. Complete the Validation Checklist at the end of
|
|
29
|
+
**Fill every section immediately** — document test scope, test cases, acceptance criteria, signoff decision, and any risks. List consulted files under `source_refs`. Complete the Validation Checklist at the end of each file.
|
|
29
30
|
|
|
30
31
|
## 3. Validate
|
|
31
32
|
|
|
32
33
|
```bash
|
|
33
34
|
acs validate --role qa --task TASK-123
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Do not proceed until validation passes.
|
|
38
|
+
|
|
39
|
+
## 4. Request Approval
|
|
40
|
+
|
|
41
|
+
Ask the user or responsible stakeholder to review and approve the QA artifacts before handoff.
|
|
42
|
+
|
|
43
|
+
Do not create the SA handoff until all required QA artifacts are approved:
|
|
44
|
+
|
|
45
|
+
- Test plan
|
|
46
|
+
- QA signoff
|
|
47
|
+
|
|
48
|
+
If approval is granted, update each QA artifact frontmatter so `status: approved` and `approval_status: approved`.
|
|
49
|
+
|
|
50
|
+
Then re-run validation:
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
acs validate --role qa --task TASK-123
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
If approval is not granted, capture the requested changes in the artifacts and repeat validation before asking again.
|
|
57
|
+
|
|
58
|
+
## 5. Hand Off to SA
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
acs handoff create --from qa --to sa --task TASK-123
|
|
62
|
+
acs package --task TASK-123 --role sa
|
|
34
63
|
acs index
|
|
35
64
|
```
|
|
36
65
|
|
|
37
|
-
##
|
|
66
|
+
## 6. Output Handoff Prompt
|
|
38
67
|
|
|
39
|
-
|
|
68
|
+
Only after approval and handoff creation succeed, end your response with this prompt for the SA agent:
|
|
40
69
|
|
|
41
70
|
```
|
|
42
|
-
[
|
|
71
|
+
[HANDOFF: QA → SA | TASK-123]
|
|
43
72
|
|
|
44
|
-
QA has completed
|
|
73
|
+
The QA role has completed and received approval for QA validation for TASK-123.
|
|
45
74
|
|
|
46
|
-
Artifacts
|
|
75
|
+
Artifacts ready for you:
|
|
47
76
|
- <path to test plan>
|
|
77
|
+
- <path to QA signoff>
|
|
78
|
+
|
|
79
|
+
Context package: <path printed by acs package>
|
|
48
80
|
|
|
49
|
-
|
|
81
|
+
Your next steps (SA role):
|
|
82
|
+
1. Read the context package above.
|
|
83
|
+
2. Run: acs role explain sa --task TASK-123
|
|
84
|
+
3. Create the release readiness report: acs sa new release-readiness-report --task TASK-123 --title "<title>"
|
|
85
|
+
4. Fill all sections, then validate: acs validate --role sa --task TASK-123
|
|
50
86
|
|
|
51
87
|
Outstanding issues or risks:
|
|
52
88
|
- <list any issues found during QA, or "None">
|
|
@@ -21,7 +21,7 @@ acs package --task TASK-123 --role sa
|
|
|
21
21
|
|
|
22
22
|
## 2. Create SA Artifacts
|
|
23
23
|
|
|
24
|
-
Create
|
|
24
|
+
Create the required SA artifacts before handing off to DEV:
|
|
25
25
|
|
|
26
26
|
```bash
|
|
27
27
|
acs sa new sdd --task TASK-123 --title "Feature system design"
|
|
@@ -39,7 +39,27 @@ acs validate --role sa --task TASK-123
|
|
|
39
39
|
|
|
40
40
|
Do not proceed until validation passes.
|
|
41
41
|
|
|
42
|
-
## 4.
|
|
42
|
+
## 4. Request Approval
|
|
43
|
+
|
|
44
|
+
Ask the user or responsible stakeholder to review and approve the SA design artifacts before handoff.
|
|
45
|
+
|
|
46
|
+
Do not create the DEV handoff until all required design artifacts are approved:
|
|
47
|
+
|
|
48
|
+
- SDD
|
|
49
|
+
- ADR
|
|
50
|
+
- API design
|
|
51
|
+
|
|
52
|
+
If approval is granted, update each SA artifact frontmatter so `status: approved` and `approval_status: approved`.
|
|
53
|
+
|
|
54
|
+
Then re-run validation:
|
|
55
|
+
|
|
56
|
+
```bash
|
|
57
|
+
acs validate --role sa --task TASK-123
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
If approval is not granted, capture the requested changes in the artifacts and repeat validation before asking again.
|
|
61
|
+
|
|
62
|
+
## 5. Hand Off to DEV
|
|
43
63
|
|
|
44
64
|
```bash
|
|
45
65
|
acs handoff create --from sa --to dev --task TASK-123
|
|
@@ -47,14 +67,14 @@ acs package --task TASK-123 --role dev
|
|
|
47
67
|
acs index
|
|
48
68
|
```
|
|
49
69
|
|
|
50
|
-
##
|
|
70
|
+
## 6. Output Handoff Prompt
|
|
51
71
|
|
|
52
|
-
|
|
72
|
+
Only after approval and handoff creation succeed, end your response with this prompt for the DEV agent:
|
|
53
73
|
|
|
54
74
|
```
|
|
55
75
|
[HANDOFF: SA → DEV | TASK-123]
|
|
56
76
|
|
|
57
|
-
The SA role has completed the system design for TASK-123.
|
|
77
|
+
The SA role has completed and received approval for the system design for TASK-123.
|
|
58
78
|
|
|
59
79
|
Artifacts ready for you:
|
|
60
80
|
- <paths to SDD / ADR / API design artifacts>
|
|
@@ -64,9 +84,9 @@ Context package: <path printed by acs package>
|
|
|
64
84
|
Your next steps (DEV role):
|
|
65
85
|
1. Read the context package above.
|
|
66
86
|
2. Run: acs role explain dev --task TASK-123
|
|
67
|
-
3. Create
|
|
87
|
+
3. Create implementation artifacts: acs dev new implementation-note --task TASK-123 and acs dev new unit-test-note --task TASK-123
|
|
68
88
|
4. Fill all sections, then validate: acs validate --role dev --task TASK-123
|
|
69
|
-
5.
|
|
89
|
+
5. Mark DEV artifacts `status: ready_for_review`, re-validate, then hand off to QA: acs handoff create --from dev --to qa --task TASK-123
|
|
70
90
|
|
|
71
91
|
Open questions from SA (resolve before or during implementation):
|
|
72
92
|
- <list any open questions from the design artifacts>
|
package/package.json
CHANGED
|
@@ -1,9 +1,32 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "agent-context-store",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.11",
|
|
4
4
|
"description": "acs CLI for Agent Context Store Toolkit.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"license": "MIT",
|
|
7
|
+
"keywords": [
|
|
8
|
+
"ai",
|
|
9
|
+
"ai-agent",
|
|
10
|
+
"ai-agents",
|
|
11
|
+
"agentic-engineering",
|
|
12
|
+
"multi-agent",
|
|
13
|
+
"agent-handoff",
|
|
14
|
+
"a2a",
|
|
15
|
+
"agent2agent",
|
|
16
|
+
"context",
|
|
17
|
+
"context-store",
|
|
18
|
+
"context-engineering",
|
|
19
|
+
"sdlc",
|
|
20
|
+
"claude",
|
|
21
|
+
"claude-code",
|
|
22
|
+
"cursor",
|
|
23
|
+
"codex",
|
|
24
|
+
"openai-agents",
|
|
25
|
+
"agent-framework",
|
|
26
|
+
"schema-validated",
|
|
27
|
+
"git-backed",
|
|
28
|
+
"cli"
|
|
29
|
+
],
|
|
7
30
|
"homepage": "https://github.com/max9159/agent-context-store#readme",
|
|
8
31
|
"repository": {
|
|
9
32
|
"type": "git",
|
|
@@ -23,7 +46,7 @@
|
|
|
23
46
|
},
|
|
24
47
|
"dependencies": {
|
|
25
48
|
"@inquirer/prompts": "^8.4.2",
|
|
26
|
-
"agent-context-store-core": "0.2.
|
|
49
|
+
"agent-context-store-core": "0.2.11"
|
|
27
50
|
},
|
|
28
51
|
"scripts": {
|
|
29
52
|
"build": "tsc -p tsconfig.json"
|