← ClaudeAtlas

fix-notelisted

Turn a bug you just fixed — the session's debugging or a closed issue — into one specific 'we fixed X' post. You draft from the real diff; capx never writes, it ships it guarded.
vb-tyagi/capx-cafe · ★ 0 · AI & Automation · score 75
Install: claude install-skill vb-tyagi/capx-cafe
Turn a bug the developer just closed into one honest "we fixed X" X post. **You write it** from the real debugging — the failing test that's now green, the root cause you tracked down, the diff that shipped. capx never generates content; it only ships (the post passes the casserole guardrail at send). Which fix, if the user named one: "$ARGUMENTS" Follow these steps: 1. **Find the real fix.** Default to the debugging you just did *this session* — the bug you closed, the root cause you found, the test now passing. If "$ARGUMENTS" points at something specific (an issue, PR, or commit), read it: `git show <sha>`, `git log --oneline`, and `gh issue view` / `gh pr view` if available. You need three *true* things: the **symptom** (what was broken, as someone actually hit it), the **cause** (why), and the **fix** (what changed). If you can't ground all three in the real work, ask — do not invent a bug or a fix. 2. **Check it's worth a post.** A user-facing bug, a nasty crash, data that was silently wrong, a hard root cause — those are worth telling people about. A typo fix, an internal refactor nobody hit, a lint tweak — skip it. If the fix isn't interesting to anyone outside the repo, say so and stop. 3. **Draft ONE post — symptom → fix.** The shape that lands is "*here's what was broken → here's what caused it → it's fixed now*," concrete throughout. Make it: - **Specific about the symptom** — name what actually broke and who felt it. "Loops silently