一键导入
code-test
Use only when autopilot-code dispatches implementation verification and evidence recording. Not for top-level user requests or primary capability routing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use only when autopilot-code dispatches implementation verification and evidence recording. Not for top-level user requests or primary capability routing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when source code must be implemented, debugged, refactored, or code-audited through a plan, execution, test, and report loop. Not for requirements-only changes, new empirical experiments, or document-only editing.
Use when persistent analysis of code, a paper, or a document must be created or refreshed because it is absent, stale, or explicitly requested. Not for read-only project orientation, context recovery, or status reporting.
Use when durable cross-project user preferences must be inferred from coding, writing, or analysis evidence and stored as a profile. Not for one-project context recovery, casual preference acknowledgment, or ordinary task execution.
Use when a visual product surface needs references, design tokens, components or mockups, review, and development handoff. Not for implementing an already-approved design in code or for document prose work.
Use when a new paper, presentation, report, proposal, or other user-facing document must be produced from evidence. Not for correcting only an existing document or for source-code implementation.
Use only when autopilot-draft dispatches document strategy and evidence-plan creation. Not for top-level user requests or primary capability routing.
基于 SOC 职业分类
| name | code-test |
| description | Use only when autopilot-code dispatches implementation verification and evidence recording. Not for top-level user requests or primary capability routing. |
| argument-hint | <plan name, path, or test scope> [--intensity direct|quick|standard|strong|thorough|adversarial] |
| metadata | {"group":"sub","fam":"sub","invocation_class":"parent-invoked","modes":[],"blurb":"Verify implementation results in stages and record evidence.","use_when":"Use only when autopilot-code dispatches implementation verification and evidence recording.","not_for":"Not for top-level user requests or primary capability routing."} |
Stage-session entry (
standard+dispatch, spec/stage-dispatch SD-2): Run in-session or as an isolated dispatch-depth-2 stage worker dispatched by theautopilot-codeconductor. Read the verification section inplan/plan.mdand marks inplan/checklist.mdfrom disk; never depend on prior-stage conversation. Source is read-only in this stage. The write class istest_logs/and_internal/test_reviews/. The stage runs as theqa/testunit (the node's unit); it dispatches no units itself.
Plan resolution: Treat arguments-and-decisions.md#plan-resolution as the single authority for resolving
$ARG. If no plan matches, interpret the argument as the file or directory test target instead of returning a plan-resolution error.
Language rule: Follow the audience and artifact language contract in arguments-and-decisions.md#language-rule. Preserve commands, paths, test names, identifiers, and raw output.
Run the qa/test unit. Select one prompt form:
Plan path:
Run graduated tests for plan: {$ARG}
Read the plan verification sections and plan/checklist.md in the task root to identify targets.
Execute Level 1 → 2 → 3 → 4 → 5 in order, stopping on the first failure.
File or directory path:
Run graduated tests on: {$ARG}
Execute Level 1 → 2 → 3 → 4 → 5 in order, stopping on the first failure.
Skip levels that do not apply, such as Level 4 when no plan exists.
Empty argument:
Run graduated tests on recently changed files.
Use git diff --name-only HEAD~1 to find targets.
Execute Level 1 → 2 → 3 → 4 → 5 in order, stopping on the first failure.
Skip levels that do not apply, such as Level 4 when no plan exists.
Always include this requirement in the qa/test unit test prompt:
Write a detailed test log to: {log_dir}/test_logs/test_report.md
The report structure is owned by the qa/test unit persona (roles/units/qa/test.md): exact command, full stdout/stderr (or the last 50 lines when long), and a per-test PASS/FAIL verdict with the error reason. Do not restate a competing format in the prompt.
Run test commands through the active adapter's bounded verification runner when its contract requires one. Preserve the actual exit status in the log.
When changed outputs include a report spectrogram, add the report-figure
semantic level from roles/units/qa/test.md: run
tools/figure-semantic-verify.py or the adapter-native figure-gen --verify-report wrapper against the manifest and report. Exit 2 is a test
failure; unavailable or unreadable required inputs are blockers. Record the
manifest path, PNG hash, claim-evidence verdict, and visual-review evidence.
PNG existence, dimensions, count, and links alone are not a pass.
This is the concrete final verify stage. Derive rigor from plan frontmatter or caller intensity; do not hardcode Thorough or automatically open a parallel QA loop.
| Rigor | Concrete verification | Optional adequacy review |
|---|---|---|
quick | Run the narrowest applicable command or check and record skip reasons | None by default |
light | Run focused syntax, import, smoke, or caller-specified checks | One fast review only when risk selects it |
standard | Run applicable graduated levels and capture command evidence | One focused adequacy review for a nontrivial change surface |
thorough | Broaden target coverage and add behavioral runtime observation for changed user-facing surfaces | Parallel or dispatch-depth-2 review only when selected by intensity=thorough |
adversarial | Thorough verification plus applicable security, failure-mode, and external-adversary evidence | Prove every claimed adversary or security pass ran |
After the qa/test unit returns, read test_logs/test_report.md. Run a separate adequacy review only when the selected assurance budget requires it, and append its findings to the report. Otherwise return the concrete verification verdict directly.
Do not modify source or invoke a hotfix worker from this stage. Any repair belongs to the caller's bounded retry/fix path.
Return the report path, executed commands, skipped levels and reasons, blockers, and the first actionable failure when present.
plan/; for example, <artifact-root>/plans/2026-03-18_refactor/plan/plan.md → <artifact-root>/plans/2026-03-18_refactor/.<artifact-root>/tests/.Test: $ARG