agent-pipeline · diff
git:20260827.e9312a3 to git:20260827.ebd5ea3
32 added, 1 removed. Audit A to A.
---
name: agent-pipeline
- description: Defines the 6-stage BDB Software Engineering Pipeline (DEFINE, PLAN, BUILD, VERIFY, REVIEW, SHIP) with corresponding slash commands (/spec, /plan, /build, /test, /review, /ship) and autonomous orchestrator /startcycle.
+ description: Use when defines the 6-stage BDB Software Engineering Pipeline (DEFINE, PLAN, BUILD, VERIFY, REVIEW, SHIP) with corresponding slash commands (/spec, /plan, /build, /test, /review, /ship) and autonomous orchestrator /startcycle.
category: bdb-core
---
# 🔄 BDB Software Engineering Pipeline
When orchestrating or executing software development, AI agents MUST follow the 6-stage lifecycle pipeline.
```
DEFINE PLAN BUILD VERIFY REVIEW SHIP
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ Idea │ ───▶ │ Spec │ ───▶ │ Code │ ───▶ │ Test │ ───▶ │ QA │ ───▶ │ Go │
│Refine│ │ PRD │ │ Impl │ │Debug │ │ Gate │ │ Live │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
/spec /plan /build /test /review /ship
└─────────────────────────────────────────────────────────────────────────────┘
🚀 Master Macro: /startcycle
```
---
## ⚡ Autonomous Orchestration: `/startcycle`
To run the entire pipeline autonomously across a multi-agent team without manual step-by-step prompts, invoke:
```bash
/startcycle
```
`/startcycle` automatically assigns:
- **Stages 1 & 2 (DEFINE + PLAN):** `Planner_Orchestrator` ➔ `production_artifacts/00_execution_plan.md`
- **Stage 3 (BUILD):** `Godmode_UI_UX`, `Godmode_Engineering`, `Godmode_Media_EventTech`
- **Stages 4 & 5 (VERIFY + REVIEW):** `Godmode_Shipping` ➔ `production_artifacts/04_release_report.md`
- **Stage 6 (SHIP):** `openwiki-skill` (wiki sync) + `memb-ingest` (vector memory)
---
## 📌 Individual Pipeline Stages & Slash Commands
### 1. DEFINE (`/spec`)
* **Focus:** Idea Refinement & Requirement Elicitation
* **Action:** Interview the user, clarify scope, define key constraints, and gather missing technical docs.
* **Output:** User Stories, Scope Boundaries, and Spec RFCs.
### 2. PLAN (`/plan`)
* **Focus:** Architectural Design & Technical Specification (PRD)
* **Action:** Generate implementation plan artifacts, draw Mermaid diagrams, define file-by-file diffs, and request user approval.
* **Output:** Approved Implementation Plan Artifact (`<plan_name>.md`).
### 3. BUILD (`/build`)
* **Focus:** Code Implementation & Refactoring
* **Action:** Execute plan steps using modular edits, adhere to clean code principles, and avoid breaking existing API contracts.
* **Output:** Functional codebase modifications & newly created components.
### 4. VERIFY (`/test`)
* **Focus:** Automated Testing & Debugging
* **Action:** Run unit test suites, lint checks, and type checkers (`pytest`, `npm test`, `cargo test`, `vitest`). Inspect runtime logs upon failure.
* **Output:** Verified test run outputs (100% green build status).
### 5. REVIEW (`/review`)
* **Focus:** QA Gate & Code Review
* **Action:** Perform architectural reviews, security scans for hardcoded secrets, UI/UX compliance audits (`godmode-ui-ux`), and code simplification passes.
* **Output:** Code review summary & QA gate approval.
### 6. SHIP (`/ship`)
* **Focus:** Production Deployment, Knowledge Sync & Release Gate
* **Action:**
1. **Pre-Push Sanitization (`github-repo`):** Audit for absolute local paths, usernames, and uncommitted secrets.
2. **Codebase Wiki Sync (`openwiki-skill`):** Scan git diff, update `.openwiki/` (`architecture.md`, `release_notes.md`, `quickstart.md`), and refresh `README.md`.
3. **Memory Engine Feeding (`memb-ingest`):** Feed updated docs and architecture into the local memB vector brain (`~/.MemBDB/`) via `memb-mcp` or `memb_ingest.py`.
4. **Release Deployment:** Take git snapshot, commit structured changes, push to private remote repository, and trigger deployment/release tags.
* **Output:** Live deployment confirmation, synced `.openwiki/` release notes, and refreshed memB long-term memory.
+
+ ## 1. Overview
+ This skill provides domain-specific logic and rules for its respective BDB pipeline component to ensure standardization across multi-agent workflows.
+
+ ## 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.
+
+ ## 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.
+
+ ## 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. |
+
+ ## 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.
+
+ ## 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.