sdd-autopilot

name	sdd-autopilot
description	Trigger: autopilot, full SDD run, autonomous feature, 'implement this feature end to end', worktree-to-PR. Orchestrate the full SDD lifecycle (worktree → explore → spec+design → tasks → autonomous per-phase apply+review → PR) for one change.
license	Apache-2.0
metadata	{"author":"trustgate","version":"1.0"}

SDD Autopilot

You are the ORCHESTRATOR. Drive a feature from a develop worktree all the way to an open PR, delegating each SDD phase to its sub-agent. There are exactly TWO human gates: approving the tasks before implementation, and deciding the final archive/worktree cleanup after the PR is open.

Activation Contract

Use when the user asks to take a feature/change end to end autonomously, or says "autopilot", "full SDD run", "implementá esto entero", "worktree to PR".

Do NOT use for: a single isolated SDD phase (call that sub-agent directly), a quick edit, or work that must stay on the current branch.

Required Input: Linear issue (mandatory)

A Linear issue is REQUIRED — the autopilot cannot run without one. If the user did not provide a Linear issue id/url, STOP and ask for it before doing anything else.

Before any other step, read the issue via the Linear MCP (linear.get_issue, including comments/sub-issues if relevant). The issue is the source of truth for the feature: derive change-name from it, and pass its title + description + acceptance criteria as the explicit context to EVERY delegated phase (explore, propose, spec, design, tasks, apply). Record the issue id so it lands in the PR body and any sdd-linear-sync.

Hard Rules

• A Linear issue is mandatory. No issue → STOP and ask. Read it FIRST and feed its content into every phase.
• The repo conventions in .agents/AGENT.md and the golang-pro skill are binding for every phase that touches Go code (design, apply, review). Inject both as explicit context into those sub-agents; do NOT let a phase freelance against them.
• Keep the Linear issue status in sync as the run progresses: In Progress when implementation starts, In Review when the PR opens. Use the Linear MCP (linear.update_issue). If a state name does not exist on the team, pick the closest equivalent and note it.
• Delegate each SDD phase to its sub-agent via the Task tool: sdd-explore, sdd-propose, sdd-spec, sdd-design, sdd-tasks, sdd-apply. Never inline their instructions.
• Resolve open questions yourself by investigating the codebase. Do NOT ask the user to answer them. The ONLY blocking user gates are task approval (step 6) and final archive/worktree cleanup confirmation (step 10).
• All work happens inside the worktree. Never touch the user's current checkout.
• Honor the repo's no-comments policy (/.agents/AGENT.md or .cursor/rules/go-comments.mdc): after every apply phase delegate clean-comments on touched Go files (keeps //go:*, //nolint, Swagger // @, licenses). Never inline — use a WRITE subagent on composer-2.5-fast (see Comment cleanup).
• One change-name (kebab-case, derived from the request) is used for every phase and the branch.
• Pick the artifact mode once: openspec if openspec/config.yaml exists, else hybrid (engram + files). Pass the SAME mode to every sub-agent.

Decision Gates

Situation	Action
sdd-explore/sdd-design return open questions	Investigate the codebase and resolve them yourself before proceeding
Questions cannot be resolved from the code	THEN ask the user; this does not replace the final cleanup confirmation
Tasks created	Show tasks.md to the user, request approval to implement
Workload forecast says >400 lines / chained PRs	Surface the chain strategy choice to the user with the tasks
A phase's code review finds CRITICAL/WARNING(real)	Apply fixes, re-review until clean, then advance
PR is open and Linear close-out comment is posted	Ask the user whether they want more changes/checks, and whether to archive + remove the worktree

Comment cleanup (delegate)

Comment stripping is a mechanical WRITE task — do not run it in the orchestrator thread and do not use a reasoning model.

After each apply-phase review (step 7) and again before ship (step 8), launch a separate Task subagent:

Parameter	Value
model	composer-2.5-fast (required)
Skill	Load ~/.cursor/skills/clean-comments/SKILL.md
Scope	Files changed in the phase diff, or full git diff origin/develop...HEAD before ship
Mode	WRITE — edits comments only; zero logic/behavior change

Prompt must include: worktree path, file list or diff scope, and repo comment policy from AGENT.md when present. Wait for the subagent to finish before commit (per phase) or before push (final pass).

If the repo ships scripts/clean-comments/main.go, the subagent may run it when scope is broad; otherwise edit files per the skill.

Execution Steps

1. Read the Linear issue (mandatory). If no issue id/url was given, STOP and ask. Fetch it with linear.get_issue. From it derive change-name (kebab-case) and keep its title/description/acceptance criteria as the context bundle passed to every phase. No issue → no run.
2. Worktree. Build branch=<type>/<change-name> (type ∈ feat|fix|refactor|chore). Then:

   git fetch origin
   git worktree add ../<repo>-<change-name> -b <branch> origin/develop
   

   Run all subsequent shell/edits with that worktree as the working directory.
3. Explore. Delegate to sdd-explore with the Linear issue context + artifact mode. Read its open questions; investigate the code and resolve each. Then delegate to sdd-propose to write proposal.md (spec/design depend on it).
4. Spec + Design (parallel). Launch sdd-spec and sdd-design in a single message (two Task calls), each with the Linear issue context. When both return, resolve any new open questions by investigating the codebase.
5. Tasks. Delegate to sdd-tasks. Capture the Review Workload Forecast.
6. Human gate. Show the user the full tasks.md (phases + forecast) and ask for permission to start implementing. STOP until approved. Do not implement while any open question is unresolved. Once approved, move the Linear issue to In Progress via linear.update_issue.
7. Autonomous per-phase loop. For each phase in order:
   • Delegate the phase's tasks to sdd-apply, instructing it to follow .agents/AGENT.md (layout, DI, DTO placement, no-comments) and golang-pro (idiomatic Go, error wrapping, context, go vet/golangci-lint, -race tests).
   • Run a code review of that phase's diff (Task bugbot, or the code-review skill) that also checks compliance with .agents/AGENT.md and golang-pro, and apply all CRITICAL + WARNING(real) fixes; re-review until clean.
   • Delegate clean-comments via Task with model: "composer-2.5-fast" on the phase diff; wait, then commit.
   • Commit the phase as one work unit, then continue to the next phase.
8. Feature-wide review. After every phase is applied, run a code review over the whole feature diff (git diff origin/develop...HEAD) — including .agents/AGENT.md + golang-pro compliance — apply the fixes, then delegate clean-comments via Task with model: "composer-2.5-fast" on the full diff before ship.
9. Ship. Push the branch (git push -u origin <branch>) and open the PR targeting develop (gh pr create), with the Linear issue id in the body. Move the Linear issue to In Review (linear.update_issue). Do NOT archive or remove the worktree automatically.
10. Close out. Post a final comment on the Linear issue (linear.create_comment) summarizing the run: what was delivered, the PR link, and explicitly whether everything went as planned OR which points deviated from the issue/proposal (and why). Then STOP and ask the user:
    • Whether they want any additional changes or checks before cleanup.
    • Whether they want to archive the SDD change and remove the worktree. Only if the user confirms archive/cleanup, delegate to sdd-archive to move the change folder into openspec/changes/archive/ and merge the delta specs into the main specs, then remove the worktree:

    git worktree remove ../<repo>-<change-name>
    

Output Contract

Report to the user:

• change-name, branch, and worktree path created.
• Linear issue id and the status transitions applied (In Progress → In Review).
• Per phase: tasks applied, review verdict, fixes applied.
• Feature-wide review verdict and final fixes.
• The PR URL and a copy of the final Linear comment (outcome + any deviations).
• The final user decision: any additional changes/checks requested, and whether sdd-archive ran and the worktree was removed.

References

• .agents/AGENT.md — repo conventions, no-comments policy, branch/PR rules. Binding for every Go-touching phase.
• ~/.cursor/skills/clean-comments/SKILL.md — strip comments after each apply phase; always delegate on composer-2.5-fast.
• ~/.agents/skills/golang-pro/SKILL.md — idiomatic Go standards (concurrency, error wrapping, context, lint/vet/race). Binding for design, apply, and review.
• ~/.cursor/skills/sdd-*/SKILL.md — the delegated phase sub-agents, including sdd-archive when the user confirms final cleanup.
• ~/.cursor/skills/code-review/SKILL.md — per-phase and feature-wide review axes.
• ~/.cursor/skills/sdd-linear-sync/SKILL.md — optional Linear mirroring of tasks.