| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 9 | 16 | 0% |
| Commands | 0 | 1 | 1 | 0% |
| Section tags | 0 | 4 | 3 | 0% |
What each file covers
Sections
0 shared · 9 only in A · 16 only in B- − bigpowers — Gemini CLI
- − Project
- − Commands
- − Architecture
- − Conventions
- − Never
- − Token Management
- − Agent Rules
- − bts toolchain
- + Assess Impact
- + Modes
- + Process
- + 1. Identify the target
- + 2. Find dependents
- + 3. Map to release plan stories
- + 4. List test coverage
- + 5. Classify risk
- + 6. Write specs/IMPACT_LATEST.md
- + Target
- + Dependents ([count])
- + Affected Stories
- + Test Coverage
- + Risk: Low / Medium / High
- + Recommended action
- + Risk score gating
Commands
0 shared · 1 only in A · 1 only in B- − npm install -g bigpowers && bigpowers setup
- + git log --oneline -10 -- [file-path]
Section tags
0 shared · 4 only in A · 3 only in B- − setup
- − code-style
- − do-not
- − agent-behaviour
- + test
- + testing-strategy
- + deployment
Line diff
danielvm-git/bigpowers · GEMINI.md
@@ −1 @@
1# bigpowers — Gemini CLI
2
3> **Auto-generated** by `sync-skills.sh` from `CLAUDE.md`. Edit CLAUDE.md, not this file.
4
5Read CONVENTIONS.md before any GitHub or git operation.
6
7## Project
8
9bigpowers — 58 agent skills for spec-driven, test-first software development by solo developers.
10Stack: Markdown / Bash (documentation-based; skills integrate with Claude Code, Cursor, Gemini CLI)
11
12## Commands
13
14| Action | Command |
15|---------|---------|
16| Install | `npm install -g bigpowers && bigpowers setup` |
17| Run | `bash scripts/sync-skills.sh` |
18| Test | N/A (documentation project) |
19| Build | `bash scripts/install.sh` (from source) |
20| Lint | `bash scripts/sync-skills.sh` (validates SKILL.md syntax) |
21
22## Architecture
23
24Collection of 58 verb-noun skills, each with a SKILL.md source file and supporting documentation. Includes Verify phase and profiles/. The sync-skills.sh script auto-generates artifacts for Cursor (.cursor/rules) and Gemini CLI (.gemini/extensions/bigpowers/) from SKILL.md sources. All planning and spec output goes to specs/ at the project root.
25
26## Conventions
27
28- Skill directories use verb-noun naming (two words, kebab-case)
29- Every skill has a single SKILL.md file as its source of truth
30- All planning/spec output goes to specs/ at project root
31- Artifacts in .cursor/rules and .gemini/ are auto-generated; edit SKILL.md, not artifacts
32- Run sync-skills.sh after any SKILL.md changes to regenerate artifacts
33
34## Never
35
36- Never edit .cursor/rules or .gemini/extensions/ directly — these are generated files
37- Never create a skill without a SKILL.md file and proper verb-noun naming
38- Never push changes without running sync-skills.sh first
39
40## Token Management
41
42- **Auto-Terse**: When a session exceeds 20 turns or the context window feels "heavy" (latency increasing), you MUST switch to `terse-mode` to save tokens.
43- **Context Compaction**: Every 10 turns, summarize the current session state and implementation decisions into a short, high-density note.
44- **Minimal Output**: Prefer text-only output for simple status; use `web_fetch` or `run_shell_command` only for evidence.
45
46## Agent Rules
47
48- **Workflow Mandate:** You MUST use the bigpowers skills (e.g., `plan-work`, `develop-tdd`, `craft-skill`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
49- Read specs/ and CONVENTIONS.md before writing code.
50- Write the minimum code that solves the stated problem. Nothing extra.
51- Never refactor, rename, or reorganize code outside the task scope.
52- Run tests after every change. Show evidence before declaring done.
53- One clarifying question beats a wrong assumption baked into 200 lines.
54- All written output (plans, specs, investigations) goes in specs/.
55
56## bts toolchain
57
58`bts` is installed. Prefer its verbs over ad-hoc shell commands.
59
60| Task | Command | Avoid |
61|------|---------|-------|
62| Search code | `bts find --print <pattern>` | grep / find / cat |
63| Interactive search | `bts find <pattern>` | manual grep pipes |
64| Compress for context | `bts compress <file>` or `cmd \| bts compress` | summarising by hand |
65| Repo map | `bts map` | listing files by hand |
66| Library docs | `bts docs <lib>` | guessing from training data |
67| Package source | `bts src <pkg>` | git clone |
68| Toolchain health | `bts doctor` | which / command -v |
69
70**Rules**
71- Search with `bts find` before opening files to locate a symbol or pattern.
72- Pipe anything > 200 lines through `bts compress` before adding to context.
73- Run `bts map` when asked for a repo overview.
74- Use `bts docs <lib>` before answering questions about library APIs.
75- If a tool is missing, say so and run `bts doctor` — do not silently substitute.
76
danielvm-git/bigpowers · .cursor/rules/assess-impact.mdc
@@ +1 @@
1---
2description: "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT_LATEST.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\"."
3alwaysApply: false
4---
5
6# Assess Impact
7
8> **HARD GATE** — Run this skill before `plan-work` whenever a change touches an existing module, symbol, or file used by more than one caller. Skip only for net-new code with no existing dependents.
9
10Find the blast radius of the proposed change before a single line is written.
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
17## Process
18
19### 1. Identify the target
20
21Name the symbol, module, or file being changed. If the user hasn't specified, ask one question: "What exactly are you changing?"
22
23### 2. Find dependents
24
25```
26grep -rn "[symbol-name]" . --include="*.ts" | grep -v node_modules
27git log --oneline -10 -- [file-path]
28```
29
30→ verify: `test -f specs/IMPACT_LATEST.md || test -d specs/bugs`
31
32### 3. Map to release plan stories
33
34Read `specs/release-plan.yaml + epic capsule directories` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
35
36→ verify: `test -f specs/release-plan.yaml && grep -ci "stor" specs/release-plan.yaml`
37
38### 4. List test coverage
39
40Find tests that exercise the target:
41
42```
43grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
44```
45
46→ verify: `test -d specs/epics || test -d skills`
47
48### 5. Classify risk
49
50| Level | Condition |
51|-------|-----------|
52| Low | ≤ 2 callers, all covered by tests |
53| Medium | 3–10 callers, partial test coverage |
54| High | > 10 callers, or shared API/interface, or no tests |
55
56### 6. Write specs/IMPACT_LATEST.md
57
58```
59## Target
60[symbol or file being changed]
61
62## Dependents ([count])
63- [file]: [caller or usage]
64
65## Affected Stories
66- Story [X.Y]: [title]
67
68## Test Coverage
69- [test file]: covers [scenario]
70- Gap: [untested behavior]
71
72## Risk: Low / Medium / High
73[One-sentence rationale]
74
75## Recommended action
76[Proceed / Add tests first / Discuss design]
77```
78
79→ verify: `grep "Risk:" specs/IMPACT_LATEST.md`
80
81Suggest `plan-work` once risk is understood and any test gaps are noted.
82
83## Risk score gating
84
85In `--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`.
91
@@ −1 +1 @@
1−# bigpowers — Gemini CLI
1+---
2+description: "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT_LATEST.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\"."
3+alwaysApply: false
4+---
25
3−> **Auto-generated** by `sync-skills.sh` from `CLAUDE.md`. Edit CLAUDE.md, not this file.
6+# Assess Impact
47
5−Read CONVENTIONS.md before any GitHub or git operation.
8+> **HARD GATE** — Run this skill before `plan-work` whenever a change touches an existing module, symbol, or file used by more than one caller. Skip only for net-new code with no existing dependents.
69
7−## Project
10+Find the blast radius of the proposed change before a single line is written.
811
9−bigpowers — 58 agent skills for spec-driven, test-first software development by solo developers.
10−Stack: Markdown / Bash (documentation-based; skills integrate with Claude Code, Cursor, Gemini CLI)
12+## Modes
1113
12−## Commands
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.
1316
14−| Action | Command |
15−|---------|---------|
16−| Install | `npm install -g bigpowers && bigpowers setup` |
17−| Run | `bash scripts/sync-skills.sh` |
18−| Test | N/A (documentation project) |
19−| Build | `bash scripts/install.sh` (from source) |
20−| Lint | `bash scripts/sync-skills.sh` (validates SKILL.md syntax) |
17+## Process
2118
22−## Architecture
19+### 1. Identify the target
2320
24−Collection of 58 verb-noun skills, each with a SKILL.md source file and supporting documentation. Includes Verify phase and profiles/. The sync-skills.sh script auto-generates artifacts for Cursor (.cursor/rules) and Gemini CLI (.gemini/extensions/bigpowers/) from SKILL.md sources. All planning and spec output goes to specs/ at the project root.
21+Name the symbol, module, or file being changed. If the user hasn't specified, ask one question: "What exactly are you changing?"
2522
26−## Conventions
23+### 2. Find dependents
2724
28−- Skill directories use verb-noun naming (two words, kebab-case)
29−- Every skill has a single SKILL.md file as its source of truth
30−- All planning/spec output goes to specs/ at project root
31−- Artifacts in .cursor/rules and .gemini/ are auto-generated; edit SKILL.md, not artifacts
32−- Run sync-skills.sh after any SKILL.md changes to regenerate artifacts
25+```
26+grep -rn "[symbol-name]" . --include="*.ts" | grep -v node_modules
27+git log --oneline -10 -- [file-path]
28+```
3329
34−## Never
30+→ verify: `test -f specs/IMPACT_LATEST.md || test -d specs/bugs`
3531
36−- Never edit .cursor/rules or .gemini/extensions/ directly — these are generated files
37−- Never create a skill without a SKILL.md file and proper verb-noun naming
38−- Never push changes without running sync-skills.sh first
32+### 3. Map to release plan stories
3933
40−## Token Management
34+Read `specs/release-plan.yaml + epic capsule directories` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
4135
42−- **Auto-Terse**: When a session exceeds 20 turns or the context window feels "heavy" (latency increasing), you MUST switch to `terse-mode` to save tokens.
43−- **Context Compaction**: Every 10 turns, summarize the current session state and implementation decisions into a short, high-density note.
44−- **Minimal Output**: Prefer text-only output for simple status; use `web_fetch` or `run_shell_command` only for evidence.
36+→ verify: `test -f specs/release-plan.yaml && grep -ci "stor" specs/release-plan.yaml`
4537
46−## Agent Rules
38+### 4. List test coverage
4739
48−- **Workflow Mandate:** You MUST use the bigpowers skills (e.g., `plan-work`, `develop-tdd`, `craft-skill`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
49−- Read specs/ and CONVENTIONS.md before writing code.
50−- Write the minimum code that solves the stated problem. Nothing extra.
51−- Never refactor, rename, or reorganize code outside the task scope.
52−- Run tests after every change. Show evidence before declaring done.
53−- One clarifying question beats a wrong assumption baked into 200 lines.
54−- All written output (plans, specs, investigations) goes in specs/.
40+Find tests that exercise the target:
5541
56−## bts toolchain
42+```
43+grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
44+```
5745
58−`bts` is installed. Prefer its verbs over ad-hoc shell commands.
46+→ verify: `test -d specs/epics || test -d skills`
5947
60−| Task | Command | Avoid |
61−|------|---------|-------|
62−| Search code | `bts find --print <pattern>` | grep / find / cat |
63−| Interactive search | `bts find <pattern>` | manual grep pipes |
64−| Compress for context | `bts compress <file>` or `cmd \| bts compress` | summarising by hand |
65−| Repo map | `bts map` | listing files by hand |
66−| Library docs | `bts docs <lib>` | guessing from training data |
67−| Package source | `bts src <pkg>` | git clone |
68−| Toolchain health | `bts doctor` | which / command -v |
48+### 5. Classify risk
6949
70−**Rules**
71−- Search with `bts find` before opening files to locate a symbol or pattern.
72−- Pipe anything > 200 lines through `bts compress` before adding to context.
73−- Run `bts map` when asked for a repo overview.
74−- Use `bts docs <lib>` before answering questions about library APIs.
75−- If a tool is missing, say so and run `bts doctor` — do not silently substitute.
50+| Level | Condition |
51+|-------|-----------|
52+| Low | ≤ 2 callers, all covered by tests |
53+| Medium | 3–10 callers, partial test coverage |
54+| High | > 10 callers, or shared API/interface, or no tests |
55+
56+### 6. Write specs/IMPACT_LATEST.md
57+
58+```
59+## Target
60+[symbol or file being changed]
61+
62+## Dependents ([count])
63+- [file]: [caller or usage]
64+
65+## Affected Stories
66+- Story [X.Y]: [title]
67+
68+## Test Coverage
69+- [test file]: covers [scenario]
70+- Gap: [untested behavior]
71+
72+## Risk: Low / Medium / High
73+[One-sentence rationale]
74+
75+## Recommended action
76+[Proceed / Add tests first / Discuss design]
77+```
78+
79+→ verify: `grep "Risk:" specs/IMPACT_LATEST.md`
80+
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`.
7691
