bigpowers 2.15.0 → 2.17.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/.pi/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bigpowers",
3
- "version": "2.15.0",
3
+ "version": "2.17.0",
4
4
  "description": "67 skills — 61 agent skills for spec-driven, test-first software development by solo developers",
5
5
  "keywords": [
6
6
  "pi-package"
@@ -9,6 +9,11 @@ description: Analyze the blast radius of a proposed change before any code is wr
9
9
 
10
10
  Find the blast radius of the proposed change before a single line is written.
11
11
 
12
+ ## Modes
13
+
14
+ - Default: full impact analysis (dependents + affected stories + test coverage mapping)
15
+ - --lightweight: Fast fan-in/fan-out only (<10s). Maps callers and imports without test coverage mapping. Used by build-epic step 2 as a pre-plan gate. Risk score > 7 triggers a mandatory grill-me session before proceeding.
16
+
12
17
  ## Process
13
18
 
14
19
  ### 1. Identify the target
@@ -74,3 +79,12 @@ grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
74
79
  → verify: `grep "Risk:" specs/IMPACT.md`
75
80
 
76
81
  Suggest `plan-work` once risk is understood and any test gaps are noted.
82
+
83
+ ## Risk score gating
84
+
85
+ In `--lightweight` mode (used by build-epic step 2), assign a numeric risk score (1–10):
86
+ - Fan-in (how many callers): 0–4 points
87
+ - Fan-out (how many dependencies the module itself uses): 0–3 points
88
+ - Recent churn (git log --oneline -5 count): 0–3 points
89
+
90
+ **Risk score > 7**: Gate — require a `grill-me` session before proceeding to implementation. Document the grill-me result in the impact report at `specs/IMPACT-<epic>-<story>.md`.
@@ -29,7 +29,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
29
29
  ## Process
30
30
 
31
31
  1. Read `specs/state.yaml`, `specs/execution-status.yaml`, `specs/release-plan.yaml`, active `specs/epics/eNN-slug/epic.yaml`.
32
- 2. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
32
+ 2. **Assess Impact (Step 2):** Before writing tasks, run `assess-impact --lightweight` on the proposed change. If the risk score exceeds 7, gate require a `grill-me` session. Write the impact report to `specs/IMPACT-<epic>-<story>.md`. For net-new code with no existing dependents, skip.
33
+ 3. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
33
34
  3. If `epic_cycle.step` missing, set to `1`.
34
35
  4. Run **only the current step** (resume mode) unless user asked for full auto-run.
35
36
  5. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
@@ -9,15 +9,33 @@ description: Bug fix orchestrator — active_flow fix_bug; reads specs/bugs/BUG-
9
9
 
10
10
  Orchestrates **fix_bug** flow without mixing epic build state.
11
11
 
12
- > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug`.
12
+ > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug` and `bug_cycle.current_step: 1` before starting.
13
+
14
+ ## Five steps (`bug_cycle` in state.yaml)
15
+
16
+ | Step | Skill / action |
17
+ |------|----------------|
18
+ | 1 | `investigate-bug` — create BUG-*.md with RCA |
19
+ | 2 | `diagnose-root` — 4-phase root cause analysis |
20
+ | 3 | `develop-tdd` — red-green against bug file verify steps |
21
+ | 4 | `validate-fix` — re-run failing test, full suite, lint |
22
+ | 5 | `release-branch` — PR or solo land the fix |
23
+
24
+ ### Checkpoint / resume
25
+
26
+ Track progress via `specs/state.yaml` `bug_cycle`:
27
+ - `bug_cycle.current_step`: current step (1–5)
28
+ - `bug_cycle.completed_steps`: completed step numbers
29
+ - `handoff.next_skill`: skill for the current step
30
+ - On resume, read `bug_cycle.current_step` and continue from there
13
31
 
14
32
  ## Process
15
33
 
16
- 1. If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file.
17
- 2. `develop-tdd` against the bug file's verify steps.
18
- 3. `validate-fix` re-run failing test, full suite, lint.
19
- 4. `bash scripts/sync-bugs-registry.sh` — refresh `specs/bugs/registry.yaml`.
20
- 5. Clear `active_flow` or return to `build_epic` when done.
34
+ 1. **Step 1 — investigate-bug:** If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file. Increment `bug_cycle.current_step` to 2 on completion.
35
+ 2. **Step 2 — diagnose-root:** Run 4-phase RCA (reproduce → isolate → hypothesize → verify). Record findings in the bug file. Increment to step 3.
36
+ 3. **Step 3 — develop-tdd:** `develop-tdd` against the bug file's verify steps. Increment to step 4 on all-green.
37
+ 4. **Step 4 — validate-fix:** `validate-fix` — re-run failing test, full suite, typecheck, lint. Increment to step 5.
38
+ 5. **Step 5 — release-branch:** Land the fix via `release-branch`. Clear `bug_cycle` and `active_flow` when done.
21
39
 
22
40
  ## Bug file SoT
23
41
 
@@ -31,6 +31,14 @@ claude /orchestrate --mode fast-track
31
31
  5. **VERIFY** (1-3 hours): Validate success criteria. Deliverables: UAT evidence, `specs/EVALS-*.md` if used.
32
32
  6. **RELEASE** (30 min - 2 hours): Ship to production. Deliverables: Release tag (vX.Y.Z), `state.yaml` `release.last_tag`.
33
33
 
34
+ ### Checkpoint / resume
35
+
36
+ Track progress via `specs/state.yaml` `project_cycle`:
37
+ - `project_cycle.current_phase`: current phase (1–6)
38
+ - `project_cycle.completed_phases`: completed phase numbers
39
+ - `handoff.next_skill`: skill for the current phase
40
+ - On resume, read `project_cycle.current_phase` and continue from there
41
+
34
42
  See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate types.
35
43
 
36
44
  ## How Orchestrate Works
@@ -67,24 +67,23 @@ Whenever a significant decision is made or a milestone is reached:
67
67
 
68
68
  → verify: `bash scripts/validate-specs-yaml.sh`
69
69
 
70
- ## State Write-Lock Protocol
70
+ ## Universal checkpoint pattern
71
71
 
72
- > **HARD GATE** Lock `specs/state.yaml.lock` before writes; stale (>60s) may be force-released.
72
+ Every multi-step flow (>3 steps) in bigpowers uses a cycle counter in `state.yaml`:
73
73
 
74
- 1. Check lock exists. If fresh (<60s), wait 2s retry (max 15). Stale → remove.
75
- 2. Write `agent_id: <name>\nacquired_at: <ISO-8601>` to lock.
76
- 3. After write, `rm specs/state.yaml.lock`.
74
+ | Flow | Cycle key | Step field | Phases/Steps |
75
+ |------|-----------|------------|-------------|
76
+ | build-epic | `epic_cycle` | `current_step` | 8 (survey → release) |
77
+ | fix-bug | `bug_cycle` | `current_step` | 5 (investigate → release) |
78
+ | orchestrate-project | `project_cycle` | `current_phase` | 6 (discover → release) |
77
79
 
78
- Lock format:
79
- ```yaml
80
- agent_id: session-state
81
- acquired_at: "2026-06-11T14:30:00Z"
82
- ```
80
+ **Checkpoint:** After each step/phase completes, increment the counter in `state.yaml` and update `handoff.next_skill`.
83
81
 
82
+ **Resume:** On session start, read the current step/phase from the cycle key — continue from there, not from step 1.
84
83
 
85
- ## Operations
84
+ **Completed steps:** Track completed steps in `completed_steps` (comma-separated string) for audit trail.
86
85
 
87
- ### show-state (absorbed)
86
+ ## Strategic compaction
88
87
 
89
88
  Print the current session state: `cat specs/state.yaml`, then display `active_flow` and `handoff.next_skill` for quick reference.
90
89
 
@@ -11,6 +11,11 @@ model: sonnet
11
11
 
12
12
  Find the blast radius of the proposed change before a single line is written.
13
13
 
14
+ ## Modes
15
+
16
+ - Default: full impact analysis (dependents + affected stories + test coverage mapping)
17
+ - --lightweight: Fast fan-in/fan-out only (<10s). Maps callers and imports without test coverage mapping. Used by build-epic step 2 as a pre-plan gate. Risk score > 7 triggers a mandatory grill-me session before proceeding.
18
+
14
19
  ## Process
15
20
 
16
21
  ### 1. Identify the target
@@ -76,3 +81,12 @@ grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
76
81
  → verify: `grep "Risk:" specs/IMPACT.md`
77
82
 
78
83
  Suggest `plan-work` once risk is understood and any test gaps are noted.
84
+
85
+ ## Risk score gating
86
+
87
+ In `--lightweight` mode (used by build-epic step 2), assign a numeric risk score (1–10):
88
+ - Fan-in (how many callers): 0–4 points
89
+ - Fan-out (how many dependencies the module itself uses): 0–3 points
90
+ - Recent churn (git log --oneline -5 count): 0–3 points
91
+
92
+ **Risk score > 7**: Gate — require a `grill-me` session before proceeding to implementation. Document the grill-me result in the impact report at `specs/IMPACT-<epic>-<story>.md`.
@@ -31,7 +31,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
31
31
  ## Process
32
32
 
33
33
  1. Read `specs/state.yaml`, `specs/execution-status.yaml`, `specs/release-plan.yaml`, active `specs/epics/eNN-slug/epic.yaml`.
34
- 2. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
34
+ 2. **Assess Impact (Step 2):** Before writing tasks, run `assess-impact --lightweight` on the proposed change. If the risk score exceeds 7, gate require a `grill-me` session. Write the impact report to `specs/IMPACT-<epic>-<story>.md`. For net-new code with no existing dependents, skip.
35
+ 3. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
35
36
  3. If `epic_cycle.step` missing, set to `1`.
36
37
  4. Run **only the current step** (resume mode) unless user asked for full auto-run.
37
38
  5. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
@@ -11,15 +11,33 @@ model: sonnet
11
11
 
12
12
  Orchestrates **fix_bug** flow without mixing epic build state.
13
13
 
14
- > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug`.
14
+ > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug` and `bug_cycle.current_step: 1` before starting.
15
+
16
+ ## Five steps (`bug_cycle` in state.yaml)
17
+
18
+ | Step | Skill / action |
19
+ |------|----------------|
20
+ | 1 | `investigate-bug` — create BUG-*.md with RCA |
21
+ | 2 | `diagnose-root` — 4-phase root cause analysis |
22
+ | 3 | `develop-tdd` — red-green against bug file verify steps |
23
+ | 4 | `validate-fix` — re-run failing test, full suite, lint |
24
+ | 5 | `release-branch` — PR or solo land the fix |
25
+
26
+ ### Checkpoint / resume
27
+
28
+ Track progress via `specs/state.yaml` `bug_cycle`:
29
+ - `bug_cycle.current_step`: current step (1–5)
30
+ - `bug_cycle.completed_steps`: completed step numbers
31
+ - `handoff.next_skill`: skill for the current step
32
+ - On resume, read `bug_cycle.current_step` and continue from there
15
33
 
16
34
  ## Process
17
35
 
18
- 1. If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file.
19
- 2. `develop-tdd` against the bug file's verify steps.
20
- 3. `validate-fix` re-run failing test, full suite, lint.
21
- 4. `bash scripts/sync-bugs-registry.sh` — refresh `specs/bugs/registry.yaml`.
22
- 5. Clear `active_flow` or return to `build_epic` when done.
36
+ 1. **Step 1 — investigate-bug:** If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file. Increment `bug_cycle.current_step` to 2 on completion.
37
+ 2. **Step 2 — diagnose-root:** Run 4-phase RCA (reproduce → isolate → hypothesize → verify). Record findings in the bug file. Increment to step 3.
38
+ 3. **Step 3 — develop-tdd:** `develop-tdd` against the bug file's verify steps. Increment to step 4 on all-green.
39
+ 4. **Step 4 — validate-fix:** `validate-fix` — re-run failing test, full suite, typecheck, lint. Increment to step 5.
40
+ 5. **Step 5 — release-branch:** Land the fix via `release-branch`. Clear `bug_cycle` and `active_flow` when done.
23
41
 
24
42
  ## Bug file SoT
25
43
 
@@ -33,6 +33,14 @@ claude /orchestrate --mode fast-track
33
33
  5. **VERIFY** (1-3 hours): Validate success criteria. Deliverables: UAT evidence, `specs/EVALS-*.md` if used.
34
34
  6. **RELEASE** (30 min - 2 hours): Ship to production. Deliverables: Release tag (vX.Y.Z), `state.yaml` `release.last_tag`.
35
35
 
36
+ ### Checkpoint / resume
37
+
38
+ Track progress via `specs/state.yaml` `project_cycle`:
39
+ - `project_cycle.current_phase`: current phase (1–6)
40
+ - `project_cycle.completed_phases`: completed phase numbers
41
+ - `handoff.next_skill`: skill for the current phase
42
+ - On resume, read `project_cycle.current_phase` and continue from there
43
+
36
44
  See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate types.
37
45
 
38
46
  ## How Orchestrate Works
@@ -69,24 +69,23 @@ Whenever a significant decision is made or a milestone is reached:
69
69
 
70
70
  → verify: `bash scripts/validate-specs-yaml.sh`
71
71
 
72
- ## State Write-Lock Protocol
72
+ ## Universal checkpoint pattern
73
73
 
74
- > **HARD GATE** Lock `specs/state.yaml.lock` before writes; stale (>60s) may be force-released.
74
+ Every multi-step flow (>3 steps) in bigpowers uses a cycle counter in `state.yaml`:
75
75
 
76
- 1. Check lock exists. If fresh (<60s), wait 2s retry (max 15). Stale → remove.
77
- 2. Write `agent_id: <name>\nacquired_at: <ISO-8601>` to lock.
78
- 3. After write, `rm specs/state.yaml.lock`.
76
+ | Flow | Cycle key | Step field | Phases/Steps |
77
+ |------|-----------|------------|-------------|
78
+ | build-epic | `epic_cycle` | `current_step` | 8 (survey → release) |
79
+ | fix-bug | `bug_cycle` | `current_step` | 5 (investigate → release) |
80
+ | orchestrate-project | `project_cycle` | `current_phase` | 6 (discover → release) |
79
81
 
80
- Lock format:
81
- ```yaml
82
- agent_id: session-state
83
- acquired_at: "2026-06-11T14:30:00Z"
84
- ```
82
+ **Checkpoint:** After each step/phase completes, increment the counter in `state.yaml` and update `handoff.next_skill`.
85
83
 
84
+ **Resume:** On session start, read the current step/phase from the cycle key — continue from there, not from step 1.
86
85
 
87
- ## Operations
86
+ **Completed steps:** Track completed steps in `completed_steps` (comma-separated string) for audit trail.
88
87
 
89
- ### show-state (absorbed)
88
+ ## Strategic compaction
90
89
 
91
90
  Print the current session state: `cat specs/state.yaml`, then display `active_flow` and `handoff.next_skill` for quick reference.
92
91
 
package/CHANGELOG.md CHANGED
@@ -1,3 +1,17 @@
1
+ # [2.17.0](https://github.com/danielvm-git/bigpowers/compare/v2.16.0...v2.17.0) (2026-06-21)
2
+
3
+
4
+ ### Features
5
+
6
+ * **e18s04:** universal checkpoint pattern in fix-bug + orchestrate ([5a47aac](https://github.com/danielvm-git/bigpowers/commit/5a47aac8f0dd1a4463749ab36c64aeded86aa8a4))
7
+
8
+ # [2.16.0](https://github.com/danielvm-git/bigpowers/compare/v2.15.0...v2.16.0) (2026-06-21)
9
+
10
+
11
+ ### Features
12
+
13
+ * **e18s03:** assess-impact --lightweight in build-epic step 2 ([eff1b3a](https://github.com/danielvm-git/bigpowers/commit/eff1b3a3dfa7677db8c525d6424147c08a9b4809))
14
+
1
15
  # [2.15.0](https://github.com/danielvm-git/bigpowers/compare/v2.14.0...v2.15.0) (2026-06-21)
2
16
 
3
17
 
package/SKILL-INDEX.md CHANGED
@@ -3,7 +3,7 @@
3
3
  > **DO NOT EDIT** — This file is auto-generated by `scripts/generate-skill-index.sh`.
4
4
  > Edit `SKILL.md` source files or `skills-lock.json` instead. Run `bash scripts/sync-skills.sh` to regenerate.
5
5
 
6
- **Generated:** 2026-06-21T21:31:53Z
6
+ **Generated:** 2026-06-21T21:41:36Z
7
7
  **Skills:** 67
8
8
 
9
9
  ---
@@ -10,6 +10,11 @@ description: Analyze the blast radius of a proposed change before any code is wr
10
10
 
11
11
  Find the blast radius of the proposed change before a single line is written.
12
12
 
13
+ ## Modes
14
+
15
+ - Default: full impact analysis (dependents + affected stories + test coverage mapping)
16
+ - --lightweight: Fast fan-in/fan-out only (<10s). Maps callers and imports without test coverage mapping. Used by build-epic step 2 as a pre-plan gate. Risk score > 7 triggers a mandatory grill-me session before proceeding.
17
+
13
18
  ## Process
14
19
 
15
20
  ### 1. Identify the target
@@ -75,3 +80,12 @@ grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
75
80
  → verify: `grep "Risk:" specs/IMPACT.md`
76
81
 
77
82
  Suggest `plan-work` once risk is understood and any test gaps are noted.
83
+
84
+ ## Risk score gating
85
+
86
+ In `--lightweight` mode (used by build-epic step 2), assign a numeric risk score (1–10):
87
+ - Fan-in (how many callers): 0–4 points
88
+ - Fan-out (how many dependencies the module itself uses): 0–3 points
89
+ - Recent churn (git log --oneline -5 count): 0–3 points
90
+
91
+ **Risk score > 7**: Gate — require a `grill-me` session before proceeding to implementation. Document the grill-me result in the impact report at `specs/IMPACT-<epic>-<story>.md`.
@@ -30,7 +30,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
30
30
  ## Process
31
31
 
32
32
  1. Read `specs/state.yaml`, `specs/execution-status.yaml`, `specs/release-plan.yaml`, active `specs/epics/eNN-slug/epic.yaml`.
33
- 2. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
33
+ 2. **Assess Impact (Step 2):** Before writing tasks, run `assess-impact --lightweight` on the proposed change. If the risk score exceeds 7, gate require a `grill-me` session. Write the impact report to `specs/IMPACT-<epic>-<story>.md`. For net-new code with no existing dependents, skip.
34
+ 3. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
34
35
  3. If `epic_cycle.step` missing, set to `1`.
35
36
  4. Run **only the current step** (resume mode) unless user asked for full auto-run.
36
37
  5. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
package/fix-bug/SKILL.md CHANGED
@@ -10,15 +10,33 @@ description: Bug fix orchestrator — active_flow fix_bug; reads specs/bugs/BUG-
10
10
 
11
11
  Orchestrates **fix_bug** flow without mixing epic build state.
12
12
 
13
- > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug`.
13
+ > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug` and `bug_cycle.current_step: 1` before starting.
14
+
15
+ ## Five steps (`bug_cycle` in state.yaml)
16
+
17
+ | Step | Skill / action |
18
+ |------|----------------|
19
+ | 1 | `investigate-bug` — create BUG-*.md with RCA |
20
+ | 2 | `diagnose-root` — 4-phase root cause analysis |
21
+ | 3 | `develop-tdd` — red-green against bug file verify steps |
22
+ | 4 | `validate-fix` — re-run failing test, full suite, lint |
23
+ | 5 | `release-branch` — PR or solo land the fix |
24
+
25
+ ### Checkpoint / resume
26
+
27
+ Track progress via `specs/state.yaml` `bug_cycle`:
28
+ - `bug_cycle.current_step`: current step (1–5)
29
+ - `bug_cycle.completed_steps`: completed step numbers
30
+ - `handoff.next_skill`: skill for the current step
31
+ - On resume, read `bug_cycle.current_step` and continue from there
14
32
 
15
33
  ## Process
16
34
 
17
- 1. If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file.
18
- 2. `develop-tdd` against the bug file's verify steps.
19
- 3. `validate-fix` re-run failing test, full suite, lint.
20
- 4. `bash scripts/sync-bugs-registry.sh` — refresh `specs/bugs/registry.yaml`.
21
- 5. Clear `active_flow` or return to `build_epic` when done.
35
+ 1. **Step 1 — investigate-bug:** If no `specs/bugs/BUG-*.md`, run `investigate-bug` first — it handles history check, RCA (via `diagnose-root`), fix approach, and writes the bug file. Increment `bug_cycle.current_step` to 2 on completion.
36
+ 2. **Step 2 — diagnose-root:** Run 4-phase RCA (reproduce → isolate → hypothesize → verify). Record findings in the bug file. Increment to step 3.
37
+ 3. **Step 3 — develop-tdd:** `develop-tdd` against the bug file's verify steps. Increment to step 4 on all-green.
38
+ 4. **Step 4 — validate-fix:** `validate-fix` — re-run failing test, full suite, typecheck, lint. Increment to step 5.
39
+ 5. **Step 5 — release-branch:** Land the fix via `release-branch`. Clear `bug_cycle` and `active_flow` when done.
22
40
 
23
41
  ## Bug file SoT
24
42
 
@@ -32,6 +32,14 @@ claude /orchestrate --mode fast-track
32
32
  5. **VERIFY** (1-3 hours): Validate success criteria. Deliverables: UAT evidence, `specs/EVALS-*.md` if used.
33
33
  6. **RELEASE** (30 min - 2 hours): Ship to production. Deliverables: Release tag (vX.Y.Z), `state.yaml` `release.last_tag`.
34
34
 
35
+ ### Checkpoint / resume
36
+
37
+ Track progress via `specs/state.yaml` `project_cycle`:
38
+ - `project_cycle.current_phase`: current phase (1–6)
39
+ - `project_cycle.completed_phases`: completed phase numbers
40
+ - `handoff.next_skill`: skill for the current phase
41
+ - On resume, read `project_cycle.current_phase` and continue from there
42
+
35
43
  See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate types.
36
44
 
37
45
  ## How Orchestrate Works
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bigpowers",
3
- "version": "2.15.0",
3
+ "version": "2.17.0",
4
4
  "description": "61 agent skills for spec-driven, test-first software development by solo developers",
5
5
  "main": "index.js",
6
6
  "scripts": {
@@ -68,24 +68,23 @@ Whenever a significant decision is made or a milestone is reached:
68
68
 
69
69
  → verify: `bash scripts/validate-specs-yaml.sh`
70
70
 
71
- ## State Write-Lock Protocol
71
+ ## Universal checkpoint pattern
72
72
 
73
- > **HARD GATE** Lock `specs/state.yaml.lock` before writes; stale (>60s) may be force-released.
73
+ Every multi-step flow (>3 steps) in bigpowers uses a cycle counter in `state.yaml`:
74
74
 
75
- 1. Check lock exists. If fresh (<60s), wait 2s retry (max 15). Stale → remove.
76
- 2. Write `agent_id: <name>\nacquired_at: <ISO-8601>` to lock.
77
- 3. After write, `rm specs/state.yaml.lock`.
75
+ | Flow | Cycle key | Step field | Phases/Steps |
76
+ |------|-----------|------------|-------------|
77
+ | build-epic | `epic_cycle` | `current_step` | 8 (survey → release) |
78
+ | fix-bug | `bug_cycle` | `current_step` | 5 (investigate → release) |
79
+ | orchestrate-project | `project_cycle` | `current_phase` | 6 (discover → release) |
78
80
 
79
- Lock format:
80
- ```yaml
81
- agent_id: session-state
82
- acquired_at: "2026-06-11T14:30:00Z"
83
- ```
81
+ **Checkpoint:** After each step/phase completes, increment the counter in `state.yaml` and update `handoff.next_skill`.
84
82
 
83
+ **Resume:** On session start, read the current step/phase from the cycle key — continue from there, not from step 1.
85
84
 
86
- ## Operations
85
+ **Completed steps:** Track completed steps in `completed_steps` (comma-separated string) for audit trail.
87
86
 
88
- ### show-state (absorbed)
87
+ ## Strategic compaction
89
88
 
90
89
  Print the current session state: `cat specs/state.yaml`, then display `active_flow` and `handoff.next_skill` for quick reference.
91
90
 
package/skills-lock.json CHANGED
@@ -8,7 +8,7 @@
8
8
  },
9
9
  "assess-impact": {
10
10
  "description": "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\".",
11
- "sha256": "cad0c4534f31a207",
11
+ "sha256": "740925970c6cf9ce",
12
12
  "path": "assess-impact/SKILL.md"
13
13
  },
14
14
  "audit-code": {
@@ -18,7 +18,7 @@
18
18
  },
19
19
  "build-epic": {
20
20
  "description": "Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic capsule; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work.",
21
- "sha256": "d33ba1c86463d91f",
21
+ "sha256": "3c1707cca32b24de",
22
22
  "path": "build-epic/SKILL.md"
23
23
  },
24
24
  "change-request": {
@@ -113,7 +113,7 @@
113
113
  },
114
114
  "fix-bug": {
115
115
  "description": "Bug fix orchestrator — active_flow fix_bug; reads specs/bugs/BUG-*.md; chains investigate-bug, develop-tdd, validate-fix. Use when user reports a defect.",
116
- "sha256": "466c0847b5312b6f",
116
+ "sha256": "aa6fe406ba87a648",
117
117
  "path": "fix-bug/SKILL.md"
118
118
  },
119
119
  "grill-me": {
@@ -168,7 +168,7 @@
168
168
  },
169
169
  "orchestrate-project": {
170
170
  "description": "Meta-skill that enforces the 6-phase core loop (discover → elaborate → plan → build → verify → release) with hard gates. Use to coordinate multi-phase projects with guaranteed quality checkpoints. One-time command for the entire project lifecycle.",
171
- "sha256": "aef26df7a83a4cd3",
171
+ "sha256": "542276f88198ae72",
172
172
  "path": "orchestrate-project/SKILL.md"
173
173
  },
174
174
  "organize-workspace": {
@@ -248,7 +248,7 @@
248
248
  },
249
249
  "session-state": {
250
250
  "description": "Track implementation decisions and progress in specs/state.yaml to prevent context rot. Use at the start of a session to load context, and whenever a significant decision is made or a milestone is reached.",
251
- "sha256": "5ac473ace06c72b1",
251
+ "sha256": "4efd54a453e3e2cd",
252
252
  "path": "session-state/SKILL.md"
253
253
  },
254
254
  "setup-environment": {