Compare commits
9 Commits
6bbbd915e6
...
cb6dbe3384
| Author | SHA1 | Date |
|---|---|---|
|
|
cb6dbe3384 | |
|
|
0a7329ff23 | |
|
|
7afe018f82 | |
|
|
8c59fb96a7 | |
|
|
7fcfd4c1b8 | |
|
|
53220420a5 | |
|
|
9c0314732e | |
|
|
542a7429ec | |
|
|
6143754b13 |
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
name: 'generate-project-context'
|
||||
description: 'Scan existing codebase to generate a lean LLM-optimized project-context.md with critical implementation rules and patterns for AI agents'
|
||||
---
|
||||
|
||||
IT IS CRITICAL THAT YOU FOLLOW THESE STEPS - while staying in character as the current agent persona you may have loaded:
|
||||
|
||||
<steps CRITICAL="TRUE">
|
||||
1. Always LOAD the FULL @{project-root}/_bmad/core/tasks/workflow.xml
|
||||
2. READ its entire contents - this is the CORE OS for EXECUTING the specific workflow-config @{project-root}/_bmad/bmm/workflows/generate-project-context/workflow.md
|
||||
3. Pass the yaml path @{project-root}/_bmad/bmm/workflows/generate-project-context/workflow.md as 'workflow-config' parameter to the workflow.xml instructions
|
||||
4. Follow workflow.xml instructions EXACTLY as written to process and follow the specific workflow config and its instructions
|
||||
5. Save outputs after EACH section when generating any documents from templates
|
||||
</steps>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 126 KiB |
|
|
@ -0,0 +1,374 @@
|
|||
---
|
||||
title: "Game Types Reference"
|
||||
---
|
||||
|
||||
BMGD supports 24 game type templates. Each adds genre-specific sections to your GDD.
|
||||
|
||||
## Game Types
|
||||
|
||||
### Action & Combat
|
||||
|
||||
#### Action Platformer
|
||||
|
||||
Side-scrolling or 3D platforming with combat mechanics.
|
||||
|
||||
**Examples:** Hollow Knight, Mega Man, Celeste
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Movement systems (jumps, dashes, wall mechanics)
|
||||
- Combat mechanics (melee/ranged, combos)
|
||||
- Level design patterns
|
||||
- Boss design
|
||||
|
||||
#### Shooter
|
||||
|
||||
Projectile combat with aiming mechanics.
|
||||
|
||||
**Examples:** Doom, Call of Duty, Splatoon
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Weapon systems
|
||||
- Aiming and accuracy
|
||||
- Enemy AI patterns
|
||||
- Level/arena design
|
||||
- Multiplayer considerations
|
||||
|
||||
#### Fighting
|
||||
|
||||
1v1 combat with combos and frame data.
|
||||
|
||||
**Examples:** Street Fighter, Tekken, Super Smash Bros.
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Frame data systems
|
||||
- Combo mechanics
|
||||
- Character movesets
|
||||
- Competitive balance
|
||||
- Netcode requirements
|
||||
|
||||
### Strategy & Tactics
|
||||
|
||||
#### Strategy
|
||||
|
||||
Resource management with tactical decisions.
|
||||
|
||||
**Examples:** StarCraft, Civilization, Europa Universalis
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Resource systems
|
||||
- Unit/building design
|
||||
- AI opponent behavior
|
||||
- Map/scenario design
|
||||
- Victory conditions
|
||||
|
||||
#### Turn-Based Tactics
|
||||
|
||||
Grid-based movement with turn order.
|
||||
|
||||
**Examples:** XCOM, Fire Emblem, Into the Breach
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Grid and movement systems
|
||||
- Turn order mechanics
|
||||
- Cover and positioning
|
||||
- Unit progression
|
||||
- Procedural mission generation
|
||||
|
||||
#### Tower Defense
|
||||
|
||||
Wave-based defense with tower placement.
|
||||
|
||||
**Examples:** Bloons TD, Kingdom Rush, Plants vs. Zombies
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Tower types and upgrades
|
||||
- Wave design and pacing
|
||||
- Economy systems
|
||||
- Map design patterns
|
||||
- Meta-progression
|
||||
|
||||
### RPG & Progression
|
||||
|
||||
#### RPG
|
||||
|
||||
Character progression with stats, inventory, and quests.
|
||||
|
||||
**Examples:** Final Fantasy, The Witcher, Baldur's Gate
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Character stats and leveling
|
||||
- Inventory and equipment
|
||||
- Quest system design
|
||||
- Combat system (action/turn-based)
|
||||
- Skill trees and builds
|
||||
|
||||
#### Roguelike
|
||||
|
||||
Procedural generation with permadeath and run-based progression.
|
||||
|
||||
**Examples:** Hades, Dead Cells, Spelunky
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Procedural generation rules
|
||||
- Permadeath and persistence
|
||||
- Run structure and pacing
|
||||
- Item/ability synergies
|
||||
- Meta-progression systems
|
||||
|
||||
#### Metroidvania
|
||||
|
||||
Interconnected world with ability gating.
|
||||
|
||||
**Examples:** Metroid, Castlevania: Symphony of the Night, Ori
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- World map connectivity
|
||||
- Ability gating design
|
||||
- Backtracking flow
|
||||
- Secret and collectible placement
|
||||
- Power-up progression
|
||||
|
||||
### Narrative & Story
|
||||
|
||||
#### Adventure
|
||||
|
||||
Story-driven exploration with puzzle elements.
|
||||
|
||||
**Examples:** Monkey Island, Myst, Life is Strange
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Puzzle design
|
||||
- Narrative delivery
|
||||
- Exploration mechanics
|
||||
- Dialogue systems
|
||||
- Story branching
|
||||
|
||||
#### Visual Novel
|
||||
|
||||
Narrative choices with branching story.
|
||||
|
||||
**Examples:** Doki Doki Literature Club, Phoenix Wright, Steins;Gate
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Branching narrative structure
|
||||
- Choice and consequence
|
||||
- Character routes
|
||||
- UI/presentation
|
||||
- Save/load states
|
||||
|
||||
#### Text-Based
|
||||
|
||||
Text input/output games with parser or choice mechanics.
|
||||
|
||||
**Examples:** Zork, 80 Days, Dwarf Fortress (adventure mode)
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Parser or choice systems
|
||||
- World model
|
||||
- Narrative structure
|
||||
- Text presentation
|
||||
- Save state management
|
||||
|
||||
### Simulation & Management
|
||||
|
||||
#### Simulation
|
||||
|
||||
Realistic systems with management and building.
|
||||
|
||||
**Examples:** SimCity, RollerCoaster Tycoon, The Sims
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Core simulation loops
|
||||
- Economy modeling
|
||||
- AI agents/citizens
|
||||
- Building/construction
|
||||
- Failure states
|
||||
|
||||
#### Sandbox
|
||||
|
||||
Creative freedom with building and minimal objectives.
|
||||
|
||||
**Examples:** Minecraft, Terraria, Garry's Mod
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Creation tools
|
||||
- Physics/interaction systems
|
||||
- Persistence and saving
|
||||
- Sharing/community features
|
||||
- Optional objectives
|
||||
|
||||
### Sports & Racing
|
||||
|
||||
#### Racing
|
||||
|
||||
Vehicle control with tracks and lap times.
|
||||
|
||||
**Examples:** Mario Kart, Forza, Need for Speed
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Vehicle physics model
|
||||
- Track design
|
||||
- AI opponents
|
||||
- Progression/career mode
|
||||
- Multiplayer racing
|
||||
|
||||
#### Sports
|
||||
|
||||
Team-based or individual sports simulation.
|
||||
|
||||
**Examples:** FIFA, NBA 2K, Tony Hawk's Pro Skater
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Sport-specific rules
|
||||
- Player/team management
|
||||
- AI opponent behavior
|
||||
- Season/career modes
|
||||
- Multiplayer modes
|
||||
|
||||
### Multiplayer
|
||||
|
||||
#### MOBA
|
||||
|
||||
Multiplayer team battles with hero selection.
|
||||
|
||||
**Examples:** League of Legends, Dota 2, Smite
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Hero/champion design
|
||||
- Lane and map design
|
||||
- Team composition
|
||||
- Matchmaking
|
||||
- Economy (gold/items)
|
||||
|
||||
#### Party Game
|
||||
|
||||
Local multiplayer with minigames.
|
||||
|
||||
**Examples:** Mario Party, Jackbox, Overcooked
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Minigame design patterns
|
||||
- Controller support
|
||||
- Round/game structure
|
||||
- Scoring systems
|
||||
- Player count flexibility
|
||||
|
||||
### Horror & Survival
|
||||
|
||||
#### Survival
|
||||
|
||||
Resource gathering with crafting and persistent threats.
|
||||
|
||||
**Examples:** Don't Starve, Subnautica, The Forest
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Resource gathering
|
||||
- Crafting systems
|
||||
- Hunger/health/needs
|
||||
- Threat systems
|
||||
- Base building
|
||||
|
||||
#### Horror
|
||||
|
||||
Atmosphere and tension with limited resources.
|
||||
|
||||
**Examples:** Resident Evil, Silent Hill, Amnesia
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Fear mechanics
|
||||
- Resource scarcity
|
||||
- Sound design
|
||||
- Lighting and visibility
|
||||
- Enemy/threat design
|
||||
|
||||
### Casual & Progression
|
||||
|
||||
#### Puzzle
|
||||
|
||||
Logic-based challenges and problem-solving.
|
||||
|
||||
**Examples:** Tetris, Portal, The Witness
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Puzzle mechanics
|
||||
- Difficulty progression
|
||||
- Hint systems
|
||||
- Level structure
|
||||
- Scoring/rating
|
||||
|
||||
#### Idle/Incremental
|
||||
|
||||
Passive progression with upgrades and automation.
|
||||
|
||||
**Examples:** Cookie Clicker, Adventure Capitalist, Clicker Heroes
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Core loop design
|
||||
- Prestige systems
|
||||
- Automation unlocks
|
||||
- Number scaling
|
||||
- Offline progress
|
||||
|
||||
#### Card Game
|
||||
|
||||
Deck building with card mechanics.
|
||||
|
||||
**Examples:** Slay the Spire, Hearthstone, Magic: The Gathering Arena
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Card design framework
|
||||
- Deck building rules
|
||||
- Mana/resource systems
|
||||
- Rarity and collection
|
||||
- Competitive balance
|
||||
|
||||
### Rhythm
|
||||
|
||||
#### Rhythm
|
||||
|
||||
Music synchronization with timing-based gameplay.
|
||||
|
||||
**Examples:** Guitar Hero, Beat Saber, Crypt of the NecroDancer
|
||||
|
||||
**GDD sections:**
|
||||
|
||||
- Note/beat mapping
|
||||
- Scoring systems
|
||||
- Difficulty levels
|
||||
- Music licensing
|
||||
- Input methods
|
||||
|
||||
## Hybrid Types
|
||||
|
||||
Multiple game types can be combined. GDD sections from all selected types are included.
|
||||
|
||||
| Hybrid | Components | Combined Sections |
|
||||
|--------|------------|-------------------|
|
||||
| Action RPG | Action Platformer + RPG | Movement, combat, stats, inventory |
|
||||
| Survival Horror | Survival + Horror | Resources, crafting, atmosphere, fear |
|
||||
| Roguelike Deckbuilder | Roguelike + Card Game | Run structure, procedural gen, cards |
|
||||
| Tactical RPG | Turn-Based Tactics + RPG | Grid movement, stats, progression |
|
||||
| Open World Survival | Sandbox + Survival | Building, crafting, exploration |
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
title: "BMGD Quick Guide"
|
||||
description: Quick reference for BMad Game Dev Studio
|
||||
---
|
||||
|
||||

|
||||
|
||||
# BMGD Quick Guide
|
||||
|
||||
BMad Game Dev Studio (BMGD) extends BMM with game-specific capabilities. Developed by game industry veterans, it guides you through product research, technical design, narrative design, and a full epic-driven production cycle.
|
||||
|
||||
## Under Construction
|
||||
|
||||
Documentation is under heavy construction catching up with the new beta release. We'll have complete documentation up as soon as possible. For now, please ask in the BMGD section of the Discord if you have any questions.
|
||||
|
||||

|
||||
|
||||
## Quick Start
|
||||
|
||||
**Install → Game Brief → GDD → (Narrative) → Architecture → Build**
|
||||
|
||||
BMGD is an optional module installed via BMAD Method: `npx bmad-method install`
|
||||
|
||||
See [How-To Reference](#how-to-reference) for commands.
|
||||
|
||||
## Development Phases
|
||||
|
||||
| Phase | Name | Key Activities |
|
||||
|-------|------|----------------|
|
||||
| 1 | **Preproduction** | Brainstorm Game, Game Brief, market research |
|
||||
| 2 | **Design** | GDD creation, Narrative Design (for story-driven games) |
|
||||
| 3 | **Technical** | Game Architecture (engine, systems, patterns) |
|
||||
| 4 | **Production** | Sprint planning, story development, code review, testing |
|
||||
|
||||
## BMGD Agents
|
||||
|
||||
| Agent | Purpose |
|
||||
|-------|---------|
|
||||
| Game Designer | Game mechanics, balance, player psychology |
|
||||
| Game Developer | Implementation with engine-specific patterns |
|
||||
| Game Architect | Engine selection, systems design, technical structure |
|
||||
| Game Scrum Master | Sprint planning and epic management |
|
||||
| Game QA | Playtesting, engine-specific testing, performance profiling |
|
||||
| Game Solo Dev | Full-stack game development for solo projects |
|
||||
|
||||
## Key Documents
|
||||
|
||||
| Document | Purpose |
|
||||
|----------|---------|
|
||||
| **Game Brief** | Vision, market positioning, fundamentals |
|
||||
| **GDD** | Core loop, mechanics, progression, art/audio direction |
|
||||
| **Narrative Design** | Story structure, characters, world-building, dialogue |
|
||||
| **Architecture** | Engine, systems, patterns, project structure |
|
||||
|
||||
## Game Type Templates
|
||||
|
||||
BMGD includes 24 game type templates that auto-configure GDD sections:
|
||||
|
||||
Action, Adventure, Puzzle, RPG, Strategy, Simulation, Sports, Racing, Fighting, Horror, Platformer, Shooter, and more.
|
||||
|
||||
Each template provides genre-specific GDD sections, mechanics patterns, testing considerations, and common pitfalls to avoid.
|
||||
|
||||
## Explanation: BMGD vs BMM
|
||||
|
||||
### When to Use Each
|
||||
|
||||
| Use BMGD for | Use BMM for |
|
||||
|--------------|-------------|
|
||||
| Video games | Web applications |
|
||||
| Interactive experiences | APIs and services |
|
||||
| Game prototyping | Mobile apps (non-game) |
|
||||
| Game jams | General software projects |
|
||||
|
||||
### Phase Mapping
|
||||
|
||||
| BMM Phase | BMGD Phase | Key Difference |
|
||||
|-----------|------------|----------------|
|
||||
| Analysis | Preproduction | Game concepts, Game Brief instead of Product Brief |
|
||||
| Planning | Design | GDD instead of PRD; optional Narrative Design |
|
||||
| Solutioning | Technical | Focus on engine selection, game-specific patterns |
|
||||
| Implementation | Production | Game QA replaces TEA; engine-specific testing |
|
||||
|
||||
### Document Differences
|
||||
|
||||
| BMM | BMGD | Notes |
|
||||
|-----|------|-------|
|
||||
| Product Brief | Game Brief | Captures vision, market, fundamentals |
|
||||
| PRD | GDD | Includes mechanics, balance, player experience |
|
||||
| N/A | Narrative Design | Story, characters, world (story-driven games) |
|
||||
| Architecture | Architecture | BMGD version includes engine-specific patterns and considerations |
|
||||
|
||||
### Testing Differences
|
||||
|
||||
**BMM (TEA):** Web-focused testing with Playwright, Cypress, API testing, E2E for web apps.
|
||||
|
||||
**BMGD (Game QA):** Engine-specific frameworks (Unity, Unreal, Godot), gameplay testing, performance profiling, playtest planning, balance validation.
|
||||
|
||||
## How-To Reference
|
||||
|
||||
| I need to... | Action |
|
||||
|--------------|--------------------------------------------------------------------------------------------------------|
|
||||
| Install BMGD | Run `npx bmad-method install` and select BMGD during module installation |
|
||||
| Start a new game | Run `/bmad-gds-brainstorm-game`, then `/bmad:gds:create-game-brief` |
|
||||
| Design my game | Run `/bmad-gds-create-gdd`; add `/bmad:gds:narrative` if story-heavy |
|
||||
| Plan architecture | Run `/bmad-gds-game-architecture` with Game Architect |
|
||||
| Build my game | Use Phase 4 production workflows - Run `/bmad-help` to see what's next |
|
||||
| Test an idea quickly | Use [Quick-Flow](quick-flow-workflows.md) for rapid prototyping |
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [Game Types Guide](game-types.md)
|
||||
- [Quick-Flow Guide](quick-flow-workflows.md)
|
||||
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
---
|
||||
title: "Quick Flow Workflows"
|
||||
---
|
||||
|
||||
How to create tech specs and execute implementations with Quick Flow.
|
||||
|
||||
## Choosing a Workflow
|
||||
|
||||
| Situation | Workflow | Command |
|
||||
|-----------|----------|---------|
|
||||
| Need to document before implementing | Quick-Spec | `/bmad-gds-quick-spec` |
|
||||
| Multiple approaches to evaluate | Quick-Spec | `/bmad-gds-quick-spec` |
|
||||
| Have a completed tech-spec | Quick-Dev | `/bmad-gds-quick-dev path/to/spec.md` |
|
||||
| Have clear, direct instructions | Quick-Dev | `/bmad-gds-quick-dev` |
|
||||
| Building complete game system | Full GDS | `/bmad-gds-workflow-init` |
|
||||
| Epic-level features | Full GDS | `/bmad-gds-workflow-init` |
|
||||
|
||||
---
|
||||
|
||||
## How to Create a Tech Spec (Quick-Spec)
|
||||
|
||||
### Step 1: Start the workflow
|
||||
|
||||
```bash
|
||||
/bmad-gds-quick-spec
|
||||
```
|
||||
|
||||
### Step 2: Describe your requirement
|
||||
|
||||
Provide your feature request. The agent scans the codebase and asks clarifying questions.
|
||||
|
||||
**Checkpoint options:**
|
||||
- `[a]` Advanced Elicitation - explore requirements deeper
|
||||
- `[c]` Continue to investigation
|
||||
- `[p]` Party Mode - consult expert agents
|
||||
|
||||
### Step 3: Review investigation findings
|
||||
|
||||
The agent analyzes the codebase for patterns, constraints, and similar implementations. Review the findings.
|
||||
|
||||
**Checkpoint options:**
|
||||
- `[c]` Continue to spec generation
|
||||
- `[p]` Party Mode - get technical review
|
||||
|
||||
### Step 4: Review generated spec
|
||||
|
||||
The agent creates an ordered task list with file paths and acceptance criteria. Verify completeness.
|
||||
|
||||
**Checkpoint options:**
|
||||
- `[c]` Continue to final review
|
||||
- `[p]` Party Mode - technical review
|
||||
|
||||
### Step 5: Finalize
|
||||
|
||||
Confirm the spec meets these standards:
|
||||
- Every task has a file path and specific action
|
||||
- Tasks ordered by dependency
|
||||
- Acceptance criteria in Given/When/Then format
|
||||
- No placeholders or TBD sections
|
||||
|
||||
**Options:**
|
||||
- `[d]` Start Quick-Dev immediately
|
||||
- `[done]` Save spec and exit
|
||||
|
||||
**Output:** `{planning_artifacts}/tech-spec-{slug}.md`
|
||||
|
||||
---
|
||||
|
||||
## How to Execute Implementation (Quick-Dev)
|
||||
|
||||
### With a Tech-Spec
|
||||
|
||||
```bash
|
||||
/bmad-gds-quick-dev path/to/tech-spec-feature.md
|
||||
```
|
||||
|
||||
The agent:
|
||||
1. Captures baseline git commit
|
||||
2. Loads and validates the spec
|
||||
3. Executes tasks in order
|
||||
4. Runs self-check
|
||||
5. Performs adversarial review
|
||||
6. Resolves findings
|
||||
7. Validates against acceptance criteria
|
||||
|
||||
### With Direct Instructions
|
||||
|
||||
```bash
|
||||
/bmad-gds-quick-dev
|
||||
```
|
||||
|
||||
Then describe what you want implemented:
|
||||
1. Captures baseline git commit
|
||||
2. Evaluates complexity (may suggest planning)
|
||||
3. Gathers context from codebase
|
||||
4. Executes implementation
|
||||
5. Runs self-check and adversarial review
|
||||
6. Resolves findings
|
||||
|
||||
**Escalation:** If the agent detects complexity (multiple components, system-level scope, uncertainty), it offers:
|
||||
- `[t]` Create tech-spec first
|
||||
- `[w]` Use full GDS workflow
|
||||
- `[e]` Execute anyway
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Spec has placeholders or TBD sections
|
||||
|
||||
Return to investigation step. Complete missing research, inline all findings, re-run review.
|
||||
|
||||
### Workflow lost context mid-step
|
||||
|
||||
Check frontmatter for `stepsCompleted`. Resume from last completed step.
|
||||
|
||||
### Agent suggested planning but you want to execute
|
||||
|
||||
You can override with `[e]`, but document your assumptions. Escalation heuristics exist because planning saves time on complex tasks.
|
||||
|
||||
### Tests failing after implementation
|
||||
|
||||
Return to the resolve-findings step. Review failures, fix issues, ensure test expectations are correct, re-run full suite.
|
||||
|
||||
### Need help
|
||||
|
||||
```bash
|
||||
/bmad-help
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Reference
|
||||
|
||||
### File Locations
|
||||
|
||||
| File | Location |
|
||||
|------|----------|
|
||||
| Work in progress | `{implementation_artifacts}/tech-spec-wip.md` |
|
||||
| Completed specs | `{planning_artifacts}/tech-spec-{slug}.md` |
|
||||
| Archived specs | `{implementation_artifacts}/tech-spec-{slug}-archived-{date}.md` |
|
||||
| Workflow files | `_bmad/gds/workflows/gds-quick-flow/` |
|
||||
|
||||
### Validation Criteria
|
||||
|
||||
**Self-check (before adversarial review):**
|
||||
- All tasks/instructions completed
|
||||
- Tests written and passing
|
||||
- Follows existing patterns
|
||||
- No obvious bugs
|
||||
- Acceptance criteria met
|
||||
- Code is readable
|
||||
|
||||
**Adversarial review:**
|
||||
- Correctness
|
||||
- Security
|
||||
- Performance
|
||||
- Maintainability
|
||||
- Test coverage
|
||||
- Error handling
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 118 KiB |
|
|
@ -16,7 +16,6 @@ agent:
|
|||
principles: |
|
||||
- Planning and execution are two sides of the same coin.
|
||||
- Specs are for building, not bureaucracy. Code that ships is better than perfect code that doesn't.
|
||||
- If `**/project-context.md` exists, follow it. If absent, proceed without.
|
||||
|
||||
menu:
|
||||
- trigger: TS or fuzzy match on tech-spec
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ agent:
|
|||
title: Technical Writer
|
||||
icon: 📚
|
||||
module: bmm
|
||||
hasSidecar: false
|
||||
hasSidecar: true
|
||||
|
||||
persona:
|
||||
role: Technical Documentation Specialist + Knowledge Curator
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
||||
bmm,anytime,Document Project,DP,10,_bmad/bmm/workflows/document-project/workflow.yaml,bmad-bmm-document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
|
||||
bmm,anytime,Generate Project Context,GPC,15,_bmad/bmm/workflows/generate-project-context/workflow.md,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects and quick-flow.",output_folder,"project context",
|
||||
bmm,anytime,Quick Spec,TS,20,_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md,bmad-bmm-quick-spec,false,quick-flow-solo-dev,Create Mode,"Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method. Quick one-off tasks small changes simple apps utilities without extensive planning",planning_artifacts,"tech spec",
|
||||
bmm,anytime,Quick Dev,QD,30,_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Quick one-off tasks small changes simple apps utilities without extensive planning - Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method, unless the user is already working through the implementation phase and just requests a 1 off things not already in the plan",,,
|
||||
bmm,anytime,Correct Course,CC,40,_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
|
||||
|
|
|
|||
|
Can't render this file because it has a wrong number of fields in line 7.
|
|
|
@ -5,7 +5,7 @@ description: 'Optimize and polish the complete PRD document for flow, coherence,
|
|||
# File References
|
||||
nextStepFile: './step-12-complete.md'
|
||||
outputFile: '{planning_artifacts}/prd.md'
|
||||
purposeFile: './data/prd-purpose.md'
|
||||
purposeFile: '../data/prd-purpose.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: 'Complete & Validate - Present options for next steps including ful
|
|||
|
||||
# File references (ONLY variables used in this step)
|
||||
prdFile: '{prd_file_path}'
|
||||
validationWorkflow: './steps-v/step-v-01-discovery.md'
|
||||
validationWorkflow: '../steps-v/step-v-01-discovery.md'
|
||||
---
|
||||
|
||||
# Step E-4: Complete & Validate
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
sections_completed: ['technology_stack']
|
||||
existing_patterns_found: { { number_of_patterns_discovered } }
|
||||
---
|
||||
|
||||
# Project Context for AI Agents
|
||||
|
||||
_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
|
||||
|
||||
---
|
||||
|
||||
## Technology Stack & Versions
|
||||
|
||||
_Documented after discovery phase_
|
||||
|
||||
## Critical Implementation Rules
|
||||
|
||||
_Documented after discovery phase_
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
# Step 1: Context Discovery & Initialization
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- ✅ ALWAYS treat this as collaborative discovery between technical peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on discovering existing project context and technology stack
|
||||
- 🎯 IDENTIFY critical implementation rules that AI agents need
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 📖 Read existing project files to understand current context
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 🚫 FORBIDDEN to load next step until discovery is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Focus on existing project files and architecture decisions
|
||||
- Look for patterns, conventions, and unique requirements
|
||||
- Prioritize rules that prevent implementation mistakes
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Discover the project's technology stack, existing patterns, and critical implementation rules that AI agents must follow when writing code.
|
||||
|
||||
## DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Check for Existing Project Context
|
||||
|
||||
First, check if project context already exists:
|
||||
|
||||
- Look for file at `{project_knowledge}/project-context.md or {project-root}/**/project-context.md`
|
||||
- If exists: Read complete file to understand existing rules
|
||||
- Present to user: "Found existing project context with {number_of_sections} sections. Would you like to update this or create a new one?"
|
||||
|
||||
### 2. Discover Project Technology Stack
|
||||
|
||||
Load and analyze project files to identify technologies:
|
||||
|
||||
**Architecture Document:**
|
||||
|
||||
- Look for `{planning_artifacts}/architecture.md`
|
||||
- Extract technology choices with specific versions
|
||||
- Note architectural decisions that affect implementation
|
||||
|
||||
**Package Files:**
|
||||
|
||||
- Check for `package.json`, `requirements.txt`, `Cargo.toml`, etc.
|
||||
- Extract exact versions of all dependencies
|
||||
- Note development vs production dependencies
|
||||
|
||||
**Configuration Files:**
|
||||
|
||||
- Look for project language specific configs ( example: `tsconfig.json`)
|
||||
- Build tool configs (webpack, vite, next.config.js, etc.)
|
||||
- Linting and formatting configs (.eslintrc, .prettierrc, etc.)
|
||||
- Testing configurations (jest.config.js, vitest.config.ts, etc.)
|
||||
|
||||
### 3. Identify Existing Code Patterns
|
||||
|
||||
Search through existing codebase for patterns:
|
||||
|
||||
**Naming Conventions:**
|
||||
|
||||
- File naming patterns (PascalCase, kebab-case, etc.)
|
||||
- Component/function naming conventions
|
||||
- Variable naming patterns
|
||||
- Test file naming patterns
|
||||
|
||||
**Code Organization:**
|
||||
|
||||
- How components are structured
|
||||
- Where utilities and helpers are placed
|
||||
- How services are organized
|
||||
- Test organization patterns
|
||||
|
||||
**Documentation Patterns:**
|
||||
|
||||
- Comment styles and conventions
|
||||
- Documentation requirements
|
||||
- README and API doc patterns
|
||||
|
||||
### 4. Extract Critical Implementation Rules
|
||||
|
||||
Look for rules that AI agents might miss:
|
||||
|
||||
**Language-Specific Rules:**
|
||||
|
||||
- TypeScript strict mode requirements
|
||||
- Import/export conventions
|
||||
- Async/await vs Promise usage patterns
|
||||
- Error handling patterns specific to the language
|
||||
|
||||
**Framework-Specific Rules:**
|
||||
|
||||
- React hooks usage patterns
|
||||
- API route conventions
|
||||
- Middleware usage patterns
|
||||
- State management patterns
|
||||
|
||||
**Testing Rules:**
|
||||
|
||||
- Test structure requirements
|
||||
- Mock usage conventions
|
||||
- Integration vs unit test boundaries
|
||||
- Coverage requirements
|
||||
|
||||
**Development Workflow Rules:**
|
||||
|
||||
- Branch naming conventions
|
||||
- Commit message patterns
|
||||
- PR review requirements
|
||||
- Deployment procedures
|
||||
|
||||
### 5. Initialize Project Context Document
|
||||
|
||||
Based on discovery, create or update the context document:
|
||||
|
||||
#### A. Fresh Document Setup (if no existing context)
|
||||
|
||||
Copy template from `{installed_path}/project-context-template.md` to `{output_folder}/project-context.md`
|
||||
Initialize frontmatter fields.
|
||||
|
||||
#### B. Existing Document Update
|
||||
|
||||
Load existing context and prepare for updates
|
||||
Set frontmatter `sections_completed` to track what will be updated
|
||||
|
||||
### 6. Present Discovery Summary
|
||||
|
||||
Report findings to user:
|
||||
|
||||
"Welcome {{user_name}}! I've analyzed your project for {{project_name}} to discover the context that AI agents need.
|
||||
|
||||
**Technology Stack Discovered:**
|
||||
{{list_of_technologies_with_versions}}
|
||||
|
||||
**Existing Patterns Found:**
|
||||
|
||||
- {{number_of_patterns}} implementation patterns
|
||||
- {{number_of_conventions}} coding conventions
|
||||
- {{number_of_rules}} critical rules
|
||||
|
||||
**Key Areas for Context Rules:**
|
||||
|
||||
- {{area_1}} (e.g., TypeScript configuration)
|
||||
- {{area_2}} (e.g., Testing patterns)
|
||||
- {{area_3}} (e.g., Code organization)
|
||||
|
||||
{if_existing_context}
|
||||
**Existing Context:** Found {{sections}} sections already defined. We can update or add to these.
|
||||
{/if_existing_context}
|
||||
|
||||
Ready to create/update your project context. This will help AI agents implement code consistently with your project's standards.
|
||||
|
||||
[C] Continue to context generation"
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing project context properly detected and handled
|
||||
✅ Technology stack accurately identified with versions
|
||||
✅ Critical implementation patterns discovered
|
||||
✅ Project context document properly initialized
|
||||
✅ Discovery findings clearly presented to user
|
||||
✅ User ready to proceed with context generation
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not checking for existing project context before creating new one
|
||||
❌ Missing critical technology versions or configurations
|
||||
❌ Overlooking important coding patterns or conventions
|
||||
❌ Not initializing frontmatter properly
|
||||
❌ Not presenting clear discovery summary to user
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects [C] to continue, load `./step-02-generate.md` to collaboratively generate the specific project context rules.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery is confirmed and the initial file has been written as directed in this discovery step!
|
||||
|
|
@ -0,0 +1,318 @@
|
|||
# Step 2: Context Rules Generation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- ✅ ALWAYS treat this as collaborative discovery between technical peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on unobvious rules that AI agents need to be reminded of
|
||||
- 🎯 KEEP CONTENT LEAN - optimize for LLM context efficiency
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 📝 Focus on specific, actionable rules rather than general advice
|
||||
- ⚠️ Present A/P/C menu after each major rule category
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter with completed sections
|
||||
- 🚫 FORBIDDEN to load next step until all sections are complete
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices for each rule category:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to explore nuanced implementation rules
|
||||
- **P (Party Mode)**: Bring multiple perspectives to identify critical edge cases
|
||||
- **C (Continue)**: Save the current rules and proceed to next category
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
|
||||
- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Discovery results from step-1 are available
|
||||
- Technology stack and existing patterns are identified
|
||||
- Focus on rules that prevent implementation mistakes
|
||||
- Prioritize unobvious details that AI agents might miss
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Collaboratively generate specific, critical rules that AI agents must follow when implementing code in this project.
|
||||
|
||||
## CONTEXT GENERATION SEQUENCE:
|
||||
|
||||
### 1. Technology Stack & Versions
|
||||
|
||||
Document the exact technology stack from discovery:
|
||||
|
||||
**Core Technologies:**
|
||||
Based on user skill level, present findings:
|
||||
|
||||
**Expert Mode:**
|
||||
"Technology stack from your architecture and package files:
|
||||
{{exact_technologies_with_versions}}
|
||||
|
||||
Any critical version constraints I should document for agents?"
|
||||
|
||||
**Intermediate Mode:**
|
||||
"I found your technology stack:
|
||||
|
||||
**Core Technologies:**
|
||||
{{main_technologies_with_versions}}
|
||||
|
||||
**Key Dependencies:**
|
||||
{{important_dependencies_with_versions}}
|
||||
|
||||
Are there any version constraints or compatibility notes agents should know about?"
|
||||
|
||||
**Beginner Mode:**
|
||||
"Here are the technologies you're using:
|
||||
|
||||
**Main Technologies:**
|
||||
{{friendly_description_of_tech_stack}}
|
||||
|
||||
**Important Notes:**
|
||||
{{key_things_agents_need_to_know_about_versions}}
|
||||
|
||||
Should I document any special version rules or compatibility requirements?"
|
||||
|
||||
### 2. Language-Specific Rules
|
||||
|
||||
Focus on unobvious language patterns agents might miss:
|
||||
|
||||
**TypeScript/JavaScript Rules:**
|
||||
"Based on your codebase, I notice some specific patterns:
|
||||
|
||||
**Configuration Requirements:**
|
||||
{{typescript_config_rules}}
|
||||
|
||||
**Import/Export Patterns:**
|
||||
{{import_export_conventions}}
|
||||
|
||||
**Error Handling Patterns:**
|
||||
{{error_handling_requirements}}
|
||||
|
||||
Are these patterns correct? Any other language-specific rules agents should follow?"
|
||||
|
||||
**Python/Ruby/Other Language Rules:**
|
||||
Adapt to the actual language in use with similar focused questions.
|
||||
|
||||
### 3. Framework-Specific Rules
|
||||
|
||||
Document framework-specific patterns:
|
||||
|
||||
**React Rules (if applicable):**
|
||||
"For React development, I see these patterns:
|
||||
|
||||
**Hooks Usage:**
|
||||
{{hooks_usage_patterns}}
|
||||
|
||||
**Component Structure:**
|
||||
{{component_organization_rules}}
|
||||
|
||||
**State Management:**
|
||||
{{state_management_patterns}}
|
||||
|
||||
**Performance Rules:**
|
||||
{{performance_optimization_requirements}}
|
||||
|
||||
Should I add any other React-specific rules?"
|
||||
|
||||
**Other Framework Rules:**
|
||||
Adapt for Vue, Angular, Next.js, Express, etc.
|
||||
|
||||
### 4. Testing Rules
|
||||
|
||||
Focus on testing patterns that ensure consistency:
|
||||
|
||||
**Test Structure Rules:**
|
||||
"Your testing setup shows these patterns:
|
||||
|
||||
**Test Organization:**
|
||||
{{test_file_organization}}
|
||||
|
||||
**Mock Usage:**
|
||||
{{mock_patterns_and_conventions}}
|
||||
|
||||
**Test Coverage Requirements:**
|
||||
{{coverage_expectations}}
|
||||
|
||||
**Integration vs Unit Test Rules:**
|
||||
{{test_boundary_patterns}}
|
||||
|
||||
Are there testing rules agents should always follow?"
|
||||
|
||||
### 5. Code Quality & Style Rules
|
||||
|
||||
Document critical style and quality rules:
|
||||
|
||||
**Linting/Formatting:**
|
||||
"Your code style configuration requires:
|
||||
|
||||
**ESLint/Prettier Rules:**
|
||||
{{specific_linting_rules}}
|
||||
|
||||
**Code Organization:**
|
||||
{{file_and_folder_structure_rules}}
|
||||
|
||||
**Naming Conventions:**
|
||||
{{naming_patterns_agents_must_follow}}
|
||||
|
||||
**Documentation Requirements:**
|
||||
{{comment_and_documentation_patterns}}
|
||||
|
||||
Any additional code quality rules?"
|
||||
|
||||
### 6. Development Workflow Rules
|
||||
|
||||
Document workflow patterns that affect implementation:
|
||||
|
||||
**Git/Repository Rules:**
|
||||
"Your project uses these patterns:
|
||||
|
||||
**Branch Naming:**
|
||||
{{branch_naming_conventions}}
|
||||
|
||||
**Commit Message Format:**
|
||||
{{commit_message_patterns}}
|
||||
|
||||
**PR Requirements:**
|
||||
{{pull_request_checklist}}
|
||||
|
||||
**Deployment Patterns:**
|
||||
{{deployment_considerations}}
|
||||
|
||||
Should I document any other workflow rules?"
|
||||
|
||||
### 7. Critical Don't-Miss Rules
|
||||
|
||||
Identify rules that prevent common mistakes:
|
||||
|
||||
**Anti-Patterns to Avoid:**
|
||||
"Based on your codebase, here are critical things agents must NOT do:
|
||||
|
||||
{{critical_anti_patterns_with_examples}}
|
||||
|
||||
**Edge Cases:**
|
||||
{{specific_edge_cases_agents_should_handle}}
|
||||
|
||||
**Security Rules:**
|
||||
{{security_considerations_agents_must_follow}}
|
||||
|
||||
**Performance Gotchas:**
|
||||
{{performance_patterns_to_avoid}}
|
||||
|
||||
Are there other 'gotchas' agents should know about?"
|
||||
|
||||
### 8. Generate Context Content
|
||||
|
||||
For each category, prepare lean content for the project context file:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Technology Stack & Versions
|
||||
|
||||
{{concise_technology_list_with_exact_versions}}
|
||||
|
||||
## Critical Implementation Rules
|
||||
|
||||
### Language-Specific Rules
|
||||
|
||||
{{bullet_points_of_critical_language_rules}}
|
||||
|
||||
### Framework-Specific Rules
|
||||
|
||||
{{bullet_points_of_framework_patterns}}
|
||||
|
||||
### Testing Rules
|
||||
|
||||
{{bullet_points_of_testing_requirements}}
|
||||
|
||||
### Code Quality & Style Rules
|
||||
|
||||
{{bullet_points_of_style_and_quality_rules}}
|
||||
|
||||
### Development Workflow Rules
|
||||
|
||||
{{bullet_points_of_workflow_patterns}}
|
||||
|
||||
### Critical Don't-Miss Rules
|
||||
|
||||
{{bullet_points_of_anti_patterns_and_edge_cases}}
|
||||
```
|
||||
|
||||
### 9. Present Content and Menu
|
||||
|
||||
After each category, show the generated rules and present choices:
|
||||
|
||||
"I've drafted the {{category_name}} rules for your project context.
|
||||
|
||||
**Here's what I'll add:**
|
||||
|
||||
[Show the complete markdown content for this category]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Explore nuanced rules for this category
|
||||
[P] Party Mode - Review from different implementation perspectives
|
||||
[C] Continue - Save these rules and move to next category"
|
||||
|
||||
### 10. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Execute advanced-elicitation.xml with current category rules
|
||||
- Process enhanced rules that come back
|
||||
- Ask user: "Accept these enhanced rules for {{category}}? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Execute party-mode workflow with category rules context
|
||||
- Process collaborative insights on implementation patterns
|
||||
- Ask user: "Accept these changes to {{category}} rules? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Save the current category content to project context file
|
||||
- Update frontmatter: `sections_completed: [...]`
|
||||
- Proceed to next category or step-03 if complete
|
||||
|
||||
## APPEND TO PROJECT CONTEXT:
|
||||
|
||||
When user selects 'C' for a category, append the content directly to `{output_folder}/project-context.md` using the structure from step 8.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All critical technology versions accurately documented
|
||||
✅ Language-specific rules cover unobvious patterns
|
||||
✅ Framework rules capture project-specific conventions
|
||||
✅ Testing rules ensure consistent test quality
|
||||
✅ Code quality rules maintain project standards
|
||||
✅ Workflow rules prevent implementation conflicts
|
||||
✅ Content is lean and optimized for LLM context
|
||||
✅ A/P/C menu presented and handled correctly for each category
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Including obvious rules that agents already know
|
||||
❌ Making content too verbose for LLM context efficiency
|
||||
❌ Missing critical anti-patterns or edge cases
|
||||
❌ Not getting user validation for each rule category
|
||||
❌ Not documenting exact versions and configurations
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After completing all rule categories and user selects 'C' for the final category, load `./step-03-complete.md` to finalize the project context file.
|
||||
|
||||
Remember: Do NOT proceed to step-03 until all categories are complete and user explicitly selects 'C' for each!
|
||||
|
|
@ -0,0 +1,278 @@
|
|||
# Step 3: Context Completion & Finalization
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- ✅ ALWAYS treat this as collaborative completion between technical peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on finalizing a lean, LLM-optimized project context
|
||||
- 🎯 ENSURE all critical rules are captured and actionable
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 📝 Review and optimize content for LLM context efficiency
|
||||
- 📖 Update frontmatter with completion status
|
||||
- 🚫 NO MORE STEPS - this is the final step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All rule categories from step-2 are complete
|
||||
- Technology stack and versions are documented
|
||||
- Focus on final review, optimization, and completion
|
||||
- Ensure the context file is ready for AI agent consumption
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Complete the project context file, optimize it for LLM efficiency, and provide guidance for usage and maintenance.
|
||||
|
||||
## COMPLETION SEQUENCE:
|
||||
|
||||
### 1. Review Complete Context File
|
||||
|
||||
Read the entire project context file and analyze:
|
||||
|
||||
**Content Analysis:**
|
||||
|
||||
- Total length and readability for LLMs
|
||||
- Clarity and specificity of rules
|
||||
- Coverage of all critical areas
|
||||
- Actionability of each rule
|
||||
|
||||
**Structure Analysis:**
|
||||
|
||||
- Logical organization of sections
|
||||
- Consistency of formatting
|
||||
- Absence of redundant or obvious information
|
||||
- Optimization for quick scanning
|
||||
|
||||
### 2. Optimize for LLM Context
|
||||
|
||||
Ensure the file is lean and efficient:
|
||||
|
||||
**Content Optimization:**
|
||||
|
||||
- Remove any redundant rules or obvious information
|
||||
- Combine related rules into concise bullet points
|
||||
- Use specific, actionable language
|
||||
- Ensure each rule provides unique value
|
||||
|
||||
**Formatting Optimization:**
|
||||
|
||||
- Use consistent markdown formatting
|
||||
- Implement clear section hierarchy
|
||||
- Ensure scannability with strategic use of bolding
|
||||
- Maintain readability while maximizing information density
|
||||
|
||||
### 3. Final Content Structure
|
||||
|
||||
Ensure the final structure follows this optimized format:
|
||||
|
||||
```markdown
|
||||
# Project Context for AI Agents
|
||||
|
||||
_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
|
||||
|
||||
---
|
||||
|
||||
## Technology Stack & Versions
|
||||
|
||||
{{concise_technology_list}}
|
||||
|
||||
## Critical Implementation Rules
|
||||
|
||||
### Language-Specific Rules
|
||||
|
||||
{{specific_language_rules}}
|
||||
|
||||
### Framework-Specific Rules
|
||||
|
||||
{{framework_patterns}}
|
||||
|
||||
### Testing Rules
|
||||
|
||||
{{testing_requirements}}
|
||||
|
||||
### Code Quality & Style Rules
|
||||
|
||||
{{style_and_quality_patterns}}
|
||||
|
||||
### Development Workflow Rules
|
||||
|
||||
{{workflow_patterns}}
|
||||
|
||||
### Critical Don't-Miss Rules
|
||||
|
||||
{{anti_patterns_and_edge_cases}}
|
||||
|
||||
---
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
**For AI Agents:**
|
||||
|
||||
- Read this file before implementing any code
|
||||
- Follow ALL rules exactly as documented
|
||||
- When in doubt, prefer the more restrictive option
|
||||
- Update this file if new patterns emerge
|
||||
|
||||
**For Humans:**
|
||||
|
||||
- Keep this file lean and focused on agent needs
|
||||
- Update when technology stack changes
|
||||
- Review quarterly for outdated rules
|
||||
- Remove rules that become obvious over time
|
||||
|
||||
Last Updated: {{date}}
|
||||
```
|
||||
|
||||
### 4. Present Completion Summary
|
||||
|
||||
Based on user skill level, present the completion:
|
||||
|
||||
**Expert Mode:**
|
||||
"Project context complete. Optimized for LLM consumption with {{rule_count}} critical rules across {{section_count}} sections.
|
||||
|
||||
File saved to: `{output_folder}/project-context.md`
|
||||
|
||||
Ready for AI agent integration."
|
||||
|
||||
**Intermediate Mode:**
|
||||
"Your project context is complete and optimized for AI agents!
|
||||
|
||||
**What we created:**
|
||||
|
||||
- {{rule_count}} critical implementation rules
|
||||
- Technology stack with exact versions
|
||||
- Framework-specific patterns and conventions
|
||||
- Testing and quality guidelines
|
||||
- Workflow and anti-pattern rules
|
||||
|
||||
**Key benefits:**
|
||||
|
||||
- AI agents will implement consistently with your standards
|
||||
- Reduced context switching and implementation errors
|
||||
- Clear guidance for unobvious project requirements
|
||||
|
||||
**Next steps:**
|
||||
|
||||
- AI agents should read this file before implementing
|
||||
- Update as your project evolves
|
||||
- Review periodically for optimization"
|
||||
|
||||
**Beginner Mode:**
|
||||
"Excellent! Your project context guide is ready! 🎉
|
||||
|
||||
**What this does:**
|
||||
Think of this as a 'rules of the road' guide for AI agents working on your project. It ensures they all follow the same patterns and avoid common mistakes.
|
||||
|
||||
**What's included:**
|
||||
|
||||
- Exact technology versions to use
|
||||
- Critical coding rules they might miss
|
||||
- Testing and quality standards
|
||||
- Workflow patterns to follow
|
||||
|
||||
**How AI agents use it:**
|
||||
They read this file before writing any code, ensuring everything they create follows your project's standards perfectly.
|
||||
|
||||
Your project context is saved and ready to help agents implement consistently!"
|
||||
|
||||
### 5. Final File Updates
|
||||
|
||||
Update the project context file with completion information:
|
||||
|
||||
**Frontmatter Update:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
sections_completed:
|
||||
['technology_stack', 'language_rules', 'framework_rules', 'testing_rules', 'quality_rules', 'workflow_rules', 'anti_patterns']
|
||||
status: 'complete'
|
||||
rule_count: { { total_rules } }
|
||||
optimized_for_llm: true
|
||||
---
|
||||
```
|
||||
|
||||
**Add Usage Section:**
|
||||
Append the usage guidelines from step 3 to complete the document.
|
||||
|
||||
### 6. Completion Validation
|
||||
|
||||
Final checks before completion:
|
||||
|
||||
**Content Validation:**
|
||||
✅ All critical technology versions documented
|
||||
✅ Language-specific rules are specific and actionable
|
||||
✅ Framework rules cover project conventions
|
||||
✅ Testing rules ensure consistency
|
||||
✅ Code quality rules maintain standards
|
||||
✅ Workflow rules prevent conflicts
|
||||
✅ Anti-pattern rules prevent common mistakes
|
||||
|
||||
**Format Validation:**
|
||||
✅ Content is lean and optimized for LLMs
|
||||
✅ Structure is logical and scannable
|
||||
✅ No redundant or obvious information
|
||||
✅ Consistent formatting throughout
|
||||
|
||||
### 7. Completion Message
|
||||
|
||||
Present final completion to user:
|
||||
|
||||
"✅ **Project Context Generation Complete!**
|
||||
|
||||
Your optimized project context file is ready at:
|
||||
`{output_folder}/project-context.md`
|
||||
|
||||
**📊 Context Summary:**
|
||||
|
||||
- {{rule_count}} critical rules for AI agents
|
||||
- {{section_count}} comprehensive sections
|
||||
- Optimized for LLM context efficiency
|
||||
- Ready for immediate agent integration
|
||||
|
||||
**🎯 Key Benefits:**
|
||||
|
||||
- Consistent implementation across all AI agents
|
||||
- Reduced common mistakes and edge cases
|
||||
- Clear guidance for project-specific patterns
|
||||
- Minimal LLM context usage
|
||||
|
||||
**📋 Next Steps:**
|
||||
|
||||
1. AI agents will automatically read this file when implementing
|
||||
2. Update this file when your technology stack or patterns evolve
|
||||
3. Review quarterly to optimize and remove outdated rules
|
||||
|
||||
Your project context will help ensure high-quality, consistent implementation across all development work. Great work capturing your project's critical implementation requirements!"
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Complete project context file with all critical rules
|
||||
✅ Content optimized for LLM context efficiency
|
||||
✅ All technology versions and patterns documented
|
||||
✅ File structure is logical and scannable
|
||||
✅ Usage guidelines included for agents and humans
|
||||
✅ Frontmatter properly updated with completion status
|
||||
✅ User provided with clear next steps and benefits
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Final content is too verbose for LLM consumption
|
||||
❌ Missing critical implementation rules or patterns
|
||||
❌ Not optimizing content for agent readability
|
||||
❌ Not providing clear usage guidelines
|
||||
❌ Frontmatter not properly updated
|
||||
❌ Not validating file completion before ending
|
||||
|
||||
## WORKFLOW COMPLETE:
|
||||
|
||||
This is the final step of the Generate Project Context workflow. The user now has a comprehensive, optimized project context file that will ensure consistent, high-quality implementation across all AI agents working on the project.
|
||||
|
||||
The project context file serves as the critical "rules of the road" that agents need to implement code consistently with the project's standards and patterns.
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
name: generate-project-context
|
||||
description: Creates a concise project-context.md file with critical rules and patterns that AI agents must follow when implementing code. Optimized for LLM context efficiency.
|
||||
---
|
||||
|
||||
# Generate Project Context Workflow
|
||||
|
||||
**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
|
||||
|
||||
**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **micro-file architecture** for disciplined execution:
|
||||
|
||||
- Each step is a self-contained file with embedded rules
|
||||
- Sequential progression with user control at each step
|
||||
- Document state tracked in frontmatter
|
||||
- Focus on lean, LLM-optimized content generation
|
||||
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Configuration Loading
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Paths
|
||||
|
||||
- `installed_path` = `{project-root}/_bmad/bmm/workflows/generate-project-context`
|
||||
- `template_path` = `{installed_path}/project-context-template.md`
|
||||
- `output_file` = `{output_folder}/project-context.md`
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
Load and execute `steps/step-01-discover.md` to begin the workflow.
|
||||
|
||||
**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.
|
||||
|
|
@ -81,7 +81,7 @@
|
|||
<action>Continue to next step</action>
|
||||
</if>
|
||||
<if response="p">
|
||||
<action>Start the party-mode workflow {project-root}/_bmad/core/workflows/party-mode/workflow.yaml</action>
|
||||
<action>Start the party-mode workflow {project-root}/_bmad/core/workflows/party-mode/workflow.md</action>
|
||||
</if>
|
||||
<if
|
||||
response="y">
|
||||
|
|
|
|||
|
|
@ -283,6 +283,7 @@ class ConfigDrivenIdeSetup extends BaseIdeSetup {
|
|||
return `---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
You must fully embody this agent's persona and follow all activation instructions exactly as specified.
|
||||
|
|
@ -297,6 +298,7 @@ You must fully embody this agent's persona and follow all activation instruction
|
|||
return `---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# {{name}}
|
||||
|
|
|
|||
|
|
@ -411,6 +411,7 @@ class CodexSetup extends BaseIdeSetup {
|
|||
const launcherContent = `---
|
||||
name: '${agentName}'
|
||||
description: '${agentName} agent'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
const path = require('node:path');
|
||||
const YAML = require('yaml');
|
||||
const { BaseIdeSetup } = require('./_base-ide');
|
||||
const chalk = require('chalk');
|
||||
const { AgentCommandGenerator } = require('./shared/agent-command-generator');
|
||||
|
|
@ -92,43 +93,31 @@ class KiloSetup extends BaseIdeSetup {
|
|||
* Create a mode entry for an agent
|
||||
*/
|
||||
async createModeEntry(artifact, projectDir) {
|
||||
// Extract metadata from launcher content
|
||||
const titleMatch = artifact.content.match(/title="([^"]+)"/);
|
||||
const title = titleMatch ? titleMatch[1] : this.formatTitle(artifact.name);
|
||||
const title = artifact.content.match(/title="([^"]+)"/)?.[1] ?? this.formatTitle(artifact.name);
|
||||
|
||||
const iconMatch = artifact.content.match(/icon="([^"]+)"/);
|
||||
const icon = iconMatch ? iconMatch[1] : '🤖';
|
||||
const icon = artifact.content.match(/icon="([^"]+)"/)?.[1] ?? '🤖';
|
||||
|
||||
const whenToUseMatch = artifact.content.match(/whenToUse="([^"]+)"/);
|
||||
const whenToUse = whenToUseMatch ? whenToUseMatch[1] : `Use for ${title} tasks`;
|
||||
const whenToUse = artifact.content.match(/whenToUse="([^"]+)"/)?.[1] ?? `Use for ${title} tasks`;
|
||||
|
||||
const roleDefinition =
|
||||
artifact.content.match(/roleDefinition="([^"]+)"/)?.[1] ?? `You are a ${title} specializing in ${title.toLowerCase()} tasks.`;
|
||||
|
||||
// Get the activation header from central template
|
||||
const activationHeader = await this.getAgentCommandHeader();
|
||||
|
||||
const roleDefinitionMatch = artifact.content.match(/roleDefinition="([^"]+)"/);
|
||||
const roleDefinition = roleDefinitionMatch
|
||||
? roleDefinitionMatch[1]
|
||||
: `You are a ${title} specializing in ${title.toLowerCase()} tasks.`;
|
||||
|
||||
// Get relative path
|
||||
const relativePath = path.relative(projectDir, artifact.sourcePath).replaceAll('\\', '/');
|
||||
|
||||
// Build mode entry (KiloCode uses same schema as Roo)
|
||||
const slug = `bmad-${artifact.module}-${artifact.name}`;
|
||||
let modeEntry = ` - slug: ${slug}\n`;
|
||||
modeEntry += ` name: '${icon} ${title}'\n`;
|
||||
modeEntry += ` roleDefinition: ${roleDefinition}\n`;
|
||||
modeEntry += ` whenToUse: ${whenToUse}\n`;
|
||||
modeEntry += ` customInstructions: |\n`;
|
||||
modeEntry += ` ${activationHeader} Read the full YAML from ${relativePath} start activation to alter your state of being follow startup section instructions stay in this being until told to exit this mode\n`;
|
||||
modeEntry += ` groups:\n`;
|
||||
modeEntry += ` - read\n`;
|
||||
modeEntry += ` - edit\n`;
|
||||
modeEntry += ` - browser\n`;
|
||||
modeEntry += ` - command\n`;
|
||||
modeEntry += ` - mcp\n`;
|
||||
const entry = {
|
||||
slug: `bmad-${artifact.module}-${artifact.name}`,
|
||||
name: `${icon} ${title}`,
|
||||
roleDefinition,
|
||||
whenToUse,
|
||||
customInstructions:
|
||||
`${activationHeader}` +
|
||||
`Read the full YAML from ${relativePath} start activation to alter your state of being follow startup section instructions stay in this being until told to exit this mode`,
|
||||
groups: ['read', 'edit', 'browser', 'command', 'mcp'],
|
||||
};
|
||||
|
||||
return modeEntry;
|
||||
return YAML.stringify([entry], { indent: 2 });
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
|
|||
|
|
@ -72,6 +72,7 @@ class TaskToolCommandGenerator {
|
|||
|
||||
return `---
|
||||
description: '${description.replaceAll("'", "''")}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# ${item.displayName || item.name}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
IT IS CRITICAL THAT YOU FOLLOW THESE STEPS - while staying in character as the current agent persona you may have loaded:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @{project-root}/{{bmadFolderName}}/{{path}}, READ its entire contents and follow its directions exactly!
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
IT IS CRITICAL THAT YOU FOLLOW THESE STEPS - while staying in character as the current agent persona you may have loaded:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
description: '{{description}}'
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @{{workflow_path}}, READ its entire contents and follow its directions exactly!
|
||||
|
|
|
|||
Loading…
Reference in New Issue