cc-dev-template 0.1.95 → 0.1.96
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/package.json
CHANGED
|
@@ -4,23 +4,21 @@ Orchestrate implementation using spec-implementer and spec-validator sub-agents.
|
|
|
4
4
|
|
|
5
5
|
Read `{spec_dir}/spec.md` and list all task files in `{spec_dir}/tasks/`.
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## Step 1: Hydrate Task System
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
**This step is mandatory — do not skip it.** The task system is how you track dependency order, implementation status, and validation status throughout this phase. Without it, you will lose track of what's done and what's blocked.
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
4. "Handle failures" — triage and re-attempt if needed
|
|
15
|
-
5. "Finalize" — present results
|
|
11
|
+
Read each task file in `{spec_dir}/tasks/`. For each one, create a Claude Code task (TaskCreate) with:
|
|
12
|
+
- The task title and description from the task file
|
|
13
|
+
- `blockedBy` relationships based on the `depends_on` field in each task file's frontmatter
|
|
16
14
|
|
|
17
|
-
|
|
15
|
+
After hydration, use TaskList to verify all tasks are created with correct dependencies before proceeding.
|
|
18
16
|
|
|
19
|
-
|
|
17
|
+
## Step 2: Implement and Validate
|
|
20
18
|
|
|
21
|
-
|
|
19
|
+
Work through tasks in dependency order. For each task that is ready (no blockers):
|
|
22
20
|
|
|
23
|
-
|
|
21
|
+
**Implement** — dispatch an implementer agent:
|
|
24
22
|
|
|
25
23
|
```
|
|
26
24
|
Agent tool:
|
|
@@ -28,11 +26,9 @@ Agent tool:
|
|
|
28
26
|
prompt: "Implement the task described in {task_file_path}. Read the task file for requirements, files to modify, and verification steps. Also read {spec_dir}/spec.md for overall context. After implementation, run the verification steps described in the task file."
|
|
29
27
|
```
|
|
30
28
|
|
|
31
|
-
|
|
29
|
+
When the implementer returns, use TaskUpdate to mark the task as `in_progress` (implementation done, not yet validated).
|
|
32
30
|
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
For each completed task, dispatch a validator:
|
|
31
|
+
**Validate** — dispatch a validator agent for the same task:
|
|
36
32
|
|
|
37
33
|
```
|
|
38
34
|
Agent tool:
|
|
@@ -40,15 +36,12 @@ Agent tool:
|
|
|
40
36
|
prompt: "Validate the task described in {task_file_path}. Review the code changes, run tests, and verify against the acceptance criteria in {spec_dir}/spec.md. Report pass/fail with details."
|
|
41
37
|
```
|
|
42
38
|
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
If any validation fails:
|
|
39
|
+
- **If pass**: Use TaskUpdate to mark the task as `completed`. This unblocks downstream tasks.
|
|
40
|
+
- **If fail**: Re-dispatch the spec-implementer with the validation feedback appended to the prompt, then re-validate. If a task fails validation twice, flag it for the user and ask how to proceed.
|
|
46
41
|
|
|
47
|
-
|
|
48
|
-
- Re-validate after fixes
|
|
49
|
-
- If a task fails validation twice, flag it for the user with the error details and ask how to proceed
|
|
42
|
+
Run independent tasks (no dependency between them) in parallel when possible. Always check TaskList before dispatching to confirm which tasks are ready.
|
|
50
43
|
|
|
51
|
-
##
|
|
44
|
+
## Step 3: Finalize
|
|
52
45
|
|
|
53
46
|
Update `{spec_dir}/state.yaml` — set `phase: complete`.
|
|
54
47
|
|