Enforce checkpoint-level verification before multi-phase work advances, using bounded auto-remediation and explicit escalation when failures are ambiguous or risky. Use when complex work should not proceed to the next stage without validating the current stage, including acceptance-oriented checkpoint profiles that still stay under checkpoint verdict ownership. Do not use for plan lifecycle ownership, session handoff, or full long-running orchestration.
Create and maintain SDD execution plans for coding work, including concrete feature or fix planning, milestone status tracking, user-confirmed completion gates, archive or index synchronization under docs/plans, and optional harness state handoff without duplicating lifecycle ownership. Use when users ask for a specific plan, plan refinement, phased execution tracking, progress updates, or plan closure. Do not use for one-off tiny edits, pure Q and A, or internal scratch planning with no user-visible plan output.
Create a session-level continuation pack when the current coding window should offload context before continuing in a new window. Use when users ask to整理当前 session, prepare a new window to continue the same unfinished task, or create a handoff/context-offload summary from current progress, blockers, plans, memory, and lessons. Do not use for reusable experience capture, standalone plan updates, or full transcript archival.
Maintain deferred but currently binding technical guardrails for long-horizon architecture direction, including independent deferred-plan artifacts, status management, and a narrow adapter that resolves whether current planning should inherit those guardrails. Use when a technical direction is intentionally deferred now but must still constrain near-term planning to prevent drift. Do not use for concrete execution planning, general backlog management, discussion-only evaluation, or project memory capture.
Advise whether a dirty worktree should be checkpoint-committed before complex work moves to a new phase, new plan, or new window. Use when unfinished implementation, mixed changes, or large dirty trees need a clear checkpoint commit strategy with explicit layering such as governance anchor and known-bad snapshot. Do not use for plan lifecycle ownership, checkpoint validation, session handoff generation, or generic git history management.
Turn a coarse sprint or planned work slice into an evaluable execution contract before implementation or stage validation begins, including what the sprint closes, why the boundary exists, done signals, evidence checklist, negative cases, and suggested checkpoints. Use when planning direction is already aligned but downstream review, checkpoint, or acceptance needs task-specific criteria. Do not use for lifecycle updates, checkpoint verdict execution, or final acceptance review itself.
Decide whether a coding task should run as one-shot, research-first, discussion-first, or sprint-required before execution starts, and provide coarse sprint topology with rationale when one-shot execution is too risky. Use when task complexity, uncertainty, cross-module coupling, or verification cost suggests continuous solo execution may be unsafe. Do not use for plan lifecycle updates, checkpoint validation, final acceptance review, or runtime orchestration.
Capture reusable coding experience cards from key alignment and hard-problem resolution moments. Use when users ask to summarize lessons, preserve decision rules, or build reusable play patterns across tasks and projects. Do not use for next-window handoff, context offload, verbatim transcript archival, routine progress logging, or replacing layered project memory.