메뉴
Use when you need to refine user journeys or process flows step by step in small review batches, including states, alternate paths, edge cases, and acceptance detail.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | spec-forge-journeys |
| description | Use when you need to refine user journeys or process flows step by step in small review batches, including states, alternate paths, edge cases, and acceptance detail. |
Use this stage to refine the behavior of each major journey in progressive review batches.
This stage answers: what happens step by step, which states and alternate paths exist, what rules apply, and which code touchpoints the journey implies.
spec-forge-cli resolvespec-forge-cli applyspec-forge-cli artifact getspec-forge-cli artifact putspec-forge-cli artifact mergespec-forge-cli approvespec-forge-cli focusspec-forge-cli gate checkspec-forge-cli stage advanceRead ../spec-forge/assets/contracts/ux-contracts.yaml
before collecting parameters.
At the start of the stage, run:
spec-forge-cli resolve --target <target-dir> --skill spec-forge-journeys --stage journeys --write
If the runtime is not Plan mode, stop and ask the user to switch before collecting inputs or showing any choice dialog.
Use chat summaries as the approval surface; YAML remains the persisted contract for the stage.
| # | Check | Source |
|---|---|---|
| 1 | Architecture artifacts exist | Architecture stage |
| 2 | Architecture artifacts are approved | Architecture stage |
spec-forge-cli resolve --target <target-dir> --skill spec-forge-journeys --stage journeys --write
Confirm chat language and file language before stage-specific journey
questions.
Then collect only the next missing parameter, one step at a time, and record
every accepted answer or choice with
spec-forge-cli apply ....spec-forge-cli focus --target <target-dir> --spec-id <spec-id> --stage journeys --max-items 1 --write.spec-forge/specs/<spec-id>/journeys/<journey-id>.yaml.
Use spec-forge-cli artifact get to inspect the current artifact when
needed, then persist detail with spec-forge-cli artifact merge for
incremental patches or spec-forge-cli artifact put for a full replacement.discussion_roles for that journey. Common roles are:
product-managerux-architectqa-leadtech-lead.spec-forge/specs/<spec-id>/journeys/batches.yaml so each batch reflects real review
status, using spec-forge-cli artifact merge --file journeys/batches.yaml
or spec-forge-cli artifact put --file journeys/batches.yaml.spec-forge-cli approve --target <target-dir> --spec-id <spec-id> --file journeys/<journey-id>.yamlspec-forge-cli approve --target <target-dir> --spec-id <spec-id> --file journeys/batches.yamlspec-forge-cli gate check --target <target-dir> --spec-id <spec-id> --stage journeys --writespec-forge-cli stage advance --target <target-dir> --spec-id <spec-id> --stage journeys.spec-forge/specs/<spec-id>/journeys/batches.yaml.spec-forge/specs/<spec-id>/journeys/<journey-id>.yaml.spec-forge/specs/<spec-id>/gates/journeys.yaml| # | Check |
|---|---|
| 1 | Journey batches exist |
| 2 | Every in-scope journey has a YAML detail artifact |
| 3 | Every in-scope journey detail artifact is user-approved |
| 4 | Journey batch file is user-approved |
Continue with
../spec-forge-components/SKILL.md.
Use when the task requires operating or validating the package-local `spec-forge-cli` Rust command surface for initializing workspaces, resolving interactions, mutating YAML artifacts, recording approvals, selecting focus batches, checking gates, advancing stages, or validating UX contracts.
Use when you need to turn approved framing into a top-level solution shape, journey list, and component list before refining detailed flows or implementation contracts.
Use when you need to define component-level contracts in reviewable batches, including responsibilities, interfaces, state, data models, and implementation constraints.
Use when you need to execute an approved implementation spec, record what changed, capture validations, and track whether any blockers still prevent completion.
Use when you need to turn a rough request into a clear spec framing by defining the problem, stakeholders, scope boundaries, and non-negotiable constraints before solution design begins.
Use when you need to consolidate prior stage artifacts into an implementation-ready spec, confirm completeness, record open assumptions, and decide whether the work is ready to build.