From cc-skills
When the user substantively pushes back on your approach or design and that pushback resolves into a changed direction, write a concise markdown entry to /Users/jcjustin/Projects/tippytop/pushback-vault and commit it. Trigger automatically (the user does not need to ask) on questioning, reframing, root-cause diagnoses, Socratic challenges, or approach corrections that materially change what you do. Skip trivial corrections (typos, syntax preferences) and unresolved disagreements.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cc-skills:pushback-vaultThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
When the user pushes back on something you said or did — and that pushback resolves into a real change — capture it in `/Users/jcjustin/Projects/tippytop/pushback-vault/` and commit it. **This is automatic. The user does not have to ask.**
When the user pushes back on something you said or did — and that pushback resolves into a real change — capture it in /Users/jcjustin/Projects/tippytop/pushback-vault/ and commit it. This is automatic. The user does not have to ask.
When the user pushes back during a conversation, you often defend the existing direction across several turns before conceding. By the time the conversation ends, that resistance has been quietly replaced with the better answer — but the learning lives in the diff between your initial position and the final one. The vault captures that diff so the user can read back later and you can read back to recognize patterns in your own reasoning.
The vault is not a complaint log. It's a record of decisions that moved because of the user's input, written so a future reader can reconstruct the why.
A pushback episode has three parts: (1) user pushes back, (2) you initially defend or partially concede, (3) the conversation resolves into a changed approach. Write the entry at step 3, not at step 1. Writing too early risks capturing a "resolution" that gets reversed two turns later.
A pushback has resolved when at least one of the following holds, and the conversation has moved forward for at least one turn:
If you write an entry and the resolution gets reversed later in the same session, edit or delete the file rather than leaving a stale snapshot.
This skill captures pushback that arises organically during work. If the user is explicitly invoking this skill — e.g., "vault this", "write up that pushback", "create a pushback entry" — that's a direct request, not an automatic trigger. Follow it as a request without invoking the skill recursively to log the act of being asked.
Use this exact template. Keep entries under ~50 lines so they stay scannable.
# Pushback — <topic in 3-7 words>
**Date:** YYYY-MM-DD
**Scope:** <repo / area / project — e.g., "ren, ren-backend (feat/hybrid-grading)" or "general workflow">
## Context
<One paragraph. What were we doing? What was the design / approach / claim I was defending? Why was the user engaging with it?>
## The pushback(s)
### 1. <Short label for this push>
> "<verbatim quote of the user's message>"
<1-3 sentences. What was I doing before? Where did I give ground in response?>
### 2. <Short label> — only if there were distinct moves
> "<verbatim quote>"
<as above>
## What changed
<3-6 bullets. Concrete deliverables: schema changes, code refactors, design pivots, things removed. Make the resolved outcome legible.>
## Pattern to notice next time
<1-3 sentences. What was the reasoning failure mode? What would have shortcut the conversation if I'd done it in turn 1?>
Two or three pushbacks is usually enough. If the user pushed back five times on the same point before you conceded, that's one episode with one or two load-bearing moves, not five entries. Use judgment about which exchanges actually shifted the design vs. which were friction on the way to the same shift.
The Pattern to notice next time section is the most valuable part for future-you. Be honest about the failure mode (defending the existing design reflexively, missing a precedent already in the codebase, generating plausible-sounding justifications without naming the core mechanism) rather than describing the disagreement neutrally. The point is calibration, not a chronological transcript.
Honest about reasoning failures, not self-flagellating. "I defended the existing design across three turns before conceding" is good. "I was completely wrong and should have known better" is not — it's both inaccurate and useless for future calibration. The user wants to learn from these, not read apologies.
/Users/jcjustin/Projects/tippytop/pushback-vault/YYYY-MM-DD-<kebab-case-slug>.mdassignment-mode-source-of-truth, migration-backfill-orphans, worktree-test-discoveryIf a file with the same date+slug already exists, append a suffix (-2, -3). Use today's date (date +%F), not the date of the original disagreement if you're catching up retroactively.
After writing the file, commit it without prompting:
cd /Users/jcjustin/Projects/tippytop && \
git add pushback-vault/<filename>.md && \
git commit -m "vault: <kebab-slug>"
Use a short conventional commit message. Do not add Co-Authored-By trailers (the user's global instruction forbids them). Do not push — the vault is local-history, not a published artifact.
If /Users/jcjustin/Projects/tippytop is not a git repo (or the vault folder lives outside one), check first with git -C /Users/jcjustin/Projects/tippytop rev-parse --is-inside-work-tree and skip the commit step if it's not tracked. Tell the user so they know.
After writing + committing, send a one-liner so they know it happened:
Vaulted:
pushback-vault/2026-05-18-assignment-mode-source-of-truth.md— committed.
No further explanation needed unless the user asks. Avoid making the vault entry itself part of the conversation — write it quietly and move on.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub jcsnap/claude-code-skills --plugin cc-skills