bigpowers 2.49.0 → 2.51.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 +1 -1
- package/.pi/prompts/evolve-skill.md +7 -6
- package/.pi/prompts/plan-release.md +0 -1
- package/.pi/prompts/release-branch.md +74 -56
- package/.pi/prompts/session-state.md +2 -0
- package/.pi/prompts/survey-context.md +1 -1
- package/.pi/skills/evolve-skill/SKILL.md +7 -6
- package/.pi/skills/plan-release/SKILL.md +0 -1
- package/.pi/skills/release-branch/SKILL.md +74 -56
- package/.pi/skills/session-state/SKILL.md +2 -0
- package/.pi/skills/survey-context/SKILL.md +1 -1
- package/CHANGELOG.md +23 -0
- package/CLAUDE.md +20 -0
- package/CONVENTIONS.md +11 -0
- package/package.json +1 -1
- package/scripts/audit-compliance.sh +1 -4
- package/scripts/record-cycle-time.sh +340 -0
- package/scripts/run-golden-suite.sh +59 -1
- package/scripts/validate-okf.sh +198 -0
- package/scripts/wait-for-ci.sh +130 -0
- package/skills/align-grid/SKILL.md +1 -0
- package/skills/assess-impact/SKILL.md +1 -0
- package/skills/audit-code/SKILL.md +1 -0
- package/skills/audit-plan/SKILL.md +1 -0
- package/skills/build-epic/SKILL.md +1 -0
- package/skills/change-request/SKILL.md +1 -0
- package/skills/commit-message/SKILL.md +1 -0
- package/skills/compose-workflow/SKILL.md +1 -0
- package/skills/craft-skill/SKILL.md +1 -0
- package/skills/deepen-architecture/SKILL.md +1 -0
- package/skills/define-language/SKILL.md +1 -0
- package/skills/define-success/SKILL.md +1 -0
- package/skills/delegate-task/SKILL.md +1 -0
- package/skills/deploy/SKILL.md +1 -0
- package/skills/design-interface/SKILL.md +1 -0
- package/skills/develop-tdd/SKILL.md +1 -0
- package/skills/diagnose-root/SKILL.md +1 -0
- package/skills/dispatch-agents/SKILL.md +1 -0
- package/skills/edit-document/SKILL.md +1 -0
- package/skills/elaborate-spec/SKILL.md +1 -0
- package/skills/enforce-first/SKILL.md +1 -0
- package/skills/evolve-skill/SKILL.md +8 -6
- package/skills/execute-plan/SKILL.md +1 -0
- package/skills/extract-design/SKILL.md +1 -0
- package/skills/fix-bug/SKILL.md +1 -0
- package/skills/grill-me/SKILL.md +1 -0
- package/skills/grill-with-docs/SKILL.md +1 -0
- package/skills/guard-git/SKILL.md +1 -0
- package/skills/hook-commits/SKILL.md +1 -0
- package/skills/inspect-quality/SKILL.md +1 -0
- package/skills/investigate-bug/SKILL.md +1 -0
- package/skills/kickoff-branch/SKILL.md +1 -0
- package/skills/map-codebase/SKILL.md +1 -0
- package/skills/migrate-spec/SKILL.md +1 -0
- package/skills/model-domain/SKILL.md +1 -0
- package/skills/orchestrate-project/SKILL.md +1 -0
- package/skills/organize-workspace/SKILL.md +1 -0
- package/skills/plan-refactor/SKILL.md +1 -0
- package/skills/plan-release/SKILL.md +1 -1
- package/skills/plan-work/SKILL.md +1 -0
- package/skills/publish-package/SKILL.md +1 -0
- package/skills/quick-fix/SKILL.md +1 -0
- package/skills/release-branch/REFERENCE.md +57 -54
- package/skills/release-branch/SKILL.md +20 -4
- package/skills/request-review/SKILL.md +1 -0
- package/skills/research-first/SKILL.md +1 -0
- package/skills/reset-baseline/SKILL.md +1 -0
- package/skills/respond-review/SKILL.md +1 -0
- package/skills/run-benchmark/SKILL.md +1 -0
- package/skills/run-evals/SKILL.md +1 -0
- package/skills/run-planning/SKILL.md +1 -0
- package/skills/scope-work/SKILL.md +1 -0
- package/skills/search-skills/SKILL.md +1 -0
- package/skills/security-review/SKILL.md +1 -0
- package/skills/seed-conventions/SKILL.md +1 -0
- package/skills/session-state/SKILL.md +3 -0
- package/skills/setup-environment/SKILL.md +1 -0
- package/skills/simulate-agents/SKILL.md +1 -0
- package/skills/slice-tasks/SKILL.md +1 -0
- package/skills/smoke-test/SKILL.md +1 -0
- package/skills/spike-prototype/SKILL.md +1 -0
- package/skills/stocktake-skills/SKILL.md +1 -0
- package/skills/survey-context/SKILL.md +2 -1
- package/skills/terse-mode/SKILL.md +1 -0
- package/skills/trace-requirement/SKILL.md +1 -0
- package/skills/using-bigpowers/SKILL.md +1 -0
- package/skills/validate-contracts/SKILL.md +1 -0
- package/skills/validate-fix/SKILL.md +1 -0
- package/skills/verify-work/SKILL.md +1 -0
- package/skills/visual-dashboard/SKILL.md +1 -0
- package/skills/wire-ci/SKILL.md +1 -0
- package/skills/wire-observability/SKILL.md +1 -0
- package/skills/write-document/SKILL.md +1 -0
- package/skills-lock.json +72 -72
|
@@ -40,22 +40,65 @@ If `git worktree remove` fails due to uncommitted changes, ask: "There are uncom
|
|
|
40
40
|
|
|
41
41
|
## Cycle-time recording
|
|
42
42
|
|
|
43
|
-
After landing the branch, record delivery metrics
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
- id: e01s01
|
|
52
|
-
bcps: 3
|
|
53
|
-
start: "2026-06-10T09:45:00Z"
|
|
54
|
-
end: "2026-06-10T11:15:00Z"
|
|
55
|
-
cycle_minutes: 90
|
|
56
|
-
bcp_per_hour: 2.0
|
|
43
|
+
After landing the branch, record delivery metrics using the git-derived,
|
|
44
|
+
additive script (replaces hand-arithmetic):
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
bash scripts/record-cycle-time.sh append \
|
|
48
|
+
--story <story_id> --bcps <bcps> \
|
|
49
|
+
--range "$(git merge-base main HEAD)..HEAD" \
|
|
50
|
+
--file specs/metrics/cycle-times.yaml
|
|
57
51
|
```
|
|
58
52
|
|
|
53
|
+
This appends a row to the cycle-times ledger with two separated metrics:
|
|
54
|
+
|
|
55
|
+
- **effort_hours** — ADDITIVE. Idle-stripped estimated effort from git commit
|
|
56
|
+
history (git-hours model: 120-min session threshold, 120-min first-commit pad).
|
|
57
|
+
Sums exactly to whole-repo effort. NO hand-arithmetic, NO wall-clock includes.
|
|
58
|
+
- **lead_time_minutes** — calendar latency from first commit to merge.
|
|
59
|
+
Median-aggregated across stories; NEVER summed.
|
|
60
|
+
|
|
61
|
+
The script also runs an additivity self-check: Σ(story effort) == whole-repo effort
|
|
62
|
+
within rounding tolerance.
|
|
63
|
+
|
|
64
|
+
### Why not story_start minus story_end?
|
|
65
|
+
|
|
66
|
+
The previous hand-arithmetic approach (survey-context writes `story_start`,
|
|
67
|
+
release-branch writes `story_end`, agent hand-computes `cycle_minutes`) was
|
|
68
|
+
retired because:
|
|
69
|
+
|
|
70
|
+
1. It was **agent-self-reported** — trivially fabricated or mis-subtracted.
|
|
71
|
+
2. Wall-clock included **overnight/weekend/UAT gaps** — calendar latency,
|
|
72
|
+
not coding effort.
|
|
73
|
+
3. The `bcp_per_hour` metric was **computationally meaningless** (velocity
|
|
74
|
+
derived from a latency measurement).
|
|
75
|
+
|
|
76
|
+
The new approach derives effort from commit history (objective, reproducible)
|
|
77
|
+
and lead time from first commit → merge (honest calendar latency). See
|
|
78
|
+
`docs/references/bcp.md` for BCP sizing context and
|
|
79
|
+
`scripts/record-cycle-time.sh` for the full algorithm.
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## CI verification
|
|
84
|
+
|
|
85
|
+
The CI polling logic has been extracted to `scripts/wait-for-ci.sh`.
|
|
86
|
+
See the script's `--help` for usage. Step 7b of the main SKILL.md invokes it directly:
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
bash scripts/wait-for-ci.sh --timeout 600 --interval 30
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
**Exit codes:**
|
|
93
|
+
- **0** — all workflows green. Set `release.ci_verified: true` in state.yaml.
|
|
94
|
+
- **1** — at least one workflow failed. Prints failure URLs. Set `handoff.next_skill = fix-bug`.
|
|
95
|
+
- **2** — timeout. CI did not complete. Retry or investigate.
|
|
96
|
+
- **0 with warning** — `gh` CLI not available, git-only fallback confirmed push landed but CI status unverified.
|
|
97
|
+
|
|
98
|
+
The script handles: auto-discovery of all workflows for the current
|
|
99
|
+
branch/commit, polling until completion, success/failure/timeout exit codes,
|
|
100
|
+
and git-only fallback when `gh` CLI is unavailable.
|
|
101
|
+
|
|
59
102
|
---
|
|
60
103
|
|
|
61
104
|
## Solo-local fallback detail
|
|
@@ -96,43 +139,3 @@ git push origin "$DEFAULT_BRANCH"
|
|
|
96
139
|
# Clean up local feature branch
|
|
97
140
|
git branch -d "$FEATURE_BRANCH"
|
|
98
141
|
```
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## Reference block 2
|
|
103
|
-
|
|
104
|
-
```bash
|
|
105
|
-
echo "==> Polling CI for main branch..."
|
|
106
|
-
TIMEOUT=600 # 10 minutes
|
|
107
|
-
INTERVAL=30 # poll every 30 seconds
|
|
108
|
-
ELAPSED=0
|
|
109
|
-
|
|
110
|
-
while [ $ELAPSED -lt $TIMEOUT ]; do
|
|
111
|
-
CI_JSON=$(gh run list --limit 1 --branch main --workflow CI --json status,conclusion,headSha,databaseId 2>/dev/null)
|
|
112
|
-
CI_STATUS=$(echo "$CI_JSON" | jq -r '.[0].status // "unknown"')
|
|
113
|
-
CI_CONCLUSION=$(echo "$CI_JSON" | jq -r '.[0].conclusion // ""')
|
|
114
|
-
CI_SHA=$(echo "$CI_JSON" | jq -r '.[0].headSha // ""')
|
|
115
|
-
CI_ID=$(echo "$CI_JSON" | jq -r '.[0].databaseId // ""')
|
|
116
|
-
|
|
117
|
-
if [ "$CI_STATUS" = "completed" ] && [ "$CI_CONCLUSION" = "success" ]; then
|
|
118
|
-
echo "OK: CI passed for $(git rev-parse --short HEAD)"
|
|
119
|
-
bp-yaml-set.sh specs/state.yaml release.ci_verified true 2>/dev/null || \
|
|
120
|
-
echo " (bp-yaml-set not available — manually set release.ci_verified: true in state.yaml)"
|
|
121
|
-
break
|
|
122
|
-
fi
|
|
123
|
-
|
|
124
|
-
if [ "$CI_STATUS" = "completed" ] && [ "$CI_CONCLUSION" = "failure" ]; then
|
|
125
|
-
echo "FAIL: CI failed for $(git rev-parse --short HEAD)"
|
|
126
|
-
echo " Run URL: https://github.com/$(gh repo view --json nameWithOwner -q .nameWithOwner)/actions/runs/$CI_ID"
|
|
127
|
-
echo " Handoff to fix-bug with the failure URL above."
|
|
128
|
-
return 1
|
|
129
|
-
fi
|
|
130
|
-
|
|
131
|
-
sleep $INTERVAL
|
|
132
|
-
ELAPSED=$((ELAPSED + INTERVAL))
|
|
133
|
-
echo " Waiting... (${ELAPSED}s / ${TIMEOUT}s)"
|
|
134
|
-
done
|
|
135
|
-
|
|
136
|
-
echo "FAIL: CI did not complete within ${TIMEOUT}s timeout"
|
|
137
|
-
return 1
|
|
138
|
-
```
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: release-branch
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Make the merge/PR/keep/discard decision for a feature branch, verify coverage gates, create the PR with gh, and clean up the worktree. Use when a feature is done and ready to ship, or when user says "release", "merge", or "open a PR".
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -100,11 +101,16 @@ mv specs/epics/eNN-slug specs/epics/archive/
|
|
|
100
101
|
|
|
101
102
|
> **HARD GATE** — Do NOT declare success until CI completes. A push that fails CI is a regression, not a release.
|
|
102
103
|
|
|
103
|
-
After push (solo-local step 5 or team-pr step 7),
|
|
104
|
+
After push (solo-local step 5 or team-pr step 7), run the CI polling script:
|
|
104
105
|
|
|
105
|
-
|
|
106
|
+
```bash
|
|
107
|
+
bash scripts/wait-for-ci.sh --timeout 600 --interval 30
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
The script auto-discovers workflow runs for the pushed commit and polls until completion.
|
|
111
|
+
See [REFERENCE.md](REFERENCE.md) for exit code semantics and git-only fallback.
|
|
106
112
|
|
|
107
|
-
- [ ] CI workflow passes after push
|
|
113
|
+
- [ ] CI workflow passes after push (wait-for-ci.sh exit 0)
|
|
108
114
|
- [ ] `release.ci_verified: true` documented in state.yaml
|
|
109
115
|
- On failure: `handoff.next_skill = fix-bug` with the CI failure URL
|
|
110
116
|
|
|
@@ -118,7 +124,17 @@ git branch -d <branch-name>
|
|
|
118
124
|
|
|
119
125
|
### 8a. Cycle-time recording
|
|
120
126
|
|
|
121
|
-
After landing, record delivery metrics
|
|
127
|
+
After landing, record delivery metrics with the git-derived, additive script:
|
|
128
|
+
|
|
129
|
+
```bash
|
|
130
|
+
bash scripts/record-cycle-time.sh append \
|
|
131
|
+
--story <story_id> --bcps <bcps> \
|
|
132
|
+
--range "$(git merge-base main HEAD)..HEAD" \
|
|
133
|
+
--file specs/metrics/cycle-times.yaml
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
This replaces the previous hand-arithmetic approach (story_end minus story_start).
|
|
137
|
+
See [REFERENCE.md](REFERENCE.md) for the git-hours model and field definitions.
|
|
122
138
|
|
|
123
139
|
### 9. Return to main
|
|
124
140
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: request-review
|
|
3
3
|
model: opus
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Dispatch a fresh reviewer agent with a clean context to critique the code after audit-code passes. The reviewer has no shared state with the coding agent and gives a genuine second opinion. Use after audit-code passes, before committing, or when user wants an independent code review.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: research-first
|
|
3
3
|
description: Look-before-build — search registries, repo, existing skills, and web for prior art before implementing. Appends Prior Art to the spec. Use after survey-context and before elaborate-spec, when adding dependencies, or when the task may already be solved.
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Research First
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: respond-review
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Act on a reviewer agent's feedback systematically — categorize findings, apply fixes, verify tests still pass. Use after request-review returns a report, or when user wants to work through code review findings.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: run-evals
|
|
3
3
|
description: Eval-Driven Development — define capability and regression evals before building; code graders use verify commands, model graders use explicit rubrics; log pass@k. Use before develop-tdd on new features, or when measuring agent capability over runs.
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Run Evals
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: run-planning
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: "DISCOVER-PHASE ADVANCER — Drive the discover-phase checklist (specs/planning-status.yaml) through survey-context → scope-work → research-first → elaborate-spec → plan-release → slice-tasks. NOT a duplicate of plan-work or the planning spine; it orchestrates the pre-coding discover phase only."
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: scope-work
|
|
3
3
|
description: "PLANNING SPINE STEP 1 of 3 — Scope the work: define what is in and out of scope and save as specs/product/SCOPE_LATEST.yaml. Use before slice-tasks or plan-release on any new initiative. Not a substitute for slice-tasks (step 2) or plan-work (step 3)."
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Scope Work
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: search-skills
|
|
3
3
|
description: Find the right bigpowers skill from natural-language intent using a local lexical index over SKILL.md frontmatter. Use when unsure which skill to invoke, or at start of research-first.
|
|
4
4
|
model: haiku
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Search Skills
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: seed-conventions
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Generate CLAUDE.md and CONVENTIONS.md for a brand-new project through a brief interview, and create the specs/ directory with evolved bigpowers structure (product/, tech-architecture/, verifications/, epics/archive/). Entry point for greenfield projects. Use when starting a new project from scratch, when user asks to set up AI agent conventions, or when there is no CLAUDE.md yet.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: session-state
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
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.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -10,6 +11,8 @@ description: Track implementation decisions and progress in specs/state.yaml to
|
|
|
10
11
|
|
|
11
12
|
Track the current state of implementation, including decisions made, pending tasks, and open questions, to ensure continuity across session boundaries and prevent "context rot."
|
|
12
13
|
|
|
14
|
+
Session-state implements the **isolate** strategy from the context-engineering framework (docs/references/context-engineering.md): each agent gets exactly the context it needs — no more — by recording decisions so the next agent can cold-start without replaying history. The four strategies (write, select, compress, isolate) work together: session-state handles isolation, terse-mode handles compression, survey-context handles selection, and CONVENTIONS.md ensures token-efficient writing.
|
|
15
|
+
|
|
13
16
|
## Goal
|
|
14
17
|
|
|
15
18
|
Maintain a single source of truth for the *current* session in `specs/state.yaml`. This complements long-term docs in `specs/tech-architecture/` and delivery detail in `specs/epics/` + `specs/release-plan.yaml`.
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: setup-environment
|
|
3
3
|
description: Pre-install dependencies and configure tools before development work begins. Use at session start on a fresh clone, before kickoff-branch, or when user says setup environment or install deps.
|
|
4
4
|
model: haiku
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Setup Environment
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: simulate-agents
|
|
3
3
|
description: Run Mock User and Auditor agents against a feature in fresh contexts before human review. Use after verify-work, before request-review, when user wants pre-review simulation.
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Simulate Agents
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: slice-tasks
|
|
3
3
|
description: "PLANNING SPINE STEP 2 of 3 — Slice the work: break a scoped PRD into vertical-slice stories in specs/epics/. Use after scope-work (step 1), before plan-work (step 3). Not a substitute for scope-work or plan-work."
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Slice Tasks
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: spike-prototype
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Throw-away prototype for unknown problem spaces. Output is learning notes in specs/archive/spikes/SPIKE-<name>.md, not production code. Use when the domain or technology is unexplored, when estimates are impossible without experimentation, or when user says "spike", "prototype", or "proof of concept".
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: stocktake-skills
|
|
3
3
|
description: Sequential subagent batch audit of the bigpowers skill catalog — Quick Scan (changed only) or Full (all skills). Use during sustain phase, before a major release, or when catalog drift is suspected.
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Stocktake Skills
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: survey-context
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -114,7 +115,7 @@ Report blockers first, before recommendations.
|
|
|
114
115
|
|
|
115
116
|
### 8. Record story start timestamp
|
|
116
117
|
|
|
117
|
-
At story start, write `metrics.story_start` with the current ISO 8601 timestamp to `specs/state.yaml`
|
|
118
|
+
At story start, write `metrics.story_start` with the current ISO 8601 timestamp to `specs/state.yaml` as an **informational progress marker only** — not a measurement input. Cycle-time metrics are now derived from git commit history via `scripts/record-cycle-time.sh` (see `skills/release-branch/REFERENCE.md` §Cycle-time recording).
|
|
118
119
|
|
|
119
120
|
## Utility outputs
|
|
120
121
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: terse-mode
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Fallback ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use ONLY when context is critically long and compressing output is necessary to continue. Not a strategy — token discipline comes from code shape (small functions, unique names, headless tests), not terser prompts. Use when user says "caveman mode", "terse mode", "less tokens", "be brief", or invokes /terse-mode.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: trace-requirement
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Link story IDs from specs/release-plan.yaml + epic capsule directories to the implementing code and tests. Produces specs/TRACEABILITY_LATEST.md. Use when you want to verify coverage of a release plan, audit which stories are implemented, or find "dark" stories with no code.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: using-bigpowers
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: One-time bootstrap that introduces the bigpowers skills system, the PMBOK lifecycle arc, and tells you which skill to call first for your situation. Use when starting with bigpowers for the first time, when user asks "where do I start?", or when the skills system needs to be explained.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: validate-contracts
|
|
3
3
|
description: "Assert data shape consistency across system boundaries — live API responses against JSON Schema, key-set comparison across layers, data shape validation for migrations and exports. Catches silent data corruption before deploy."
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Validate Contracts
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: validate-fix
|
|
3
3
|
model: haiku
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Prove a fix works before declaring done — re-run the failing test, run the full suite, typecheck, lint, and harden against recurrence. Use after implementing a bug fix, when user says "is this fixed?", or before closing an investigation.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: verify-work
|
|
3
3
|
description: Multi-phase UAT gate — cold-start smoke, build, typecheck, lint, tests, step-by-step manual verification, gaps-closure loop. Use after execute-plan or develop-tdd, before audit-code.
|
|
4
4
|
model: haiku
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Verify Work
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: visual-dashboard
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers/dashboard/. Reads specs/state.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.
|
|
5
6
|
---
|
|
6
7
|
|
package/skills/wire-ci/SKILL.md
CHANGED
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: wire-ci
|
|
3
3
|
description: "CI pipeline setup with pre-built templates and local validation. Generates GitHub Actions workflows, validates YAML syntax and permissions, supports dry-run via act/gh. The CI equivalent of wire-observability."
|
|
4
4
|
model: sonnet
|
|
5
|
+
effort: standard
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Wire CI
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wire-observability
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: write-document
|
|
3
3
|
model: sonnet
|
|
4
|
+
effort: standard
|
|
4
5
|
description: Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory.
|
|
5
6
|
---
|
|
6
7
|
|