// Primary execution workflow for durable /goal runtime. Use when a Goal Contract is active or when the user asks to execute, continue, verify, or complete a goal.
| name | agentic-goal |
| description | Primary execution workflow for durable /goal runtime. Use when a Goal Contract is active or when the user asks to execute, continue, verify, or complete a goal. |
Work only through the durable /goal runtime.
/goal status when a goal may be active./goal status./goal <request> is used as a new entrypoint, triage the request first: answer simple investigation/question/explanation requests like normal prompts, but route complex, ambiguous, or verifier-worthy work into deep clarification before durable goal activation./goal is invoked without a specific target, continue the entire active goal across subgoals until the goal itself receives verifier PASS.todoread and todowrite./goal evidence <targetId> <evidence> before requesting completion.For /goal <request>, silently decide whether the request needs durable goal runtime:
/goal status./goal evidence./goal complete <targetId>.The /goal runtime is canonical. Do not use external planning documents as the source of truth. Do not route to legacy workflow skills as user-facing next steps.
Use when a user's request is vague, ambiguous, or underspecified. Launches an iterative Q&A loop to resolve ambiguity, using an explorer subagent only when codebase context is needed. Outputs a Goal Contract for the durable /goal runtime. Triggers on "I want to...", "I need...", "let's build...", "can you help me...", "we should...", or any request where the full scope isn't immediately clear.
Review changed code for reuse opportunities, quality issues, and inefficiencies using three parallel review agents, then fix any issues found. Triggers when the user says "agentic-simplify", "clean up the code", "review the changes", or after goal implementation when code quality verification is needed.
Use when encountering any bug, test failure, or unexpected behavior. Enforces a strict reproduce-first, root-cause-first, failing-test-first debugging workflow before fixing.
Interactive idea development through guided Q&A dialogue. This skill helps users clarify and develop their ideas by asking targeted questions, expanding on possibilities, and producing a structured markdown document capturing the essence of their thinking. Triggers: "brainstorm", "idea", "organize ideas", "I want to organize my thoughts", "whatever comes to mind"
Behavioral guardrails to prevent common LLM coding mistakes — enforces surgical changes, assumption verification, and scope discipline before and during implementation. Use when implementing features, modifying code, or when you notice yourself about to make changes without reading the existing code first.
Rob Pike's 5 Rules of Programming — a decision framework that prevents premature optimization and enforces measurement-driven development. Use when the user says "optimize", "slow", "performance", "bottleneck", "speed up", "make faster", "too slow", or any request to improve code speed/efficiency. Also use when you notice yourself about to suggest a performance optimization without measurement data. This is a thinking discipline, not a tooling workflow.