swe-workflow-skills 0.1.0

package/skills/project-proposal/evals/evals.json

@@ -0,0 +1,31 @@
+{
+  "skill_name": "project-proposal",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I want to propose migrating our monolithic Django app to microservices. Our CTO is skeptical and wants to see a business case. We have 15 engineers, the app serves 50K users, and deployments take 2 hours with frequent rollbacks. Help me write the proposal.",
+      "expected_output": "Should produce a concise proposal with clear problem statement (deployment pain, not just 'microservices are trendy'), alternatives including 'do nothing' and 'modular monolith', honest risk assessment, and measurable success criteria.",
+      "assertions": [
+        "Frames the problem as deployment pain and team scalability, not 'microservices are better'",
+        "Includes 'do nothing' and 'modular monolith' as alternatives",
+        "Provides rough effort estimate in person-weeks with a range",
+        "Risk assessment includes distributed system complexity and team skill gaps",
+        "Success criteria are measurable (deploy time, rollback rate, team velocity)",
+        "Keeps the proposal to 1-2 pages equivalent",
+        "Does NOT assume microservices are the right answer — presents it objectively"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Write a project proposal for adding a real-time chat feature to our SaaS product. Budget approval needed from the VP of Engineering.",
+      "expected_output": "Should ask clarifying questions about the business case before writing, then produce a structured proposal.",
+      "assertions": [
+        "Asks about the business justification (why chat? user demand data?)",
+        "Asks about build vs buy (Sendbird, Stream, custom WebSocket)",
+        "Includes build vs buy as alternatives",
+        "Estimates account for ongoing operational cost (not just build cost)",
+        "Risk section addresses real-time infrastructure complexity"
+      ]
+    }
+  ]
+}

package/skills/project-proposal/references/proposal-examples.md

@@ -0,0 +1,140 @@
+# Project Proposal Examples
+
+## Calibrating Depth by Project Scale
+
+A proposal for a 1-week internal tool looks very different from a proposal for a 6-month platform investment. Match depth to stakes:
+
+| Scale | Team size | Duration | Proposal length | Business case depth |
+|-------|-----------|----------|-----------------|---------------------|
+| Small | 1-2 engineers | < 2 weeks | Half a page | Problem + 1 metric |
+| Medium | 2-5 engineers | 2-8 weeks | 1 page | Full problem, ROI estimate |
+| Large | 5+ engineers or cross-team | 2+ months | 1-2 pages | Full business case, risk table |
+
+---
+
+## Small Scale: Quick-Start Proposal
+
+**Proposal**: Automate weekly dependency audit
+
+**Problem**: Our team manually checks `npm audit` and `pip audit` each Monday. This takes ~45 minutes and often gets skipped when the team is busy. Three unaddressed vulnerabilities slipped into production last quarter.
+
+**Solution**: Add a weekly scheduled CI job that runs security audits and opens a GitHub issue with findings if new critical/high vulnerabilities exist. Auto-closes the issue when the audit passes.
+
+**Estimate**: 1 engineer, 3 days.
+
+**Cost**: Zero infrastructure cost (existing CI minutes). Saves ~3 engineer-hours/month.
+
+**Success**: Zero manually-skipped audits. Vulnerabilities detected within 7 days of publication.
+
+---
+
+What makes this good: Problem is concrete ("three slipped into production"), solution is tiny in scope, estimate is honest, success is measurable. No risk table needed for a 3-day project.
+
+---
+
+## Medium Scale: Full Proposal
+
+**Proposal**: Customer-Facing Usage Dashboard
+
+**Problem**
+
+Enterprise customers currently email support to ask "how many API calls did we make this month?" Support handles ~40 such requests per month (4 hours of engineer time). 3 churned customers cited "poor visibility into usage" in exit surveys. Without usage visibility, customers don't know when they're approaching plan limits until they hit them — causing unexpected billing surprises.
+
+**Solution**
+
+Build a usage dashboard in the customer portal showing:
+- API calls (daily/weekly/monthly)
+- Current period usage vs. plan limit
+- Per-endpoint breakdown
+- Downloadable CSV for billing reconciliation
+
+Usage data already exists in our analytics database. This is a read-only UI over existing data.
+
+**Scope**
+
+Included: Web dashboard, email alerts at 80%/100% of plan limits, CSV export
+Excluded: Real-time updates (batch refresh every hour is sufficient), mobile app, per-user breakdown within an org
+
+**Estimate**
+
+- 2 engineers, 4 weeks
+- Design: 1 week (1 designer)
+- Infrastructure: No new services; read from existing analytics DB
+
+**Risks**
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| Analytics DB performance (high-read queries) | Medium | Medium | Add read replica; query pre-aggregated tables |
+| Scope expansion (customers request more metrics) | High | Low | Strict non-goals; defer to v2 |
+| Data accuracy concerns | Low | High | Display data freshness timestamp; add reconciliation note |
+
+**Success Criteria**
+
+- Support requests about usage drop by 80% within 60 days of launch
+- Customer satisfaction score (CSAT) for billing/usage queries improves
+- Zero plan limit surprises in first 90 days post-launch
+
+---
+
+## Large Scale: Platform Investment Proposal
+
+**Proposal**: Migrate Authentication to a Centralized Auth Service
+
+**Problem**
+
+Authentication logic is currently duplicated across 4 services (API, admin panel, mobile backend, partner portal). Last quarter:
+- A JWT signing key rotation took 3 days because it required coordinated deploys across all 4 services
+- An auth bug was fixed in 2 of 4 services; the other 2 remained vulnerable for 11 days
+- Onboarding a 5th service (analytics API) would require duplicating auth logic again
+
+Security team has flagged our auth architecture as high-risk in the last two security reviews.
+
+**Solution**
+
+Build a centralized auth service (OAuth2/OIDC server) that issues JWTs. All services validate tokens against a shared public key. Services no longer implement auth — they only validate tokens.
+
+**Architecture summary**:
+- Auth Service: issues tokens, handles login/logout/refresh, manages sessions
+- All other services: validate token signature + claims only (stateless validation)
+- Migration: phased, service by service, with backwards compatibility
+
+**Alternatives Considered**
+
+1. **Status quo + better coordination**: Document the auth pattern, add cross-service testing. Lower effort but doesn't eliminate duplication or key rotation pain.
+2. **Adopt a managed auth provider (Auth0, Cognito)**: Faster to implement, reduces maintenance burden. Rejected: $8,000/month at our user volume, and we'd lose control of session data (compliance concern).
+3. **Centralized auth service** (proposed): Higher upfront cost, eliminates duplication, solves key rotation, enables SSO as future option.
+
+**Estimate**
+
+- 3 engineers + 1 security engineer, 3 months
+- Phase 1 (auth service + API migration): 6 weeks
+- Phase 2 (remaining 3 services): 6 weeks
+- Infrastructure: +$200/month for dedicated auth service instances
+
+**Risks**
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| Auth service becomes single point of failure | Low | Critical | Multi-region deploy; circuit breakers in all services |
+| Migration breaks a service | Medium | High | Feature flag per service; rollback is re-enable old auth path |
+| Team expertise gap (OAuth2/OIDC) | Medium | Medium | Security engineer on team; use established library (Hydra or Keycloak) |
+| Scope expansion (add SSO, MFA) | High | Medium | Strict phase gating; SSO is explicitly v2 |
+
+**Success Criteria**
+
+- Key rotation takes < 1 hour (down from 3 days)
+- Auth vulnerabilities are patched in all services within 24 hours of discovery
+- New services require < 1 day to integrate auth (vs. current 2+ weeks)
+- Zero auth-related incidents in the 90 days following full rollout
+
+---
+
+## What to Cut When Time Is Short
+
+If stakeholders need a decision quickly, prioritize in this order:
+1. **Problem statement + impact** — without this, there's no decision to make
+2. **Estimate** — stakeholders need to know the cost
+3. **Success criteria** — how will we know it worked?
+4. **Risks** — what could go wrong?
+5. **Alternatives** — can be verbal rather than written for small proposals

package/skills/project-proposal/templates/proposal.md

@@ -0,0 +1,76 @@
+# Project Proposal Template
+
+```markdown
+# Project Proposal: [Project Name]
+
+**Author**: [Name]
+**Date**: [YYYY-MM-DD]
+**Status**: Draft | In Review | Approved | Rejected
+**Decision by**: [Date needed]
+
+## Problem
+
+[2-3 sentences: What problem exists, who has it, and what's the impact of not solving it?
+Include data if available: "Support receives ~40 tickets/week about X, costing ~$Y/month."]
+
+## Proposed Solution
+
+[1-2 paragraphs: What we'll build, at a high level. Not a technical spec — just enough
+for a stakeholder to understand the approach.]
+
+### Scope
+
+**In scope:**
+- [What's included]
+
+**Out of scope:**
+- [What's explicitly excluded — important for setting expectations]
+
+### Alternatives Considered
+
+| Option | Pros | Cons | Why not? |
+|--------|------|------|----------|
+| Do nothing | No cost | Problem persists | [Impact of inaction] |
+| [Alternative A] | [Pros] | [Cons] | [Reason rejected] |
+| [Alternative B] | [Pros] | [Cons] | [Reason rejected] |
+
+## Estimates
+
+| Item | Estimate |
+|------|----------|
+| Team size | [N] engineers, [N] designer |
+| Duration | [X-Y] weeks |
+| Infrastructure cost | $[X]/month |
+| Third-party tools | $[X]/month |
+| Total estimated investment | ~[X] person-weeks |
+
+## Risks
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| [Risk 1] | Med | High | [Strategy] |
+| [Risk 2] | Low | High | [Strategy] |
+| [Risk 3] | High | Med | [Strategy] |
+
+## Success Criteria
+
+| Metric | Current | Target | Measured After |
+|--------|---------|--------|----------------|
+| [Metric 1] | [Baseline] | [Goal] | [Timeframe] |
+| [Metric 2] | [Baseline] | [Goal] | [Timeframe] |
+
+## Timeline (Rough)
+
+- **Week 1-2**: [Phase 1 — e.g., Design + technical spike]
+- **Week 3-5**: [Phase 2 — e.g., Core implementation]
+- **Week 6**: [Phase 3 — e.g., Testing + launch]
+
+## Decision Requested
+
+[What you need from stakeholders: approval to proceed, budget allocation,
+resource commitment, or feedback on approach.]
+
+## References
+
+- [Related documents, prior research, competitive analysis]
+```

package/skills/project-review/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: project-review
+description: "Review a built project's execution health before a milestone — scope alignment, roadmap / execution-plan adherence, implementation maturity (what's production-ready vs stub/deferred), and the evidence it actually works (tests, coverage, validation results, changelog). Triggers: project review, execution review, are we on track, implementation vs roadmap, scope drift, readiness review, what's actually built, validation results review, pre-launch review. Use strategic-review for vision/positioning/market; technical-debt-review for a pure code-health audit."
+model: opus
+allowed-tools: Read, Grep, Glob, WebFetch, Write, Edit
+---
+
+# Project Review
+
+Assess how a project is actually executing against its own plan — what's built,
+what's claimed, what's proven, and where the gaps are. The output is an honest,
+prioritized execution picture a decision-maker can act on, not a code-by-code
+critique. The discipline is **separating "built" from "validated" from
+"planned"** and refusing to let any of the three stand in for the others.
+
+This is the **execution lens**. For vision, positioning, and market, run
+`strategic-review`; the two compose into a full pre-public / pre-milestone review
+(see [templates/full-review-prompt.md](../strategic-review/templates/full-review-prompt.md)).
+
+## Ground rule: cite or label
+
+Every claim is either **confirmed** (cite the file/path/command output that proves
+it) or **inferred** (say so, and say from what). A reviewer who blurs the two is
+worse than no reviewer — the decision-maker can't tell evidence from optimism.
+Never report a capability as working unless you saw it work or saw a test that
+exercises it.
+
+## Step 1: Inventory the claims and the plan
+
+Read the project's own statements of intent before judging anything:
+
+- **Scope & status claims** — README, vision/strategy docs, roadmap, execution
+  plan, CHANGELOG, milestone/issue tracker. What does the project say it is, what
+  phase does it say it's in, and what does it promise for the milestone in question?
+- **The hard boundaries** — declared scope and explicit non-goals. These are what
+  you measure scope drift against.
+
+Capture this as the baseline. Everything downstream is "reality vs this baseline."
+
+## Step 2: Map implementation maturity
+
+Walk the actual code/artifacts and classify each major component:
+
+| Tier | Meaning | Signals |
+|------|---------|---------|
+| **Production-ready** | Built, integrated, tested | Real implementation, callers, tests, in CI |
+| **Functional / thin** | Works but unproven or partial | Implemented, light/no tests, edge cases open |
+| **Stub / scaffold** | Shape exists, behavior doesn't | `TODO`, `NotImplemented`, empty handlers, returns mock data |
+| **Deferred / absent** | Named in the plan, not started | Referenced in docs/roadmap, no code |
+
+Be specific: name the package/module/path and the tier. The deliverable is a
+maturity map, not a vibe. Grep for stub markers (`TODO`, `FIXME`, `raise
+NotImplementedError`, `throw new Error("not implemented")`, `pass  # stub`).
+
+## Step 3: Reconcile against the roadmap — and find the drift
+
+Lay the maturity map over the plan from Step 1:
+
+- **Ahead / behind** — where is the code further along than the docs admit (common,
+  and a sign the strategy doc is stale), and where is it behind a milestone it
+  claims to have hit?
+- **Scope drift** — what got built that isn't in scope? What's in scope but
+  silently dropped? What crossed a declared non-goal boundary?
+- **Sequencing risk** — is load-bearing work scheduled after the milestone that
+  depends on it?
+
+## Step 4: Review the evidence it works
+
+This is where most reviews are too generous. "The code is built" is not "the
+concept is validated." Assess the evidence chain:
+
+- **Tests** — do they exist for the load-bearing paths, or only happy paths?
+  Coverage numbers if available; quality, not just quantity.
+- **Validation / experimental results** — if the project ran its own validation
+  (efficacy data, benchmarks, A/B results, user trials), read the *actual numbers*
+  and report what they say, including when they're **negative or inconclusive**.
+  Foreground an uncomfortable result; don't bury it.
+- **CI / checks** — does the pipeline actually gate, or is it advisory?
+- **The built-vs-validated gap** — state it explicitly: which capabilities are
+  built but unproven, and what evidence would close the gap?
+
+## Step 5: Prioritized execution findings
+
+Produce ranked, severity-tagged findings, each tied to its evidence:
+
+- **Severity** — Critical (blocks the milestone / claim is false) / High (material
+  risk) / Medium (should fix) / Low (note it).
+- **Each finding**: what, the evidence (cited), why it matters for the milestone,
+  and the smallest action that addresses it.
+- **An execution scorecard** — maturity, roadmap-adherence, evidence-strength,
+  each rated with a one-line justification, so the reader gets the picture at a glance.
+
+For the rendered deliverable (interactive HTML report, dashboards, sortable
+findings table), hand off to `artifact-design`. Default to writing it to a
+gitignored location (e.g. `.local/`) unless told otherwise.
+
+## Principles Applied
+
+- **Honesty over comfort** — a review that flatters the plan is worthless; lead
+  with the most load-bearing problem, even when it undercuts the project's thesis.
+- **Evidence over assertion** — confirmed vs inferred, always; cite the source.
+- **Prioritize** — a ranked short list of what matters beats an exhaustive catalog.
+- **Right altitude** — execution health, not line-level nits (that's `code-reviewing`).
+
+## Cross-Skill References
+
+- `strategic-review` — the other half of a pre-public review: vision, positioning, market.
+- `technical-debt-review` — when the question is purely codebase health / remediation roadmap.
+- `code-reviewing` — for a specific diff or PR, not a whole-project assessment.
+- `metrics-and-okrs` — to turn findings into measurable readiness gates.
+- `artifact-design` — to render the review as a polished interactive report.

package/skills/project-review/evals/evals.json

@@ -0,0 +1,42 @@
+{
+  "skill_name": "project-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're about to go public with our toolkit. It's spread across a strategy repo, a core implementation repo, and a validation harness. Before we announce, review where the project actually stands against its roadmap — what's really built, what's still a stub, and whether our own validation backs up the claims.",
+      "expected_output": "A structured execution review: inventories the project's own scope/roadmap claims, maps implementation maturity by component (production-ready vs stub/deferred), reconciles against the roadmap to surface ahead/behind and scope drift, reads the actual validation results (including negative ones), and produces prioritized severity-tagged findings with an execution scorecard.",
+      "assertions": [
+        "Starts by inventorying the project's own claims/scope/roadmap before judging",
+        "Maps implementation maturity by component into tiers (production-ready / thin / stub / deferred), naming specific paths",
+        "Explicitly distinguishes what is built from what is validated from what is planned",
+        "Reads and reports the actual validation/evidence results, including negative or inconclusive ones, rather than assuming success",
+        "Surfaces scope drift and roadmap mismatches (ahead-of-docs or behind-a-claimed-milestone)",
+        "Produces prioritized, severity-tagged findings tied to cited evidence, not an exhaustive nit list",
+        "Defers vision/positioning/market questions to strategic-review rather than answering them here"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Our strategy doc says the project is still 'pre-development', but I think engineering has actually built most of phase 1 already. Can you review the real state? Also a lot of the docs claim features that I'm not sure are real.",
+      "expected_output": "Recognizes the docs may be stale or over-claiming and treats code as the source of truth: maps what's actually implemented vs what docs claim, flags both directions of mismatch (built-but-undocumented and claimed-but-absent), and labels each finding confirmed vs inferred with a cited source.",
+      "assertions": [
+        "Treats the actual code/artifacts as ground truth when docs and reality conflict",
+        "Flags claimed-but-absent features (documentation over-claiming) as findings",
+        "Flags built-but-understated work (code ahead of the stated status) as findings",
+        "Labels each conclusion as confirmed (with a cited source) or inferred",
+        "Greps for stub/not-implemented markers rather than trusting prose descriptions of capability"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "There's a 20-line function in our payments module with a bug. Can you review it and tell me how to fix it?",
+      "expected_output": "Recognizes this is a single small code change, not a project-level execution review — redirects to code-reviewing / bug-investigating rather than launching the full review workflow.",
+      "assertions": [
+        "Recognizes this is a narrow, single-unit task, not a whole-project execution review",
+        "Does not launch the full project-review workflow (claims inventory, maturity map, etc.)",
+        "Redirects to code-reviewing or bug-investigating as the right-altitude skill",
+        "Can still help with the specific function, scoped appropriately"
+      ]
+    }
+  ]
+}

package/skills/refactoring/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: refactoring
+description: "Systematic code improvement via design principles, smell detection, and safe transformation patterns. Triggers: refactor this, clean this up, simplify this code, reduce complexity, extract this, this code is messy, tech debt, improve this code, code smell, rename, extract function, dead code."
+model: sonnet
+allowed-tools: Read, Grep, Glob, Write, Edit, Bash
+---
+
+# Refactoring
+
+Guide safe, incremental code improvements that preserve behavior while enhancing design. Refactoring is disciplined — every change is small, tested, and reversible.
+
+## Core Rule
+
+**Never change behavior and structure in the same step.** Either you're adding a feature (behavior change) or you're refactoring (structure change). Mixing them creates bugs that are hard to trace.
+
+## Workflow
+
+### Step 1: Ensure Test Coverage
+
+Before refactoring anything, verify that tests exist for the behavior you're about to restructure. If tests are missing:
+
+1. Write characterization tests that document current behavior (even if the behavior has quirks)
+2. Run them and confirm they pass
+3. Only then begin refactoring
+
+If the user resists writing tests first, explain: refactoring without tests is not refactoring, it's rewriting with hope.
+
+### Step 2: Identify Smells
+
+Read the code and identify code smells. Prioritize by impact — don't try to fix everything at once. The most common smells, roughly ordered by severity:
+
+1. **Long function** (>30 lines) → Extract method
+2. **Duplicated logic** → Extract and share
+3. **Deep nesting** (>3 levels) → Early returns, extract method
+4. **Long parameter list** (>4 params) → Introduce parameter object
+5. **Feature envy** → Move method to the class it uses most
+6. **Primitive obsession** → Introduce domain types
+7. **Shotgun surgery** → Consolidate related logic
+8. **Divergent change** → Split class by responsibility
+
+See [references/transformations.md](references/transformations.md) for the complete catalog of safe transformations.
+
+### Step 3: Plan the Sequence
+
+Order refactoring steps so that each step:
+- Is small enough to verify easily
+- Keeps all tests green
+- Makes the next step easier
+
+A good sequence often looks like:
+1. Rename for clarity (cheapest, highest readability impact)
+2. Extract helpers to reduce function length
+3. Consolidate duplicates using the extracted helpers
+4. Move methods to better homes
+5. Simplify interfaces
+
+### Step 4: Execute — One Step at a Time
+
+For each transformation:
+
+1. **Explain** what you're about to do and why
+2. **Apply** the single transformation
+3. **Run tests** and confirm green
+4. **Show the diff** to the user
+
+If tests break, undo immediately. A failing test after refactoring means the transformation changed behavior — that's a bug, not a test to fix.
+
+### Step 5: Review the Result
+
+After completing the planned sequence:
+
+- Compare before/after: Is the intent clearer? Is the code simpler?
+- Run the full test suite
+- Check that no public API changed (unless that was the goal)
+- Look for any new smells introduced by the refactoring
+
+## Principles Applied
+
+- **DRY**: Eliminate duplication discovered during refactoring
+- **KISS**: Every transformation should make the code simpler, not more abstract
+- **SRP**: Each extracted function/class should have one reason to change
+- **YAGNI**: Don't introduce abstractions for hypothetical future needs during refactoring
+- **Functional Independence**: Refactoring should reduce coupling, not increase it
+- **Boy Scout Rule**: Leave the code cleaner than you found it — every refactoring session should improve the surrounding code slightly, not just the target. Small cleanups (renaming, removing dead code) near the area you're working in compound over time.
+- **Kent Beck's 4 Rules of Simple Design**: After refactoring, the code should: (1) pass all tests, (2) reveal intention clearly, (3) contain no duplication, (4) use the fewest classes and methods needed. Apply these as a checklist during Step 5 review.
+
+## Cross-Skill References
+
+- `technical-debt-review` — use to identify which areas are worth refactoring at a strategic level before starting
+- `dependency-impact-analysis` — use before refactoring a shared component or public interface to understand blast radius

package/skills/refactoring/evals/evals.json

@@ -0,0 +1,44 @@
+{
+  "skill_name": "refactoring",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Refactor this JavaScript function:\n\nfunction processData(data, type, format, verbose, dryRun) {\n  let result = [];\n  for (let i = 0; i < data.length; i++) {\n    if (type === 'user') {\n      if (data[i].age > 18) {\n        if (data[i].active) {\n          if (format === 'json') {\n            result.push(JSON.stringify(data[i]));\n          } else if (format === 'csv') {\n            result.push(`${data[i].name},${data[i].age},${data[i].email}`);\n          } else {\n            result.push(data[i].toString());\n          }\n        }\n      }\n    } else if (type === 'order') {\n      if (data[i].total > 0) {\n        if (data[i].status !== 'cancelled') {\n          if (format === 'json') {\n            result.push(JSON.stringify(data[i]));\n          } else if (format === 'csv') {\n            result.push(`${data[i].id},${data[i].total},${data[i].status}`);\n          } else {\n            result.push(data[i].toString());\n          }\n        }\n      }\n    }\n    if (verbose) console.log(`Processed item ${i}`);\n  }\n  if (!dryRun) {\n    saveToFile(result);\n  }\n  return result;\n}",
+      "expected_output": "Should identify multiple smells (deep nesting, long parameter list, duplicated formatting logic, SRP violation), check for tests first, then apply transformations one at a time.",
+      "assertions": [
+        "Asks about or checks for existing tests before refactoring",
+        "Identifies deep nesting as the primary smell",
+        "Identifies duplicated format logic between user and order branches",
+        "Identifies long parameter list (5 params)",
+        "Applies early returns to flatten nesting",
+        "Extracts formatting logic into a shared function",
+        "Introduces a parameter object or options pattern",
+        "Shows each transformation step separately",
+        "Runs or suggests running tests between steps"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I want to refactor this module but there are no tests. What should I do?",
+      "expected_output": "Should insist on writing characterization tests first, explain why, and help write them before any refactoring begins.",
+      "assertions": [
+        "Does not start refactoring without tests",
+        "Explains characterization tests and their purpose",
+        "Offers to help write the characterization tests",
+        "Tests document current behavior, including quirks"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Can you refactor my entire codebase to use better patterns?",
+      "expected_output": "Should push back on the scope — suggest identifying the highest-impact areas first, then refactoring incrementally. Should not attempt a sweeping rewrite.",
+      "assertions": [
+        "Does not attempt to refactor everything at once",
+        "Suggests identifying highest-impact areas first",
+        "Recommends incremental approach",
+        "Asks which areas cause the most pain or confusion",
+        "Applies KISS to the refactoring process itself"
+      ]
+    }
+  ]
+}