Files
2026-03-16 19:54:53 -04:00

200 lines
12 KiB
Markdown

---
name: build-process
description: Six-phase conversational discovery process for building BMad agents. Covers intent discovery, capabilities strategy, requirements gathering, drafting, building, and summary.
---
**Language:** Use `{communication_language}` for all output.
# Build Process
Build AI agents through six phases of conversational discovery. Act as an architect guide — probe deeper than what users articulate, suggest what they haven't considered, and build something that exceeds what they imagined.
## Phase 1: Discover Intent
Understand their vision before diving into specifics. Ask what they want to build and encourage detail.
If editing/converting an existing agent: read it, analyze what exists vs what's missing, understand what needs changing and specifically ensure it conforms to our standard with building new agents upon completion.
## Phase 2: Capabilities Strategy
Early check: internal capabilities only, external skills, both, or unclear?
**If external skills involved:** Suggest `bmad-module-builder` to bundle agents + skills into a cohesive module. Modules are the heart of the BMad ecosystem — shareable packages for any domain.
**Script Opportunity Discovery** (active probing — do not skip):
Walk through each planned capability with the user and apply these filters:
1. "Does this operation have clear pass/fail criteria?" → Script candidate
2. "Could this run without LLM judgment — no interpretation, no creativity, no ambiguity?" → Strong script candidate
3. "Does it validate, transform, count, parse, format-convert, compare against a schema, or check structure?" → Almost certainly a script
**Common script-worthy operations:**
- Schema/format validation (JSON, YAML, frontmatter, file structure)
- Data extraction and transformation (parsing, restructuring, field mapping)
- Counting, aggregation, and metric collection (token counts, file counts, summary stats)
- File/directory structure checks (existence, naming conventions, required files)
- Pattern matching against known standards (path conventions, naming rules)
- Comparison operations (diff, version compare, before/after, cross-reference checking)
- Dependency graphing (parsing imports, references, manifest entries)
- Memory structure validation (required sections, path correctness)
- Access boundary extraction and verification
- Pre-processing for LLM capabilities (extract compact metrics from large files so the LLM works from structured data, not raw content)
- Post-processing validation (verify LLM output conforms to expected schema/structure)
**Present your script plan**: Before moving to Phase 3, explicitly tell the user which operations you plan to implement as scripts vs. prompts, with one-line reasoning for each. Ask if they agree or want to adjust.
If scripts are planned, the `scripts/` folder will be created. Scripts are invoked from prompts when needed, not run automatically.
## Phase 3: Gather Requirements
Work through these conversationally:
- **Name:** Functional (kebab-case), display name, title, icon
- **Overview:** Draft a 2-3 sentence overview following the 3-part formula:
- **What** — What this agent does
- **How** — Role, approach, or key capabilities
- **Why/Outcome** — Value delivered or quality standard
- *Example:* "This skill provides a {role} who helps users {outcome}. Act as {name} — {key quality}."
- **Identity:** Who is this agent? How do they communicate? What guides their decisions?
- **Module context:** Standalone (`bmad-agent-{name}`) or part of a module (`bmad-{modulecode}-agent-{name}`)
- **Activation modes:**
- **Interactive only** — User invokes the agent directly
- **Interactive + Autonomous** — Also runs on schedule/cron for background tasks
- **Memory & Persistence:**
- **Sidecar needed?** — What persists across sessions?
- **Critical data** (must persist immediately): What data is essential to capture the moment it's created?
- **Checkpoint data** (save periodically): What can be batched and saved occasionally?
- **Save triggers:** After which interactions should memory be updated?
- **Capabilities:**
- **Internal prompts:** Capabilities the agent knows itself (each will get its own prompt file)
- **External skills:** Skills the agent invokes (ask for **exact registered skill names** — e.g., `bmad-init`, `skill-creator`)
- Note: Skills may exist now or be created later
- **First-run:** What should it ask on first activation? (standalone only; module-based gets config from module's config.yaml)
**If autonomous mode is enabled, ask additional questions:**
- **Autonomous tasks:** What should the agent do when waking on a schedule?
- Examples: Review/organize memory, process queue, maintenance tasks, implement tickets
- **Default wake behavior:** What happens with `--headless` | `-H` (no specific task)?
- **Named tasks:** What specific tasks can be invoked with `--headless:{task-name}` or `-H:{task-name}`?
- **Folder Dominion / Access Boundaries:**
- **What folders can this agent read from?** (e.g., `journals/`, `financials/`, specific file patterns)
- **What folders can this agent write to?** (e.g., output folders, log locations)
- **Are there any explicit deny zones?** (folders the agent must never touch)
- Store these boundaries in memory as the standard `access-boundaries` section (see memory-system template)
**Key distinction:** Folder dominion (where things live) ≠ agent memory (what persists across sessions)
- **Path Conventions** (CRITICAL for reliable agent behavior):
- **Memory location:** `{project-root}/_bmad/_memory/{skillName}-sidecar/`
- **Project artifacts:** `{project-root}/_bmad/...` when referencing project-level files
- **Skill-internal files:** Use relative paths (`references/`, `scripts/`)
- **Config variables:** Use directly — they already contain full paths (NO `{project-root}` prefix)
- Correct: `{output_folder}/file.md`
- Wrong: `{project-root}/{output_folder}/file.md` (double-prefix breaks resolution)
- **No absolute paths** (`/Users/...`) or relative prefixes (`./`, `../`)
## Phase 4: Draft & Refine
Once you have a cohesive idea, think one level deeper. Once you have done this, present a draft outline. Point out vague areas. Ask what else is needed. Iterate until they say they're ready.
## Phase 5: Build
**Always load these before building:**
- Load `references/standard-fields.md` — field definitions, description format, path rules
- Load `references/skill-best-practices.md` — authoring patterns (freedom levels, templates, anti-patterns)
- Load `references/quality-dimensions.md` — quick mental checklist for build quality
**Load based on context:**
- **If module-based:** Load `references/metadata-reference.md` — manifest.json field definitions, module metadata structure, config loading requirements
- **Always load** `references/script-opportunities-reference.md` — script opportunity spotting guide, catalog, and output standards. Use this to identify additional script opportunities not caught in Phase 2, even if no scripts were initially planned.
When confirmed:
1. Load template substitution rules from `references/template-substitution-rules.md` and apply
2. Create skill structure using templates from `assets/` folder:
- **SKILL-template.md** — skill wrapper with full persona content embedded
- **init-template.md** — first-run setup (if sidecar)
- **memory-system.md** — memory (if sidecar, saved at root level)
- **autonomous-wake.md** — autonomous activation behavior (if activation_modes includes "autonomous")
- **save-memory.md** — explicit memory save capability (if sidecar enabled)
3. **Generate bmad-manifest.json** — Use `scripts/manifest.py` (validation is automatic on every write). **IMPORTANT:** The generated manifest must NOT include a `$schema` field — the schema is used for validation tooling only and is not part of the delivered skill.
```bash
# Create manifest with agent identity
python3 scripts/manifest.py create {skill-path} \
--persona "Succinct distillation of who this agent is" \
--module-code {code} # if part of a module \
--has-memory # if sidecar needed
# Add each capability
# NOTE: capability description must be VERY short — what it produces, not how it works
python3 scripts/manifest.py add-capability {skill-path} \
--name {name} --menu-code {MC} --description "Short: what it produces." \
--supports-autonomous \
--prompt {name}.md # internal capability
# OR --skill-name {skill} # external skill
# omit both if SKILL.md handles it directly
# Module capabilities need sequencing metadata (confirm with user):
# - phase-name: which module phase (e.g., "1-analysis", "2-design", "anytime")
# - after: array of skill names that should run before this (inputs/dependencies)
# - before: array of skill names this should run before (downstream consumers)
# - is-required: if true, skills in 'before' are blocked until this completes
# - description: VERY short — what it produces, not how it works
python3 scripts/manifest.py add-capability {skill-path} \
--name {name} --menu-code {MC} --description "Short: what it produces." \
--phase-name anytime \
--after skill-a skill-b \
--before skill-c \
--is-required
```
4. **Folder structure:**
```
{skill-name}/
├── SKILL.md # Contains full persona content (agent.md embedded)
├── bmad-manifest.json # Capabilities, persona, memory, module integration
├── init.md # First-run setup (if sidecar)
├── autonomous-wake.md # Autonomous activation (if autonomous mode)
├── save-memory.md # Explicit memory save (if sidecar)
├── {name}.md # Each internal capability prompt
├── references/ # Reference data, schemas, guides (read for context)
│ └── memory-system.md # (if sidecar needed)
├── assets/ # Templates, starter files (copied/transformed into output)
└── scripts/ # Deterministic code — validation, transformation, testing
└── run-tests.sh # uvx-powered test runner (if python tests exist)
```
**What goes where:**
| Location | Contains | LLM relationship |
|----------|----------|-----------------|
| **Root `.md` files** | Prompt/instruction files, subagent definitions | LLM **loads and executes** these as instructions — they are extensions of SKILL.md |
| **`references/`** | Reference data, schemas, tables, examples, guides | LLM **reads for context** — informational, not executable |
| **`assets/`** | Templates, starter files, boilerplate | LLM **copies/transforms** these into output — not for reasoning |
| **`scripts/`** | Python, shell scripts with tests | LLM **invokes** these — deterministic operations that don't need judgment |
Only create subfolders that are needed — most skills won't need all four.
5. Output to `bmad_builder_output_folder` from config, or `{project-root}/bmad-builder-creations/`
6. **Lint gate** — run deterministic validation scripts:
```bash
python3 scripts/scan-path-standards.py {skill-path}
python3 scripts/scan-scripts.py {skill-path}
```
- If any script returns critical issues: fix them before proceeding
- If only warnings/medium: note them but proceed
## Phase 6: Summary
Present what was built: location, structure, first-run behavior, capabilities. Ask if adjustments needed.
**After the build completes, offer quality optimization:**
Ask: *"Build is done. Would you like to run a Quality Scan to optimize the agent further?"*
If yes, load `quality-optimizer.md` with `{scan_mode}=full` and the agent path.
Remind them: BMad module system compliant. Use `bmad-init` skill to integrate into a project.