st-full-workflow 是 Strikethroo（来源仓库 e0ipso/strikethroo）中的一个端到端工作流技能。它的用途是：当用户要求针对某个工作单一次性运行完整的 Strikethroo 工作流时触发，把整个流程当作一个整体来执行。
触发与输入：触发条件包括完整工作流等场景；工作单由用户以对话方式提供。
总体规则：技能要求顺序执行三个步骤，步骤之间不等待用户输入。
步骤一：计划创建。首先定位 Strikethroo 根目录（运行 scripts/find-strikethroo-root.cjs，若退出码非零则停止并请用户运行 npx strikethroo init），后续步骤均以该路径为 <root>。随后运行 scripts/check-for-updates.cjs 并读取 stdout 的一行 JSON，若存在更新通知则保留其原文用于最终回复，但不暂停征求许可、也不执行更新。接着加载项目上下文：读取 <root>/config/STRIKETHROO.md、执行 <root>/config/hooks/PRE_PLAN.md、读取 <root>/config/templates/PLAN_TEMPLATE.md 与 <root>/config/shared/anti-rationalization.md。然后分析工作单的目标、范围与边界、成功标准、依赖与阻塞、技术需求与约束。若缺少关键上下文，进入澄清循环，反复提出针对性问题直到没有疑问，并明确确认是否需要向后兼容；绝不臆造答案，也不掩盖缺失答案；若用户拒绝澄清阻塞性问题，则停止并报告计划需要澄清，不产出部分计划。之后运行 scripts/get-next-plan-id.cjs 分配下一个计划 ID，按 {padded-id}--{slug} 规则命名目录并把未补零整数写入计划 frontmatter。计划写入 <root>/plans/{padded-id}--{slug}/plan-{padded-id}--{slug}.md，须符合模板的 frontmatter 与章节；不包含时间估计、任务列表或代码示例。slug 由计划摘要派生，小写、仅字母数字与连字符。随后执行 <root>/config/hooks/POST_PLAN.md，并以固定结构输出步骤一小结（计划 ID 与计划文件绝对路径），供步骤二使用。
步骤二：任务生成。先用计划 ID 运行 scripts/validate-plan-blueprint.cjs 解析计划文件路径，失败则输出 stderr 并停止，不猜测其他 ID。加载上下文后分析并拆解计划：只把计划中明确声明的交付物拆成原子任务，执行强制任务最小化（相比全面清单目标减少 20–30%），每个任务对应明确需求而非“最佳实践”或未来扩展，且职责不重叠，错误处理归属拥有该行为的任务。粒度与技能规则要求任务单一目的、原子、可由具备 1–2 项技术技能的智能体执行、具备显式可运行验收标准；技能名用 kebab-case，单一领域一个、互补领域两个，三个及以上需进一步拆分。测试哲学为“写少量测试、以集成测试为主”，仅在自定义业务逻辑与算法、关键用户流程与数据转换、核心功能的边界与错误条件、组件集成点、复杂校验或计算逻辑时写测试，不为第三方库功能、无自定义逻辑的简单 CRUD、平凡 getter/setter 与静态配置写测试，相关测试场景合并为一个任务，并把规则复制到每个测试任务的 Implementation Notes。随后做依赖分析（硬依赖/软依赖，确保无环）、复杂度分析（1–10 分，评分≥8 继续拆解，6–7 打磨或拆分，模糊验收标准改为可运行验证，过小相邻任务合并；应用拆分/打磨/合并后重跑依赖分析与评分，最多三轮，仍未解决则停止并上报阻塞）。任务 ID 由 scripts/get-next-task-id.cjs 分配，frontmatter 用未补零整数、文件名用补零形式。任务写入 <root>/plans/<plan-dir-name>/tasks/{padded-id}--{slug}.md，符合 TASK_TEMPLATE.md；仅在需要说明分数时写 complexity_notes；绝不写 execution_profile。填充每个正文部分，详细实现指引放在 Implementation Notes 的 <details> 块内。生成结束前执行验证清单：覆盖计划中每个明确交付物、任务无重叠、依赖无环、分组一致；并运行脚本校验复杂度分数，若为否则修复后重跑。随后进行任务执行路由：读取 <root>/config/hooks/TASK_EXECUTION_ROUTING.md，运行 profiles 查询；若未配置或禁用则跳过路由；若配置无效则停止并上报，不生成蓝图。为每个任务分配一个已配置 profile 名称，把任务 ID 到 profile 的映射写入临时 JSON 文件并运行 apply；成功后删除临时文件，失败则停止并上报。绝不手写具体执行目标到任务 frontmatter 或正文。最后执行 POST_TASK_GENERATION_ALL 钩子，蓝图结构使用 BLUEPRINT_TEMPLATE.md，且仅在路由成功或报告关闭后运行。
步骤三：蓝图执行。再次解析计划文件与计划目录路径，校验任务数量与蓝图是否存在；若 taskCount 为 0 或 blueprintExists 为 no，则通知用户并自动执行步骤二的任务生成，然后刷新路径与计数；若仍无任务或蓝图则停止并报告失败。可选创建功能分支（scripts/create-feature-branch.cjs，跳过不算失败，错误则停止），并运行 scripts/capture-base-commit.cjs 记录评审门禁对比的提交。随后按 Execution Blueprint 定义的阶段顺序执行：阶段执行前运行 scripts/check-phase-readiness.cjs 并执行 PRE_PHASE.md；任务分派阶段先读取 PRE_TASK_ASSIGNMENT.md，再并行解析每个选定任务的路由，并按结果类型采取对应动作（native-default、native-override、external-override、fallback、launched-success、launched-failure、infrastructure-failure），遵守 handoff 规则（使用解析器返回的原始不透明字符串，不重建、不复用、启动后不重跑解析）。所有剩余原生子智能体需在实现前读取并执行 PRE_TASK_EXECUTION.md。阶段完成验证要求每个任务状态为 completed 并收集输出，不以子智能体报告成功为证据，须应用 verification-gate 的证据门禁。随后执行阶段后置钩子（资料在 POST_ 处截断，后续内容暂未提供）。
依赖与环境：该技能依赖仓库内的脚本与配置文件（如 scripts/ 下的多个 .cjs、config/ 下的模板与钩子），以及支持的 harness 标识与工作目录参数。除仓库与脚本要求外，收费、价格、具体适用平台、运行环境与效果等信息暂未提供。