git:20260827.92dbe37 to git:20260827.2138bd9

39 added, 138 removed. Audit A to A.

---

name: startcycle

- description: Use when running the autonomous multi-agent build pipeline after /bdbrainstorm or /grill-me. A dispatcher reads production_artifacts/state.json and invokes Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, and Shipping in turn per .agents/graph.md's edge table — the agents never invoke each other.

+ description: Use when running the autonomous multi-agent build pipeline after /bdbrainstorm or /grill-me. Routes to the startcycle-dispatch Dynamic Workflow, which reads production_artifacts/state.json and invokes Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, and Shipping in turn per .agents/graph.md's edge table — the agents never invoke each other.

category: bdb-core

disable-model-invocation: true

---

# 🚀 BDB Autonomous Development Cycle (`/startcycle`)

- The `/startcycle` workflow is the autonomous, multi-agent execution pipeline of the BDB ecosystem. It translates high-level specifications and brainstorming results into fully implemented, tested, documented, and production-ready code without manual prompt-chaining.

- ```

- ┌──────────────────────────────────────────────┐

- │ 1. BRAINSTORM & SPECIFICATION │

- │ (/bdbrainstorm / /grill-me) │

- └──────────────────────┬───────────────────────┘

- │

- ▼

- ┌──────────────────────────────────────────────┐

- │ 2. AUTONOMOUS CYCLE (/startcycle) │

- │ • Task Decomposition & Architecture │

- │ • Parallel Frontend/Backend/Media Streams │

- │ • Verification & Quality Gate │

- └──────────────────────┬───────────────────────┘

- │

- ┌────────────────┴────────────────┐

- ▼ ▼

- ┌───────────────────────────────┐ ┌──────────────────────────────┐

- │ 3a. OPENWIKI (.openwiki/) │ │ 3b. MEMB VECTOR & VAULT │

- │ • quickstart.md │ │ • SQLite Vector Embeddings│

- │ • architecture.md │ │ • AI-Vault: God_Mode.md │

- │ • release_notes.md │ │ • Triggered via ingest.py │

- └──────────────┬────────────────┘ └──────────────┬────────────────┘

- │ │

- └────────────────┬────────────────┘

- │

- ▼

- ┌─────────────────────────────────────────────┐

- │ 4. PERSISTENT AGENT MEMORY & RETRIEVAL │

- │ • AGENTS.md / CLAUDE.md ──▶ .openwiki │

- │ • search_memory Tool ──▶ memB │

- └──────────────────────────────────────────────┘

- ```

- ---

- ## 📋 Dispatcher-Mediated Graph (v2)

- **This replaces the old linear 4-phase description below the diagram above.**

- The full contract — state schema, node table, edge predicates, the Stop-hook

- loop-keeper — lives in [`.agents/graph.md`](../../../.agents/graph.md) and

- [`.agents/state.schema.json`](../../../.agents/state.schema.json); this

- section is a summary, not the source of truth.

- **The dispatcher is runnable, not just specified:**

- [`.claude/workflows/startcycle.mjs`](../../../.claude/workflows/startcycle.mjs)

- implements the loop below as an actual Dynamic Workflow script — running

- `/startcycle` on Claude Code executes it. It reads the goal, drives the

- Architect/TechLead approval loop, fans the build nodes out in parallel, runs

- Reviewer's repair loop with a no-progress guard, and stops at `ready_to_ship`

- for a human `GO` rather than shipping on its own. Other harnesses without an

- equivalent "workflow" primitive fall back to this file and `.agents/graph.md`

- as a manual dispatch guide.

- **The one rule:** these seven agents never invoke each other. A dispatcher —

- the main session running `/startcycle`, or whatever plays that role in a

- given harness — reads `production_artifacts/state.json` after each agent

- returns and decides which one runs next. The old version of this skill

- described "streams" and "hand-offs" in a way that read as agents calling

- agents; that framing is corrected (see `audit-agents.md` F-17).

- |---|---|---|---|

- **Repair loop (the gap the old version of this skill flagged as a Red Flag,

- now closed):** if TechLead rejects the plan, Reviewer has an open blocking

- finding, or Shipping's gate fails, the dispatcher increments

- `state.iteration` and re-invokes the owning node — it does not just stop. A

- `Stop` hook (`.claude/hooks/graph-gate.mjs`) enforces this deterministically:

- it blocks the turn from ending while the gate is failing and

- `iteration < max_iterations` (default 3). Once the ceiling is hit, the

- dispatcher sets `phase: escalated` and hands control back to the user instead

- of looping forever.

- **No-progress guard:** if a repair round reports the exact same blocking

- finding ID(s) Reviewer already flagged before the build node was re-invoked

- to fix them, the dispatcher escalates immediately instead of repeating an

- identical cycle. (This replaced an earlier "two clean cycles" framing that

- turned out to have no reachable trigger once the dispatcher became a real

- script — see `.agents/graph.md`'s Reviewer discipline for the full story.)

- **`/ship` (after `state.phase: done`):**

- 1. **Wiki Sync (`openwiki-skill`)**: scans the git diff, updates `.openwiki/architecture.md`, `.openwiki/release_notes.md`, and root `README.md`.

- 2. **memB Memory Ingestion (`memb-ingest`)**: ingests new documentation, schemas, and patterns into local vector memory (`~/.MemBDB/`).

- 3. **Git Release**: atomic commit, version tag, push to the private remote — gated by `go-gate.mjs` like any other push in this repo.

- ---

- ## 🛠️ Slash Command Invocation

- To trigger the autonomous cycle in any supported agent harness (Antigravity, Roo Code, Claude Code, Cursor, Codex):

- ```bash

- /startcycle

- ```

- Or pass a specific focus area:

- ```bash

- /startcycle frontend

- /startcycle fullstack

- /startcycle mediastorm

- ```

+ **Action — do this, and nothing else:** call the `Workflow` tool with

+ `name: "startcycle-dispatch"` and `args` set to the goal text that follows

+ `ARGUMENTS:` below this file's content. Pass it through verbatim. If there is

+ no `ARGUMENTS:` text, pass no `args` (or `args: undefined`) — the workflow

+ itself asks for a goal in that case rather than guessing one.

- ## 1. Overview

- This skill provides domain-specific logic and rules for its respective BDB pipeline component to ensure standardization across multi-agent workflows.

+ Then wait for the `Workflow` tool call to finish and report its result

+ (including `phase`, any `reason`, and — at `ready_to_ship` — the instruction

+ to reply `GO`) back to the user. Do not summarize or reinterpret it; relay it.

- ## 2. When to Use

- - Use when specifically requested by the user or triggered by an orchestration agent.

- - Use when the current task aligns with the skill's domain.

- - Exclude when standard tool execution is sufficient.

+ **Do NOT decompose the task, write anything under `production_artifacts/`, or

+ implement any part of the goal yourself in response to this skill.** This

+ file exists only to route the `/startcycle` slash command to the real

+ dispatcher — a Dynamic Workflow script

+ (`.claude/workflows/startcycle-dispatch.mjs`) that holds the actual

+ node/edge graph, spawns the seven agents, and drives the repair loop. If you

+ catch yourself about to write a plan file or code directly because of this

+ skill, stop — that means the `Workflow` tool call was skipped, which is

+ exactly the failure this file was rewritten to close (see

+ `SESSION-HANDOVER-v3.13.md` in the source repo for the incident: an earlier

+ version of this file embedded the full pipeline description in prose, and

+ the model followed it "in spirit" inline instead of invoking the script —

+ silently skipping the whole graph, with no `state.json`, no subagents, no

+ Reviewer, and no quality gate ever running).

- ## 3. Core Process

- 1. Read the provided context and ensure preconditions are met.

- 2. Run the required script or tool and confirm the state change.

- 3. Verify exit codes, file modifications, or DB counts to guarantee success before reporting completion.

+ ## Why this file is a thin router, not a spec

- ## 4. Common Rationalizations

- | Rationalization | Reality |

- |---|---|

- | "The code change was small, so I skipped updating OpenWiki docs." | Every state change must be reflected in the relevant system records. |

- | "The ingest script exited without an error, so the memB index must be updated." | Silent failures happen; explicit verification of the side effect is mandatory. |

- | "I'll let the /startcycle proceed without a defined rollback path." | Proceeding without a rollback path corrupts the workflow integrity and safety. |

- | "I trust the cached agent registry instead of rescanning after a skill change." | Caches stale out quickly; explicit rescans prevent ghost failures. |

+ The full contract — state schema, node/edge table, the Stop-hook

+ loop-keeper, the no-progress guard — lives in

+ [`.agents/graph.md`](../../../.agents/graph.md) and

+ [`.agents/state.schema.json`](../../../.agents/state.schema.json). Those are

+ read by the dispatcher script itself and by the agents it invokes, not

+ duplicated here — so there is nothing here to follow "in spirit" instead of

+ actually running.

- ## 5. Red Flags

- - Bypassing the verification step after a script execution.

- - Proceeding to the next pipeline stage without confirming the previous stage's side effects.

- - Ignoring domain-specific constraints listed in this skill.

- - One agent's prompt or output directly instructing another agent to act ("hand off to Engineering now") instead of the dispatcher reading `state.json` and deciding the next invocation itself — this is the node-to-node hand-off pattern `.agents/graph.md` explicitly rules out (F-17).

- - A repair cycle running again with the exact same finding IDs as the last one, instead of escalating per the no-progress guard.

+ ## If the `Workflow` tool is unavailable

- ## 6. Verification

- - [ ] Verified script exit codes are explicitly checked.

- - [ ] Confirmed target files or database records reflect the expected change.

- - [ ] Ensured no silent failures were ignored before reporting success.

+ Some harnesses (or Claude Code with Dynamic Workflows toggled off in

+ `/config`) have no `Workflow` tool at all. Only in that case, fall back to

+ manually driving `.agents/graph.md`'s node/edge table yourself as the

+ dispatcher: read `production_artifacts/state.json`, decide the next node

+ per the edge predicates, invoke exactly that one agent, and repeat. Never

+ let one agent's output instruct another agent directly — that hand-off

+ pattern is the thing `.agents/graph.md` (F-17) rules out.