菜单
Extend an existing goal — broaden or add to its objective, building on top of what the earlier /goal run already implemented. Use when the user wants to expand a goal after a /goal run.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ab-extend-goal |
| description | Extend an existing goal — broaden or add to its objective, building on top of what the earlier /goal run already implemented. Use when the user wants to expand a goal after a /goal run. |
This skill runs the AB Method extend-goal workflow.
Follow the workflow defined in .ab-method/core/extend-goal.md exactly — it contains the full process, output format, and rules.
Before doing anything, check .ab-method/structure/index.yaml. It defines where this workflow reads from and writes to. Paths are user-configurable; never hardcode them.
Post-implementation documentation-sync detector. Spins up ONE read-only subagent on a completed task's diff to find everything the change introduced that the architecture docs don't yet know about — new endpoints, patterns, dependencies, domain terms, ADR-worthy decisions — routed to the exact doc each belongs in. Autonomous runs apply only append-only safe additions and defer domain/ADR reshapes; interactive runs present the proposed doc deltas to pick. Use after a task's missions are done (from create-task / start-task / start-roadmap) or standalone on a diff.
Cross-plan coherence critic for a whole roadmap. Reads roadmap.md plus every planned task's progress-tracker.md and pushes back ONLY on genuine discrepancies BETWEEN the finished plans — broken seams, coverage gaps, duplicated work, reversed/missing edges, terminology drift, conflicting assumptions. Read-only; silent when the plans cohere. Run standalone after planning finishes and before /start-roadmap.
Pre-implementation critic. Spins up a read-only domain critic that challenges a drafted plan — a task's missions or a roadmap's task graph — against the ubiquitous language, CONTEXT.md, and ADRs, and pushes back ONLY on genuine conflicts. Silent when the plan is sound. Use before implementing (from create-task / create-roadmap) or standalone to stress-test a plan against the project's domain model.
Post-implementation review. Spins up three read-only critics on a completed task's diff — cleaner-architecture, slop-defender, reusability-inspector — that push back ONLY on real issues. Autonomous runs apply safe fixes (tests-green-gated) and write everything to review.md next to progress-tracker.md; interactive runs present findings to pick. Use after a task's missions are done (from start-task / start-roadmap / create-task) or standalone on a diff.
Execute a roadmap autonomously to completion — the layer above start-task. Use when a roadmap's tasks are planned and you want them run in dependency order, with independent tasks optionally in parallel. Verifies the dependency tree is planned before running; stops if a needed task has no plan. Executor only.
Turn a larger idea into a dependency-ordered roadmap of tasks — the layer above create-task. Use when the work is several distinct tasks with real ordering between them (schema before API before UI), and you want the whole task graph drawn before implementing. Producer only; ab-start-roadmap executes it.
