First read Workflow Execution Conventions and Interview Mode and Fact Standards: gather evidence first, work according to real capabilities, and locate resources from the current installation location.
By default, follow the user's input language; explicit specification takes precedence. Metadata fields, enums, IDs, and comment markers remain in English; templates and subtasks inherit the same output_language, see Language Rules。
Triggers and Boundaries
Used to clarify or organize user operation flows, cross-Journey jumps, and exception/boundary behaviors based on a BRD. Does not replace technical design, PRD approval, or implementation. When only editing existing Journey fragments, only check the affected scope and do not restart the full interview.
Mode Selection
| Mode | Behavior |
|---|---|
| interview | Vague goals or explicit request for an interview: open discovery, provide credible options when necessary, 2-3 key gaps per round; respect the requirement for item-by-item confirmation |
| synthesis | Sufficient materials and request for organization: reuse known journeys, steps, priorities, and jumps in bulk, deliver the draft directly, do not force item-by-item re-confirmation |
| gap_followup | Materials are basically complete: only ask about unresolved branches, source conflicts, or missing decisions; do not re-ask about valid baselines and existing facts |
Keep confirmed facts separate from formal approval of this artifact; if the user only requests a draft, keep it as draft. Without an approved BRD, an exploratory draft with source status can still be produced, and it must not be self-upgraded to a formal baseline.
Workflow
1. Read the BRD and journey materials
Read the user-specified BRD, relevant approval basis, and existing flows. Extract target users, business goals, in/out-scope, success definition, version, and source. When multiple sources conflict, cite the specific differences and focus questions on genuine gaps; a filename, an "approved" label, or a modification time does not by itself prove approval.
2. Establish scope and stable IDs
Reuse the already clarified Journey scope and priorities, ask about missing items only when truly necessary, and do not re-confirm all provided content. Maintain stable JOURNEY artifact IDs, FLOW-* Journey IDs, and S1/S2/... Step IDs for each Journey; do not arbitrarily renumber when updating existing materials. Establish the BRD → Journey mapping and Journey Graph. Journeys newly discovered beyond the current scope should first be treated as pending items; do not expand scope without authorization.
3. Refine steps, jumps, and boundaries
For each in-scope Journey, organize:
- Who, goal, preconditions/entry, endpoint, and the result the user gets.
- Happy Path steps; for each flow record from/to, trigger conditions, cross-Journey target entry, and data handoff; use END to indicate termination.
- Relevant branches such as exceptions, rollback, retry, interruption, permissions, state changes, and partial success. Reuse decisions already given directly; keep key behaviors not yet given as pending.
- According to Step-Level Boundary Framework check applicable categories; do not list only vague nouns.
Each in-scope edge case records EC ID, category, applicable Sx, trigger condition, user-visible result, handling flow, data retention/recovery, MVP/follow-up, and confirmed/pending. P0 Journeys must not skip all boundaries wholesale; when there genuinely are no additional applicable items, state the reason. Missing MVP boundaries blocks locking the baseline but does not block a transparent draft. These are content coverage requirements, not that every field must be asked of the user again.
4. Cross-Journey Consistency and Checkpoint
Check shared steps/exception policies, priority dependencies, dangling jumps, undefined entry points, and exit paths of cross-Journey loops. Directly retain already-consistent decisions, and only ask follow-up questions for substantive conflicts. Record content coverage, evidence, and approval conditions separately by checkpoint-gates.md ; do not claim approved merely because materials are sufficient or lint succeeds.
5. Delivery and Verification
Read by language Chinese template or English template, including:
- TRACEABILITY-METADATA, stable IDs, source_documents, relations in the journey-profile-v1 example ; use that actual path, do not guess a schema file with the same name.
- Journey Graph, step/jump table, step-level Edge Case Matrix.
- BRD → Journey and Journey → PRD mapping, Checkpoint Decision, pending items, and a real review record.
Use the user-specified path; when unspecified, choose a reasonable default within the project and explain it, and do not repeatedly ask about the path. After generation, first resolve TESTANY_ENG_ROOT (the plugin root directory) from the location of the current SKILL.md; do not assume that environment variable already exists. Execute the actually available checks:
python3 "$TESTANY_ENG_ROOT/scripts/trace_lint.py" --format json --profile journey-profile-v1 "[Journey路径]"
If lint was not run or failed, record it truthfully; do not automatically install missing required dependencies, and do not block draft delivery; do not claim lint has passed. Only when checkpoint conditions are met and there is real approval for the current version/scope may the baseline be locked. A user-specified draft is not automatically promoted because checks pass; after changing the metadata status, the final version must be re-validated.
Return the actual document, current status, check results, and remaining decisions. When recommending downstream, state whether it can serve as a locked baseline; do not automatically start PRD upon draft completion or make the user repeat upstream known information.
Output Specification
Flowcharts use Mermaid; if the delivery format requested by the user cannot carry Mermaid, retain an auditable node/edge table and explain the limitation, and do not replace flow evidence with decorative diagrams. The specific structure is subject to the template and journey-profile-v1; example statuses in the template are not approval facts and should be filled in according to this instance's evidence.
Usage Examples
- "First interview the main reimbursement flow, and continue only after each item is confirmed": interview according to that checkpoint and wait.
- "Organize the complete process notes into a User Journey draft": generate directly, without repeating confirmation step by step.
- "Only two points are undecided: whether to retry after failure, and whether to retain the draft after cancellation": ask follow-up questions only about those two points, reuse the rest, and keep them pending until answered.
- "Only modify the button copy for S2": make the local modification and check the consistency of related steps/jumps, without reopening the full exit readiness.