bmad-method 4.2.0 → 4.4.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/analyst.md +14 -20
- package/.claude/commands/architect.md +15 -20
- package/.claude/commands/bmad-master.md +18 -26
- package/.claude/commands/bmad-orchestrator.md +80 -33
- package/.claude/commands/dev.md +5 -4
- package/.claude/commands/pm.md +11 -16
- package/.claude/commands/sm.md +20 -25
- package/.cursor/rules/analyst.mdc +13 -19
- package/.cursor/rules/architect.mdc +14 -19
- package/.cursor/rules/bmad-master.mdc +18 -26
- package/.cursor/rules/bmad-orchestrator.mdc +80 -33
- package/.cursor/rules/dev.mdc +5 -4
- package/.cursor/rules/pm.mdc +11 -16
- package/.cursor/rules/sm.mdc +19 -24
- package/.releaserc.json +2 -1
- package/.roo/README.md +0 -11
- package/.vscode/settings.json +4 -0
- package/.windsurf/rules/analyst.md +13 -19
- package/.windsurf/rules/architect.md +14 -19
- package/.windsurf/rules/bmad-master.md +18 -26
- package/.windsurf/rules/bmad-orchestrator.md +80 -33
- package/.windsurf/rules/dev.md +5 -4
- package/.windsurf/rules/pm.md +11 -16
- package/.windsurf/rules/sm.md +19 -24
- package/CHANGELOG.md +126 -2
- package/CONTRIBUTING.md +2 -0
- package/README.md +20 -2
- package/{.bmad-core → bmad-core}/agent-teams/team-all.yml +1 -3
- package/bmad-core/agent-teams/team-fullstack.yml +18 -0
- package/{.bmad-core → bmad-core}/agent-teams/team-no-ui.yml +0 -2
- package/{.bmad-core → bmad-core}/agents/analyst.md +14 -20
- package/{.bmad-core → bmad-core}/agents/architect.md +15 -20
- package/{.bmad-core → bmad-core}/agents/bmad-master.md +18 -26
- package/bmad-core/agents/bmad-orchestrator.md +128 -0
- package/{.bmad-core → bmad-core}/agents/dev.md +5 -4
- package/{.bmad-core → bmad-core}/agents/pm.md +11 -16
- package/{.bmad-core → bmad-core}/agents/qa.md +11 -17
- package/bmad-core/agents/sm.md +55 -0
- package/{.bmad-core → bmad-core}/agents/ux-expert.md +14 -20
- package/bmad-core/bmad-core-config.yml +60 -0
- package/bmad-core/data/bmad-kb.md +47 -0
- package/bmad-core/tasks/doc-migration-task.md +143 -0
- package/bmad-core/tasks/document-project.md +389 -0
- package/bmad-core/tasks/generate-ai-frontend-prompt.md +51 -0
- package/{.bmad-core → bmad-core}/tasks/index-docs.md +8 -3
- package/{.bmad-core → bmad-core}/tasks/shard-doc.md +5 -3
- package/{.bmad-core → bmad-core}/templates/architecture-tmpl.md +16 -13
- package/{.bmad-core → bmad-core}/templates/brownfield-architecture-tmpl.md +6 -6
- package/{.bmad-core → bmad-core}/templates/front-end-spec-tmpl.md +6 -6
- package/{.bmad-core → bmad-core}/templates/fullstack-architecture-tmpl.md +85 -103
- package/{.bmad-core → bmad-core}/templates/prd-tmpl.md +1 -1
- package/bmad-core/templates/simple-project-prd-tmpl.md +461 -0
- package/{.bmad-core → bmad-core}/templates/story-tmpl.md +2 -2
- package/{.bmad-core → bmad-core}/utils/agent-switcher.ide.md +6 -6
- package/{.bmad-core → bmad-core}/utils/workflow-management.md +14 -15
- package/{.bmad-core → bmad-core}/web-bundles/agents/analyst.txt +26 -21
- package/{.bmad-core → bmad-core}/web-bundles/agents/architect.txt +608 -236
- package/{.bmad-core → bmad-core}/web-bundles/agents/bmad-master.txt +467 -1049
- package/bmad-core/web-bundles/agents/bmad-orchestrator.txt +647 -0
- package/{.bmad-core → bmad-core}/web-bundles/agents/dev.txt +5 -4
- package/{.bmad-core → bmad-core}/web-bundles/agents/pm.txt +477 -18
- package/{.bmad-core → bmad-core}/web-bundles/agents/po.txt +3 -3
- package/{.bmad-core → bmad-core}/web-bundles/agents/qa.txt +11 -17
- package/{.bmad-core → bmad-core}/web-bundles/agents/sm.txt +22 -27
- package/{.bmad-core → bmad-core}/web-bundles/agents/ux-expert.txt +57 -70
- package/{.bmad-core → bmad-core}/workflows/greenfield-fullstack.yml +3 -3
- package/{.bmad-core → creator-tools}/tasks/create-agent.md +10 -12
- package/{.bmad-core/tasks/create-expansion-pack.md → creator-tools/tasks/generate-expansion-pack.md} +8 -6
- package/docs/bmad-workflow-guide.md +161 -0
- package/docs/claude-code-guide.md +119 -0
- package/docs/core-architecture.md +213 -0
- package/docs/cursor-guide.md +127 -0
- package/docs/how-to-contribute-with-pull-requests.md +141 -0
- package/docs/roo-code-guide.md +140 -0
- package/docs/user-guide.md +1044 -0
- package/docs/versioning-and-releases.md +4 -4
- package/docs/windsurf-guide.md +127 -0
- package/expansion-packs/README.md +1 -111
- package/expansion-packs/bmad-2d-phaser-game-dev/agent-teams/team-game-dev.yml +12 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.md +58 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.md +66 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.md +51 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/checklists/game-design-checklist.md +201 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/checklists/game-story-dod-checklist.md +160 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/data/bmad-kb.md +254 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md +631 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/manifest.yml +45 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/advanced-elicitation.md +111 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/create-game-story.md +216 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/game-design-brainstorming.md +308 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-architecture-tmpl.md +560 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-brief-tmpl.md +345 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-design-doc-tmpl.md +331 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-story-tmpl.md +235 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/level-design-doc-tmpl.md +451 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-designer.txt +1758 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-developer.txt +1444 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-sm.txt +674 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/team-game-dev.txt +4395 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/teams/team-game-dev.txt +4395 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-dev-greenfield.yml +183 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-prototype.yml +175 -0
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/README.md +5 -5
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/agents/infra-devops-platform.md +3 -3
- package/expansion-packs/bmad-infrastructure-devops/manifest.yml +23 -0
- package/expansion-packs/bmad-infrastructure-devops/tasks/create-doc.md +74 -0
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/templates/infrastructure-platform-from-arch-tmpl.md +0 -0
- package/expansion-packs/bmad-infrastructure-devops/web-bundles/agents/infra-devops-platform.txt +2021 -0
- package/package.json +20 -14
- package/tools/builders/web-builder.js +207 -17
- package/tools/cli.js +55 -7
- package/tools/installer/README.md +2 -2
- package/tools/installer/bin/bmad.js +107 -28
- package/tools/installer/config/install.config.yml +43 -43
- package/tools/installer/lib/config-loader.js +39 -2
- package/tools/installer/lib/file-manager.js +20 -3
- package/tools/installer/lib/ide-setup.js +11 -1
- package/tools/installer/lib/installer.js +275 -29
- package/tools/installer/package-lock.json +538 -336
- package/tools/installer/package.json +8 -8
- package/tools/lib/dependency-resolver.js +2 -2
- package/tools/semantic-release-sync-installer.js +31 -0
- package/tools/sync-installer-version.js +34 -0
- package/tools/upgraders/v3-to-v4-upgrader.js +18 -13
- package/tools/version-bump.js +33 -26
- package/tools/yaml-format.js +54 -25
- package/.bmad-core/agent-teams/team-fullstack.yml +0 -26
- package/.bmad-core/agents/bmad-orchestrator.md +0 -81
- package/.bmad-core/agents/sm.md +0 -60
- package/.bmad-core/data/bmad-kb.md +0 -36
- package/.bmad-core/schemas/agent-team-schema.yml +0 -153
- package/.bmad-core/tasks/create-team.md +0 -229
- package/.bmad-core/tasks/doc-migration-task.md +0 -198
- package/.bmad-core/tasks/generate-ai-frontend-prompt.md +0 -58
- package/.bmad-core/web-bundles/agents/bmad-orchestrator.txt +0 -1455
- package/.bmad-core/web-bundles/teams/team-all.txt +0 -10315
- package/.bmad-core/web-bundles/teams/team-fullstack.txt +0 -9663
- package/.bmad-core/web-bundles/teams/team-no-ui.txt +0 -8504
- package/.claude/settings.local.json +0 -22
- package/expansion-packs/infrastructure-devops/manifest.yml +0 -38
- /package/{.bmad-core → bmad-core}/agents/po.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/architect-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/change-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/pm-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/po-master-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/story-dod-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/story-draft-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/data/technical-preferences.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/advanced-elicitation.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brainstorming-techniques.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brownfield-create-epic.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brownfield-create-story.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/core-dump.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/correct-course.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-deep-research-prompt.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-doc.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-next-story.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/execute-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/agent-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/brownfield-prd-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/competitor-analysis-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/expansion-pack-plan-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/front-end-architecture-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/market-research-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/project-brief-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/web-agent-startup-instructions-template.md +0 -0
- /package/{.bmad-core → bmad-core}/utils/template-format.md +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-fullstack.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-service.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-ui.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/greenfield-service.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/greenfield-ui.yml +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/checklists/infrastructure-checklist.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/tasks/review-infrastructure.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/tasks/validate-infrastructure.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/templates/infrastructure-architecture-tmpl.md +0 -0
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
agent_file_references:
|
|
2
|
+
core_docs:
|
|
3
|
+
- docs/index.md
|
|
4
|
+
- docs/prd.md
|
|
5
|
+
- docs/architecture.md
|
|
6
|
+
- docs/architecture/index.md
|
|
7
|
+
- 'docs/architecture/coding-standards.md # Required by DEV at startup'
|
|
8
|
+
- 'docs/architecture/tech-stack.md # Technology stack reference'
|
|
9
|
+
- 'docs/architecture/unified-project-structure.md # Project structure guide'
|
|
10
|
+
- 'docs/architecture/testing-strategy.md # Testing requirements'
|
|
11
|
+
story_files:
|
|
12
|
+
- 'docs/stories/ # Stories directory (pattern: {epicNum}.{storyNum}.story.md)'
|
|
13
|
+
epic_locations:
|
|
14
|
+
primary: docs/
|
|
15
|
+
secondary: docs/prd/
|
|
16
|
+
architecture_shards:
|
|
17
|
+
backend:
|
|
18
|
+
- 'docs/architecture/backend-architecture.md # Backend service patterns'
|
|
19
|
+
- 'docs/architecture/rest-api-spec.md # API endpoint specifications'
|
|
20
|
+
- 'docs/architecture/data-models.md # Data structures and validation'
|
|
21
|
+
- 'docs/architecture/database-schema.md # Database design'
|
|
22
|
+
- 'docs/architecture/external-apis.md # Third-party integrations'
|
|
23
|
+
frontend:
|
|
24
|
+
- 'docs/architecture/frontend-architecture.md # Frontend patterns'
|
|
25
|
+
- docs/architecture/components.md
|
|
26
|
+
- 'docs/architecture/core-workflows.md # User interaction flows'
|
|
27
|
+
- 'docs/architecture/ui-ux-spec.md # UI/UX specifications'
|
|
28
|
+
shared:
|
|
29
|
+
- 'docs/architecture/tech-stack.md # Technology constraints'
|
|
30
|
+
- 'docs/architecture/unified-project-structure.md # Code organization'
|
|
31
|
+
- 'docs/architecture/coding-standards.md # Project conventions'
|
|
32
|
+
- 'docs/architecture/testing-strategy.md # Testing requirements'
|
|
33
|
+
additional_docs:
|
|
34
|
+
- 'docs/tech-stack.md # Technology stack (if separate)'
|
|
35
|
+
- 'docs/data-models.md # Data models (if separate)'
|
|
36
|
+
- 'docs/api-reference.md # API reference (if separate)'
|
|
37
|
+
- 'docs/frontend-architecture.md # Frontend arch (if separate)'
|
|
38
|
+
bmad_core_dependencies:
|
|
39
|
+
tasks:
|
|
40
|
+
- .bmad-core/tasks/create-next-story.md
|
|
41
|
+
- .bmad-core/tasks/execute-checklist.md
|
|
42
|
+
- .bmad-core/tasks/correct-course.md
|
|
43
|
+
- .bmad-core/tasks/shard-doc.md
|
|
44
|
+
- .bmad-core/tasks/index-docs.md
|
|
45
|
+
templates:
|
|
46
|
+
- .bmad-core/templates/story-tmpl.md
|
|
47
|
+
checklists:
|
|
48
|
+
- .bmad-core/checklists/story-draft-checklist.md
|
|
49
|
+
- .bmad-core/checklists/story-dod-checklist.md
|
|
50
|
+
utils:
|
|
51
|
+
- .bmad-core/utils/template-format.md
|
|
52
|
+
file_patterns:
|
|
53
|
+
story_files: '{epicNum}.{storyNum}.story.md'
|
|
54
|
+
epic_files: epic-{n}-{description}.md
|
|
55
|
+
story_statuses:
|
|
56
|
+
- Draft
|
|
57
|
+
- Approved
|
|
58
|
+
- In Progress
|
|
59
|
+
- Review
|
|
60
|
+
- Done
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# BMAD Knowledge Base
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework that combines AI agents with Agile development methodologies. The v4 system introduces a modular architecture with improved dependency management, bundle optimization, and support for both web and IDE environments.
|
|
6
|
+
|
|
7
|
+
### Key Features
|
|
8
|
+
|
|
9
|
+
- **Modular Agent System**: Specialized AI agents for each Agile role
|
|
10
|
+
- **Build System**: Automated dependency resolution and optimization
|
|
11
|
+
- **Dual Environment Support**: Optimized for both web UIs and IDEs
|
|
12
|
+
- **Reusable Resources**: Portable templates, tasks, and checklists
|
|
13
|
+
- **Slash Command Integration**: Quick agent switching and control
|
|
14
|
+
|
|
15
|
+
## Core Philosophy
|
|
16
|
+
|
|
17
|
+
### Vibe CEO'ing
|
|
18
|
+
|
|
19
|
+
You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a singular vision. Your AI agents are your high-powered team, and your role is to:
|
|
20
|
+
|
|
21
|
+
- **Direct**: Provide clear instructions and objectives
|
|
22
|
+
- **Refine**: Iterate on outputs to achieve quality
|
|
23
|
+
- **Oversee**: Maintain strategic alignment across all agents
|
|
24
|
+
|
|
25
|
+
### Core Principles
|
|
26
|
+
|
|
27
|
+
1. **MAXIMIZE_AI_LEVERAGE**: Push the AI to deliver more. Challenge outputs and iterate.
|
|
28
|
+
2. **QUALITY_CONTROL**: You are the ultimate arbiter of quality. Review all outputs.
|
|
29
|
+
3. **STRATEGIC_OVERSIGHT**: Maintain the high-level vision and ensure alignment.
|
|
30
|
+
4. **ITERATIVE_REFINEMENT**: Expect to revisit steps. This is not a linear process.
|
|
31
|
+
5. **CLEAR_INSTRUCTIONS**: Precise requests lead to better outputs.
|
|
32
|
+
6. **DOCUMENTATION_IS_KEY**: Good inputs (briefs, PRDs) lead to good outputs.
|
|
33
|
+
7. **START_SMALL_SCALE_FAST**: Test concepts, then expand.
|
|
34
|
+
8. **EMBRACE_THE_CHAOS**: Adapt and overcome challenges.
|
|
35
|
+
|
|
36
|
+
## IDE Development Workflow
|
|
37
|
+
|
|
38
|
+
1. Shard the PRD (And Architecture documents if they exist also based on workflow type) using the Doc Shard task. The BMad-Master agent can help you do this. You will select the task, provide the doc to shard and the output folder. for example: `BMad Master, please Shard the docs/prd.md to the doc/prd/ folder` - this should ask you to use the md-tree-parser which is recommended, but either way shoudl result in multiple documents being created in the folder docs/prd.
|
|
39
|
+
2. If you have fullstack, front end and or back end architecture documents you will want to follow the same thing, but shard all of these to an architecture folder instead of a prd folder.
|
|
40
|
+
3. Ensure that you have at least one epic-n.md file in your prd folder, with the stories in order to develop.
|
|
41
|
+
4. The docs or architecture folder or prd folder should have a source tree document and coding standards at a minimum. These are used by the dev agent, and the many other sharded docs are used by the SM agent.
|
|
42
|
+
5. Use a new chat window to allow the SM agent to `draft the next story`.
|
|
43
|
+
6. If you agree the story is correct, mark it as approved in the status field, and then start a new chat window with the dev agent.
|
|
44
|
+
7. Ask the dev agent to implement the next story. If you draft the story file into the chat it will save time for the dev to have to find what the next one is. The dev should follow the tasks and subtasks marking them off as they are completed. The dev agent will also leave notes potentially for the SM to know about any deviations that might have occured to help draft the next story.
|
|
45
|
+
8. Once complete and you have verified, mark it done, and start a new chat. Ask the SM to draft the next story - repeating the cycle.
|
|
46
|
+
|
|
47
|
+
With this work flow, there is only 1 story in progress at a time, worked sequentially.
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
# Document Migration Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Simple document migration that cleans up heading formats and adds epic structure for PRDs.
|
|
6
|
+
|
|
7
|
+
## Task Requirements
|
|
8
|
+
|
|
9
|
+
1. **Input**: User specifies the document to migrate (e.g., `docs/prd.md`)
|
|
10
|
+
2. **Detection**: Automatically determine if it's a PRD or other document type
|
|
11
|
+
3. **Migration**: Apply appropriate transformations
|
|
12
|
+
4. **Backup**: Create backup with `.bak` extension
|
|
13
|
+
|
|
14
|
+
## Migration Rules
|
|
15
|
+
|
|
16
|
+
### For PRDs
|
|
17
|
+
|
|
18
|
+
- Find all level 3 headings that appear to be epics
|
|
19
|
+
- Add a level 2 heading "## Epic #" (incrementing number) before each epic
|
|
20
|
+
- Also apply the heading cleanup rules below
|
|
21
|
+
|
|
22
|
+
### For All Documents
|
|
23
|
+
|
|
24
|
+
- Find all level 2 headings (`## ...`)
|
|
25
|
+
- Remove leading numbers and symbols
|
|
26
|
+
- Keep only alphabetic characters and spaces
|
|
27
|
+
- **CRITICAL**: Do not lose any information - preserve all content under appropriate headings
|
|
28
|
+
- Examples:
|
|
29
|
+
- `## 1. Foo & Bar` → `## Foo Bar`
|
|
30
|
+
- `## 2.1 Technical Overview` → `## Technical Overview`
|
|
31
|
+
- `## 3) User Experience` → `## User Experience`
|
|
32
|
+
|
|
33
|
+
### For Architecture Documents
|
|
34
|
+
|
|
35
|
+
- **PRIMARY GOAL**: Align level 2 headings to match template level 2 titles exactly
|
|
36
|
+
- **PRESERVE EVERYTHING**: Do not lose any information during migration
|
|
37
|
+
- Map existing content to the closest matching template section
|
|
38
|
+
- If content doesn't fit template sections, create appropriate level 3 subsections
|
|
39
|
+
|
|
40
|
+
## Detection Logic
|
|
41
|
+
|
|
42
|
+
A document is considered a PRD if:
|
|
43
|
+
|
|
44
|
+
- Filename contains "prd" (case insensitive)
|
|
45
|
+
- OR main title contains "Product Requirements" or "PRD"
|
|
46
|
+
- OR contains sections like "User Stories", "Functional Requirements", "Acceptance Criteria"
|
|
47
|
+
|
|
48
|
+
## Implementation Steps
|
|
49
|
+
|
|
50
|
+
1. **Backup Original**: Copy `filename.md` to `filename.md.bak`
|
|
51
|
+
2. **Detect Type**: Check if document is a PRD
|
|
52
|
+
3. **Process Headings**:
|
|
53
|
+
- Clean all level 2 headings
|
|
54
|
+
- If PRD: Add epic structure before level 3 headings that look like epics
|
|
55
|
+
4. **Write Result**: Overwrite original file with migrated content
|
|
56
|
+
|
|
57
|
+
## Epic Detection for PRDs
|
|
58
|
+
|
|
59
|
+
Level 3 headings are treated as epics if they:
|
|
60
|
+
|
|
61
|
+
- Describe features or functionality
|
|
62
|
+
- Are substantial sections (not just "Overview" or "Notes")
|
|
63
|
+
- Common epic patterns: "User Management", "Payment Processing", "Reporting Dashboard"
|
|
64
|
+
|
|
65
|
+
The epic numbering starts at 1 and increments for each epic found.
|
|
66
|
+
|
|
67
|
+
## Example
|
|
68
|
+
|
|
69
|
+
### Before (PRD):
|
|
70
|
+
|
|
71
|
+
`````markdown
|
|
72
|
+
# Product Requirements Document
|
|
73
|
+
|
|
74
|
+
## 1. Executive Summary
|
|
75
|
+
|
|
76
|
+
Content here...
|
|
77
|
+
|
|
78
|
+
## 2.1 Functional Requirements & Specs
|
|
79
|
+
|
|
80
|
+
Content here...
|
|
81
|
+
|
|
82
|
+
### User Management System
|
|
83
|
+
|
|
84
|
+
Epic content...
|
|
85
|
+
|
|
86
|
+
### Payment Processing
|
|
87
|
+
|
|
88
|
+
Epic content...
|
|
89
|
+
|
|
90
|
+
## 3) Success Metrics
|
|
91
|
+
|
|
92
|
+
Content here...
|
|
93
|
+
|
|
94
|
+
````text
|
|
95
|
+
|
|
96
|
+
### After (PRD):
|
|
97
|
+
```markdown
|
|
98
|
+
# Product Requirements Document
|
|
99
|
+
|
|
100
|
+
## Executive Summary
|
|
101
|
+
Content here...
|
|
102
|
+
|
|
103
|
+
## Functional Requirements Specs
|
|
104
|
+
Content here...
|
|
105
|
+
|
|
106
|
+
## Epic 1
|
|
107
|
+
### User Management System
|
|
108
|
+
Epic content...
|
|
109
|
+
|
|
110
|
+
## Epic 2
|
|
111
|
+
### Payment Processing
|
|
112
|
+
Epic content...
|
|
113
|
+
|
|
114
|
+
## Success Metrics
|
|
115
|
+
Content here...
|
|
116
|
+
```text
|
|
117
|
+
|
|
118
|
+
### Before (Non-PRD):
|
|
119
|
+
```markdown
|
|
120
|
+
# Architecture Document
|
|
121
|
+
|
|
122
|
+
## 1. System Overview
|
|
123
|
+
Content...
|
|
124
|
+
|
|
125
|
+
## 2.1 Technical Stack & Tools
|
|
126
|
+
Content...
|
|
127
|
+
```text
|
|
128
|
+
|
|
129
|
+
### After (Non-PRD):
|
|
130
|
+
```markdown
|
|
131
|
+
# Architecture Document
|
|
132
|
+
|
|
133
|
+
## System Overview
|
|
134
|
+
Content...
|
|
135
|
+
|
|
136
|
+
## Technical Stack Tools
|
|
137
|
+
Content...
|
|
138
|
+
````
|
|
139
|
+
`````
|
|
140
|
+
|
|
141
|
+
```text
|
|
142
|
+
|
|
143
|
+
```
|
|
@@ -0,0 +1,389 @@
|
|
|
1
|
+
# Document an Existing Project
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
|
|
6
|
+
|
|
7
|
+
## Task Instructions
|
|
8
|
+
|
|
9
|
+
### 1. Initial Project Analysis
|
|
10
|
+
|
|
11
|
+
[[LLM: Begin by conducting a comprehensive analysis of the existing project. Use available tools to:
|
|
12
|
+
|
|
13
|
+
1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
|
|
14
|
+
2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
|
|
15
|
+
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
|
|
16
|
+
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
|
|
17
|
+
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
|
|
18
|
+
|
|
19
|
+
Ask the user these elicitation questions to better understand their needs:
|
|
20
|
+
|
|
21
|
+
- What is the primary purpose of this project?
|
|
22
|
+
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
|
|
23
|
+
- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
|
|
24
|
+
- Are there any existing documentation standards or formats you prefer?
|
|
25
|
+
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
|
|
26
|
+
]]
|
|
27
|
+
|
|
28
|
+
### 2. Core Documentation Generation
|
|
29
|
+
|
|
30
|
+
[[LLM: Based on your analysis, generate the following core documentation files. Adapt the content and structure to match the specific project type and context you discovered:
|
|
31
|
+
|
|
32
|
+
**Core Documents (always generate):**
|
|
33
|
+
|
|
34
|
+
1. **docs/index.md** - Master documentation index
|
|
35
|
+
2. **docs/architecture/index.md** - Architecture documentation index
|
|
36
|
+
3. **docs/architecture/coding-standards.md** - Coding conventions and style guidelines
|
|
37
|
+
4. **docs/architecture/tech-stack.md** - Technology stack and version constraints
|
|
38
|
+
5. **docs/architecture/unified-project-structure.md** - Project structure and organization
|
|
39
|
+
6. **docs/architecture/testing-strategy.md** - Testing approaches and requirements
|
|
40
|
+
|
|
41
|
+
**Backend Documents (generate for backend/full-stack projects):**
|
|
42
|
+
|
|
43
|
+
7. **docs/architecture/backend-architecture.md** - Backend service patterns and structure
|
|
44
|
+
8. **docs/architecture/rest-api-spec.md** - API endpoint specifications
|
|
45
|
+
9. **docs/architecture/data-models.md** - Data structures and validation rules
|
|
46
|
+
10. **docs/architecture/database-schema.md** - Database design and relationships
|
|
47
|
+
11. **docs/architecture/external-apis.md** - Third-party integrations
|
|
48
|
+
|
|
49
|
+
**Frontend Documents (generate for frontend/full-stack projects):**
|
|
50
|
+
|
|
51
|
+
12. **docs/architecture/frontend-architecture.md** - Frontend patterns and structure
|
|
52
|
+
13. **docs/architecture/components.md** - UI component specifications
|
|
53
|
+
14. **docs/architecture/core-workflows.md** - User interaction flows
|
|
54
|
+
15. **docs/architecture/ui-ux-spec.md** - UI/UX specifications and guidelines
|
|
55
|
+
|
|
56
|
+
**Additional Documents (generate if applicable):**
|
|
57
|
+
|
|
58
|
+
16. **docs/prd.md** - Product requirements document (if not exists)
|
|
59
|
+
17. **docs/architecture/deployment-guide.md** - Deployment and operations info
|
|
60
|
+
18. **docs/architecture/security-considerations.md** - Security patterns and requirements
|
|
61
|
+
19. **docs/architecture/performance-guidelines.md** - Performance optimization patterns
|
|
62
|
+
|
|
63
|
+
**Optional Enhancement Documents:**
|
|
64
|
+
|
|
65
|
+
20. **docs/architecture/troubleshooting-guide.md** - Common issues and solutions
|
|
66
|
+
21. **docs/architecture/changelog-conventions.md** - Change management practices
|
|
67
|
+
22. **docs/architecture/code-review-checklist.md** - Review standards and practices
|
|
68
|
+
|
|
69
|
+
Present each document section by section, using the advanced elicitation task after each major section.]]
|
|
70
|
+
|
|
71
|
+
### 3. Document Structure Template
|
|
72
|
+
|
|
73
|
+
[[LLM: Use this standardized structure for each documentation file, adapting content as needed:
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
# {{Document Title}}
|
|
77
|
+
|
|
78
|
+
## Overview
|
|
79
|
+
|
|
80
|
+
{{Brief description of what this document covers and why it's important for AI agents}}
|
|
81
|
+
|
|
82
|
+
## Quick Reference
|
|
83
|
+
|
|
84
|
+
{{Key points, commands, or patterns that agents need most frequently}}
|
|
85
|
+
|
|
86
|
+
## Detailed Information
|
|
87
|
+
|
|
88
|
+
{{Comprehensive information organized into logical sections}}
|
|
89
|
+
|
|
90
|
+
## Examples
|
|
91
|
+
|
|
92
|
+
{{Concrete examples showing proper usage or implementation}}
|
|
93
|
+
|
|
94
|
+
## Common Patterns
|
|
95
|
+
|
|
96
|
+
{{Recurring patterns agents should recognize and follow}}
|
|
97
|
+
|
|
98
|
+
## Things to Avoid
|
|
99
|
+
|
|
100
|
+
{{Anti-patterns, deprecated approaches, or common mistakes}}
|
|
101
|
+
|
|
102
|
+
## Related Resources
|
|
103
|
+
|
|
104
|
+
{{Links to other relevant documentation or external resources}}
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Each document should be:
|
|
108
|
+
|
|
109
|
+
- **Concrete and actionable** - Focus on what agents need to do, not just concepts
|
|
110
|
+
- **Pattern-focused** - Highlight recurring patterns agents can recognize and replicate
|
|
111
|
+
- **Example-rich** - Include specific code examples and real file references
|
|
112
|
+
- **Context-aware** - Reference actual project files, folders, and conventions
|
|
113
|
+
- **Assumption-free** - Don't assume agents know project history or implicit knowledge
|
|
114
|
+
]]
|
|
115
|
+
|
|
116
|
+
### 4. Content Guidelines for Each Document Type
|
|
117
|
+
|
|
118
|
+
#### Core Architecture Documents
|
|
119
|
+
|
|
120
|
+
##### docs/architecture/index.md
|
|
121
|
+
|
|
122
|
+
[[LLM: Create a comprehensive index of all architecture documentation:
|
|
123
|
+
|
|
124
|
+
- List all architecture documents with brief descriptions
|
|
125
|
+
- Group documents by category (backend, frontend, shared)
|
|
126
|
+
- Include quick links to key sections
|
|
127
|
+
- Provide reading order recommendations for different use cases]]
|
|
128
|
+
|
|
129
|
+
##### docs/architecture/unified-project-structure.md
|
|
130
|
+
|
|
131
|
+
[[LLM: Document the complete project structure:
|
|
132
|
+
|
|
133
|
+
- Root-level directory structure with explanations
|
|
134
|
+
- Where each type of code belongs (backend, frontend, tests, etc.)
|
|
135
|
+
- File naming conventions and patterns
|
|
136
|
+
- Module/package organization
|
|
137
|
+
- Generated vs. source file locations
|
|
138
|
+
- Build output locations]]
|
|
139
|
+
|
|
140
|
+
##### docs/architecture/coding-standards.md
|
|
141
|
+
|
|
142
|
+
[[LLM: Capture project-wide coding conventions:
|
|
143
|
+
|
|
144
|
+
- Language-specific style guidelines
|
|
145
|
+
- Naming conventions (variables, functions, classes, files)
|
|
146
|
+
- Code organization within files
|
|
147
|
+
- Import/export patterns
|
|
148
|
+
- Comment and documentation standards
|
|
149
|
+
- Linting and formatting tool configurations
|
|
150
|
+
- Git commit message conventions]]
|
|
151
|
+
|
|
152
|
+
##### docs/architecture/tech-stack.md
|
|
153
|
+
|
|
154
|
+
[[LLM: Document all technologies and versions:
|
|
155
|
+
|
|
156
|
+
- Primary languages and versions
|
|
157
|
+
- Frameworks and major libraries with versions
|
|
158
|
+
- Development tools and their versions
|
|
159
|
+
- Database systems and versions
|
|
160
|
+
- External services and APIs used
|
|
161
|
+
- Browser/runtime requirements]]
|
|
162
|
+
|
|
163
|
+
##### docs/architecture/testing-strategy.md
|
|
164
|
+
|
|
165
|
+
[[LLM: Define testing approaches and requirements:
|
|
166
|
+
|
|
167
|
+
- Test file locations and naming conventions
|
|
168
|
+
- Unit testing patterns and frameworks
|
|
169
|
+
- Integration testing approaches
|
|
170
|
+
- E2E testing setup (if applicable)
|
|
171
|
+
- Test coverage requirements
|
|
172
|
+
- Mocking strategies
|
|
173
|
+
- Test data management]]
|
|
174
|
+
|
|
175
|
+
#### Backend Architecture Documents
|
|
176
|
+
|
|
177
|
+
##### docs/architecture/backend-architecture.md
|
|
178
|
+
|
|
179
|
+
[[LLM: Document backend service structure:
|
|
180
|
+
|
|
181
|
+
- Service layer organization
|
|
182
|
+
- Controller/route patterns
|
|
183
|
+
- Middleware architecture
|
|
184
|
+
- Authentication/authorization patterns
|
|
185
|
+
- Request/response flow
|
|
186
|
+
- Background job processing
|
|
187
|
+
- Service communication patterns]]
|
|
188
|
+
|
|
189
|
+
##### docs/architecture/rest-api-spec.md
|
|
190
|
+
|
|
191
|
+
[[LLM: Specify all API endpoints:
|
|
192
|
+
|
|
193
|
+
- Base URL and versioning strategy
|
|
194
|
+
- Authentication methods
|
|
195
|
+
- Common headers and parameters
|
|
196
|
+
- Each endpoint with:
|
|
197
|
+
- HTTP method and path
|
|
198
|
+
- Request parameters/body
|
|
199
|
+
- Response format and status codes
|
|
200
|
+
- Error responses
|
|
201
|
+
- Rate limiting and quotas]]
|
|
202
|
+
|
|
203
|
+
##### docs/architecture/data-models.md
|
|
204
|
+
|
|
205
|
+
[[LLM: Define data structures and validation:
|
|
206
|
+
|
|
207
|
+
- Core business entities
|
|
208
|
+
- Data validation rules
|
|
209
|
+
- Relationships between entities
|
|
210
|
+
- Computed fields and derivations
|
|
211
|
+
- Data transformation patterns
|
|
212
|
+
- Serialization formats]]
|
|
213
|
+
|
|
214
|
+
##### docs/architecture/database-schema.md
|
|
215
|
+
|
|
216
|
+
[[LLM: Document database design:
|
|
217
|
+
|
|
218
|
+
- Database type and version
|
|
219
|
+
- Table/collection structures
|
|
220
|
+
- Indexes and constraints
|
|
221
|
+
- Relationships and foreign keys
|
|
222
|
+
- Migration patterns
|
|
223
|
+
- Seed data requirements
|
|
224
|
+
- Backup and recovery procedures]]
|
|
225
|
+
|
|
226
|
+
##### docs/architecture/external-apis.md
|
|
227
|
+
|
|
228
|
+
[[LLM: Document third-party integrations:
|
|
229
|
+
|
|
230
|
+
- List of external services used
|
|
231
|
+
- Authentication methods for each
|
|
232
|
+
- API endpoints and usage patterns
|
|
233
|
+
- Rate limits and quotas
|
|
234
|
+
- Error handling strategies
|
|
235
|
+
- Webhook configurations
|
|
236
|
+
- Data synchronization patterns]]
|
|
237
|
+
|
|
238
|
+
#### Frontend Architecture Documents
|
|
239
|
+
|
|
240
|
+
##### docs/architecture/frontend-architecture.md
|
|
241
|
+
|
|
242
|
+
[[LLM: Document frontend application structure:
|
|
243
|
+
|
|
244
|
+
- Component hierarchy and organization
|
|
245
|
+
- State management patterns
|
|
246
|
+
- Routing architecture
|
|
247
|
+
- Data fetching patterns
|
|
248
|
+
- Authentication flow
|
|
249
|
+
- Error boundary strategies
|
|
250
|
+
- Performance optimization patterns]]
|
|
251
|
+
|
|
252
|
+
##### docs/architecture/components.md
|
|
253
|
+
|
|
254
|
+
[[LLM: Specify UI components:
|
|
255
|
+
|
|
256
|
+
- Component library/design system used
|
|
257
|
+
- Custom component specifications
|
|
258
|
+
- Props and state for each component
|
|
259
|
+
- Component composition patterns
|
|
260
|
+
- Styling approaches
|
|
261
|
+
- Accessibility requirements
|
|
262
|
+
- Component testing patterns]]
|
|
263
|
+
|
|
264
|
+
##### docs/architecture/core-workflows.md
|
|
265
|
+
|
|
266
|
+
[[LLM: Document user interaction flows:
|
|
267
|
+
|
|
268
|
+
- Major user journeys
|
|
269
|
+
- Screen flow diagrams
|
|
270
|
+
- Form handling patterns
|
|
271
|
+
- Navigation patterns
|
|
272
|
+
- Data flow through workflows
|
|
273
|
+
- Error states and recovery
|
|
274
|
+
- Loading and transition states]]
|
|
275
|
+
|
|
276
|
+
##### docs/architecture/ui-ux-spec.md
|
|
277
|
+
|
|
278
|
+
[[LLM: Define UI/UX guidelines:
|
|
279
|
+
|
|
280
|
+
- Design system specifications
|
|
281
|
+
- Color palette and typography
|
|
282
|
+
- Spacing and layout grids
|
|
283
|
+
- Responsive breakpoints
|
|
284
|
+
- Animation and transition guidelines
|
|
285
|
+
- Accessibility standards
|
|
286
|
+
- Browser compatibility requirements]]
|
|
287
|
+
|
|
288
|
+
### 5. Adaptive Content Strategy
|
|
289
|
+
|
|
290
|
+
[[LLM: Adapt your documentation approach based on project characteristics:
|
|
291
|
+
|
|
292
|
+
**For Web Applications:**
|
|
293
|
+
|
|
294
|
+
- Focus on component patterns, routing, state management
|
|
295
|
+
- Include build processes, asset handling, and deployment
|
|
296
|
+
- Cover API integration patterns and data fetching
|
|
297
|
+
|
|
298
|
+
**For Backend Services:**
|
|
299
|
+
|
|
300
|
+
- Emphasize service architecture, data models, and API design
|
|
301
|
+
- Include database interaction patterns and migration strategies
|
|
302
|
+
- Cover authentication, authorization, and security patterns
|
|
303
|
+
|
|
304
|
+
**For CLI Tools:**
|
|
305
|
+
|
|
306
|
+
- Focus on command structure, argument parsing, and output formatting
|
|
307
|
+
- Include plugin/extension patterns if applicable
|
|
308
|
+
- Cover configuration file handling and user interaction patterns
|
|
309
|
+
|
|
310
|
+
**For Libraries/Frameworks:**
|
|
311
|
+
|
|
312
|
+
- Emphasize public API design and usage patterns
|
|
313
|
+
- Include extension points and customization approaches
|
|
314
|
+
- Cover versioning, compatibility, and migration strategies
|
|
315
|
+
|
|
316
|
+
**For Mobile Applications:**
|
|
317
|
+
|
|
318
|
+
- Focus on platform-specific patterns and navigation
|
|
319
|
+
- Include state management and data persistence approaches
|
|
320
|
+
- Cover platform integration and native feature usage
|
|
321
|
+
|
|
322
|
+
**For Data Science/ML Projects:**
|
|
323
|
+
|
|
324
|
+
- Emphasize data pipeline patterns and model organization
|
|
325
|
+
- Include experiment tracking and reproducibility approaches
|
|
326
|
+
- Cover data validation and model deployment patterns
|
|
327
|
+
]]
|
|
328
|
+
|
|
329
|
+
### 6. Quality Assurance
|
|
330
|
+
|
|
331
|
+
[[LLM: Before completing each document:
|
|
332
|
+
|
|
333
|
+
1. **Accuracy Check**: Verify all file paths, commands, and code examples work
|
|
334
|
+
2. **Completeness Review**: Ensure the document covers the most important patterns an agent would encounter
|
|
335
|
+
3. **Clarity Assessment**: Check that explanations are clear and actionable
|
|
336
|
+
4. **Consistency Verification**: Ensure terminology and patterns align across all documents
|
|
337
|
+
5. **Agent Perspective**: Review from the viewpoint of an AI agent that needs to contribute to this project
|
|
338
|
+
|
|
339
|
+
Ask the user to review each completed document and use the advanced elicitation task to refine based on their feedback.]]
|
|
340
|
+
|
|
341
|
+
### 7. Final Integration
|
|
342
|
+
|
|
343
|
+
[[LLM: After all documents are completed:
|
|
344
|
+
|
|
345
|
+
1. Ensure all documents are created in the proper BMAD-expected locations:
|
|
346
|
+
|
|
347
|
+
- Core docs in `docs/` (index.md, prd.md)
|
|
348
|
+
- Architecture shards in `docs/architecture/` subdirectory
|
|
349
|
+
- Create the `docs/architecture/` directory if it doesn't exist
|
|
350
|
+
|
|
351
|
+
2. Create/update the master index documents:
|
|
352
|
+
|
|
353
|
+
- Update `docs/index.md` to reference all documentation
|
|
354
|
+
- Create `docs/architecture/index.md` listing all architecture shards
|
|
355
|
+
|
|
356
|
+
3. Verify document cross-references:
|
|
357
|
+
|
|
358
|
+
- Ensure all documents link to related documentation
|
|
359
|
+
- Check that file paths match the actual project structure
|
|
360
|
+
- Validate that examples reference real files in the project
|
|
361
|
+
|
|
362
|
+
4. Provide maintenance guidance:
|
|
363
|
+
|
|
364
|
+
- Document update triggers (when to update each doc)
|
|
365
|
+
- Create a simple checklist for keeping docs current
|
|
366
|
+
- Suggest automated validation approaches
|
|
367
|
+
|
|
368
|
+
5. Summary report including:
|
|
369
|
+
- List of all documents created with their paths
|
|
370
|
+
- Any gaps or areas needing human review
|
|
371
|
+
- Recommendations for project-specific additions
|
|
372
|
+
- Next steps for maintaining documentation accuracy
|
|
373
|
+
|
|
374
|
+
Present a summary of what was created and ask if any additional documentation would be helpful for AI agents working on this specific project.]]
|
|
375
|
+
|
|
376
|
+
## Success Criteria
|
|
377
|
+
|
|
378
|
+
- Documentation enables AI agents to understand project context without additional explanation
|
|
379
|
+
- All major architectural patterns and coding conventions are captured
|
|
380
|
+
- Examples reference actual project files and demonstrate real usage
|
|
381
|
+
- Documentation is structured consistently and easy to navigate
|
|
382
|
+
- Content is actionable and focuses on what agents need to do, not just understand
|
|
383
|
+
|
|
384
|
+
## Notes
|
|
385
|
+
|
|
386
|
+
- This task is designed to work with any project type, language, or framework
|
|
387
|
+
- The documentation should reflect the project as it actually is, not as it should be
|
|
388
|
+
- Focus on patterns that agents can recognize and replicate consistently
|
|
389
|
+
- Include both positive examples (what to do) and negative examples (what to avoid)
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Create AI Frontend Prompt Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
To generate a masterful, comprehensive, and optimized prompt that can be used with any AI-driven frontend development tool (e.g., Vercel v0, Lovable.ai, or similar) to scaffold or generate significant portions of a frontend application.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- Completed UI/UX Specification (`front-end-spec`)
|
|
10
|
+
- Completed Frontend Architecture Document (`front-end-architecture`) or a full stack combined architecture such as `architecture.md`
|
|
11
|
+
- Main System Architecture Document (`architecture` - for API contracts and tech stack to give further context)
|
|
12
|
+
|
|
13
|
+
## Key Activities & Instructions
|
|
14
|
+
|
|
15
|
+
### 1. Core Prompting Principles
|
|
16
|
+
|
|
17
|
+
Before generating the prompt, you must understand these core principles for interacting with a generative AI for code.
|
|
18
|
+
|
|
19
|
+
- **Be Explicit and Detailed**: The AI cannot read your mind. Provide as much detail and context as possible. Vague requests lead to generic or incorrect outputs.
|
|
20
|
+
- **Iterate, Don't Expect Perfection**: Generating an entire complex application in one go is rare. The most effective method is to prompt for one component or one section at a time, then build upon the results.
|
|
21
|
+
- **Provide Context First**: Always start by providing the AI with the necessary context, such as the tech stack, existing code snippets, and overall project goals.
|
|
22
|
+
- **Mobile-First Approach**: Frame all UI generation requests with a mobile-first design mindset. Describe the mobile layout first, then provide separate instructions for how it should adapt for tablet and desktop.
|
|
23
|
+
|
|
24
|
+
### 2. The Structured Prompting Framework
|
|
25
|
+
|
|
26
|
+
To ensure the highest quality output, you MUST structure every prompt using the following four-part framework.
|
|
27
|
+
|
|
28
|
+
1. **High-Level Goal**: Start with a clear, concise summary of the overall objective. This orients the AI on the primary task.
|
|
29
|
+
- _Example: "Create a responsive user registration form with client-side validation and API integration."_
|
|
30
|
+
2. **Detailed, Step-by-Step Instructions**: Provide a granular, numbered list of actions the AI should take. Break down complex tasks into smaller, sequential steps. This is the most critical part of the prompt.
|
|
31
|
+
- _Example: "1. Create a new file named `RegistrationForm.js`. 2. Use React hooks for state management. 3. Add styled input fields for 'Name', 'Email', and 'Password'. 4. For the email field, ensure it is a valid email format. 5. On submission, call the API endpoint defined below."_
|
|
32
|
+
3. **Code Examples, Data Structures & Constraints**: Include any relevant snippets of existing code, data structures, or API contracts. This gives the AI concrete examples to work with. Crucially, you must also state what _not_ to do.
|
|
33
|
+
- _Example: "Use this API endpoint: `POST /api/register`. The expected JSON payload is `{ "name": "string", "email": "string", "password": "string" }`. Do NOT include a 'confirm password' field. Use Tailwind CSS for all styling."_
|
|
34
|
+
4. **Define a Strict Scope**: Explicitly define the boundaries of the task. Tell the AI which files it can modify and, more importantly, which files to leave untouched to prevent unintended changes across the codebase.
|
|
35
|
+
- _Example: "You should only create the `RegistrationForm.js` component and add it to the `pages/register.js` file. Do NOT alter the `Navbar.js` component or any other existing page or component."_
|
|
36
|
+
|
|
37
|
+
### 3. Assembling the Master Prompt
|
|
38
|
+
|
|
39
|
+
You will now synthesize the inputs and the above principles into a final, comprehensive prompt.
|
|
40
|
+
|
|
41
|
+
1. **Gather Foundational Context**:
|
|
42
|
+
- Start the prompt with a preamble describing the overall project purpose, the full tech stack (e.g., Next.js, TypeScript, Tailwind CSS), and the primary UI component library being used.
|
|
43
|
+
2. **Describe the Visuals**:
|
|
44
|
+
- If the user has design files (Figma, etc.), instruct them to provide links or screenshots.
|
|
45
|
+
- If not, describe the visual style: color palette, typography, spacing, and overall aesthetic (e.g., "minimalist", "corporate", "playful").
|
|
46
|
+
3. **Build the Prompt using the Structured Framework**:
|
|
47
|
+
- Follow the four-part framework from Section 2 to build out the core request, whether it's for a single component or a full page.
|
|
48
|
+
4. **Present and Refine**:
|
|
49
|
+
- Output the complete, generated prompt in a clear, copy-pasteable format (e.g., a large code block).
|
|
50
|
+
- Explain the structure of the prompt and why certain information was included, referencing the principles above.
|
|
51
|
+
- <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>
|