engineering-workflow

Delegate a bounded coding implementation to the Google Antigravity CLI (agy), then review its diff and land it from the parent. Use only when the user explicitly asks to delegate implementation to Antigravity or agy. Do not use for direct implementation, generic Google-model requests, or automatic provider selection.

Delegate a bounded coding implementation to a separate Claude Code CLI session, then review its diff and land it from the parent. Use only when the user explicitly asks for another Claude or the claude CLI to implement. Do not trigger because the current agent is Claude, for direct implementation, or for automatic provider selection.

Delegate a bounded coding implementation to the OpenAI Codex CLI, then review its diff and land it from the parent. Use only when the user explicitly asks to delegate implementation to Codex or run a coding task through Codex. Do not use for direct implementation by the current agent, review-only requests that need no implementer, or automatic provider selection.

Investigate and optionally fix concrete software failures with an evidence-first Debug Work Order. Use when the user provides or reports a reproducible error, failing test, stack trace, regression, flaky behavior, performance fault, or multiple known bugs and asks to diagnose, debug, or repair them; also use to resume an existing `.debug-workflow` ledger. Do not use for designing debugging tools or methodology, ordinary feature work, general code review or speculative bug hunting, cosmetic “fixes,” active production incidents before containment, or conceptual explanations that require no investigation.

Delegate a bounded coding implementation to the Grok Build CLI, then review its diff and land it from the parent. Use only when the user explicitly asks to delegate implementation to Grok or Grok Build. Do not use for direct implementation, ordinary Grok questions, or automatic provider selection.

Delegate a bounded coding implementation to the Pi coding agent CLI, then review its diff and land it from the parent. Use only when the user explicitly asks to delegate implementation to Pi or the pi CLI. Do not use for direct implementation, mathematical pi requests, or automatic provider selection.

Guide a repository change through the lightweight spec, plan, tasks, build, and verification workflow. Use when the user invokes $sdd, asks for spec-driven development, wants to continue an existing .specs change, or needs an implementation recovered from durable SDD artifacts.

Implement a valid .specs change task by task, using bounded fresh subagents when useful and parent-owned verification. Use when spec.md, plan.md, and tasks.md are valid and current, or when resuming remaining tasks from those artifacts.

Create or repair an SDD change plan.md from a valid spec.md, binding the current specification digest and requirement coverage. Use when an SDD specification is ready but its technical plan is missing, invalid, or stale.

Create or repair an SDD change spec.md with intent, requirements, scenarios, and non-goals. Use when an SDD change has no valid spec, requirements are unclear, or an upstream specification must be revised before planning.

Create or repair an SDD change tasks.md from current spec and plan artifacts, with requirement traceability, dependencies, file scopes, and verification recipes. Use when an SDD plan is valid but executable tasks are missing, invalid, or stale.

Plan and execute a test-first red-green-refactor loop. The Hook is advisory and does not enforce file order; the agent must run and judge RED and GREEN.

Orchestrate test-first implementation with observed RED and GREEN evidence while the plugin Hook provides an advisory reminder.