Verify Behavior Placement Research

Decision

verify-behavior is a reusable planning capability. It belongs at skills/agnostic/planning/verify-behavior/ in the shared wearedevpunks/skills source and in the default planning pack.

The lifecycle graph does not change:

• implement-spec invokes verify for visibly exercisable behavior after task and runtime checks and before goal-level acceptance classification;
• debugging-phase invokes reproduce for a reported visible failure before forming hypotheses or changing code;
• review-phase audits retained behavioral evidence against the frozen target and acceptance criteria. It does not become the primary verifier or gain a review lens;
• delivery-phase remains the router and consumes the same implementation, debugging, and review outcomes.

The accepted source-first implementation is retained on wearedevpunks/skills branch team/stefan/verify-behavior at commit 091973b09f5eade8f4d18eb1528b265db32de55b.

Provenance

The capability adapts the upstream skill from immutable commit ab21d0c5b70e38abe1a53ff6e2934d2637415c5b. Its MIT license permits adaptation with the notice preserved: LICENSE. The linked article presents computer/browser use in triage, implementation, and review as evidence for existing workflow parents, not a new lifecycle phase: The computer use verification skill that every agent needs.

Upstream defines two modes. reproduce determines whether a reported failure occurs on the baseline. verify determines whether a feature or fix matches its expected visible behavior. It covers browser, desktop, mobile, and other interactive surfaces; backend-only, CI-only, and text-only changes are outside its scope. The adaptation retains that semantic contract while using whichever supported browser or computer-use capability owns the current surface.

Placement rationale

implement-spec already owns behavioral completion. Plan tasks carry acceptance criteria, review mode, RED/GREEN evidence, and optional runtime-validation requirements. Implementation already runs automated and runtime checks, audits acceptance, and produces a manual review checklist. Behavioral verification therefore belongs immediately before acceptance classification, close to the repair loop and early enough for review to consume its proof.

debugging-phase already owns reported runtime symptoms, reproduction scenarios, evidence matrices, bounded fixes, and before/after comparison. Calling reproduce before hypothesis formation strengthens that boundary without creating a separate triage phase.

review-phase has a readonly frozen-target contract and five normative lenses. It may assess whether retained evidence maps to the reviewed head and acceptance criteria. Missing, stale, or contradicted proof is a finding routed through delivery; review does not manufacture implementation evidence.

Behavior Verification Evidence

Every applicable run writes one durable table under ## Behavior Verification Evidence in IMPLEMENTATION-NOTES.md:

The table cross-references matching Runtime Validation Evidence; it does not duplicate it. verify uses verified, partially verified, not verified, or blocked; reproduce uses confirmed, partially confirmed, not reproduced, or blocked. A visible claim is valid only when cited interactive evidence supports it. An unavailable channel produces an exact blocker, never a passing status. Retain screenshots, browser traces, recordings, run links, logs, or concrete observations only when the active capability actually returns them.

Verification uses acceptance criteria from the accepted spec and plan. The grill-to-spec-to-backlog-to-plan chain therefore supplies the story and expected behavior; the skill supplies channel selection, scenario execution, evidence quality, and honest status classification.

Operational boundaries

• Use the supported interaction adapter for the product surface; the skill does not duplicate browser-control instructions.
• Keep secrets and interactive approvals under operator control.
• Parallelize only independent stories with isolated runtimes. Serialize shared credentials, mutable state, and dependent scenarios.
• A verify mismatch becomes runtime evidence and routes through delivery into debugging-phase. A confirmed reproduce result feeds debugging hypotheses and the bounded fix loop.
• A required applicable scenario with inconclusive evidence blocks its affected acceptance criterion until resolved or explicitly re-scoped.

Source-first integration

The shared skill repo is authoritative. Harness .agents/skills/* and apps/cli/skills/* are projections and must be refreshed through the supported bun run sync:skills path after the source ref is accepted and pushed. The planning catalog and default planning pack select verify-behavior; parent skills link to it as a disclosed reference, keeping the behavioral contract in one place.

The implementation should be validated through source skill tests, catalog and pack checks, link/reference checks, and focused Harness sync/scaffold checks. Managed Harness projections must not be hand-edited to bypass scaffold authority.