Startcycle

/startcycle — Linear Build Pipeline

A straight-line run through the BDB agent roster. Whoever invokes this skill invokes each step in turn, in order, and every hand-off between steps is a file written under production_artifacts/. Nothing else is shared between steps — no memory, no live conversation state, no orchestrator process watching over the run.

                  ┌──────────────────────────────────────────────┐
                  │ 0. BRAINSTORM & SPECIFICATION                │
                  │    (/bdbrainstorm / /grill-me)               │
                  └──────────────────────┬───────────────────────┘
                                         │
                                         ▼
                  ┌──────────────────────────────────────────────┐
                  │ 1. ARCHITECT                                  │
                  │    goal ──▶ 00_execution_plan.md              │
                  └──────────────────────┬───────────────────────┘
                                         ▼
                  ┌──────────────────────────────────────────────┐
                  │ 2. TECHLEAD                                   │
                  │    approve plan, or send back to Architect    │
                  │    (once)                                     │
                  └──────────────────────┬───────────────────────┘
                                         ▼
              ┌──────────────────────────┴──────────────────────────┐
              ▼                          ▼                          ▼
  ┌───────────────────┐   ┌───────────────────────┐   ┌───────────────────────┐
  │ 3a. UI/UX          │   │ 3b. ENGINEERING        │   │ 3c. MEDIA/EVENTTECH    │
  │ 01_frontend_spec.md│   │ 02_backend_schema.md   │   │ 03_media_pipeline.md   │
  │ frontend/src/       │   │ backend/src/           │   │ (only if goal needs it)│
  └──────────┬──────────┘   └───────────┬────────────┘   └───────────┬────────────┘
              └──────────────────────────┴──────────────────────────┘
                                         ▼
                  ┌──────────────────────────────────────────────┐
                  │ 4. REVIEWER                                   │
                  │    adversarial pass ──▶ review_findings.md    │
                  └──────────────────────┬───────────────────────┘
                                         ▼
                              ── pipeline ends here by default ──
                                         │
                                (only if release requested)
                                         ▼
                  ┌──────────────────────────────────────────────┐
                  │ 5. SHIPPING (optional)                        │
                  │    quality gate ──▶ 04_release_report.md      │
                  └──────────────────────────────────────────────┘

Steps

1. Architect

• Agent: architect
• Reads: the goal (or /bdbrainstorm / /grill-me output), existing architecture.
• Action: turns the goal into a system plan with an explicit capability map — module boundaries, dependency direction, what streams the goal actually touches.
• Writes: production_artifacts/00_execution_plan.md

2. TechLead

• Agent: techlead
• Reads: 00_execution_plan.md.
• Action: reviews the plan for module boundaries, dependency direction, and build order. Approves it, or sends it back to Architect once for a revision. This is a gate, not a deliverable — TechLead does not invoke Architect itself; the invoker re-runs step 1 if TechLead rejects.
• Writes: no separate file; approval is just the invoker's own record of the gate having passed.

Optional — Plan Canvas. Before or alongside TechLead's gate, the plan can be reviewed in the browser: aos-plan-canvas open production_artifacts/00_execution_plan.md, then aos-plan-canvas await …. An approve verdict is a human confirmation of the gate. This is optional; the pipeline runs unchanged without it. See the plan-canvas skill.

3. Build (parallel, stream-selective)

Run only the streams the goal actually needs. A plain backend feature does not need step 3a or 3c; a pure copy change does not need 3b. Each stream's skills: frontmatter already lists what it should reach for — the invoker passes that list through rather than restating it here.

3c is for TouchDesigner, show-control, DMX/grandMA3, 3D, or other media-pipeline goals — most goals are not this. Skip it unless the plan actually calls for it.

Injecting a specific skill. /startcycle --skill=<name> <goal> (repeatable, quote a name with spaces) forces that skill into this run as a hard requirement — for a private skill of your own that isn't part of any build agent's own skills: frontmatter. Since this variant has no dispatcher script or state.json to carry it automatically, the invoker does the work startcycle-graph's script does for you: extract the --skill= flag(s) from the invocation text before anything else runs, confirm each name resolves to a real SKILL.md (under any harness's global skills directory — ~/.claude/skills/<name>/, ~/.agents/skills/, ~/.codex/skills/, ~/.cursor/skills/ or ~/.roo/skills/ — or this project's own skills/ tree) — stop and tell the user if one doesn't, don't silently proceed without it — note the validated list in 00_execution_plan.md, and include it as a hard requirement, not a suggestion in each Build stream's dispatch prompt at step 3. Reviewer (step 4) checks the resulting artifacts for evidence the skill was actually applied, not just available, and treats an ignored mandate as a contract-misread finding. See .agents/graph.md's "Mandatory Skill Injection" section for the full rationale — this is the same mechanic, just invoker-driven instead of script-driven.

4. Reviewer

• Agent: reviewer
• Reads: the artifacts each build stream produced (01/02/03) and the plan's stated contract (00_execution_plan.md) — nothing else. Never the goal directly, never a build agent's own claim that it's done; passing that claim through biases the review toward agreement.
• Action: adversarial pass — "find what is wrong," never "does this look good." Every finding is classified by fixed precedence:
  1. contract misread
  2. valid & actionable (blocking)
  3. valid trade-off (advisory)
  4. noise
• Writes: production_artifacts/review_findings.md

The linear pipeline ends here by default. A plain build or refactor goal is done at step 4 — it does not automatically drag a quality gate and release report behind it.

5. Shipping — optional, not a hard-wired terminal step

• Agent: godmode-shipping
• Runs only when: the user explicitly asks for it, or the original goal was itself a release.
• Action: lint, typecheck, tests, a11y, SEO — the mechanical quality gate, deliberately separate from Reviewer's adversarial correctness pass.
• Writes: production_artifacts/04_release_report.md

If the invoker isn't sure whether shipping applies, treat step 4 as the finish line and ask before running step 5.

Explicit non-goals

This skill deliberately does not have:

• production_artifacts/state.json or .agents/state.schema.json
• .agents/graph.md bootstrap
• a dispatcher script or Workflow tool call
• a repair loop, an iteration counter, a no-progress guard, or escalation machinery
• agents invoking each other — whoever runs the skill invokes each step in turn; no agent hands off directly to the next

If a run needs any of the above, it needs startcycle-graph, not this skill.

Which startcycle do I want?

Safety

git push, npm publish, and npm version are blocked by .claude/hooks/go-gate.mjs unless the user's immediately preceding message is the literal word GO. This skill never pushes on its own — Shipping (step 5) prepares the release report; the invoker still needs a fresh GO before anything leaves the machine.