orbit

Files (1)

• SKILL.md

SKILL.md (first lines)

# /orbit — Complete Orbit

**CRITICAL**: Run `HARNESS_DIR=$(epic path)` first. NEVER use `.harness/` in the project directory.

You are entering **Orbit** mode — the full autonomous pipeline from spec to PR in one shot.

## Phase Recovery Protocol

At the start of **every response** during an active orbit:

1. Run `ls $HARNESS_DIR/orbit/PIPELINE-*.json 2>/dev/null`
2. Find the file with `"status": "running"`
3. Read it. Verify `phase` matches where you left off
4. **If `phase` is ahead of where you think you are, trust the file** — you may have compacted
5. **Conflict resolution (crash-mid-update)**: If `phase_history` contains an entry for the current `phase` with a completed timestamp, treat that phase as done and advance to the next phase — `phase_history` wins over the `phase` field when they disagree.
6. Resume from the resolved phase. Do NOT re-ask mode selection, re-run spec, or re-discover
7. **Worktree recovery**: If `worktree_name` is set in pipeline state:
   - Check if worktree still exists: `git worktree list | grep "{worktree_name}"`
   - If exists: `cd` into the worktree path to continue work
   - If not found: worktree was cleaned up externally — abort orbit with warning, set `"status": "aborted"`

If no file with `"status": "running"` exists, orbit was not started or has completed. Do not invent one.

**Crash recovery**: If `updated_at` is older than 45 minutes and the pipeline is in `status: running`, assume a crash occurred. Read the state, determine the last completed phase from `phase_history` (rule 5 above applies), and resume from there. Report the recovery to the user.

## Step 0: Preflight

**Concurrent-orbit guard** — before starting, run:

```bash
epic orbit lock   # exit 1 + "another orbit is running" if one is active → STOP
```

On success you own the guard; run `epic orbit unlock` when the pipeline reaches
a terminal state (complete/aborted). If a crashed orbit left the lock behind,
`lock` reclaims it automatically once no PIPELINE-*.json is `running`.

Initialize pipeline state at `$HARNESS_DIR/orbit/PIPELINE-{timestamp}.json`:
```json
{
  "id": "{timestamp}",
  "mode": null,
  "phase": "auto_detect",
  "status": "running",
  "spec_file": null,
  "goal_slug": null,
  "branch": null,
  "worktree_name": null,
  "original_cwd": null,
  "audit_fail_count": 0,
  "max_retries": 3,
  "audit_report": null,
  "pr_url": null,
  "deadline": "{ISO-8601, now + 30 minutes}",
  "started_at": "{ISO-8601}",
  "updated_at": "{ISO-8601}",
  "phase_history": []
}
```

## Step 1: Auto-Detect Mode

**DO NOT ask the user for mode selection.** Auto-detect the best path:

### Detection Logic

| Signal | Mode | Reason |
|--------|------|--------|
| PRD / detailed requirements doc exists in project | `council` | Rich input → council synthesizes best approach |
| User request is specific and actionable (clear goal, defined scope) | `direct` | No need for discovery — spec directly |
| User request is vague, unfocused, or "I want to..." without specifics | `council` | Council frames the problem better than guessing |
| User explicitly says "interactive" or "let me discover first" | `interactive` | Respect explicit preference |

### Detection Process

1. Check for PRD/requirements docs: `ls {project}/PRD*.md {project}/docs/PRD*.md {project}/requirements*.md 2>/dev/null`
2. Evaluate user request clarity:
   - **Specific**: contains concrete feature descriptions, acceptance criteria, or technical constraints → `direct`
   - **Vague**: "build X", "improve Y", "add Z" without details → `council`
3. Record detected mode in pipeline state (`"mode": "direct|council|interactive"`)
4. Report mode choice to user as a **notification**, not a question: `"Orbit mode: {mode} (auto-detected)"`
5. Proceed immediately to the matching step below — **do not wait for confirmation**

## Step 2A: Direct Mode (clear request → auto-spec)

**Use when**: Request is specific and actionable.

1. Read the user's request + any existing docs (PRD, README, AGENTS.md)
2. Generate spec directly at `$HARNESS_DIR/specs/SPEC-{timestamp}.md` with `status: approved`
3. Record via `epic mem add --title "Orbit: {mode} mode decision" --type decision --importance 0.9 --body "CONTEXT"`
4. **Proceed immediately to Step 3** — no approval gate

## Step 2B: Council Auto-Spec (complex/vague request → council)

**Use when**: PRD exists or request needs framing.

1. Gather the user's request from conversation context
2. Launch 4 parallel sub-agents (Architect, Skeptic, Pragmatist, Critic) — each receives ONLY the request + codebase context, NOT the full conversation (anti-anchoring)
3. Synthesize: list agreement/disagreement, produce recommended approach
4. Generate spec at `$HARNESS_DIR/specs/SPEC-{timestamp}.md` with `status: approved`
5. Record via `epic mem add --title "Orbit: council decision" --type decision --importance 0.9 --body "CONTEXT"`
6. **Proceed immediately to Step 3** — no approval gate, no "orbit go"

## Step 2C: Interactive Mode (explicit user choice only)

**Use when**: User explicitly requested interactive mode.

1. Tell user to run `/discover` → `/spec`, then say "orbit go". STOP and wait.
2. On resume: load latest `SPEC-*.md` with `status: approved`. Proceed to Step 3.

**This mode is never auto-selected.** It requires explicit user opt-in.

## Step 3: Build (Go)

1. Load spec, extract `goal_slug`
2. **Git preflight**: verify clean working tree and not on detached HEAD:
   ```bash
   [ -z "$(git status --porcelain)" ] || (echo "ERROR: Dirty working tree or untracked files. Commit or stash first." && exit 1)
   git symbolic-ref -q HEAD || (echo "ERROR: Detached HEAD. Checkout a branch first." && exit 1)

From epicsagas/epic-harness, Apache-2.0.

More from epicsagas/epic-harness