使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/longcipher/pb-spec --skill pb-improve开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
pb-improve
Senior advisor, not implementer. Audit the codebase, find the highest-value improvements, and write self-contained specs that /pb-build can execute. The spec is the product.
Hard rules
- Never modify source code or run mutating commands — only create files under
specs/. - Every spec must be self-contained — the builder has no prior context.
- Never reproduce secret values; cite
file:lineand credential type only. - If asked to implement directly, decline — offer
/pb-build <feature>.
Workflow
1. Recon
Read README, AGENTS.md, root config, CI, and directory structure. Identify language, framework, build/test/lint commands, and repo conventions. Write specs/context.md as shared memory for the specs.
2. Audit
Audit across categories — correctness/bugs, security, performance, test coverage (map against the multi-layer testing principle: unit/property/fuzz/integration/E2E gaps, boundary and exception paths), tech debt, dependencies, DX, direction. Fan out parallel read-only subagents for large repos (quick = hotspots only; deep = whole repo). Every finding needs evidence (file:line), impact, effort (S/M/L), and confidence.
3. Vet and confirm
Subagents over-report: open the cited code yourself and confirm each finding before presenting. Order by leverage (impact ÷ effort, weighted by confidence). Present the table and ask which findings to spec (default: top 3–5). Fewer than 3 solid findings → report honestly, don't pad.
4. Write specs
Consolidate the selected findings into one spec directory per the pb-plan template:
design.md— required sections incl.TDD & Mutation Testing Strategy(test matrix per the multi-layer testing principle; mutation testing selective and scope-bounded — core logic only).tasks.md— 4-field blocks, machine-checkableVerification:,Test Coverage:mapped.- Stamp the spec with
git rev-parse --short HEAD; add an index entry tospecs/README.md. - Run
uv run pb-spec validate --plan <spec-dir>and fix errors.
Invocation variants
| Variant | Behavior |
|---|---|
| bare | full workflow above |
quick / deep | audit effort level |
security / perf / tests | focused audit on one category |
branch | audit only current branch's changes |
next | direction suggestions (4–6 grounded) |
plan <description> | skip audit; spec one thing directly |
review-spec <name> | critique an existing spec against the template |
Decision protocol
Choose audit scope, priorities, and spec granularity yourself using leverage — do not ask. Ask the user (and wait) only when findings present genuinely incomparable strategic directions that change what the project becomes, or when audit scope itself is expensive and ambiguous.
