How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/longcipher/pb-spec --skill pb-refineBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
pb-refine
Apply feedback to an existing spec. This closes the gap between one-shot planning and iterative refinement.
Workflow
1. Locate and load the spec
- List
specs/, find the directory ending with-<feature-name>; on multiple matches take the latest date prefix; on no match, report and stop (/pb-planfirst). - Load
design.md,tasks.md,AGENTS.md(read-only).
2. Apply feedback to design.md
- If behavior changes, update the
TDD & Mutation Testing Strategysection first (type contracts, invariants, test matrix, mutation scope). - Precise edits only — never rewrite whole files, preserve unaffected sections verbatim.
- Update
Status→Revised, add a## Revision Historytable entry (| Date | Change | Reason |).
3. Cascade to tasks.md
- Reset invalidated tasks:
🔄 DCR→🔴 TODO, checkboxes back to- [ ]. - Add new tasks with the next free Task ID; obsolete tasks →
⛔ OBSOLETE. - Update
Context,Verification,Test Coveragewhere affected. - Never modify completed tasks (
🟢 DONE) unless explicitly requested; if a change invalidates them, flag as a warning instead.
4. Validate and report
- Check alignment: every design change has tasks, dependencies stay ordered, no orphaned tasks.
- Run
uv run pb-spec validate --plan <spec-dir>and fix errors. - Summarize: what changed in design.md / tasks.md, warnings, and next step (
/pb-build <feature>).
Decision protocol
Apply given feedback as stated — no multi-turn probing. If the feedback admits two or more genuinely incomparable interpretations that change what gets built, ask the user and wait; otherwise adopt the most reasonable interpretation, record it in Revision History, and proceed.
Edge cases
- No feedback provided → report "No feedback detected."
- Feedback requires an entirely new design → recommend
/pb-planinstead. - Multiple conflicting feedback items → apply in order given, note conflicts in Revision History.
Constraints
- Only modify
specs/<spec-dir>/design.mdandtasks.md. Never source code.AGENTS.mdis read-only. - Incremental update only — never re-run the full planning process.
