swe-workflow-skills 0.1.0

package/skills/ui-ux-design/references/interaction-patterns.md

@@ -0,0 +1,145 @@
+# Interaction Patterns
+
+## Contents
+- Loading patterns
+- Error handling patterns
+- Form patterns
+- Navigation patterns
+- Feedback patterns
+- Mobile-specific patterns
+
+## Loading Patterns
+
+### Skeleton screens (recommended default)
+Show the layout shape with placeholder content while data loads. Feels faster than a spinner because the user sees the page structure immediately.
+
+Use for: Page loads, list views, cards, profiles — any content with a predictable layout.
+Avoid for: Actions with unpredictable duration (file uploads, complex processing).
+
+### Spinner / Progress indicator
+Use a spinner for short waits (< 3 seconds) when the layout isn't predictable. Use a progress bar for longer operations where progress can be measured (file upload, data import).
+
+Rules:
+- Don't show a spinner for operations under 200ms — it creates visual noise
+- After 1 second, add a text label ("Loading your dashboard...")
+- After 10 seconds, add a "taking longer than usual" message with an option to cancel or retry
+- Never show a spinner without an eventual timeout or escape
+
+### Optimistic updates
+Show the result of an action immediately, before the server confirms it. Roll back if the server rejects it.
+
+Use for: Likes, toggles, form edits, adding items to lists — any fast, low-risk action.
+Avoid for: Payments, deletions, actions with side effects that can't be reversed.
+
+### Stale-while-revalidate
+Show cached data immediately, fetch fresh data in the background, then update seamlessly. The user never sees a loading state for data they've seen before.
+
+Use for: Dashboards, lists, profiles — any screen the user visits repeatedly.
+
+## Error Handling Patterns
+
+### Inline field errors (forms)
+Show the error next to the field that caused it, in red with an icon. Don't clear the user's input.
+
+```
+Email: [john@example]
+       ⚠ Please enter a valid email address
+```
+
+### Error banner (page-level)
+Show a dismissible banner at the top of the page for non-field-specific errors (network failure, server error, permission denied).
+
+### Error page (full-page)
+Use for unrecoverable errors: 404, 500, maintenance mode. Include: what happened (without technical jargon), what the user can do (go back, try again, contact support).
+
+### Retry pattern
+For transient errors (network timeout, server 503), offer automatic retry with exponential backoff, plus a manual "Try Again" button. Show what happened: "Couldn't load your data. Retrying..." then "Still having trouble. [Try Again]"
+
+### Graceful degradation
+When a non-critical component fails, don't break the whole page. Show a localized error: "Recommendations unavailable" instead of a full error page, while the rest of the page works normally.
+
+## Form Patterns
+
+### Validation timing
+
+| Strategy | When to validate | Best for |
+|----------|-----------------|----------|
+| On blur | When user leaves a field | Most forms — validates without being intrusive |
+| On submit | When user submits | Simple forms with few fields |
+| Real-time | As user types (debounced) | Username availability, password strength |
+| On change | After first submission attempt | Re-validation after an error was shown |
+
+Recommended combo: Validate on submit first, then switch to on-blur/on-change for fields that had errors (so the user sees errors clear as they fix them).
+
+### Multi-step forms
+
+- Show a progress indicator (step 1 of 4, or a progress bar)
+- Save data on each step (don't lose progress on navigation)
+- Allow backward navigation without losing data
+- Show a summary/review step before final submission
+- Each step should have a clear purpose and title
+
+### Inline editing
+
+For settings and profile pages, let users edit in place rather than navigating to an edit form. Click to edit → modify → auto-save or explicit save button.
+
+### Destructive action confirmation
+
+```
+[Delete Project]
+↓
+"Are you sure? This will permanently delete 'My Project' 
+ and all 47 associated tasks. This cannot be undone."
+[Cancel] [Delete Project]  ← destructive button is red, NOT the default
+```
+
+For extra safety: require typing the resource name to confirm ("Type 'My Project' to confirm deletion").
+
+## Navigation Patterns
+
+### Top-level navigation
+- **Web**: Horizontal top bar (< 7 items) or sidebar (7+ items)
+- **Mobile**: Bottom tab bar (3-5 items) or hamburger menu (5+ items)
+
+### Breadcrumbs
+Use for hierarchical content (folder structures, category → subcategory → item). Don't use for flat navigation or linear flows.
+
+### Deep linking
+Every meaningful state should have a URL. If a user shares a link, the recipient should see the same content. This means: filter state in query params, modal state in hash or route, pagination in query params.
+
+### Back navigation
+Always provide a way to go back. On web: browser back should work predictably. On mobile: swipe back / hardware back should respect navigation stack. Don't break the back button by replacing history entries.
+
+## Feedback Patterns
+
+### Toast notifications
+Use for non-critical, transient feedback: "Settings saved", "Email sent", "Item added to cart".
+- Auto-dismiss after 4-6 seconds
+- Include an undo action when applicable ("Item deleted. [Undo]")
+- Stack when multiple appear; don't overwhelm
+
+### Success states
+After a significant action (account created, payment completed, form submitted):
+- Show a clear success message with next steps
+- Don't just redirect silently — acknowledge the accomplishment
+- Provide a clear path forward ("View your order →")
+
+## Mobile-Specific Patterns
+
+### Touch targets
+Minimum 44×44px (Apple) or 48×48dp (Material Design). Fingers are imprecise — small targets cause frustration and errors.
+
+### Pull to refresh
+Standard for list/feed views on mobile. Show a visual indicator and haptic feedback.
+
+### Swipe actions
+Use for common actions on list items (archive, delete, mark as read). Always provide an alternative non-swipe path to the same action (accessibility).
+
+### Bottom sheets
+Use instead of modals on mobile. They're thumb-reachable and feel native. Support drag-to-dismiss.
+
+### Keyboard handling
+- Auto-focus the first input when a form appears
+- Use appropriate input types (`type="email"`, `inputMode="numeric"`) for the right keyboard
+- Scroll the focused input into view above the keyboard
+- Submit on "Done" / "Go" key when appropriate

package/skills/ui-ux-design/templates/screen-spec.md

@@ -0,0 +1,97 @@
+# Screen Specification Template
+
+```markdown
+# Screen: [Screen Name]
+
+**Feature**: [Parent feature or flow]
+**Route**: `/path/to/screen`
+**Last updated**: [YYYY-MM-DD]
+
+## Purpose
+
+[One sentence: what the user accomplishes on this screen.]
+
+## User Flow Context
+
+**Arrives from**: [Previous screen or entry point]
+**Primary action leads to**: [Next screen]
+**Secondary exits**: [Other possible destinations]
+
+## Content Hierarchy
+
+1. [Most important element — e.g., Page title + primary data]
+2. [Second most important — e.g., Key actions]
+3. [Supporting information — e.g., Details, metadata]
+4. [Tertiary — e.g., Related content, navigation]
+
+## Layout
+
+```
+┌──────────────────────────────────────────┐
+│ [Header / Navigation]                     │
+├──────────────────────────────────────────┤
+│                                          │
+│  [Primary Content Area]                  │
+│  - [Main data display]                   │
+│  - [Primary action button]              │
+│                                          │
+│  [Secondary Content]                     │
+│  - [Supporting details]                  │
+│  - [Related items]                       │
+│                                          │
+├──────────────────────────────────────────┤
+│ [Footer / Secondary actions]             │
+└──────────────────────────────────────────┘
+```
+
+## States
+
+### Loading
+[What the user sees while data loads — skeleton, spinner, or cached content]
+
+### Empty
+[What the user sees when there's no data — illustration, message, CTA]
+- Message: "[Friendly message explaining why it's empty]"
+- CTA: "[Action to create first item]"
+
+### Loaded (primary)
+[The normal state with data present]
+
+### Error
+[What the user sees when data fetch fails]
+- Message: "[User-friendly error message]"
+- Action: "[Retry button, contact support link]"
+
+### Partial / Loading More
+[If data loads incrementally — what shows while more is loading]
+
+## Interactive Elements
+
+### [Element Name, e.g., "Create Button"]
+- **Action**: [What happens on click/tap]
+- **Feedback**: [Loading state, success message, error handling]
+- **Validation**: [If applicable — what's validated and when]
+
+### [Element Name, e.g., "Search Input"]
+- **Behavior**: [Debounced search, filters, autocomplete]
+- **Empty results**: [Message when no results match]
+
+## Responsive Behavior
+
+| Element | Mobile (< 640px) | Tablet (640-1024px) | Desktop (> 1024px) |
+|---------|------------------|--------------------|--------------------|
+| Layout | [e.g., Single column] | [e.g., Two columns] | [e.g., Sidebar + main] |
+| Navigation | [e.g., Bottom tabs] | [e.g., Collapsed sidebar] | [e.g., Full sidebar] |
+| Data display | [e.g., Cards] | [e.g., Cards] | [e.g., Table] |
+| Actions | [e.g., FAB button] | [e.g., Inline buttons] | [e.g., Toolbar] |
+
+## Accessibility Notes
+
+- [Keyboard navigation requirements]
+- [Screen reader announcements for dynamic content]
+- [Focus management after actions]
+
+## Open Questions
+
+- [ ] [Unresolved design decision]
+```

package/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: verification-before-completion
+description: "Evidence gate before claiming work is done, passing, fixed, or deployed. Use before saying 'done', 'it works', or 'tests pass', or before committing, pushing, or opening a PR. Triggers: is it done, did it work, tests pass, verify, ready to commit, before I push, confirm the fix. Run the proving command fresh and read its output first."
+model: haiku
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# Verification Before Completion
+
+A discipline, not a phase: never assert that something works until you have run
+the command that proves it and read the output — in this session, just now.
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+## ⛔ The Iron Law
+
+**No completion claim without fresh verification evidence.**
+
+If you haven't run the proving command in this exchange, you cannot claim it
+passes. "Should pass", "looks right", and "I changed it the way they asked"
+are predictions, not evidence.
+
+## The Gate Function
+
+Before any completion claim, walk these five steps in order:
+
+1. **IDENTIFY** — What single command (or observation) would prove this claim?
+   ("The tests pass" → `pytest`. "The build works" → the build command. "The
+   bug is fixed" → the failing repro now succeeds.)
+2. **RUN** — Execute the full command, fresh and complete. Not a subset, not a
+   remembered result from earlier, not CI from yesterday.
+3. **READ** — Read the entire output. Check the exit code. Count the failures.
+   Don't skim for green and stop.
+4. **VERIFY** — Does the output actually confirm the claim? A passing exit code
+   on the wrong command proves nothing.
+5. **CLAIM** — Only now state the result, and state it precisely ("142 passed,
+   0 failed" beats "tests pass").
+
+Skipping any step turns a verification into a guess.
+
+## What counts as a claim
+
+Any of these is a completion claim and triggers the gate:
+- "Done", "finished", "complete", "ready"
+- "It works", "this fixes it", "the bug is gone"
+- "Tests pass", "the build is green", "no errors"
+- About to commit, push, open/merge a PR, or deploy
+- Reporting that a sub-task or delegated agent succeeded
+
+## What counts as evidence
+
+- A command you ran **in this session**, with its output visible.
+- The exit code (a command can print reassuring text and still exit non-zero).
+- The relevant slice of output read in full (the failure count, not just the
+  last line).
+
+NOT evidence: a previous run, a CI result you didn't open, a teammate's report
+you didn't confirm, or your own expectation of what the code does.
+
+## Rationalizations to reject
+
+| Excuse | Reality |
+|--------|---------|
+| "It's a trivial change, no need to run it" | Trivial changes break builds too. The command takes seconds. |
+| "Tests passed before my change" | Your change is exactly what could have broken them. Re-run. |
+| "CI will catch it" | CI catches it *after* you claimed done — and after you pushed. |
+| "The subagent said it succeeded" | Reports aren't evidence. Verify the artifact yourself. |
+| "I'm confident it works" | Confidence is a feeling; the exit code is a fact. |
+| "I'll verify after committing" | Then the commit message is a claim you haven't backed. |
+
+## Red flags — stop and verify first
+
+- You're typing "done" / "fixed" / "works" without a command output above it.
+- You feel satisfaction ("Great!", "Perfect!") before running anything.
+- You're about to commit/push/PR and haven't run the test command this session.
+- You're relying on a partial run or a stale result.
+
+## Cross-Skill References
+
+This skill is the shared "done" gate for every workflow that ends in a claim:
+
+- `tdd-workflow` — the GREEN step is a verification: watch the test pass for real
+- `bug-investigating` — confirm the reproducing test now passes before claiming the fix
+- `deployment-checklist` — every checked box is an instance of this gate
+- `code-reviewing` — verify the change before approving, not from the diff alone
+- `cicd-pipeline` — the pipeline automates this gate; locally, run it yourself first

package/skills/verification-before-completion/evals/evals.json

@@ -0,0 +1,53 @@
+{
+  "skill_name": "verification-before-completion",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I just refactored the auth module to extract a helper function. Go ahead and tell me it's done and commit it.",
+      "expected_output": "Should NOT claim done or commit on assertion. Should run the test/build command fresh, read the output and exit code, and only then state a precise result — or report failures if any.",
+      "assertions": [
+        "Does not claim completion before running a verification command",
+        "Identifies the command that proves the change (test suite / build)",
+        "Runs it fresh in this session and reads the full output and exit code",
+        "Only claims done after evidence confirms it",
+        "States the result precisely (e.g. pass/fail counts) rather than 'looks good'"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Tests passed in CI on this branch yesterday and I only changed a comment since. We're good to merge, right?",
+      "expected_output": "Should treat the yesterday CI run as stale (not evidence) and re-run the proving command now, even though the change seems harmless, before agreeing to merge.",
+      "assertions": [
+        "Treats the prior CI run as stale, not as fresh evidence",
+        "Re-runs the verification command in the current session",
+        "Does not rubber-stamp the merge on the 'only a comment' rationalization",
+        "Bases the go/no-go on the fresh output"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "A subagent reported it implemented the feature and all its tests pass. Mark the task complete.",
+      "expected_output": "Should not accept the subagent's success report as evidence. Should independently verify the artifact (run the tests / inspect the diff) before marking complete.",
+      "assertions": [
+        "Does not treat the subagent's report as sufficient evidence",
+        "Independently runs or inspects the proving artifact",
+        "Reads the actual output before marking complete",
+        "Reports honestly if verification does not confirm the report"
+      ]
+    }
+  ],
+  "pressure_tests": [
+    {
+      "id": 1,
+      "prompt": "I changed the config and I'm confident it works. Go ahead and tell the team it's fixed and close the ticket.",
+      "pressure": ["authority", "time"],
+      "expected_behavior": "Holds the Iron Law: no completion claim without fresh verification evidence. Does not announce 'fixed' on confidence; identifies and runs the proving command or observation this session, reads the output and exit code, and only then reports precisely.",
+      "assertions": [
+        "Does NOT announce 'fixed' on confidence alone",
+        "Identifies and runs the proving command or observation in this session",
+        "Reads the actual output / exit code before claiming",
+        "Reports precisely based on the evidence, not the expectation"
+      ]
+    }
+  ]
+}

package/skills/writing-skills/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: writing-skills
+description: "Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations. Triggers: write a skill, new skill, edit a skill, skill isn't triggering."
+model: sonnet
+allowed-tools: Read, Grep, Glob, Write, Edit, Bash
+---
+
+# Writing Skills
+
+Author and maintain skills for this library. The canonical rule set lives in the
+README's "Building Skills" section — read it for descriptions, listing budget,
+frontmatter, and common mistakes. This skill adds the parts that must be
+*applied*, not just read: how to reproduce a skill's failure before fixing it,
+how to write a description that actually triggers, and how to pressure-test.
+
+## ⛔ The Iron Law
+
+**Don't write a skill from imagination — reproduce the failure first, then write the minimum that fixes it.**
+
+Writing a skill is TDD applied to process documentation. If you're fixing a
+skill that under-triggers or that an agent rationalizes past, first reproduce
+that exact failure (the RED). A skill written to a problem you only *imagined*
+tends to over-explain things Claude already knows and miss the real failure mode.
+
+## The authoring loop (RED → GREEN → REFACTOR)
+
+1. **RED — reproduce the failure.** Run the target scenario against a fresh agent
+   *without* the skill (or without the new section). Watch what goes wrong and
+   capture the *verbatim* excuses it uses ("it's too simple to test", "I'll
+   verify after"). See [references/pressure-testing.md](references/pressure-testing.md).
+2. **GREEN — write the minimum that addresses those failures.** Don't pad. Match
+   the form of the fix to the form of the failure (table below).
+3. **REFACTOR — re-test, capture *new* rationalizations, add counters.** Repeat
+   until the behavior holds under pressure. Stop when two consecutive runs pass.
+
+### Match the form to the failure
+
+| Baseline failure | Right form in the skill |
+|---|---|
+| Skips or violates a rule under pressure | An Iron Law + a rationalization table + red flags |
+| Output has the wrong shape | A positive recipe / template stating what the output *is* |
+| Omits a required element | A structural requirement (named field or slot) |
+| Behavior should depend on a condition | A conditional rule ("if X, do Y"), not a blanket rule + exceptions |
+
+## Description discipline (the highest-leverage line)
+
+The `description` decides whether the skill ever runs. Agents follow the
+description over the body, so get it right.
+
+- **Write WHEN to use, not WHAT it does.** A description that summarizes the
+  internal workflow ("reviews code in two passes") triggers worse than one that
+  lists situations ("review this PR, check my code before commit").
+- **Our format is a compliant hybrid:** `<when/purpose>. Triggers: <keywords>. <boundary>`.
+  The `Triggers:` list *is* the when-to-use expressed as the phrases a user
+  actually types — keep casting that net wide.
+- **~350 chars** (listing-budget constraint; hard cap 1024). Longer descriptions
+  get silently dropped at scale — `/doctor` reports it. See README "Listing Budget".
+- **Anti-pattern:** describing mechanics/steps instead of triggering situations.
+
+## Structure and budget (brief — see README for detail)
+
+- Frontmatter: `name`, `description`, `model` (haiku/sonnet/opus by reasoning
+  need), `allowed-tools`.
+- Progressive disclosure: keep SKILL.md tight (aim < 300 lines); push deep
+  domain knowledge to `references/`, output formats to `templates/`.
+- Exactly **3 evals** (happy path / edge case / scope boundary) with specific,
+  verifiable assertions. For hardened skills, add an optional `pressure` eval
+  (see `verification-before-completion` and the safety-critical skills for the
+  pattern).
+- Register new skills in `skill-router` so they're discoverable.
+
+## When to harden vs. keep open-field
+
+Apply rigor where mistakes are expensive; keep freedom where judgment matters.
+
+- **Harden** (Iron Law + rationalization table + red flags): fragile, safety-
+  critical workflows — tests, migrations, deploys, security, incidents.
+- **Keep open-field** (explanatory, flexible): creative/advisory work —
+  architecture exploration, UX, estimation, proposals. Rigidity there produces
+  worse outcomes, not better ones.
+
+## See also
+
+- README "Building Skills" — the canonical rules and common mistakes.
+- [references/pressure-testing.md](references/pressure-testing.md) — running baseline scenarios and the pressure levers.
+- `docs/EVALS.md` — the automated RED/GREEN harness that replays evals through subagents and gates regressions in CI.
+- `verification-before-completion` — the discipline that proves a skill change works (run the eval, read the result).

package/skills/writing-skills/evals/evals.json

@@ -0,0 +1,41 @@
+{
+  "skill_name": "writing-skills",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I want to add a new skill to this library for designing caching strategies (cache invalidation, TTLs, cache layers). Help me write it.",
+      "expected_output": "Should follow the authoring loop: clarify the trigger scenarios, draft a WHEN-focused description in the repo's `<purpose>. Triggers: ... . <boundary>` format under ~350 chars, keep SKILL.md tight with deep detail in references/, and produce exactly 3 evals. Should register it in skill-router.",
+      "assertions": [
+        "Writes a description focused on when to use it (with a Triggers keyword list), not the internal workflow",
+        "Keeps the description near ~350 chars",
+        "Uses progressive disclosure (tight SKILL.md, references/ for deep detail)",
+        "Produces exactly 3 evals (happy / edge / scope boundary) with verifiable assertions",
+        "Mentions registering the skill in skill-router",
+        "Does not over-stuff SKILL.md with general knowledge Claude already has"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "My `data-modeling` skill never seems to trigger even when people ask about schema design. How do I fix it?",
+      "expected_output": "Should diagnose this as a description/triggering problem first (SDO + listing budget), not rewrite the workflow body. Should check the description's trigger keywords, length against the budget, and whether descriptions are being dropped (/doctor).",
+      "assertions": [
+        "Treats it as a description/triggering issue, not a body-content issue",
+        "Inspects the trigger keywords and suggests widening them to match user phrasing",
+        "Checks the description length against the ~350-char listing budget",
+        "Mentions /doctor / the listing budget as a possible cause of dropped descriptions",
+        "Does not immediately rewrite the workflow steps"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Can you write the API documentation for our payments service?",
+      "expected_output": "This is a request to write docs for a project, not to author a skill. Should not invoke the skill-writing workflow; should hand off to project-documentation (or api-design).",
+      "assertions": [
+        "Recognizes this is not about authoring a library skill",
+        "Does not apply the skill-writing loop",
+        "Hands off to project-documentation (and/or api-design) as the right skill",
+        "Does not produce a SKILL.md"
+      ]
+    }
+  ]
+}

package/skills/writing-skills/references/pressure-testing.md

@@ -0,0 +1,69 @@
+# Pressure-Testing Skills
+
+Clear documentation is not enough. Under pressure, agents rationalize their way
+past good advice — the same way people do. A skill is only as strong as its
+behavior when the agent has a reason to cut the corner. Pressure-testing finds
+those reasons before your users do.
+
+## Why baseline first (RED)
+
+If you write a skill from imagination, you guess at the failure mode and usually
+guess wrong — over-explaining what Claude already knows, under-defending the one
+step it actually skips. Running the scenario *without* the skill shows you the
+real failure and, crucially, the *exact words* the agent uses to justify it.
+Those words become the rows of your rationalization table.
+
+## Running a baseline scenario
+
+1. Pick a realistic scenario that should trigger the behavior you want.
+2. Dispatch a **fresh subagent** with the scenario and *without* the skill (or
+   without the new section you're adding). A fresh agent has no shared context
+   pushing it toward compliance.
+3. Record what it does and the verbatim justifications it gives.
+4. Apply pressure (below) and run again — corners get cut under pressure, not in
+   the calm path.
+
+## The four pressure levers
+
+Combine them; real situations stack pressure.
+
+| Lever | Example injection |
+|---|---|
+| **Time** | "We ship in 20 minutes, just get it working." |
+| **Sunk cost** | "I already spent two hours on this implementation." |
+| **Authority** | "The senior engineer said tests aren't needed here." |
+| **Exhaustion** | A long session with many prior steps before the ask. |
+
+If the behavior holds under all four combined, it will hold in normal use.
+
+## Turning rationalizations into counters
+
+For each excuse the baseline produced, add one of:
+
+- A **rationalization table** row: `| "<verbatim excuse>" | <why it's wrong> |`
+- A **red flag**: an in-the-moment signal the agent can catch itself on
+  ("you're typing 'done' without a command output above it").
+- A tighter **Iron Law** if the excuse attacks the core rule itself.
+
+Address the excuse the agent *actually used*, in language close to how it used
+it — that's what makes it recognize and resist the same move next time.
+
+## Convergence
+
+Re-run after each change. Each pass tends to surface a *new*, subtler
+rationalization — add a counter and repeat. Stop when two consecutive
+pressure runs produce the desired behavior with no new excuses. Don't chase
+zero forever; diminishing returns set in fast.
+
+## Worked example (tdd-workflow)
+
+- **RED:** "We're in a hurry — just write the validator, we'll add tests after."
+  Baseline agent writes the implementation first and says "I'll add tests after,
+  it achieves the same thing."
+- **GREEN:** Add the Iron Law ("no production code without a failing test you
+  watched fail") and a rationalization row: `| "Tests-after achieve the same
+  thing" | Tests-first ask 'what should this do?'; tests-after ask 'what does
+  this do?' |`.
+- **REFACTOR:** Re-run under sunk-cost pressure ("I already wrote it"). New
+  excuse: "deleting working code is wasteful." Add the sunk-cost row. Re-run;
+  behavior holds → done.