workflow-start
GitHubspec-superflow工作流入口技能,用于启动或恢复变更流程。支持直接执行与规划路径,处理状态检查、手递处理及调试路由,确保变更上下文正确流转。
Trigger Scenarios
Install
npx skills add MageByte-Zero/spec-superflow --skill workflow-start -g -y
SKILL.md
Frontmatter
{
"name": "workflow-start",
"description": "Primary entry point for the spec-superflow state-machine workflow. Invoke only when the user explicitly requests spec-superflow or an active change contains .spec-superflow.yaml and the user asks to continue that change. Generic proposal, specs, design, task, or contract files are not activation signals."
}
Workflow Start
Use only for an explicit spec-superflow request or an existing change. Ordinary coding does not require a spec workflow.
Resume
Run ssf resume <change-dir> --json once. It combines state, handoffs, checkpoints and current-plan inspection. Use the returned absolute change.path for all subsequent operations: recovery may redirect a stale source copy into its recorded worktree. Follow next_action; do not repeat all component commands unless diagnosing that result. A blocked continuation is not a retry instruction; resolve its named cause before running it again. Read only the artifacts relevant to the next action.
debugging: diagnose first, even if a plan is stale. Never dispatch an eligible wave during diagnosis.closing: logical completion. If a recorded isolation still has physical finish pending, route to release-archivist for that remaining action, subject to existing merge authorization. Otherwise stop.abandoned: stop.- A ready handoff needs review through
ssf handoff resolve; an active handoff is non-blocking. Stale checkpoints are history, not current evidence. - Missing/stale Full plans block implementation, not investigation. Valid short paths and Tweak do not require plans.
Update checks are optional (ssf runtime check-update), cached and non-blocking. Never make network access a recovery prerequisite.
New request
Infer scope and risks from the request and repository; do not turn CLI fields into a questionnaire. Validate the change name as a single safe relative path segment under changes/ and create only that directory. Reuse authorization already given. Never infer approval from artifact existence.
Offer only two paths, without a mode-selection interview:
- Direct: clear requested change with a bounded proof. In the same turn run
ssf workflow start <dir> --path direct --scope "<requested outcome and bounds>". No planning pack, recommendation receipt or execution plan is needed. Use affected tests or checks;--verificationcan record tdd/new-test/bounded when relevant. Task/file counts are advisory, not hard limits. - Planned: uncertain behavior, architecture or a user-requested plan. Draft proposal.md (scope, acceptance, risks) and tasks.md (ordered tasks and proof) together. Add specs/design only when their information is needed. Check shared interfaces against actual code once. Present one concrete plan for approval, reusing approval already covering it. Then run
ssf workflow start <dir> --path planned --confirm --reason "<existing approval>". The CLI derives the execution plan and enters executing; no contract-builder, handwritten contract, DP-0..DP-4 sequence or execution recommend is required. Native + final is the default; add--mode sddonly for explicit delegation.
Continue to build-executor without another question. Ordinary debugging stays in executing. Scope changes update the affected planning sections and repeat planned start once with actual reapproval; do not traverse intermediate states. Nonsemantic corrections can use execution resync with a recorded reason, retaining review history.
Completion uses ssf workflow complete <dir> --verification-command "<required check command>". It runs the check once and preserves failures. Planned work also requires its current review and completed tasks; existing delta specs require synchronization. A user can explicitly accept known risks with workflow complete --accept-risk --confirm --reason "<decision and remaining issues>"; this records accepted-risk, never pass, and does not authorize integration.
Legacy changes
Do not convert an active legacy change or discard its receipts automatically. Resume its recorded obligations: Full/legacy Hotfix may still need contract-builder and old approval/review gates; old Quick/Tweak/Lightweight/direct Hotfix use their existing receipts. Read docs/decision-points.md only for the applicable old decision, not for every task. Use ssf runtime asset read docs/state-machine.md only when a legacy transition is unclear. Legacy ssf state init precedes ssf workflow recommend; a nonrecommended choice requires acknowledgment. Legacy Quick/direct Hotfix use workflow accept --verification and persist test_result: pass before closing; use ssf state set <change-dir> dp_0_timestamp now for portable timestamps.
Continue authorized internal work without phase-by-phase handoff questions. For all paths, read only the current task's source and evidence. Progress updates use one short paragraph; ask only for a new material decision, never “continue?” for authorized work.
Version History
-
10d5f08
Current 2026-09-22 02:00
v2版本简化执行流:默认原生执行,精简新变更的直接与规划路径,统一工作流恢复逻辑并修复Windows兼容性问题。
-
1bf565a
2026-09-02 22:23
修复轻量路径卡死、worktree隔离及review死锁等系统性缺陷,新增ssf finish收尾命令并优化状态跟踪逻辑。
-
fd8cf86
2026-08-04 19:02
新增直接短路径接收逻辑,支持快速修复场景下自动推断事实并推荐验证方式。
-
9105098
2026-08-02 21:57
将硬编码的 npx 包版本调用替换为简化的 ssf 命令;移除旧版 asset read 依赖;优化快速路径获取逻辑。
- 1970fe7 2026-07-30 20:20


