Translate "help me test this requirement" into aresumable pipeline. This skill is thin orchestration:it contains no testing methods or framework knowledge(all of that is in the phase skills and core/), and it does not make decisions on the user's behalf.
When to Use
- "Help me test this requirement / feature", "run through this feature completely", "run a complete test from requirement to report"
- the previous pipeline was interrupted and needs to resume from persisted artifacts
When NOT to Use
- only need a single-phase output → the corresponding phase skill: requirement modeling
requirement-analysis, test strategytest-strategy, write test casestest-case-writing, review existing test casestest-case-review, E2E executionautomated-e2e-testing, API executionapi-testing, exploratory sessionexploratory-testing, bug root causebug-analysis, regression scoperegression-testing - writing/modifying the methodology of a phase skill itself → does not go through this skill
Orchestration session model (context isolation between phases)
- Each phase runs in an independent context(when the host supports subsessions/subagents): load only the current phase skill's SKILL.md + references on demand + the previous phase's persisted artifact files; at any moment active instructions ≤ 1–2 skills (current phase + this orchestration)
- The main session holds only pipeline state: phase list, artifact file paths, checkpoint status—it does not load any phase skill's domain knowledge
- Fallback path: when the host does not support subsessions, or the user manually walks the pipeline within a single session, degrade tosequential sessions + persisted-file handoff—correctness is unaffected (all state is in files); the only loss is context hygiene
- Anti-pattern: sequentially accumulating and loading all SKILL.md files within a single session (9 × hundreds of lines of instructions present at the same time)
- Exception for the injection-style form: under pre-injection deployment (evaluation or the host injects all instructions at once), the isolation mechanism in this section does not exist—in this caserely on phase order to prevent crosstalk: at any moment execute only the current phase's instructions, and treat the other present files as not loaded; the principle "files are the pipeline state" applies to both forms (for the dual-form declaration see
../core/evidence.mdSection 6)
Pipeline and persisted artifacts (files are the pipeline state)
| # | Phase | skill | Persisted artifact | Human checkpoint |
|---|---|---|---|---|
| 0 | (bypass, optional) exploration first | exploratory-testing |
{项目}/探索笔记_{主题}.md |
— |
| 1 | Requirement understanding | requirement-analysis |
{项目}/需求模型.md(including clarification record) |
⏸ Clarification checkpoint: ambiguous/contradictory items await user decision |
| 2 | Test strategy | test-strategy |
{项目}/测试策略.md(Risk Map + two-domain scope including type_scope) + 专项移交_{轴}_{日期}.yaml(when there are handoff/blocked/external executor axes) |
⏸ Budget decision: when full budget trimming touches a Critical axis, present a prioritization proposal and await user decision |
| 3 | Test case writing | test-case-writing |
{项目}/测试用例_markmap.md + 测试用例.schema.yaml |
— |
| 4 | Test case review | test-case-review |
revised test case files + review record (re-extract Schema) | — |
| 5 | Execution | automated-e2e-testing / api-testing / manual |
Automated path: execution code or script (playwright/ or API test script) + execution sub-report 测试报告_{来源}_{日期}.md(for naming see ../core/report-template.md Header annotation; at minimum §2 Execution Statistics + §3 Bug List entries, fields per report-template); Manual path 手动执行记录_{日期}.md |
⏸ Execution strategy decision: confirm the automation_plan proposal (manual/e2e/api); after manual path execution, ⏸ result collection (TC × result) |
| 6 | Bug Analysis | bug-analysis(when there are confirmed Bugs) |
Intermediate artifact {项目}/Bug条目_{日期}.md(entry structure and the five extended fields such as root cause analysis per report-template §3) — at this stagecreating or rewriting is prohibitedFinal test report |
⏸ Bug qualification checkpoint: expected vs defect |
| 7 | Regression verification | regression-testing(when there are code changes/Bug fixes) |
{项目}/回归清单_{日期}.md |
— |
| 8 | Closing report | This skill (per ../core/report-template.md） |
{项目}/测试报告_{日期}.md |
— |
Bypass trigger condition: when documentation is missing / the system is unfamiliar, Phase 0 runs before Phase 1, and the exploration output (system understanding + risk list) serves as input for requirements modeling.
The manual execution path has no skill and no automated artifacts — after execution, request results from the user per the ⏸ result collection checkpoint, and write to disk
手动执行记录_{日期}.md(TC number × result [pass/fail/blocked], with failures accompanied by Bug number or symptoms): serves as the data source for §2 Execution Statistics and §3 Bug List in the Phase 8 report, preventing the "not executed" column from becoming a permanent state.Phase 6's
Bug条目_{日期}.mdis atransit intermediate artifact: the final report is only generated in Phase 8, and during this period Bug entries have nowhere to be appended — first write to the transit file, and in Phase 8 after assembling into report §3 the report prevails, and the file is archived for traceability without forming a dual data source. The专项移交_{轴}_{日期}.yamlgenerated in Phase 2 likewise enters the main session's state tracking: when any subsequent phase output or user feedback changes the handover axis state, synchronously update theexecution_statusin the yaml, preventing the handover package from being lost immediately after generation.Cross-session knowledge: when phase outputs hit QA knowledge worth depositing across sessions (environment quirks / flaky determination / defect patterns, etc.), determine per
qa-memoryand write into the project.qa/knowledge base; in-session state is still based on the artifacts written to disk, and the two cannot substitute for each other.
Workflow
1. Startup: intent recognition and routing
- The user intent isend-to-end pipeline → continue with this skill
- The user intent issingle-phase output → hand over to the corresponding phase skill, and this skill exits
- Collect inputs first before starting work(provided by the user or pointed to by the user; leave a TODO at the corresponding artifact location indicating "whom to ask for what"): requirements materials, code repository andcomparison baseline(base branch/tag/commit — Phase 7 regression scope is delimited by it, written to disk in the requirements model file header, preventing missing credentials during a resumed run), test environment and accounts
2. Breakpoint check (resume)
When resuming, first read {项目}/流水线状态.md：If there are decisions already filled in by the user in the pending area, first revise the artifacts of the affected phases incrementally according to the decisions(update requirements model assumptions, add budget_review to approved_by: 用户 , etc. — do not rerun the phases), then resume per the criteria below; pending items not yet filled in keep the conservative branch and retain the pending marker, and must not be treated as decided. Then check {项目}/ which artifacts have already been written to disk, starting fromafter the last complete phaseContinue; do not redo completed stages.Stage completion criteria（Stage 3/4 artifacts have the same name; distinguish them by the criteria, not by guessing from file existence）：
- Stage 1:
需求模型.mdexists - Stage 2:
测试策略.mdexists and../core/scripts/validate_schema.pyV1–V5 pass (when type_scope includes the handoff/blocked axis or an external executor, the corresponding专项移交_{轴}_{日期}.yamlshould have been generated) - Stage 3: test cases are persisted on both tracks and
../core/scripts/validate_schema.py {用例文件}(single-file validation of the test case Schema) passes - Stage 4: the end of the test case file contains the test-case-review sign-offreview record section "## Review Record (test-case-review …)" and the Schema has been re-extracted and validated—the same-named "Review Record" section from the self-review written during Stage 3 does not count (that is Stage 3's completion marker; distinguishing the two prevents silently skipping the independent review when resuming)
- Stage 5:
测试报告_{来源}_{日期}.md(automatic path) or手动执行记录_{日期}.md(manual path) persisted - Stage 6:
Bug条目_{日期}.mdintermediate file persisted; if there are no Bugs, append a line to{项目}/流水线状态.md: "Stage 6: no confirmed Bugs, skipped" (pipeline states such as skipped/pending are uniformly recorded in this file—the resume credential for hard rule 3 "all state in files"; if this line is missing, the stage is considered not reached) - Stage 7:
回归清单_{日期}.mdpersisted; if there are no code changes, append a line to{项目}/流水线状态.md: "Stage 7: no changes, skipped"
If an artifact is missing/corrupted, rerun from that stage.
3. Schedule stage skills in pipeline order
- For each stage: invoke the corresponding skill in an independent context (or degrade to sequential invocation); input = the previous stage'spersisted artifact file path(not session memory)
- Checkpoint pause: upon encountering a ⏸ step, present to the user the questions/proposals summarized by that stage's skill,and after waiting for the user's replyproceed to the next stage; the user's explicit reply during the clarification step has final adjudicative authority (see
../core/evidence.mdadjudication rules), and subsequent stages must not overturn it - headless / non-interactive execution(scenarios without dialogue, such as CI pipelines): ⏸ checkpoints do not wait and are not answered on the user's behalf; per
../core/pipeline-integration.md(loaded at this point), degrade by convention to persisting pending items—for those with conservative defaults, take the conservative branch and record the basis; record the rest as pending items; pending items and skip markers are uniformly persisted to{项目}/流水线状态.mdpending area, and after manual backfill of adjudications, they are incrementally consumed by the breakpoint check (§2); adjudication artifacts requiring an audit trail (such asbudget_review) shall, per Article 4 of the convention, truthfully record headless pending status and must not be written as user-approved - Stage output persistence failure (file not generated) → rerun that stage and do not proceed to the next stage
4. Wrap-up: generate the test report
After all stages are complete (or when the user requests early wrap-up), per ../core/report-template.md(loaded at this point), aggregate and generate {项目}/测试报告_{日期}.md: scope, execution statistics (automatic run results merged with manual execution records), Bug list (assembled from Stage 6's Bug条目_{日期}.md and synchronize the status item by item — those with regression results are updated according to the results to verified-closed/fixed-pending-verification, and those without regression remain newly created), residual risks, regression summary, and type-domain special results are normalized and collected axis by axis according to report-template §7 (handoff / external execution / blocked / exclude), open items (including the current status and destination of each axis in the handoff yaml), path index of artifacts for each phase, and machine-readable summary fragment (generated according to the "machine-readable summary fragment" section of report-template, for consumption by the report aggregation system).
5. Delivery
Report to the user: final report path + list of artifacts for each phase + open items (TODO ownership).
Hard rules
- Do not make decisions: clarification, execution strategy, bug characterization, and budget decisions are all presented as problems and suggestions and then await the user; do not decide on the user's behalf
- Do not include domain knowledge: testing methods and framework knowledge are all in the phase skills and
core/; the only reasonable reason for this skill to fail is an orchestration error, not a testing judgment error - All state is in files: after any session interruption, rely on
{项目}/persisted artifacts to resume execution - Phase artifact consumption goes through files: what is passed across phases is the artifact path, not paraphrasing within the session
Common Mistakes
| Error | Consequence | Correct approach |
|---|---|---|
| Load the SKILL.md of all phase skills into the same session | Instruction conflicts, context explosion | Context isolation between phases; the main session holds only state |
| Start the pipeline even for a single-phase intent | Over-execution, waste | After intent recognition, hand off to the corresponding phase skill |
| Self-answer at checkpoints (deciding on behalf of the user) | Decision invalidation; subsequent phases are based on wrong assumptions | ⏸ steps must wait for the user's reply |
| Resume execution from session memory (without reading persisted files) | After interruption, state is lost/inconsistent | Breakpoint checks only recognize files |
| The orchestration layer stuffs in testing methodology | Breaks thin orchestration; difficult to maintain | All methodology is pushed down to phase skills and core/ |
| Phase 6 creates/rewrites the final test report in advance | Duplicate writing under the same name as phase 8 finalization, dual data sources | Bug entries are first placed in Bug条目_{日期}.md intermediate files, and assembled uniformly at finalization |
| Cross-session knowledge and pipeline artifacts are mixed together | Knowledge is not accumulated / pipeline state is polluted | For in-session state, look at persisted artifacts; for cross-session knowledge, look at .qa/（qa-memory） |