task

Files (1)

• SKILL.md

SKILL.md (first lines)

# Task

One small change, done end-to-end: classify, fix, verify, sync the docs. No interview, no phase ceremony. The point is that `.harness/` 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.

Find what's affected: read the relevant feature section in `.harness/engineering/features.md`, plus `AGENTS.md` and `.harness/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

## Step 2: Fix as one vertical slice

Implement only this change, entry point through to storage:
- Match existing conventions and use the domain vocabulary from `CONTEXT.md`
- No refactors, no shared infrastructure, no adjacent improvements
- 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 (browser, simulator, CLI)

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.
- **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 `.harness/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 `.harness/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.
- Commit the spec sync with (or right after) the code change — worktrees and future sessions only see committed `.harness/` content.

## Step 5: Report and recommend

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.

From RubenGlez/harness, MIT.

More from RubenGlez/harness