Como usar
- Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
- Consulte no original as ferramentas, credenciais e ambientes necessários.
- Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.
npx skills add https://github.com/longcipher/pb-spec --skill pb-refineAntes de começar
- A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
- Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.
Documento original do Skill
Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.
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.
