claude-sdk-rs: Command for Claude Code

Application Validation Test Suite

Execute the project's validation suite, returning results in a standardized JSON format for automated processing. The suite is not hardcoded — it is read from planning/harness.json (the mechanism/policy split), so this command works for any stack.

Variables

$ARGUMENTS — optional path to the task spec and optional task number. Same format as /implement.

Examples:

• (no args) — run full suite; output JSON to chat only; no worklog/state written
• planning/<spec-slug>/tasks.md — run full suite; append a worklog section + update state for the whole spec
• planning/<spec-slug>/tasks.md 1 — run full suite; append a worklog section + update state scoped to task 1

The task number N does NOT change which checks run — all checks always run regardless. N only scopes which sdlc/state.json task entry and worklog section this run's results are recorded against.

Purpose

Proactively identify and fix issues before they impact the project or downstream work. By running this suite you can:

• Detect lint / format / type errors before they reach the build
• Catch broken tests or regressions
• Verify the project builds/compiles cleanly
• Enforce the universal harness rule: no emoji in changed markdown

Constants

TEST_COMMAND_TIMEOUT: 5 minutes

Instructions

• Step 0 — Parse $ARGUMENTS: If provided, split on the last space. Trailing number = task N; remainder = spec path. Derive the spec dir from the spec's parent directory:
  • No args: no worklog/state will be written.
  • Spec only: planning/<spec-slug>/tasks.md → planning/<spec-slug>/sdlc/ (record scoped to "all tasks")
  • Spec + task N: planning/<spec-slug>/tasks.md 1 → planning/<spec-slug>/sdlc/ (record scoped to task 1)
• Run /prime to orient to the codebase before executing any checks.
• Step 1 — Load the validation suite: Read planning/harness.json.
  • If present and valid JSON: the checks are validation.checks[], run in order, top to bottom. Each entry has name, command, purpose, and gates (whether its failure blocks the review verdict). The check whose purpose names it authoritative for the verdict is the one that always prevents PASS when it fails.
  • If absent or invalid: fall back to the spec's optional ## Validation Commands section — run each command there, in order. If there is no spec or no such section, run no project checks and record a single informational row (test_name "no_validation_suite", passed true).
  • The engine ships no stack defaults — never invent lint/test/build commands; they come only from harness.json or the spec.
• Run each check with the Bash tool. Capture the result (passed/failed) and any error messages.
• IMPORTANT: Return ONLY the JSON array with check results
  • IMPORTANT: Do not include any additional text, explanations, or markdown formatting
  • We'll immediately run JSON.parse() on the output, so make sure it's valid JSON
• If a check passes, omit the error field
• If a check fails, include the error message in the error field
• Execute all checks even if some fail
• Error Handling:
  • If a command returns a non-zero exit code, mark as failed
  • Capture stderr output for the error field
  • Timeout commands after TEST_COMMAND_TIMEOUT
• Execution order is the order in validation.checks[] (or the spec) — earlier gates (format/lint/type) before later ones (test/build)
• All commands are run from the repo root unless the command itself changes directory
• Always run pwd before each check to confirm you are in the repo root