moicle 2.3.1 → 3.0.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/README.md +36 -49
- package/assets/commands/marketing.md +6 -6
- package/assets/skills/docs/sync/SKILL.md +195 -157
- package/assets/skills/feature/build/SKILL.md +891 -0
- package/assets/skills/feature/track/SKILL.md +8 -8
- package/assets/skills/fix/bug/SKILL.md +449 -0
- package/assets/skills/fix/incident/SKILL.md +6 -6
- package/assets/skills/marketing/brand/SKILL.md +304 -0
- package/assets/skills/marketing/content/SKILL.md +199 -141
- package/assets/skills/research/explore/SKILL.md +392 -0
- package/assets/skills/review/code/SKILL.md +622 -0
- package/dist/commands/install/usage.js +2 -2
- package/dist/commands/install/usage.js.map +1 -1
- package/package.json +1 -1
- package/assets/skills/docs/write/SKILL.md +0 -274
- package/assets/skills/feature/api/SKILL.md +0 -277
- package/assets/skills/feature/deprecate/SKILL.md +0 -276
- package/assets/skills/feature/new/SKILL.md +0 -273
- package/assets/skills/feature/refactor/SKILL.md +0 -269
- package/assets/skills/fix/hotfix/SKILL.md +0 -233
- package/assets/skills/fix/pr-comment/SKILL.md +0 -186
- package/assets/skills/fix/root-cause/SKILL.md +0 -276
- package/assets/skills/marketing/logo/SKILL.md +0 -252
- package/assets/skills/marketing/seo-blog/SKILL.md +0 -367
- package/assets/skills/marketing/video/SKILL.md +0 -258
- package/assets/skills/research/onboarding/SKILL.md +0 -225
- package/assets/skills/research/spike/SKILL.md +0 -228
- package/assets/skills/research/web/SKILL.md +0 -204
- package/assets/skills/review/architect/SKILL.md +0 -274
- package/assets/skills/review/branch/SKILL.md +0 -277
- package/assets/skills/review/pr/SKILL.md +0 -231
- package/assets/skills/review/tdd/SKILL.md +0 -245
|
@@ -16,9 +16,9 @@ Run a multi-step task as a controlled loop: **brainstorm + plan first, get appro
|
|
|
16
16
|
- ✅ You want a clean history — one commit per completed step, easy to revert
|
|
17
17
|
- ✅ You want test-first discipline on each step, on a dedicated branch
|
|
18
18
|
- ❌ One-line / obvious change → just do it
|
|
19
|
-
- ❌ Urgent production bug → use `/fix-
|
|
20
|
-
- ❌ Single full DDD feature across all layers → use `/feature-
|
|
21
|
-
- ❌ Driving ONE unit test-first with no branch/checklist → use `/review-
|
|
19
|
+
- ❌ Urgent production bug → use `/fix-bug` (QUICK mode)
|
|
20
|
+
- ❌ Single full DDD feature across all layers → use `/feature-build` (NEW mode)
|
|
21
|
+
- ❌ Driving ONE unit test-first with no branch/checklist → use `/review-code` (TDD mode)
|
|
22
22
|
|
|
23
23
|
## Read Architecture First
|
|
24
24
|
|
|
@@ -119,7 +119,7 @@ Branch: `feat/{slug}`
|
|
|
119
119
|
- Tests added: {N}, all green
|
|
120
120
|
|
|
121
121
|
### Next
|
|
122
|
-
- Push + open PR, or run `/review-
|
|
122
|
+
- Push + open PR, or run `/review-code` (SELF mode) first
|
|
123
123
|
```
|
|
124
124
|
|
|
125
125
|
---
|
|
@@ -142,10 +142,10 @@ Branch: `feat/{slug}`
|
|
|
142
142
|
| When | Use |
|
|
143
143
|
|------|-----|
|
|
144
144
|
| Need idea frameworks for Phase 0 | `/brainstorm` |
|
|
145
|
-
| Drive ONE unit deeper test-first | `/review-
|
|
146
|
-
| Full DDD feature across all layers | `/feature-
|
|
147
|
-
| Self-review the branch after the loop | `/review-
|
|
148
|
-
| Urgent prod bug, no checklist | `/fix-
|
|
145
|
+
| Drive ONE unit deeper test-first | `/review-code` (TDD mode) |
|
|
146
|
+
| Full DDD feature across all layers | `/feature-build` (NEW mode) |
|
|
147
|
+
| Self-review the branch after the loop | `/review-code` (SELF mode) |
|
|
148
|
+
| Urgent prod bug, no checklist | `/fix-bug` (QUICK mode) |
|
|
149
149
|
|
|
150
150
|
## Recommended Agents
|
|
151
151
|
|
|
@@ -0,0 +1,449 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: fix-bug
|
|
3
|
+
description: Bug fixing workflow with two depths — QUICK (fast fix + rollback plan when cause is clear) and DEEP (systematic root-cause investigation for hard, intermittent, or recurring bugs). Use when fixing bugs, hotfixes, urgent issues, production bugs, or when user says "fix bug", "hotfix", "urgent fix", "production issue", "deep debug", "deep-debug", "trace bug", "find root cause", "hard bug", "investigate bug".
|
|
4
|
+
args: "[MODE]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Bug Fix Workflow
|
|
8
|
+
|
|
9
|
+
One skill, two depths. Start in **QUICK** when the cause is clear; escalate to **DEEP** when it isn't.
|
|
10
|
+
|
|
11
|
+
## Pick your mode
|
|
12
|
+
|
|
13
|
+
| Situation | Mode | Jump to |
|
|
14
|
+
|-----------|------|---------|
|
|
15
|
+
| Bug is reproducible and root cause is clear (or identifiable in <1h) | **QUICK** | [Mode QUICK](#mode-quick) |
|
|
16
|
+
| Bug keeps returning after "fixes", intermittent, vendor internals, race condition, prod ≠ local | **DEEP** | [Mode DEEP](#mode-deep) |
|
|
17
|
+
|
|
18
|
+
**Escalation rule:** if in QUICK mode the 5 Whys don't converge, or repro fails because it's environment/state-specific → switch to DEEP.
|
|
19
|
+
|
|
20
|
+
- ❌ Production is down right now → use `/fix-incident` first (triage + comms), then come back here.
|
|
21
|
+
- ❌ Bug is on an open PR review → use `/review-code` (ADDRESS mode).
|
|
22
|
+
- ❌ Building a new feature → use `/feature-build` (NEW mode).
|
|
23
|
+
|
|
24
|
+
## Read Architecture First (both modes)
|
|
25
|
+
|
|
26
|
+
Read `ddd-architecture.md` + the stack-specific doc — the fix must land in the right layer (usecase / handler / infra) per architecture rules. Severity definitions: `~/.claude/architecture/_shared/severity-levels.md` (incident table). QUICK typically covers P2-P4; P1 → start with `/fix-incident`.
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
# Mode QUICK
|
|
32
|
+
|
|
33
|
+
Fast-track bug fix with a rollback plan. Use when the cause is identifiable in under an hour of investigation.
|
|
34
|
+
|
|
35
|
+
## When to use
|
|
36
|
+
|
|
37
|
+
- ✅ Bug is reproducible and root cause is clear (or quickly identifiable)
|
|
38
|
+
- ✅ Need a fix shipped fast with a rollback plan
|
|
39
|
+
- ✅ Severity ranges from low (minor UI) to high (feature broken)
|
|
40
|
+
- ❌ Production is down right now → use `/fix-incident` first
|
|
41
|
+
- ❌ Bug has been "fixed" multiple times and keeps returning → switch to **Mode DEEP**
|
|
42
|
+
|
|
43
|
+
## Workflow
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
IDENTIFY → REPRODUCE → FIX → VERIFY → DEPLOY
|
|
47
|
+
↑ ↓
|
|
48
|
+
└── ROLLBACK (if needed)
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## Phase 1: IDENTIFY (≤15 min)
|
|
52
|
+
|
|
53
|
+
**Goal:** capture exactly what's broken — no speculation.
|
|
54
|
+
|
|
55
|
+
### Capture
|
|
56
|
+
- Error message / stack trace (verbatim)
|
|
57
|
+
- Steps to reproduce
|
|
58
|
+
- Expected vs actual behavior
|
|
59
|
+
- Environment (prod / staging / dev)
|
|
60
|
+
- Affected users (all / subset / specific tenant)
|
|
61
|
+
- Recent deploys / config changes (last 24-48h)
|
|
62
|
+
|
|
63
|
+
### 5 Whys (worked example)
|
|
64
|
+
> Q1: Why does checkout fail? A1: `OrderService.calculate` returns NaN.
|
|
65
|
+
> Q2: Why NaN? A2: `quantity * price` where price is undefined.
|
|
66
|
+
> Q3: Why undefined? A3: New SKUs from supplier feed have null price.
|
|
67
|
+
> Q4: Why null? A4: Feed schema added optional `price` field, defaulted to null.
|
|
68
|
+
> Q5: Why didn't validation catch it? A5: Import worker skips schema validation for "perf".
|
|
69
|
+
|
|
70
|
+
→ Root cause: skipped validation in import worker. Fix at the import boundary, not in checkout.
|
|
71
|
+
|
|
72
|
+
### Gate
|
|
73
|
+
- [ ] Error captured verbatim
|
|
74
|
+
- [ ] Reproduction steps known (or "intermittent" noted)
|
|
75
|
+
- [ ] Severity assigned (P2 / P3 / P4)
|
|
76
|
+
- [ ] Root cause identified (switch to **Mode DEEP** if 5 Whys doesn't converge)
|
|
77
|
+
|
|
78
|
+
## Phase 2: REPRODUCE (≤30 min)
|
|
79
|
+
|
|
80
|
+
**Goal:** reproduce locally before changing any code.
|
|
81
|
+
|
|
82
|
+
### Steps
|
|
83
|
+
1. Check out the deployed commit (NOT main if main has drifted)
|
|
84
|
+
2. Reproduce with the exact data / inputs from Phase 1
|
|
85
|
+
3. If you can't reproduce → it's environment-specific. Check:
|
|
86
|
+
- Env vars on prod vs local
|
|
87
|
+
- DB state / data shape
|
|
88
|
+
- Cache / CDN state
|
|
89
|
+
- Runtime version differences
|
|
90
|
+
|
|
91
|
+
### Gate
|
|
92
|
+
- [ ] Reproduced locally on the deployed commit
|
|
93
|
+
- [ ] OR documented why local reproduction is impossible + plan to test on staging
|
|
94
|
+
|
|
95
|
+
## Phase 3: FIX
|
|
96
|
+
|
|
97
|
+
**Goal:** smallest correct change at the right layer.
|
|
98
|
+
|
|
99
|
+
### Rules
|
|
100
|
+
- Fix at the **root cause**, not the symptom
|
|
101
|
+
- Land the fix in the right layer (boundary validation → handler/DTO; business rule → usecase; data shape → infra mapper)
|
|
102
|
+
- **Add a regression test first** (RED), then make it pass (GREEN). See `/review-code` (TDD mode).
|
|
103
|
+
- Don't refactor on the fix — separate PR
|
|
104
|
+
- If the fix requires schema migration, plan it as 2 deploys (compatible code first, then migration)
|
|
105
|
+
|
|
106
|
+
### Boundary defense
|
|
107
|
+
For data-shape bugs (null where not expected, type mismatch from external API): defend at the **trust boundary** (handler / adapter), not inside business logic.
|
|
108
|
+
|
|
109
|
+
### Gate
|
|
110
|
+
- [ ] Regression test added (red → green)
|
|
111
|
+
- [ ] Fix is in the right layer (per architecture)
|
|
112
|
+
- [ ] No unrelated changes in the PR
|
|
113
|
+
- [ ] Existing tests still pass
|
|
114
|
+
|
|
115
|
+
## Phase 4: VERIFY
|
|
116
|
+
|
|
117
|
+
**Goal:** confirm fix works without breaking other paths.
|
|
118
|
+
|
|
119
|
+
### Local
|
|
120
|
+
- [ ] Original failure no longer reproducible
|
|
121
|
+
- [ ] All tests pass (`{test command}`)
|
|
122
|
+
- [ ] Linter clean
|
|
123
|
+
- [ ] Build green
|
|
124
|
+
|
|
125
|
+
### Staging (if available)
|
|
126
|
+
- [ ] Deploy to staging
|
|
127
|
+
- [ ] Reproduce the failure scenario — should pass
|
|
128
|
+
- [ ] Smoke-test adjacent features (anything sharing the code path)
|
|
129
|
+
- [ ] Monitor logs for 5-15 min
|
|
130
|
+
|
|
131
|
+
### Gate
|
|
132
|
+
- [ ] Local + staging both verified
|
|
133
|
+
- [ ] No regressions in adjacent features
|
|
134
|
+
|
|
135
|
+
## Phase 5: DEPLOY
|
|
136
|
+
|
|
137
|
+
### Pre-deploy checklist
|
|
138
|
+
- [ ] PR reviewed (`/review-code` SELF + a teammate's PR review)
|
|
139
|
+
- [ ] Rollback plan documented (see below)
|
|
140
|
+
- [ ] On-call notified
|
|
141
|
+
- [ ] CHANGELOG entry
|
|
142
|
+
|
|
143
|
+
### Rollback plan
|
|
144
|
+
Document **before** deploying:
|
|
145
|
+
- Rollback method: `revert PR` / `redeploy commit {sha}` / `feature flag off` / `DB migration down`
|
|
146
|
+
- Estimated rollback time
|
|
147
|
+
- Who has authority to roll back (usually IC or on-call)
|
|
148
|
+
- Signal to roll back (specific metric + threshold)
|
|
149
|
+
|
|
150
|
+
### Deploy steps
|
|
151
|
+
1. Deploy via normal pipeline (don't skip CI even under pressure)
|
|
152
|
+
2. Watch metrics + logs for the symptom + adjacent code paths
|
|
153
|
+
3. Hold deploy attention for at least 1× normal request cycle (15-30 min)
|
|
154
|
+
|
|
155
|
+
### Gate
|
|
156
|
+
- [ ] Deployed successfully
|
|
157
|
+
- [ ] Symptom no longer occurring
|
|
158
|
+
- [ ] No new errors in monitoring
|
|
159
|
+
- [ ] Stakeholders notified
|
|
160
|
+
|
|
161
|
+
## Phase 6: ROLLBACK (if Phase 5 verify fails)
|
|
162
|
+
|
|
163
|
+
### When to roll back
|
|
164
|
+
- Error rate increases post-deploy
|
|
165
|
+
- New error type appears
|
|
166
|
+
- Adjacent feature breaks
|
|
167
|
+
- Performance degrades meaningfully
|
|
168
|
+
|
|
169
|
+
### How
|
|
170
|
+
1. Announce: "Rolling back {fix} in 60s due to {observation}"
|
|
171
|
+
2. Execute: revert / redeploy previous / flip flag / migration down
|
|
172
|
+
3. Verify rollback: metrics return to baseline
|
|
173
|
+
4. Post-mortem the rollback — what was missed in Phase 3/4?
|
|
174
|
+
|
|
175
|
+
## Final Report (QUICK)
|
|
176
|
+
|
|
177
|
+
```markdown
|
|
178
|
+
## Hotfix: {short description}
|
|
179
|
+
|
|
180
|
+
### Root cause
|
|
181
|
+
{From Phase 1, 5 Whys final answer}
|
|
182
|
+
|
|
183
|
+
### Fix
|
|
184
|
+
- File: `path/to/file:line` · Layer: {handler / usecase / infra}
|
|
185
|
+
- Approach: {boundary defense / logic correction / data migration}
|
|
186
|
+
|
|
187
|
+
### Tests
|
|
188
|
+
- Regression test: {file:line} — all tests passing
|
|
189
|
+
|
|
190
|
+
### Deploy
|
|
191
|
+
- Deployed: {timestamp} · Verified: {timestamp + how}
|
|
192
|
+
- Rollback plan: {revert / redeploy / flag / migration}
|
|
193
|
+
|
|
194
|
+
### Severity: {P2 / P3 / P4} · Status: SHIPPED ✅ (or ROLLED BACK + reason)
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
# Mode DEEP
|
|
201
|
+
|
|
202
|
+
For bugs that have been "fixed" multiple times and keep coming back, intermittent bugs, or errors deep inside vendor code. **Do not guess** — trace step by step.
|
|
203
|
+
|
|
204
|
+
## When to use
|
|
205
|
+
|
|
206
|
+
- ✅ Same bug returns after multiple "fixes"
|
|
207
|
+
- ✅ "Sometimes works, sometimes doesn't" — likely hidden state
|
|
208
|
+
- ✅ Error inside vendor / framework internals
|
|
209
|
+
- ✅ Local vs production behavior differs
|
|
210
|
+
- ✅ Race condition / concurrency suspected
|
|
211
|
+
- ❌ Bug is well understood, just needs a fix → **Mode QUICK**
|
|
212
|
+
- ❌ Production is down with user impact → `/fix-incident` first, then this mode
|
|
213
|
+
|
|
214
|
+
## Workflow
|
|
215
|
+
|
|
216
|
+
```
|
|
217
|
+
COLLECT → VERIFY → TRACE → ROOT CAUSE → CHECK HIDDEN STATE → FIX → VERIFY
|
|
218
|
+
```
|
|
219
|
+
|
|
220
|
+
**Time budget:** if you've traced for >2 hours with no convergence → stop, write down what you know, ask a teammate. Rabbit holes are real.
|
|
221
|
+
|
|
222
|
+
## Step 1: COLLECT — capture evidence exactly
|
|
223
|
+
|
|
224
|
+
Record **verbatim**, do not interpret:
|
|
225
|
+
|
|
226
|
+
- Exact error message (copy-paste, don't paraphrase)
|
|
227
|
+
- Stack trace: file, line, full call chain
|
|
228
|
+
- Affected environment (prod / staging / local)
|
|
229
|
+
- Frequency: always / intermittent / specific input / specific user
|
|
230
|
+
- Timing: started exactly when? aligns with a deploy / cron / data change?
|
|
231
|
+
|
|
232
|
+
### Gate
|
|
233
|
+
- [ ] Error captured verbatim
|
|
234
|
+
- [ ] Stack trace captured (or noted absent)
|
|
235
|
+
- [ ] Frequency known
|
|
236
|
+
- [ ] Timing noted (helps narrow "what changed")
|
|
237
|
+
|
|
238
|
+
## Step 2: VERIFY — running code = local code?
|
|
239
|
+
|
|
240
|
+
Do NOT assume prod = local.
|
|
241
|
+
|
|
242
|
+
- Identify the deployed commit
|
|
243
|
+
- `git diff` deployed vs local
|
|
244
|
+
- If they differ → read the deployed version before reasoning further
|
|
245
|
+
- Container / image involved? Verify the image tag, not just the source
|
|
246
|
+
|
|
247
|
+
### Gate
|
|
248
|
+
- [ ] Deployed commit identified
|
|
249
|
+
- [ ] Local checkout matches OR differences understood
|
|
250
|
+
|
|
251
|
+
## Step 3: TRACE — entry to failure, every step
|
|
252
|
+
|
|
253
|
+
The single most important step. Skip nothing.
|
|
254
|
+
|
|
255
|
+
### 3a. Entry → error line
|
|
256
|
+
- Where does the request / event / job enter? (route, listener, cron, queue handler)
|
|
257
|
+
- Which function calls which? Follow stack trace exactly
|
|
258
|
+
- How does data flow between layers?
|
|
259
|
+
|
|
260
|
+
### 3b. Where does faulty data come from?
|
|
261
|
+
- Created locally or loaded from DB / API / cache / session?
|
|
262
|
+
- Goes through serialize / deserialize?
|
|
263
|
+
- Goes through any transform / map / cast?
|
|
264
|
+
|
|
265
|
+
### 3c. Type + state at the moment of failure
|
|
266
|
+
- Actual runtime type (use a debugger or log)
|
|
267
|
+
- Expected type
|
|
268
|
+
- Why do they differ?
|
|
269
|
+
|
|
270
|
+
### 3d. Vendor / framework internals
|
|
271
|
+
- Open the vendor source at the EXACT line from the stack trace
|
|
272
|
+
- Trace backwards: who calls this method, with what args?
|
|
273
|
+
- What condition routes execution into the failing branch?
|
|
274
|
+
|
|
275
|
+
### Debugging tools
|
|
276
|
+
|
|
277
|
+
Use the right tool, not just `console.log`:
|
|
278
|
+
|
|
279
|
+
| Tool | When |
|
|
280
|
+
|------|------|
|
|
281
|
+
| **Debugger breakpoint** | Step through suspect code, inspect locals |
|
|
282
|
+
| **Conditional breakpoint** | Stop only when `x == nil` / `id == 42` |
|
|
283
|
+
| **Logpoint** (debugger) | Inject log without modifying source — useful in prod-like envs |
|
|
284
|
+
| **Memory / heap profiler** | Suspected memory leak or unbounded growth |
|
|
285
|
+
| **CPU profiler** | Slow path / hot loop |
|
|
286
|
+
| **Network trace** (Wireshark, browser devtools) | Wire-level issue with external API |
|
|
287
|
+
| **strace / dtruss** | Syscall-level (file, network) on Unix |
|
|
288
|
+
| **Time-travel debugger** (rr, Replay) | Hard non-determinism, race conditions |
|
|
289
|
+
| **Distributed tracing** (OpenTelemetry, Jaeger) | Cross-service latency or error origin |
|
|
290
|
+
|
|
291
|
+
### Gate
|
|
292
|
+
- [ ] Full call chain documented
|
|
293
|
+
- [ ] Source of faulty data identified
|
|
294
|
+
- [ ] Actual vs expected type / state recorded
|
|
295
|
+
|
|
296
|
+
## Step 4: ROOT CAUSE — answer 3 questions
|
|
297
|
+
|
|
298
|
+
1. **Why does it fail?** — the specific technical cause
|
|
299
|
+
2. **Why didn't it fail before?** — what changed (deploy, dep, data shape, config, traffic)
|
|
300
|
+
3. **Reproduction conditions?** — exact inputs / state that trigger it
|
|
301
|
+
|
|
302
|
+
If you cannot answer all 3 → return to Step 3.
|
|
303
|
+
|
|
304
|
+
### Gate
|
|
305
|
+
- [ ] All 3 questions answered with **evidence**, not speculation
|
|
306
|
+
|
|
307
|
+
## Step 5: HIDDEN STATE — check 6 sources
|
|
308
|
+
|
|
309
|
+
"Sometimes works, sometimes doesn't" bugs live here.
|
|
310
|
+
|
|
311
|
+
### 5a. Cache / serialization
|
|
312
|
+
- Cached object lost transient fields / lazy-loaded properties?
|
|
313
|
+
- Stale cache has OLD shape; new code expects NEW shape?
|
|
314
|
+
- Serialize / deserialize changes types? (int↔float, null handling, enum↔string, date timezone)
|
|
315
|
+
|
|
316
|
+
### 5b. Database / storage
|
|
317
|
+
- Collation / encoding affecting comparisons (e.g., case-insensitive collation hiding duplicates)?
|
|
318
|
+
- DB default values mismatch with code expectations (null vs empty string)?
|
|
319
|
+
- Schema on prod vs schema in code (migration not applied)?
|
|
320
|
+
- **Read replica lag** — write to primary, read from replica returns stale data?
|
|
321
|
+
|
|
322
|
+
### 5c. Concurrency / async
|
|
323
|
+
- **Race condition** — two requests modifying shared state simultaneously
|
|
324
|
+
- **Deadlock / livelock** — lock acquired but never released
|
|
325
|
+
- **Goroutine / async leak** — handler returned but background work continues
|
|
326
|
+
- **Request context cancelled** while async work depended on it
|
|
327
|
+
- **Channel / queue overflow** — messages dropped silently
|
|
328
|
+
- Use logs with nanosecond timestamps + request IDs to reconstruct the timeline
|
|
329
|
+
|
|
330
|
+
### 5d. Runtime / compiled cache
|
|
331
|
+
- OPcache / bytecode cache serving old file
|
|
332
|
+
- Compiled config / routes / views not cleared after deploy
|
|
333
|
+
- CDN / proxy cache serving stale asset
|
|
334
|
+
- Browser cache / service worker
|
|
335
|
+
|
|
336
|
+
### 5e. Environment
|
|
337
|
+
- Env vars on prod correct + complete?
|
|
338
|
+
- Runtime version (Node 20 vs 18, Go 1.22 vs 1.21) differs from local?
|
|
339
|
+
- Dependency versions differ (lockfile drift, transitive update)?
|
|
340
|
+
|
|
341
|
+
### 5f. Multi-tenancy (SaaS-specific)
|
|
342
|
+
- **Tenant ID leak** — query missing `WHERE tenant_id = ?`
|
|
343
|
+
- Cache key missing tenant prefix → tenant A sees tenant B's data
|
|
344
|
+
- Background job inherits wrong tenant context
|
|
345
|
+
- Connection pool reused across tenants without reset
|
|
346
|
+
|
|
347
|
+
### Gate
|
|
348
|
+
- [ ] All 6 categories considered (write N/A if not applicable)
|
|
349
|
+
- [ ] At least one category identified as the hidden state source (or explicitly ruled out)
|
|
350
|
+
|
|
351
|
+
## Step 6: FIX
|
|
352
|
+
|
|
353
|
+
Only after Step 4 is answered. The fix MUST:
|
|
354
|
+
|
|
355
|
+
- Address **root cause**, not symptom
|
|
356
|
+
- Be defensive at **trust boundaries** (cache, DB, external API, user input) — NOT in internal logic
|
|
357
|
+
- Handle the specific edge case found, without breaking the normal path
|
|
358
|
+
- Be small + reviewable
|
|
359
|
+
- Land in the correct layer (per `~/.claude/architecture/ddd-architecture.md`)
|
|
360
|
+
|
|
361
|
+
### Boundary defense pattern
|
|
362
|
+
For data-shape bugs from external sources: validate / coerce at the adapter, not inside business logic.
|
|
363
|
+
|
|
364
|
+
### Gate
|
|
365
|
+
- [ ] Fix targets root cause
|
|
366
|
+
- [ ] Defended at the boundary
|
|
367
|
+
- [ ] Normal code path not regressed
|
|
368
|
+
|
|
369
|
+
## Step 7: VERIFY
|
|
370
|
+
|
|
371
|
+
- Reproduce the Step 4 conditions → confirm fix works
|
|
372
|
+
- Normal code path still works
|
|
373
|
+
- Cache-related → test fresh load AND cached load
|
|
374
|
+
- Concurrency-related → reproduce under **load test** (10-100x normal concurrency)
|
|
375
|
+
- Verify against the deployed version (repeat Step 2)
|
|
376
|
+
- Add a **regression test** in the appropriate layer
|
|
377
|
+
|
|
378
|
+
### Gate
|
|
379
|
+
- [ ] Original failure no longer reproducible
|
|
380
|
+
- [ ] Normal flow works
|
|
381
|
+
- [ ] Cached / serialized paths both work (if applicable)
|
|
382
|
+
- [ ] Load-tested if concurrency-related
|
|
383
|
+
- [ ] Regression test added
|
|
384
|
+
|
|
385
|
+
## Final Report (DEEP)
|
|
386
|
+
|
|
387
|
+
```markdown
|
|
388
|
+
## Bug: {short description}
|
|
389
|
+
|
|
390
|
+
### Root Cause
|
|
391
|
+
{Specific technical cause from Step 4 Q1}
|
|
392
|
+
|
|
393
|
+
### Why it didn't fail before
|
|
394
|
+
{What changed: deploy / dependency / data shape / config / traffic / runtime}
|
|
395
|
+
|
|
396
|
+
### Reproduction
|
|
397
|
+
{Exact steps + data + environment}
|
|
398
|
+
|
|
399
|
+
### Hidden state source
|
|
400
|
+
{Cache / DB / Concurrency / Runtime / Env / Multi-tenant — or "none"}
|
|
401
|
+
|
|
402
|
+
### Fix
|
|
403
|
+
- File: `path/to/file:line` · Layer: {handler / usecase / infra adapter}
|
|
404
|
+
- Approach: {boundary defense / type coercion / locking / cache invalidation / etc.}
|
|
405
|
+
- Why this is root-cause, not symptom: {explanation}
|
|
406
|
+
|
|
407
|
+
### Regression test
|
|
408
|
+
- File: `path/to/test:line` — reproduces the original failure when fix removed
|
|
409
|
+
|
|
410
|
+
### Verification
|
|
411
|
+
- [x] Original failure no longer reproducible [x] Normal path works
|
|
412
|
+
- [x] Cached path works (if applicable) [x] Load tested (if concurrency-related)
|
|
413
|
+
```
|
|
414
|
+
|
|
415
|
+
---
|
|
416
|
+
---
|
|
417
|
+
|
|
418
|
+
## Hard Rules (both modes)
|
|
419
|
+
|
|
420
|
+
- **Reproduce before fixing** — no fix lands without local repro (or a documented reason + staging plan).
|
|
421
|
+
- **DO NOT GUESS / DO NOT FIX BEFORE UNDERSTANDING** — trace evidence, never infer from variable names; premature fix = new bug.
|
|
422
|
+
- **VERIFY DEPLOYED CODE** — never assume prod = local.
|
|
423
|
+
- **Fix at the root, not the symptom** — patching the symptom invites the bug back; defend at trust boundaries.
|
|
424
|
+
- **Regression test required** — every fix gets a test that would have caught it.
|
|
425
|
+
- **No drive-by refactor** — fix PR is focused; refactor goes in a separate PR.
|
|
426
|
+
- **Always have a rollback plan** documented before deploy; don't skip CI under pressure.
|
|
427
|
+
- **DEEP specifics:** check cache first for intermittent bugs; check multi-tenancy if SaaS; one root cause per bug; time-box investigation to ~2h before asking for help.
|
|
428
|
+
|
|
429
|
+
## Related Skills
|
|
430
|
+
|
|
431
|
+
| When | Use |
|
|
432
|
+
|------|-----|
|
|
433
|
+
| Production is down right now | `/fix-incident` first, then this skill |
|
|
434
|
+
| Bug is on an open PR | `/review-code` (ADDRESS mode) |
|
|
435
|
+
| Need to write regression test first | `/review-code` (TDD mode) |
|
|
436
|
+
| Self-review before opening PR | `/review-code` (SELF mode) |
|
|
437
|
+
| Research how others solved similar bugs | `/research-explore` (WEB mode) |
|
|
438
|
+
|
|
439
|
+
## Recommended Agents
|
|
440
|
+
|
|
441
|
+
| Phase / Mode | Agent | Purpose |
|
|
442
|
+
|--------------|-------|---------|
|
|
443
|
+
| IDENTIFY / TRACE | Stack-specific dev agent, `@code-reviewer` | Read error context / independent call-chain reading |
|
|
444
|
+
| Hidden state — DB | `@db-designer` | Schema, indexes, collation, replication |
|
|
445
|
+
| Hidden state — concurrency | `@perf-optimizer` | Race, deadlock, async leak |
|
|
446
|
+
| Hidden state — security/tenancy | `@security-audit` | Tenant isolation, auth context |
|
|
447
|
+
| FIX | Stack-specific dev agent, `@security-audit` | Boundary-defensive fix / security bugs |
|
|
448
|
+
| VERIFY | `@test-writer`, `@code-reviewer` | Regression test + quick review |
|
|
449
|
+
| DEPLOY | `@devops` | CI/CD + monitoring |
|
|
@@ -12,8 +12,8 @@ Structured workflow for handling production incidents from triage to postmortem.
|
|
|
12
12
|
- ✅ Production is down or degraded right now
|
|
13
13
|
- ✅ Users are impacted, on-call has been paged
|
|
14
14
|
- ✅ Need to coordinate response, mitigation, comms, and postmortem
|
|
15
|
-
- ❌ Bug is reported but no users impacted → use `/fix-
|
|
16
|
-
- ❌ Already mitigated, need to find root cause → use `/fix-
|
|
15
|
+
- ❌ Bug is reported but no users impacted → use `/fix-bug` (QUICK mode)
|
|
16
|
+
- ❌ Already mitigated, need to find root cause → use `/fix-bug` (DEEP mode)
|
|
17
17
|
- ❌ Postmortem only, no active incident → jump to Phase 5
|
|
18
18
|
|
|
19
19
|
---
|
|
@@ -205,7 +205,7 @@ Live walkthrough (5-10 min): outgoing IC walks incoming IC through the timeline
|
|
|
205
205
|
**Goal:** apply the permanent fix and verify.
|
|
206
206
|
|
|
207
207
|
### Actions
|
|
208
|
-
1. Confirm root cause (use `/fix-
|
|
208
|
+
1. Confirm root cause (use `/fix-bug` DEEP mode if not obvious)
|
|
209
209
|
2. Implement permanent fix following stack architecture
|
|
210
210
|
3. Add test that would have caught this
|
|
211
211
|
4. Deploy fix through normal pipeline (don't skip CI even under pressure — unless explicitly authorized)
|
|
@@ -340,10 +340,10 @@ Postmortem: {date} — link to come
|
|
|
340
340
|
|
|
341
341
|
| When | Use |
|
|
342
342
|
|------|-----|
|
|
343
|
-
| Bug reported but no active incident | `/fix-
|
|
344
|
-
| Root cause unclear, need deep investigation | `/fix-
|
|
343
|
+
| Bug reported but no active incident | `/fix-bug` (QUICK mode) |
|
|
344
|
+
| Root cause unclear, need deep investigation | `/fix-bug` (DEEP mode) |
|
|
345
345
|
| Need to roll back deployment | (use ops runbook, not a skill) |
|
|
346
|
-
| Documenting postmortem as a doc | `/docs-
|
|
346
|
+
| Documenting postmortem as a doc | `/docs-sync` (SINGLE mode) |
|
|
347
347
|
|
|
348
348
|
---
|
|
349
349
|
|