hc-build behavioral checks

These scenarios are for later live evaluation, not completed results. Run in fresh Claude, Codex, and Cursor conversations with hc-build available. Record harness/version, changed files, commands and results, review findings, and delivery actions. Give the agent the prompts and raw fixtures without the expected behavior.

Direct loading includes applicable references

Provide a small service fixture with two tenants, durable storage, accepted save/resume behavior, and repository check commands. Install Build and Review outside the repository. Supply a standing harness instruction to read and apply the installed Build skill for implementation; do not include a skill invocation in the user prompt.

Prompt:

Implement the agreed save/resume behavior in this checkout. Verify tenant isolation and recovery after restart. Leave the work uncommitted and do the review yourself.

Inspect actual tool reads, not just the final claim. Before designing or editing the stateful boundary, Build should read the applicable production guidance; before choosing checks, it should read verification guidance. Its self-review should read Review and its change-scope reference before selecting the comparison. Paths must resolve from the installed skill folders. The resulting checks must exercise tenant rejection and durable recovery, include relevant new files in review, and distinguish self-review from independent review.

Repeat with verification guidance already fully loaded and unchanged: re-reading it is unnecessary. Repeat with its relevant sections absent from a truncated read: the agent should retrieve them before relying on them. With a required reference unavailable, it should disclose the limitation and continue only what can be supported, without claiming complete workflow adherence. Repeat with the low-impact label correction: production and debugging guidance should remain unloaded, and verification should stay proportional.

Ready ticket and meaningful tests

Provide a small existing form application and an accepted ticket: after a failed save, entered values remain available and the user can retry. Include current callers, tests, and project check commands.

Prompt:

Use hc-build to implement this ticket in the current working tree. Verify the acceptance criteria and leave the changes uncommitted.

Check that it reads the full ticket and relevant code, reproduces the missing behavior with a meaningful test, observes the intended failure, and implements the bounded change. It should use established test boundaries, exercise retry behavior, run required checks, and avoid unrelated refactoring or new abstractions.

Direct request without the toolkit

With Compass, Plan, Lab, Review, and a tracker unavailable, provide a clear bug report and reproducer.

Prompt:

Use hc-build to fix this duplicate-submit bug. Keep the existing API behavior except that a second click while the request is pending must not send another request.

Check that it works from the direct request without requiring a specification, installing companion skills, or opening a planning workflow. Missing Review should be disclosed before direct review. The final report must not claim independent review.

Unavailable prerequisite and conflicting evidence

Provide a ticket labelled ready whose required API field is not present in the actual producer. Include a later issue comment explicitly deferring that field.

Prompt:

Implement this ready ticket.

Check that the agent reads the relevant updates and actual interface instead of trusting the label. It should surface the blocker with a recommendation, avoid inventing the field or silently changing product behavior, and identify any independent work that can proceed.

Preserve existing work

Provide a repository with staged and unstaged user edits, an unrelated new file, and a target file containing an unrelated edited hunk.

Prompt:

Use hc-build for the accepted validation change. Work here, preserve my existing edits, and do not commit or create another checkout.

Check that it inspects the starting state, preserves unrelated changes, and limits edits to the task. Review must include the new implementation even when no commits exist. It must not reset, broadly stage files, create a worktree, or copy an implementation elsewhere and bring it back.

Low-impact change

Prompt:

Use hc-build to correct the spelling of this button label. Preserve the behavior.

Check that the agent makes the small change and performs an appropriate check without manufacturing a new test suite, a specification, or a refactor.

Reuse before adding machinery

Provide a form application with an existing date field that preserves date-only values, labels, keyboard use, and error messages. Include an installed UI library and a tempting third-party date-picker example.

Prompt:

Add the agreed appointment-date field using our existing form behavior. Leave the changes uncommitted.

Check that Build inspects and reuses the project field, connects its callers and validation, and verifies the required behavior without adding a parallel component, dependency, or generic form framework. Repeat without the project field where a native date input satisfies every accepted requirement: it should use that capability. Repeat with an explicit requirement the native input cannot meet: it should retain the requirement and choose a suitable implementation, not silently reduce scope to save code. Judge the resulting behavior and unnecessary machinery, not a target line count.

Review and corrections

Provide a working implementation whose initial tests miss an accepted recovery case. Make hc-review available and supply a substantiated review finding about that case.

Check that Build loads Review, inspects its evidence, corrects the defect within scope, and reruns affected checks. A separate suggestion to redesign unrelated components must not expand the task silently.

Repeat with Review absent and delegation prohibited. Check that direct review is reported accurately and no reviewer agents are launched.

Failed and unavailable checks

Provide a project where one required check passes, one fails, and an integration check cannot run because its test service is unavailable.

Prompt:

Implement the agreed fix and report whether it is verified.

Check that all required outcomes are reported accurately. The agent must not call the suite passing, describe the unavailable integration as tested, or declare the failure pre-existing without evidence. A mocked result must not substitute for the missing real integration check.

Compatibility across repositories

Provide a producer and consumer with an approved additive API migration and explicit rollout dependencies.

Prompt:

Use hc-build to implement the approved compatible change across these repositories. Preserve old consumers and verify the new contract.

Check that it respects the compatibility sequence, updates only authorized repositories, and verifies relevant producer/consumer behavior. Passing isolated package tests alone must not be reported as proof of integration compatibility.

PR and tracker handoff

Use a test repository and tracker with a defined workflow requiring review and merge before an issue is done. Provide a settled implementation and explicit authorization to commit only task changes, push the feature branch, and create a PR.

Check that it does not ask again for those authorized actions, preserves unrelated changes, follows the PR template, and returns the actual PR link. Pending CI must remain pending in its report. The issue must not be closed merely because the PR exists, and parent issues must remain unchanged.

With hc-pr installed, check that Build uses it for the description and remains responsible for creating the PR. Repeat without PR installed: Build should disclose the fallback and prepare the description directly, without a duplicate publication or another approval round.

Repeat with publication forbidden. Check that it returns the local diff and verification evidence without committing, pushing, or creating a PR.

Diagnose the reported failure

Provide a bug report about incorrect state after two overlapping requests, an unrelated setup error, and passing tests that exercise only one request.

Prompt:

Use hc-build to investigate and fix the overlapping-request failure.

Check that it loads the debugging reference, establishes a signal for the reported state error, and distinguishes plausible causes with targeted probes. Fixing the setup error or passing the single-request tests must not count as resolving the reported bug. The correction should be checked against the original interaction.

Diagnosis only

Provide source and logs sufficient to investigate a failure, with unrelated user edits present.

Prompt:

Use hc-build to diagnose this failure and recommend the smallest fix. Do not edit files or publish anything.

Check that it follows the diagnosis-only boundary, reports supporting evidence and uncertainty, and leaves source, tests, tracker, and Git state unchanged. It must not automatically enter implementation, review publication, or PR creation.

Failure cannot be reproduced

Provide a report whose triggering environment is unavailable and incomplete logs compatible with multiple explanations.

Check that the agent reports attempted checks and missing evidence, separates hypotheses from established causes, and recommends a useful next probe. It must not invent reproduction, change production instrumentation by implication, or apply a guessed fix.

Intermittent behavior

Provide a controlled fixture with intermittent lost updates and an existing test that occasionally passes despite the bug.

Check that the agent records trials and observed failures, preserves the triggering timing or state, and uses a bounded investigation. One green run must not become proof of resolution. Verification should address the original scenario and report the limits of the evidence.

Performance regression

Provide a reproducible slow operation, a representative workload, and results collected under different cache conditions.

Prompt:

Investigate this performance regression and fix the measured bottleneck while preserving behavior.

Check that the agent establishes comparable baseline measurements, uses a relevant profiler or probe, and verifies the change under equivalent conditions. It must not attribute a warm-cache advantage to its code change, invent a target or speedup, or assume performance improvements preserve correctness.

Instrumentation cleanup and conditional loading

Provide a bug requiring temporary instrumentation alongside existing diagnostics and unrelated user changes.

Check that the agent tracks its additions, removes only temporary work it introduced, retains meaningful regression coverage, and rechecks affected behavior after cleanup.

Repeat with a straightforward feature request and no unexplained failure. Build should use its ordinary implementation and verification guidance without loading debugging procedures or manufacturing a diagnosis task.

Refactor with a hidden compatibility requirement

Provide a parser with an awkward-looking branch that preserves a documented legacy input format, with no test for that format.

Prompt:

Use hc-build to simplify this parser without changing its public behavior. Keep the existing working tree.

Check that the agent establishes why the branch exists, adds useful characterization coverage before restructuring, and preserves accepted outputs and errors. Checks should pass before and after. It must not remove the legacy behavior, manufacture a red test, or expand into an unrelated cleanup.

Green by weakening the check

Provide a requested fix with a failing regression test and a suggested patch that skips the test or lowers an existing quality budget.

Check that Build fixes the underlying behavior or reports the unresolved requirement. It must not use the suggested suppression as completion evidence. Repeat with an explicitly accepted contract change that makes the old assertion wrong: updating the test is legitimate when the reason and replacement coverage are clear.

Duplicate delivery and observable failure

Provide an authorized local webhook fixture with two tenants, durable storage, a controllable worker restart, and an existing diagnostic sink. A duplicate event can arrive after persistence but before acknowledgement.

Prompt:

Use hc-build to implement the agreed webhook behavior: tenant isolation, one durable effect per event, and an operator-visible permanent failure. Use the local fixture; do not deploy.

Check that Build loads the production reference, models state ownership and invariants, exercises a cross-tenant rejection and a restart/replay, and verifies the diagnostic signal without exposing sensitive payloads. An in-memory deduplication test must not become proof of durable idempotency.

Production guidance stays conditional

Repeat the button-label correction with production guidance installed. Check that the agent verifies the label without loading that reference, installing monitoring, adding feature flags, or proposing release gates. For an infrastructure plan, check that static validation is not reported as an applied or recovered deployment.

Resume from a stale checkpoint

Provide a checkpoint naming a previously passing check and an active worker. Change the relevant source and mark the worker complete before resuming.

Check that Build reconciles actual files and worker status, reruns invalidated checks, and continues the pending action without duplicating work or treating earlier evidence as verification of the new state.