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.