SinachPat
0dae13cfd3
- wursor-precheck: router skill, entry point for non-trivial tasks - wursor-principles: 21 engineering principles adapted for Wursor - wursor-tdd, wursor-bug-fix, wursor-feature, wursor-investigation, wursor-review, wursor-decision-log: playbook skills - AGENTS.md: repo guide wiring the skill routing table - Fix: double-quote YAML frontmatter descriptions (colon-space in plain scalars broke Zed's skill loader)
2.3 KiB
2.3 KiB
name, description
| name | description |
|---|---|
| wursor-feature | Build new or changed behavior in the Wursor repo, from a named data shape, TDD-first, with a defined verification path. Includes a refactoring mode for behavior-preserving structural change. Adapted from pstack's feature playbook. |
Wursor Feature
Build a new feature, or change behavior, with the rigor of a named data shape, a failing test first, and a defined verification path.
When to use
Use this skill when:
- The task is "add X", "build Y", "change Z"
- A user story describes new behavior
- A refactoring preserves behavior while changing structure
Do not use this for: one-line changes, copy edits, or bugs (use wursor-bug-fix).
Playbook
Step 1 — Name the data shape
Before any code, define what the feature operates on. The core types, in concrete form:
- What is the input? (request, event, message)
- What is the output? (response, deployed state, preview URL)
- What states does it pass through? (enumerate them)
- What can go wrong? (enumerate the errors)
Write these as types or interfaces where the language supports it. For api/ this usually means a TypeScript type or a Zod schema at the boundary. For plugin/ a class or array-shaped response.
Step 2 — Write the failing test
Following wursor-tdd:
- One test per behavior, one assertion per test
- The test must fail before implementation
- Mocks at boundaries: Grok API, plugin API, Docker, filesystem
Step 3 — Implement
Write the minimum code to pass the test(s). Follow the principles:
- Foundational thinking — the types from step 1 drive the implementation
- Make operations idempotent — the feature must be retry-safe
- Boundary discipline — parse and validate external input at the boundary
Step 4 — Verify
- The new tests pass
- The broader suite passes (
pnpm test:api,pnpm test:web, orphpunitas appropriate) - For UI features: the component renders in the browser/E2E test, not just "compiles"
Step 5 — Report
## What changed
- new module [x.ts] — does the specific thing, shaped by type T
## Data shape
- input: ..., output: ..., states: [...], errors: [...]
## Verification
- [feature.test.ts] — 4 tests, all pass
- full suite — green
## Follow-ups
- schema migration needed in [y.ts] when playbook runner lands