Add doc-trim + grill-me + human-response, drop full-code-review

.claude/skills/doc-trim/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: doc-trim
+description: Trim editorial bloat from technical docs (integration writeups, ADRs, investigation notes, READMEs). Proposes a unified diff with per-cut rationale and waits for approval. Use when asked to "trim this doc", "tighten this writeup", "filter pass on X.md", "prune the doc", or "cut the slop from this writeup".
+---
+
+# Doc trim
+
+Editorial pass on a single doc file. Propose a unified diff, tag each cut, and stop. Do not write until the user approves.
+
+## Rules
+
+- One file at a time. Ask for the path if unclear.
+- Deletions only (no reorders, no rewrites, no new sections). Add only the minimal join words needed for grammar.
+- Never cut: runnable code, fact tables, links, dates, version numbers, copy-paste commands.
+- Preserve voice. If a sentence has personality and carries signal, keep it.
+
+## Cut tags
+
+Each cut must match one. If none fits, do not cut.
+
+- `meta`: sentences about the doc itself ("this page records...", "we document the gap so...").
+- `restates-obvious`: editorial coda re-asserting what the reader just read.
+- `justification-chain`: extra clauses piled on after the conclusion already lands.
+- `wrapper-boilerplate`: shell/runner wrapping around a snippet the reader can re-wrap.
+- `duplicate-section`: section whose content is implied or already stated.
+- `prelude-padding`: "in case you wondered" clauses that delay the operative sentence.
+
+## Output
+
+Fenced unified diff for the file, then per-hunk rationale:
+
+    hunk @@ L11-L12: meta
+    hunk @@ L37: restates-obvious
+    hunk @@ L70-L78: wrapper-boilerplate
+
+Stop. Wait for "apply" / "go" / specific hunks to skip. Then write.
+
+## Push back
+
+- Already tight: say so in one line and stop.
+- Cut would change meaning: flag with `RISK:` and let the user decide.

.claude/skills/grill-me/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.

.claude/skills/human-response/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: human-response
+description: Write a warm, human-to-human written response (handoffs, status updates, testing notes for QA, sign-off requests, confirming assumptions before merging, or escalating an open question). Use when the user asks to draft a response, reply to a thread, write a handoff, send testing notes, ask the team to confirm something, phrase a Slack or PR comment, or convert dev-flavored notes into a message a teammate would actually enjoy reading.
+---
+
+# Human response
+
+Write to a colleague, not a ticket. Greet by name or @mention, frame in one line, end with thanks.
+
+## Pick the shape
+
+- Sign-off / scope confirmation: open with "I'm assuming (please confirm):" + tight bullets, one specific claim each. Then questions prefixed `Question:` / `Another one:`. Parenthetical asides welcome when they carry signal (`(There be dragons!)`).
+- Testing notes / step-by-step handoff: group setup by role ("As admin, ..." then "As <user>, ..."). One concrete action per line, in order. Close with the expected outcome in plain prose.
+- Per-item status reply: mirror their numbering. Per item, lead with resolution ("fixed.", "fixed, <one-line how>") or short rationale for judgment calls. Flag gaps ("(#4 absent in your comment)"). Surface side-discoveries inline. For design calls, name alternatives weighed and invite pushback. Close with what's next.
+
+## Hard rules
+
+- No bold. No em-dashes (use commas, periods, colons, parentheses).
+- No deflection ("ask dev", "the team will provide"). Look up the real value and inline it. If unknowable, "I will send you X separately" and follow through.
+- Quote UI labels exactly ("Offline", "No throttling"). The reader will look for that exact string.
+- Use `<angle-bracket>` placeholders for values only the recipient knows (`<user email>`, `/path/<id>`). Never invent realistic-looking examples.
+- Hedge optional verification: "You could check X if you think that's necessary, but that's more an implementation detail I think." Never prescribe optional steps.
+- Address by name, not by role ("QA", "the reviewer"). Skip "you must", "obviously", "simply", "just".
+
+## Worked examples
+
+Sign-off:
+
+> Hi @<name>. I'm assuming (please confirm):
+> - New per-user feature flag `<flag>`, default off. <Behavior> activates only when `<group_flag>` and `<flag>` are both on.
+> - Same `<endpoint>` endpoint. `<unrelated_component>` untouched.
+>
+> Question: Pilot first or staged per `<group_flag>`-enabled group?
+> Another one: <edge case> is <chosen behavior>, no <missing UI>. Acceptable? (There be dragons!)
+>
+> Thank you!
+
+Per-item status reply:
+
+> Hi @<name>! Status on each item:
+> 1. <Item 1>, fixed.
+>    - While in there I noticed <side-discovery>. Standardized to <chosen value>.
+> 2. <Item 2>, fixed UX. <One-line constraint that shaped the fix>.
+> 3. (#3 absent in your comment)
+> 4. <Item 4>. <How it works now>. I think it's better than '<alt A>' and '<alt B>'. Do you see we may need to change anything here?
+>
+> Just pushed. Let me know how each goes. Thanks!