cc-codeconductor 1.6.0 → 1.6.1

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.
Files changed (14) hide show
  1. package/README.md +5 -5
  2. package/dist/core/verification/rdd-receipt.d.ts +19 -0
  3. package/dist/core/verification/verification-runner.d.ts +16 -0
  4. package/dist/index.js +343 -245
  5. package/dist/library.js +36 -9
  6. package/package.json +2 -1
  7. package/presets/agy/skills/cc-feature/SKILL.md +17 -16
  8. package/presets/agy/skills/cc-fix/SKILL.md +28 -34
  9. package/presets/agy/workflows/cc-council.md +2 -0
  10. package/presets/claude/commands/cc/council.md +2 -83
  11. package/presets/codex/skills/cc-council/SKILL.md +2 -93
  12. package/presets/cursor/commands/cc/council.md +2 -83
  13. package/presets/gemini/commands/cc/council.toml +2 -83
  14. package/presets/opencode/commands/cc-council.md +2 -83
package/presets/opencode/commands/cc-council.md CHANGED
@@ -2,89 +2,8 @@
2
2
  description: Council-driven workflow with CCEP-1 bootstrap
3
3
  ---
4
4
 
5
- # Council-Driven Workflow
6
-
7
- Task request: $ARGUMENTS
5
+ <!-- GENERATED redirect to presets/agy/workflows/cc-council.md by scripts/inject-ccep-bootstrap.ts — DO NOT EDIT. -->
8
6
 
9
7
  ## Step 0 — CCEP Bootstrap
10
8
 
11
- Command: `council` (fixed for this workflow — do not infer from user text)
12
- command: council
13
-
14
- 1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
15
- 2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
16
- 3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
17
- 4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
18
-
19
- ---
20
-
21
- ## Step 1 — Wayfinding (repo-explorer)
22
-
23
- If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
24
- `graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
25
- to map impact radius before deliberation. Do not write code in this step.
26
-
27
- ---
28
-
29
- ## Step 2 — Deliberation & Specification (SDD)
30
-
31
- Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
32
-
33
- The council must:
34
- 1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
35
- 2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
36
- 3. Draft a Task Card & Technical Plan (The Specification).
37
-
38
- **STOP here.** Unresolved grilling questions populate `questionsForUser` in the
39
- CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
40
- answers. Show the agreed Task Card & Technical Plan and wait for confirmation
41
- before continuing.
42
-
43
- ---
44
-
45
- ## Step 3 — Test Definition (TDD)
46
-
47
- Invoke `tester` with the approved Task Card & Technical Plan.
48
-
49
- tester must:
50
- 1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
51
- 2. Confirm the tests fail as expected (Red state).
52
-
53
- **Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
54
-
55
- ---
56
-
57
- ## Step 4 — Surgical Implementation
58
-
59
- Invoke `implementer` with the failing tests and the Technical Plan.
60
-
61
- implementer must:
62
- 1. Write the minimal code required to pass the tests.
63
- 2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
64
- 3. NOT refactor adjacent code, change existing styles, or build speculative features.
65
- 4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state), at most 3 iterations -- then stop and report the failing tests instead of looping.
66
-
67
- ---
68
-
69
- ## Step 5 — Multi-Perspective Council Review
70
-
71
- Invoke the `council` skill on the generated diff to perform the final review phase.
72
-
73
- The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
74
-
75
- If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
76
- - The Review Report status is **BLOCKED**.
77
- - Return to Step 4 with the feedback (at most 3 review rounds in total -- then deliver the BLOCKED verdict with the unresolved findings instead of looping).
78
-
79
- If APPROVED (no CRITICAL findings):
80
- - Deliver the final Council Verdict and the diff summary.
81
-
82
- ---
83
-
84
- ## Completion
85
-
86
- Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.
87
-
88
- ## Next
89
-
90
- Approved: merge. Blocked: return the findings to `/cc-fix` or `/cc-feature`.
9
+ command: council. Read `presets/agy/workflows/cc-council.md`, then `ccep profile council` + `ccep compile --command council --view prompt`.