feat: add 4 mattpocock-inspired skills + tdd horizontal-slicing boost

CHANGELOG.md

@@ -5,6 +5,21 @@ All notable changes to the skill-set plugin will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.12.0] - 2026-05-04
+
+### Added
+
+- **grilling-plans**: New skill for adversarial pre-implementation interrogation of an existing plan or design — walks the decision tree one question at a time with recommended answers, prefers codebase exploration over questions, and surfaces contradictions between stated intent and actual code. Inspired by [mattpocock/skills](https://github.com/mattpocock/skills) `grill-me` / `grill-with-docs`.
+- **building-shared-vocabulary**: New skill that maintains a project's domain glossary in `CONTEXT.md` and architecture decisions in `docs/adr/` as living artifacts — files are created lazily, updated inline as terms resolve and decisions crystallize. ADR creation is gated on three criteria (hard-to-reverse, surprising-without-context, real trade-off). Inspired by [mattpocock/skills](https://github.com/mattpocock/skills) `grill-with-docs` (CONTEXT.md / ADR pattern).
+- **zooming-out-on-code**: New skill that draws a higher-level system map of unfamiliar code in the project's domain vocabulary — describes responsibility, callers, dependencies, and sibling modules without diving into implementation. Inspired by [mattpocock/skills](https://github.com/mattpocock/skills) `zoom-out`.
+- **improving-architecture**: New skill that surfaces deep-module refactor candidates across a codebase using Ousterhout's depth/seam framing — applies the deletion test, presents candidates with locality and leverage justifications, and hands off to `grilling-plans` for the chosen candidate's design. Inspired by [mattpocock/skills](https://github.com/mattpocock/skills) `improve-codebase-architecture`.
+- **/skill-set:plan:grill**: Slash command for `grilling-plans`.
+- **/skill-set:code:zoom-out**: Slash command for `zooming-out-on-code`.
+
+### Improved
+
+- **developing-test-first**: Added "Anti-Pattern: Horizontal Slicing" section after the Iron Law to forbid the bulk RED→RED→RED→...→GREEN→GREEN→GREEN pattern that produces tests of imagined rather than actual behavior. Inspired by [mattpocock/skills](https://github.com/mattpocock/skills) `tdd`.
+
 ## [1.11.1] - 2026-05-04
 
 ### Fixed

README.md

@@ -109,6 +109,8 @@ Skills are automatically available after installing the plugin. Claude will use
 /skill-set:ralph:execute
 /skill-set:pr-review:fix
 /skill-set:consulting:review
+/skill-set:plan:grill
+/skill-set:code:zoom-out
 ```
 
 ## Project Structure
@@ -164,6 +166,16 @@ Contributions welcome! Please see [AGENTS.md](AGENTS.md) for development guideli
 
 MIT
 
+## Acknowledgements
+
+The following skills were inspired by [mattpocock/skills](https://github.com/mattpocock/skills) (MIT license):
+
+- `grilling-plans` ← `grill-me` / `grill-with-docs`
+- `building-shared-vocabulary` ← `grill-with-docs` (CONTEXT.md / ADR pattern)
+- `zooming-out-on-code` ← `zoom-out`
+- `improving-architecture` ← `improve-codebase-architecture`
+- `developing-test-first` (Horizontal Slicing section) ← `tdd`
+
 ## Changelog
 
 See [CHANGELOG.md](CHANGELOG.md) for version history and migration guides.

plugins/skill-set/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "skill-set",
   "description": "Comprehensive productivity skills and development tools for Claude Code, including git workflow automation, code context understanding, peer LLM consulting, and PR review feedback processing.",
-  "version": "1.11.1",
+  "version": "1.12.0",
   "author": {
     "name": "ether-moon"
   },

plugins/skill-set/commands/code/zoom-out.md

@@ -0,0 +1,12 @@
+---
+description: Draw a higher-level system map of unfamiliar code in the project's domain vocabulary. Describes the module's responsibility, callers, dependencies, and sibling modules without diving into implementation details.
+---
+
+Invoke the `zooming-out-on-code` skill to get oriented in an unfamiliar area of the codebase. The skill goes up one level of abstraction from the file or function in question, reads the project's `CONTEXT.md` and relevant ADRs first, and produces a four-part map: responsibility, callers, dependencies, siblings — all in domain vocabulary, not implementation language.
+
+**When to use this command:**
+- Before changing code in an area you don't know
+- When a teammate hands off a system you have no prior context on
+- When you need orientation before diving deeper
+
+**Output is intentionally compact.** Deeper detail is a follow-up question, not part of this command's output.

plugins/skill-set/commands/plan/grill.md

@@ -0,0 +1,15 @@
+---
+description: Adversarially interrogate an existing plan or design before implementation. Walks the decision tree one question at a time with recommended answers, prefers codebase exploration over questions, and surfaces contradictions between stated intent and actual code.
+---
+
+Invoke the `grilling-plans` skill to stress-test the current plan, design, or proposal. The skill walks the decision tree one branch at a time, provides a recommended answer with each question, reads the codebase rather than asking when possible, and surfaces contradictions between user statements and actual code.
+
+**When to use this command:**
+- Between `superpowers:brainstorming` (creation) and `superpowers:writing-plans` (lock-down)
+- Before invoking `superpowers:executing-plans`
+- Right before a PR description is finalized
+- After picking a candidate from `improving-architecture`
+
+**Outputs:**
+- A shared understanding sharp enough to feed into implementation planning
+- Optionally hands off to `building-shared-vocabulary` if a domain term is sharpened or an ADR-worthy decision crystallizes

plugins/skill-set/skills/building-shared-vocabulary/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: building-shared-vocabulary
+description: Maintains a project's domain glossary in CONTEXT.md and architecture decisions in docs/adr/ as living artifacts — files are created lazily, updated inline as terms resolve and decisions crystallize, and conflicts with existing entries are surfaced immediately. Use this skill whenever a domain term is being pinned down, a decision sounds ADR-worthy, or vocabulary is about to drift — phrases like "domain glossary", "context.md", "we should write this down", "let's name this", "what do we call this", "is this worth an ADR", "pin down this term" — and as a side-effect of grilling-plans when terms or decisions surface.
+---
+
+# Building Shared Vocabulary
+
+## Overview
+
+A project's **domain glossary** (`CONTEXT.md`) and **architecture decision records** (`docs/adr/`) are not documentation written after the fact — they are operational artifacts that the agent reads to stay aligned with the project, and updates inline as the conversation produces new shared meaning.
+
+**Core principle:** Vocabulary is built up one resolved term at a time, in the moment the resolution happens. Batched glossary writes go stale.
+
+> `CONTEXT.md` is a **domain artifact**, not an agent directive. `guarding-agent-directives` does not apply — that skill protects `CLAUDE.md` / `AGENTS.md` and the documents they reference. This skill owns `CONTEXT.md` and `docs/adr/`.
+
+## When to Use
+
+- A domain term is being pinned down during conversation (especially during grilling)
+- A term in the user's plan conflicts with how the codebase uses it
+- A decision that is **hard-to-reverse**, **surprising-without-context**, AND **the result of a real trade-off** has been made — record an ADR
+- User explicitly asks to "build a glossary," "set up CONTEXT.md," "add an ADR"
+
+## Do NOT use for
+
+- Implementation-level documentation → README, code comments
+- Process or workflow documentation → AGENTS.md / CLAUDE.md (and check `guarding-agent-directives` first)
+- Library / framework reference → `understanding-code-context`
+- Generating PRDs or issues from conversation → out of scope here
+- Decisions that are easily reversed, obvious in hindsight, or had no real alternative → no ADR
+
+## Scope
+
+This skill supports a **single root `CONTEXT.md`** and a **single `docs/adr/` directory**. Multi-context monorepos (per-bounded-context glossaries, `CONTEXT-MAP.md` indexes) are out of scope; if a project genuinely needs them, that's a future enhancement.
+
+## Process
+
+### Lazy file creation
+
+Create files only on first real demand. An empty `CONTEXT.md` signals "this project has no shared vocabulary," not "no vocabulary surfaced yet" — speculative skeletons mislead future readers and the agent itself.
+
+| Trigger | Create |
+|---|---|
+| First domain term gets resolved | `CONTEXT.md` at repo root |
+| First decision meets the ADR bar | `docs/adr/0001-<slug>.md` |
+
+If the file already exists, append to it; never overwrite or reorder existing entries silently.
+
+### Updating `CONTEXT.md` inline
+
+When a term is resolved during conversation, update `CONTEXT.md` **right away** — not at the end of the session. Use the format in `reference/context-format.md`.
+
+**Rules:**
+- Only domain-meaningful terms. No implementation jargon, no tool names, no helper-function names.
+- One canonical name per concept. If the project has been calling the same concept by two names, pick one and note the deprecated alternative under "Avoid:".
+- Capture relationships between terms (e.g., "An Order has many Line Items").
+- Flag genuine ambiguity explicitly under "Flagged ambiguities".
+
+### Surface conflicts immediately
+
+When the user uses a term that conflicts with an existing `CONTEXT.md` entry, stop and surface it before continuing:
+
+> "`CONTEXT.md` defines **Cancellation** as the user-initiated revocation. You're using it for the system-initiated timeout. Do we update the definition, or do we need a new term?"
+
+Do not silently let the conflict pass. The conflict is the reason vocabulary exists.
+
+### Recording ADRs
+
+Offer an ADR **only when all three are true**:
+
+1. **Hard-to-reverse** — undoing the decision later costs real engineering effort
+2. **Surprising-without-context** — a future reader will wonder why this choice was made
+3. **The result of a real trade-off** — there were genuine alternatives, and one was picked for specific reasons
+
+If even one is missing, do not offer an ADR. "We picked Postgres because we know Postgres" is not an ADR.
+
+Use the format in `reference/adr-format.md`. Number sequentially (`0001-`, `0002-`, …). Filename slug should be a noun phrase (`0007-event-sourced-orders.md`).
+
+## Process Flow
+
+```
+term resolved during conversation
+  → conflict with existing CONTEXT.md entry?  yes → surface, resolve
+  → update CONTEXT.md inline
+
+decision made during conversation
+  → hard-to-reverse?       no → skip
+  → surprising-no-context? no → skip
+  → real trade-off?        no → skip
+  → all yes → offer ADR; on accept, write docs/adr/NNNN-<slug>.md
+```
+
+## Reading `CONTEXT.md` and ADRs
+
+When this skill is invoked or when the agent enters a project for code work, read these files first if present:
+
+1. `CONTEXT.md` at repo root (if exists)
+2. `docs/adr/*.md` in the area being touched (don't over-read; pull only ADRs whose titles match the area)
+
+Use the vocabulary from `CONTEXT.md` in:
+- File and module names suggested in plans
+- Variable and function names in implementations
+- PR titles, commit messages, issue descriptions
+- Conversation with the user
+
+## Reference
+
+- `reference/context-format.md` — exact format for a `CONTEXT.md` entry, with examples
+- `reference/adr-format.md` — exact ADR template and the three-criterion check
+
+## Troubleshooting
+
+| Symptom | Cause | Fix |
+|---|---|---|
+| `CONTEXT.md` is bloated with implementation terms | Adding non-domain terms | Remove anything that wouldn't appear in a conversation with a non-engineer domain expert |
+| Many ADRs over a short period | Bar set too low | Re-check each against the three criteria; demote ADRs that fail any |
+| Same concept has multiple ADRs | No conflict surfacing | When updating, search ADR titles first; if related, supersede the older one explicitly |
+| `CONTEXT.md` and code disagree | Code drifted, glossary didn't | Surface as a contradiction (this is exactly the signal `grilling-plans` Rule 4 catches) |
+| Multi-context monorepo wants per-domain glossaries | Out of scope for this skill | Use a single root `CONTEXT.md` with section headers per bounded context as a stopgap; raise as an enhancement |

plugins/skill-set/skills/building-shared-vocabulary/reference/adr-format.md

@@ -0,0 +1,96 @@
+# ADR Format
+
+Exact template for an Architecture Decision Record, plus the three-criterion check that gates whether to write one at all.
+
+## File location and naming
+
+Single directory at `/docs/adr/`. Filenames are sequential and slug-suffixed:
+
+```
+docs/adr/0001-event-sourced-orders.md
+docs/adr/0002-postgres-for-write-model.md
+docs/adr/0003-cancellation-as-line-item-operation.md
+```
+
+The slug is a noun phrase describing what the decision is about. Avoid verbs ("use-postgres") in favor of subjects ("postgres-for-write-model").
+
+## The three-criterion gate
+
+**Write an ADR only if all three are true.**
+
+### 1. Hard-to-reverse
+
+Undoing this decision later costs real engineering effort.
+
+| Hard-to-reverse | Easy-to-reverse |
+|---|---|
+| Database choice | Logger choice |
+| Public API shape | Internal helper signature |
+| Domain model decomposition | File organization |
+| Wire protocol | Local variable naming |
+| Library that touches every module | Library used in one place |
+
+### 2. Surprising-without-context
+
+A future reader, looking only at the code, would wonder *why* this choice was made.
+
+If the code makes the reasoning obvious, no ADR is needed. ADRs exist for choices whose rationale is not visible at the call site.
+
+### 3. The result of a real trade-off
+
+There were genuine alternatives. They were considered. One was picked for specific reasons.
+
+"We picked X because it's the standard" is not a real trade-off. "We picked X over Y because Y's eventual consistency would break our cancellation invariant" is.
+
+## Template
+
+The minimal template:
+
+```markdown
+# <Short title of the decision>
+
+<1-3 sentences: what's the context, what we decided, and why.>
+```
+
+That's it. **An ADR can be a single paragraph.** The value is in recording *that* a decision was made and *why* — not in filling out sections. Resist the urge to bulk it up.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs do not need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+If you reach for a section, ask: would removing this section lose information a future reader would need? If not, drop it.
+
+## Updates
+
+ADRs are immutable in principle. To change a decision:
+
+1. Write a new ADR explaining the new decision and what changed
+2. Add Status to the old ADR: `Superseded by ADR-NNNN`
+3. Cross-link both directions
+
+Do not delete superseded ADRs. The history is the value.
+
+## What qualifies for an ADR
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced; the read model is projected into Postgres."
+- **Integration patterns between contexts / services.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite — these stop the next engineer from "fixing" something deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.
+
+## What does NOT qualify
+
+- Renaming a function or file
+- Picking lint / formatter rules
+- Choosing a logger library (unless logging is a domain concern)
+- Migrating from yarn to pnpm, or similar tool swaps
+- Adding a new test framework
+- Picking commit message style
+
+If the decision is reversible by a single PR with no migration cost, it is not ADR-worthy.