task

---
name: task
description: Make a small change to a shipped product — a bug fix, behavior tweak, micro-feature, refactor, or perf fix — as one verified slice, syncing the affected feature spec on the way out. Use for day-to-day requests like "fix X", "change Y to do Z", or a single small feature that doesn't warrant a full phase of the workflow.
---

# Task

One small change, done end-to-end: classify, fix, verify, sync the docs. No interview, no phase ceremony. The point is that `.rubstack/` stays truthful as a side effect of doing the work.

## Step 1: Classify and scope

Restate the request in one sentence. Then classify:

- **Bug** — the product violates its own spec. The spec is right; the code is wrong.
- **Behavior change** — the spec said one thing, the user now wants another.
- **Micro-feature** — new behavior, small enough that a spec interview would be ceremony.
- **Refactor** — structure changes, behavior stays identical.
- **Perf** — a measured slowness to improve against a baseline.

Find what's affected: read the relevant feature section in `.rubstack/engineering/features.md`, plus `AGENTS.md` and `.rubstack/product/CONTEXT.md` if they exist.

**Escalate instead of proceeding** if any of these turn out true — recommend the right skill and stop:
- It's a meaningful new feature or behavior change that warrants a product conversation → `/evolve`
- It needs an architectural decision not covered by `architecture.md` or ADRs → `/evolve` then `/dev-plan`
- It spans several features or layers in non-trivial ways → `/implement` with proper specs
- It has security, auth, data-migration, or external-contract implications → surface the question to the user first

**Open the playbook.** Bug, Refactor and Perf each have a playbook that replaces Steps 2 and 3: [bug-fix](playbooks/bug-fix.md), [refactor](playbooks/refactor.md), [perf](playbooks/perf.md). Copy its steps verbatim into your task list before any task-specific items, and follow them in order. A step you skip stays in the list as `skip: <reason>`. Behavior change and Micro-feature use Steps 2 and 3 below. Every class continues with Step 4.

## Step 2: Fix as one vertical slice

Implement only this change, entry point through to storage:
- Match existing conventions and style, and use the domain vocabulary from `CONTEXT.md`
- No refactors, no shared infrastructure, no adjacent improvements; mention unrelated dead code instead of deleting it, and remove only what your own change left unused
- Smallest change that solves it: no speculative options, abstractions or error handling for impossible cases ([subtract-before-you-add](../_shared/principles/subtract-before-you-add.md))
- If the request is ambiguous, name the interpretations and ask rather than picking one silently
- If the change contradicts an acceptance criterion, that's expected for a behavior change — Step 4 fixes the spec, not the other way around

## Step 3: Verify

Batch size is one, so verify directly (the /implement-vs-/qa split doesn't apply here):
- Run static checks (typecheck, build, lint)
- Run the narrowest test that covers the change; for a bug, write the failing test first if the suite makes that cheap
- Exercise the change where it runs if a runtime is available: Playwright MCP for web, Argent MCP for an iOS simulator or Android emulator, the shell for a CLI. Passing static checks is not a reason to skip this ([prove-it-works](../_shared/principles/prove-it-works.md))

Not verified → not done. Don't hand unverified changes back.

## Step 4: Sync the docs

- **Bug**: spec was already right — no spec change. Note the fix only if the spec's implementation note is now misleading.
- **Refactor** or **Perf**: no acceptance criterion changes. Update an implementation note only if it now names moved or deleted code; for Perf, record the new number only if the spec states a performance target.
- **Behavior change**: patch the acceptance criterion in the affected spec to describe the new behavior (keep the Given/When/Then phrasing), with a dated one-line note ("Changed 2026-06-10: due date now resets on duplication").
- **Micro-feature**: add a minimal spec section to `.rubstack/engineering/features.md` — status `done`, the acceptance criteria you just verified phrased Given/When/Then, one-line implementation note. This keeps future `/qa` runs covering it.
- Touch `.rubstack/product/roadmap.md` only if the change alters something the roadmap states.
- If a README or other public doc describes the old behavior, update it ([../_shared/writing.md](../_shared/writing.md)).
- Commit the spec sync with (or right after) the code change — worktrees and future sessions only see committed `.rubstack/` content.

## Step 5: Report and recommend

Commit on a branch and open a PR per [../_shared/git-workflow.md](../_shared/git-workflow.md). Report: what changed (files), how it was verified, which docs were synced.

- User-visible change on a released product → "Run /ship for a patch release."
- Internal-only → done, nothing else needed.
- Found related problems along the way → list them; don't fix them in this task.

• SKILL.md 5 KB
• playbooks/bug-fix.md 3 KB
• playbooks/perf.md 1 KB
• playbooks/refactor.md 1 KB