<!-- Generated from skills/registry.yaml and skills/b-implement/prompt.md. Edit those sources, not this file. -->

b-implement

Make the scoped non-UI change in the smallest coherent step after an approved plan or clear direct request.

When to use

• The user approved a plan or gave a small direct request.
• The next action is a scoped non-UI code or repository change.

When NOT to use

• Scope or behavior is unclear -> use b-plan.
• Frontend/UI code -> use b-frontend.
• A named behavior-preserving transform -> use b-refactor.
• Test-only work -> use b-test.
• An unknown runtime failure -> use b-debug.

Tool guidance

• Use native file tools by default and native tools or local search for routine discovery. Follow the kernel CodeGraph rule: before editing indexed code, get the target's callers, blast radius, and affected tests; use native tools for prose, config, and known-path local edits. Use only context supplied in the current task rather than guessing.

Steps

1. Resolve the approved plan or direct request, run rtk git status --short, and preserve unrelated changes.
2. Before edits, consult applicable project standards, architecture boundaries, and relevant failure modes. State affected paths, invariants, observable success criteria, and relevant quality constraints. Use repository evidence, including CodeGraph impact for indexed code symbols you will change. If a material behavior or target is missing, use AskUserQuestion for the unresolved choice. Group related questions (up to four), but address independent blockers in priority order. Wait for the answer and re-evaluate. Route material external framework/API facts to targeted b-research rather than asking the user to supply documentation.
3. Ask the user directly only for material unresolved choices or blockers; do not delegate user decisions to a child.
4. Before adding code or a dependency, check for an existing repository helper, the standard library, a native platform feature, or an already-installed dependency that fits. Make the smallest coherent edit with native tools, matching the target module's local style. Remove imports/helpers made unused by it, but retain unrelated pre-existing dead code.
5. Run the narrowest useful verification. If an unambiguous in-scope defect causes failure, correct it and rerun until required verification passes. If failure reveals ambiguity, scope drift, or an unrelated issue, stop and ask or route rather than guessing. Inspect explicit non-protected changed paths.
6. Inspect every tracked and relevant untracked/derived path and diff. Apply the kernel's risk-triggered review rule to the final candidate against the task baseline after required checks pass. Direct tests/docs and faithfully regenerated outputs count with their source, not as separate subsystems; when the candidate includes regenerated outputs, run the repository's generator check to verify them. For a bounded, verified low-risk change with no trigger, finish and state why independent review was skipped under the low-risk exception. No-change tasks, including PR prose, need no changed-code review.
7. When review is required, freeze and fingerprint the exact candidate as specified by b-review (use node ~/.claude/b-agentic/bin/b-candidate-snapshot.mjs and compare only its fingerprint; the CLI omits git-ignored files unless named, so pass every relevant ignored/derived artifact with --include-ignored <path> at each checkpoint or block the fingerprint handoff and report the uncovered paths; if it is unavailable, block; if it reports complete: false, block rather than fall back to manual hashing); run the independent b-review gate with baseline, acceptance, checks, paths, and identity. Compare the identity after it returns and before normal completion. Do not edit while review is pending. A changed reviewed snapshot or missing baseline requires fresh checks and new review; NEEDS FIXES requires correcting its blockers, fresh checks, and a delta re-review whose handoff carries prior finding IDs, dispositions, correction paths, and sweep/check results. Correct blockers as a batch: for each, name the violated invariant, sweep every sibling location of that defect class (rg/CodeGraph; canonical source, generated outputs, validators, fixtures, docs, size budgets), and fix the whole class in one minimal diff limited to the finding's paths, with other ideas recorded as follow-ups. Before re-review, run each finding's regression check and the repository checks. Record each follow-up as fixed, deferred, or rejected with a reason and report it; deferred or rejected follow-ups need no new review. After 3 consecutive NEEDS FIXES rounds, stop and ask the user. Missing or failed required checks, unexpected paths, and hand-edited generated outputs block completion even without review; ask the user about ambiguous acceptance, and name the closest trigger before escalating uncertain risk to review. No review automatically commits or pushes.

Output format

Changes, verification, acceptance coverage, and deviations or gaps. Report the low-risk review exception when used; a triggered candidate requires the b-review gate before a normal final response.

Rules

• Stay within approved scope and use the smallest evidence-backed fit.
• Shared approval policy remains authoritative.
• Apply the kernel's risk triggers to changed candidates; no-change outputs must not initiate changed-code review.
• When b-review returns NEEDS FIXES, correct only unambiguous in-scope blockers, rerun checks, then request a fresh delta re-review; stop for ambiguity or scope drift, and at 3 consecutive rounds.
• Never claim shipping readiness when required verification or a triggered independent review is absent.