pbs-implement

Extract checklists from planned work, implement them, and verify each check with an independent agent.

Updated Sep 15, 2026
One-click install
npx skills add https://github.com/Peterson-Benhame/agent-skills --skill pbs-implement-peterson-benhame
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pbs-implement
Source: https://github.com/Peterson-Benhame/agent-skills/tree/main/packages/skills-catalog/skills/%28development%29/pbs-implement
Command: npx skills add https://github.com/Peterson-Benhame/agent-skills --skill pbs-implement-peterson-benhame

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Planned work loses fidelity during implementation: vague requirements become vague tests, authors verify their own code, and long builds lose context. This Skill enforces a disciplined pipeline that extracts a provable checklist from an existing plan, builds against it, and proves every check with an independent verifier agent. ## Core Features & Use Cases - Checklist Extraction: Reads tickets, PRDs, RFCs, or threads and produces a .checks/<feature>.md artifact where every claim names a concrete proof, refuses vague requirements, and sweeps nine unwritten requirement classes like idempotency and authorization. - Profile-Based Verification: Supports light, standard, and ui profiles that add coverage joins, test-policy rows, fault injection, and design-binding screen checks depending on project configuration. - Independent Verification: Dispatches a fresh sub-agent Verifier that re-runs proofs, checks assertions against checklist values, injects behavior-level faults, and writes a verdict report. - Context Handoff: Packs whole slices into token-budgeted batches and hands off between agents using the checklist and diff rather than conversation summaries. - Use Case: A user says "implement this spec" for a billing feature; the Skill extracts checks with named proofs, builds them with Conventional Commits, and produces a verification report accounting for every check. ## Quick Start Ask the agent to implement an already-approved ticket or spec by saying "implement this spec using pbs-implement" and it will extract the checklist, build it, and verify every check.

Frequently Asked Questions about pbs-implement

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a ticket or spec with an AI coding agent?▼

Provide the approved ticket, PRD, or spec and invoke pbs-implement. It reads the source completely, extracts a checklist where every claim names a concrete proof such as a specific test, builds the implementation, and dispatches an independent verifier agent to confirm each check.

What is the difference between light, standard, and ui profiles?▼

Light (the default) runs proofs and locates one assertion per check. Standard adds the Coverage join, test-policy verdicts, and fault injection. Ui adds binding design-source comparison and per-screen enumeration of copy and arrangement. Projects declare the profile in AGENTS.md.

When should I not use pbs-implement?▼

Do not use it when nobody has decided what to build or when you need design work. The Skill requires an existing decision artifact like a ticket or spec to extract checks from; open-ended requests like "should we add billing" belong in a planning flow instead.

Why does the verifier need to be a separate agent?▼

An author re-checking their own work reapplies the same thinking that produced any gap, so verification by the author is a self-report. A fresh sub-agent with no inherited context is dispatched by the orchestrator after the last batch lands, covering the full feature diff range.

How does pbs-implement handle long builds that exceed context limits?▼

It packs whole slices into batches up to a token budget (150k by default) and hands off to a fresh agent carrying the checklist plus the diff of landed work, never a conversation summary. Handoff boundaries and their arithmetic are written into the checklist before any code exists.

What happens when a test fails or a check turns out to be wrong?▼

A red proof is a stop, not a note. The Skill forbids weakening assertions, deleting tests, or quietly adjusting checks; instead it requires stopping and renegotiating the check with the user, since the checklist is the fixed bar the build runs under.