Brachnha/brachnha-insight
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ignore and untrack BMad directories

Browse Source
This commit is contained in:
Max
2026-01-26 15:49:36 +07:00
parent 7b732372e3
commit 6b113e0392
525 changed files with 2 additions and 112645 deletions
Download Patch File Download Diff File Expand all files Collapse all files

156
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-01-mode-detection.md
View File

@@ -1,156 +0,0 @@
---
name: 'step-01-mode-detection'
description: 'Determine execution mode (tech-spec vs direct), handle escalation, set state variables'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-01-mode-detection.md'
nextStepFile_modeA: './step-03-execute.md'
nextStepFile_modeB: './step-02-context-gathering.md'
---
# Step 1: Mode Detection
**Goal:** Determine execution mode, capture baseline, handle escalation if needed.
---
## STATE VARIABLES (capture now, persist throughout)
These variables MUST be set in this step and available to all subsequent steps:
- `{baseline_commit}` - Git HEAD at workflow start (or "NO_GIT" if not a git repo)
- `{execution_mode}` - "tech-spec" or "direct"
- `{tech_spec_path}` - Path to tech-spec file (if Mode A)
---
## EXECUTION SEQUENCE
### 1. Capture Baseline
First, check if the project uses Git version control:
**If Git repo exists** (`.git` directory present or `git rev-parse --is-inside-work-tree` succeeds):
- Run `git rev-parse HEAD` and store result as `{baseline_commit}`
**If NOT a Git repo:**
- Set `{baseline_commit}` = "NO_GIT"
### 2. Load Project Context
Check if `{project_context}` exists (`**/project-context.md`). If found, load it as a foundational reference for ALL implementation decisions.
### 3. Parse User Input
Analyze the user's input to determine mode:
**Mode A: Tech-Spec**
- User provided a path to a tech-spec file (e.g., `quick-dev tech-spec-auth.md`)
- Load the spec, extract tasks/context/AC
- Set `{execution_mode}` = "tech-spec"
- Set `{tech_spec_path}` = provided path
- **NEXT:** Load `step-03-execute.md`
**Mode B: Direct Instructions**
- User provided task description directly (e.g., `refactor src/foo.ts...`)
- Set `{execution_mode}` = "direct"
- **NEXT:** Evaluate escalation threshold, then proceed
---
## ESCALATION THRESHOLD (Mode B only)
Evaluate user input with minimal token usage (no file loading):
**Triggers escalation (if 2+ signals present):**
- Multiple components mentioned (dashboard + api + database)
- System-level language (platform, integration, architecture)
- Uncertainty about approach ("how should I", "best way to")
- Multi-layer scope (UI + backend + data together)
- Extended timeframe ("this week", "over the next few days")
**Reduces signal:**
- Simplicity markers ("just", "quickly", "fix", "bug", "typo", "simple")
- Single file/component focus
- Confident, specific request
Use holistic judgment, not mechanical keyword matching.
---
## ESCALATION HANDLING
### No Escalation (simple request)
Present choice:
```
**[t] Plan first** - Create tech-spec then implement
**[e] Execute directly** - Start now
```
- **[t]:** Direct user to `{quick_spec_workflow}`. **EXIT Quick Dev.**
- **[e]:** Ask for any additional guidance, then **NEXT:** Load `step-02-context-gathering.md`
### Escalation Triggered - Level 0-2
```
This looks like a focused feature with multiple components.
**[t] Create tech-spec first** (recommended)
**[w] Seems bigger than quick-dev** - see what BMad Method recommends
**[e] Execute directly**
```
- **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
### Escalation Triggered - Level 3+
```
This sounds like platform/system work.
**[w] Start BMad Method** (recommended)
**[t] Create tech-spec** (lighter planning)
**[e] Execute directly** - feeling lucky
```
- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
- **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
---
## NEXT STEP DIRECTIVE
**CRITICAL:** When this step completes, explicitly state which step to load:
- Mode A (tech-spec): "**NEXT:** Loading `step-03-execute.md`"
- Mode B (direct, [e] selected): "**NEXT:** Loading `step-02-context-gathering.md`"
- Escalation ([t] or [w]): "**EXITING Quick Dev.** Follow the directed workflow."
---
## SUCCESS METRICS
- `{baseline_commit}` captured and stored
- `{execution_mode}` determined ("tech-spec" or "direct")
- `{tech_spec_path}` set if Mode A
- Project context loaded if exists
- Escalation evaluated appropriately (Mode B)
- Explicit NEXT directive provided
## FAILURE MODES
- Proceeding without capturing baseline commit
- Not setting execution_mode variable
- Loading step-02 when Mode A (tech-spec provided)
- Attempting to "return" after escalation instead of EXIT
- No explicit NEXT directive at step completion

120
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-02-context-gathering.md
View File

@@ -1,120 +0,0 @@
---
name: 'step-02-context-gathering'
description: 'Quick context gathering for direct mode - identify files, patterns, dependencies'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-02-context-gathering.md'
nextStepFile: './step-03-execute.md'
---
# Step 2: Context Gathering (Direct Mode)
**Goal:** Quickly gather context for direct instructions - files, patterns, dependencies.
**Note:** This step only runs for Mode B (direct instructions). If `{execution_mode}` is "tech-spec", this step was skipped.
---
## AVAILABLE STATE
From step-01:
- `{baseline_commit}` - Git HEAD at workflow start
- `{execution_mode}` - Should be "direct"
- `{project_context}` - Loaded if exists
---
## EXECUTION SEQUENCE
### 1. Identify Files to Modify
Based on user's direct instructions:
- Search for relevant files using glob/grep
- Identify the specific files that need changes
- Note file locations and purposes
### 2. Find Relevant Patterns
Examine the identified files and their surroundings:
- Code style and conventions used
- Existing patterns for similar functionality
- Import/export patterns
- Error handling approaches
- Test patterns (if tests exist nearby)
### 3. Note Dependencies
Identify:
- External libraries used
- Internal module dependencies
- Configuration files that may need updates
- Related files that might be affected
### 4. Create Mental Plan
Synthesize gathered context into:
- List of tasks to complete
- Acceptance criteria (inferred from user request)
- Order of operations
- Files to touch
---
## PRESENT PLAN
Display to user:
```
**Context Gathered:**
**Files to modify:**
- {list files}
**Patterns identified:**
- {key patterns}
**Plan:**
1. {task 1}
2. {task 2}
...
**Inferred AC:**
- {acceptance criteria}
Ready to execute? (y/n/adjust)
```
- **y:** Proceed to execution
- **n:** Gather more context or clarify
- **adjust:** Modify the plan based on feedback
---
## NEXT STEP DIRECTIVE
**CRITICAL:** When user confirms ready, explicitly state:
- **y:** "**NEXT:** Loading `step-03-execute.md`"
- **n/adjust:** Continue gathering context, then re-present plan
---
## SUCCESS METRICS
- Files to modify identified
- Relevant patterns documented
- Dependencies noted
- Mental plan created with tasks and AC
- User confirmed readiness to proceed
## FAILURE MODES
- Executing this step when Mode A (tech-spec)
- Proceeding without identifying files to modify
- Not presenting plan for user confirmation
- Missing obvious patterns in existing code

113
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md
View File

@@ -1,113 +0,0 @@
---
name: 'step-03-execute'
description: 'Execute implementation - iterate through tasks, write code, run tests'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-03-execute.md'
nextStepFile: './step-04-self-check.md'
---
# Step 3: Execute Implementation
**Goal:** Implement all tasks, write tests, follow patterns, handle errors.
**Critical:** Continue through ALL tasks without stopping for milestones.
---
## AVAILABLE STATE
From previous steps:
- `{baseline_commit}` - Git HEAD at workflow start
- `{execution_mode}` - "tech-spec" or "direct"
- `{tech_spec_path}` - Tech-spec file (if Mode A)
- `{project_context}` - Project patterns (if exists)
From context:
- Mode A: Tasks and AC extracted from tech-spec
- Mode B: Tasks and AC from step-02 mental plan
---
## EXECUTION LOOP
For each task:
### 1. Load Context
- Read files relevant to this task
- Review patterns from project-context or observed code
- Understand dependencies
### 2. Implement
- Write code following existing patterns
- Handle errors appropriately
- Follow conventions observed in codebase
- Add appropriate comments where non-obvious
### 3. Test
- Write tests if appropriate for the change
- Run existing tests to catch regressions
- Verify the specific AC for this task
### 4. Mark Complete
- Check off task: `- [x] Task N`
- Continue to next task immediately
---
## HALT CONDITIONS
**HALT and request guidance if:**
- 3 consecutive failures on same task
- Tests fail and fix is not obvious
- Blocking dependency discovered
- Ambiguity that requires user decision
**Do NOT halt for:**
- Minor issues that can be noted and continued
- Warnings that don't block functionality
- Style preferences (follow existing patterns)
---
## CONTINUOUS EXECUTION
**Critical:** Do not stop between tasks for approval.
- Execute all tasks in sequence
- Only halt for blocking issues
- Tests failing = fix before continuing
- Track all completed work for self-check
---
## NEXT STEP
When ALL tasks are complete (or halted on blocker), load `step-04-self-check.md`.
---
## SUCCESS METRICS
- All tasks attempted
- Code follows existing patterns
- Error handling appropriate
- Tests written where appropriate
- Tests passing
- No unnecessary halts
## FAILURE MODES
- Stopping for approval between tasks
- Ignoring existing patterns
- Not running tests after changes
- Giving up after first failure
- Not following project-context rules (if exists)

113
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-04-self-check.md
View File

@@ -1,113 +0,0 @@
---
name: 'step-04-self-check'
description: 'Self-audit implementation against tasks, tests, AC, and patterns'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-04-self-check.md'
nextStepFile: './step-05-adversarial-review.md'
---
# Step 4: Self-Check
**Goal:** Audit completed work against tasks, tests, AC, and patterns before external review.
---
## AVAILABLE STATE
From previous steps:
- `{baseline_commit}` - Git HEAD at workflow start
- `{execution_mode}` - "tech-spec" or "direct"
- `{tech_spec_path}` - Tech-spec file (if Mode A)
- `{project_context}` - Project patterns (if exists)
---
## SELF-CHECK AUDIT
### 1. Tasks Complete
Verify all tasks are marked complete:
- [ ] All tasks from tech-spec or mental plan marked `[x]`
- [ ] No tasks skipped without documented reason
- [ ] Any blocked tasks have clear explanation
### 2. Tests Passing
Verify test status:
- [ ] All existing tests still pass
- [ ] New tests written for new functionality
- [ ] No test warnings or skipped tests without reason
### 3. Acceptance Criteria Satisfied
For each AC:
- [ ] AC is demonstrably met
- [ ] Can explain how implementation satisfies AC
- [ ] Edge cases considered
### 4. Patterns Followed
Verify code quality:
- [ ] Follows existing code patterns in codebase
- [ ] Follows project-context rules (if exists)
- [ ] Error handling consistent with codebase
- [ ] No obvious code smells introduced
---
## UPDATE TECH-SPEC (Mode A only)
If `{execution_mode}` is "tech-spec":
1. Load `{tech_spec_path}`
2. Mark all tasks as `[x]` complete
3. Update status to "Implementation Complete"
4. Save changes
---
## IMPLEMENTATION SUMMARY
Present summary to transition to review:
```
**Implementation Complete!**
**Summary:** {what was implemented}
**Files Modified:** {list of files}
**Tests:** {test summary - passed/added/etc}
**AC Status:** {all satisfied / issues noted}
Proceeding to adversarial code review...
```
---
## NEXT STEP
Proceed immediately to `step-05-adversarial-review.md`.
---
## SUCCESS METRICS
- All tasks verified complete
- All tests passing
- All AC satisfied
- Patterns followed
- Tech-spec updated (if Mode A)
- Summary presented
## FAILURE MODES
- Claiming tasks complete when they're not
- Not running tests before proceeding
- Missing AC verification
- Ignoring pattern violations
- Not updating tech-spec status (Mode A)

106
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-05-adversarial-review.md
View File

@@ -1,106 +0,0 @@
---
name: 'step-05-adversarial-review'
description: 'Construct diff and invoke adversarial review task'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-05-adversarial-review.md'
nextStepFile: './step-06-resolve-findings.md'
---
# Step 5: Adversarial Code Review
**Goal:** Construct diff of all changes, invoke adversarial review task, present findings.
---
## AVAILABLE STATE
From previous steps:
- `{baseline_commit}` - Git HEAD at workflow start (CRITICAL for diff)
- `{execution_mode}` - "tech-spec" or "direct"
- `{tech_spec_path}` - Tech-spec file (if Mode A)
---
### 1. Construct Diff
Build complete diff of all changes since workflow started.
### If `{baseline_commit}` is a Git commit hash:
**Tracked File Changes:**
```bash
git diff {baseline_commit}
```
**New Untracked Files:**
Only include untracked files that YOU created during this workflow (steps 2-4).
Do not include pre-existing untracked files.
For each new file created, include its full content as a "new file" addition.
### If `{baseline_commit}` is "NO_GIT":
Use best-effort diff construction:
- List all files you modified during steps 2-4
- For each file, show the changes you made (before/after if you recall, or just current state)
- Include any new files you created with their full content
- Note: This is less precise than Git diff but still enables meaningful review
### Capture as {diff_output}
Merge all changes into `{diff_output}`.
**Note:** Do NOT `git add` anything - this is read-only inspection.
---
### 2. Invoke Adversarial Review
With `{diff_output}` constructed, invoke the review task. If possible, use information asymmetry: run this step, and only it, in a separate subagent or process with read access to the project, but no context except the `{diff_output}`.
```xml
<invoke-task>Review {diff_output} using {project-root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
```
**Platform fallback:** If task invocation not available, load the task file and execute its instructions inline, passing `{diff_output}` as the content.
The task should: review `{diff_output}` and return a list of findings.
---
### 3. Process Findings
Capture the findings from the task output.
**If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
Order findings by severity.
Number the ordered findings (F1, F2, F3, etc.).
If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
---
## NEXT STEP
With findings in hand, load `step-06-resolve-findings.md` for user to choose resolution approach.
---
## SUCCESS METRICS
- Diff constructed from baseline_commit
- New files included in diff
- Task invoked with diff as input
- Findings received
- Findings processed into TODOs or table and presented to user
## FAILURE MODES
- Missing baseline_commit (can't construct accurate diff)
- Not including new untracked files in diff
- Invoking task without providing diff input
- Accepting zero findings without questioning
- Presenting fewer findings than the review task returned without explicit instruction to do so

140
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-06-resolve-findings.md
View File

@@ -1,140 +0,0 @@
---
name: 'step-06-resolve-findings'
description: 'Handle review findings interactively, apply fixes, update tech-spec with final status'
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
thisStepFile: './step-06-resolve-findings.md'
---
# Step 6: Resolve Findings
**Goal:** Handle adversarial review findings interactively, apply fixes, finalize tech-spec.
---
## AVAILABLE STATE
From previous steps:
- `{baseline_commit}` - Git HEAD at workflow start
- `{execution_mode}` - "tech-spec" or "direct"
- `{tech_spec_path}` - Tech-spec file (if Mode A)
- Findings table from step-05
---
## RESOLUTION OPTIONS
Present choice to user:
```
How would you like to handle these findings?
**[1] Walk through** - Discuss each finding individually
**[2] Auto-fix** - Automatically fix issues classified as "real"
**[3] Skip** - Acknowledge and proceed to commit
```
---
## OPTION 1: WALK THROUGH
For each finding in order:
1. Present the finding with context
2. Ask: **fix now / skip / discuss**
3. If fix: Apply the fix immediately
4. If skip: Note as acknowledged, continue
5. If discuss: Provide more context, re-ask
6. Move to next finding
After all findings processed, summarize what was fixed/skipped.
---
## OPTION 2: AUTO-FIX
1. Filter findings to only those classified as "real"
2. Apply fixes for each real finding
3. Report what was fixed:
```
**Auto-fix Applied:**
- F1: {description of fix}
- F3: {description of fix}
...
Skipped (noise/uncertain): F2, F4
```
---
## OPTION 3: SKIP
1. Acknowledge all findings were reviewed
2. Note that user chose to proceed without fixes
3. Continue to completion
---
## UPDATE TECH-SPEC (Mode A only)
If `{execution_mode}` is "tech-spec":
1. Load `{tech_spec_path}`
2. Update status to "Completed"
3. Add review notes:
```
## Review Notes
- Adversarial review completed
- Findings: {count} total, {fixed} fixed, {skipped} skipped
- Resolution approach: {walk-through/auto-fix/skip}
```
4. Save changes
---
## COMPLETION OUTPUT
```
**Review complete. Ready to commit.**
**Implementation Summary:**
- {what was implemented}
- Files modified: {count}
- Tests: {status}
- Review findings: {X} addressed, {Y} skipped
{Explain what was implemented based on user_skill_level}
```
---
## WORKFLOW COMPLETE
This is the final step. The Quick Dev workflow is now complete.
User can:
- Commit changes
- Run additional tests
- Start new Quick Dev session
---
## SUCCESS METRICS
- User presented with resolution options
- Chosen approach executed correctly
- Fixes applied cleanly (if applicable)
- Tech-spec updated with final status (Mode A)
- Completion summary provided
- User understands what was implemented
## FAILURE MODES
- Not presenting resolution options
- Auto-fixing "noise" or "uncertain" findings
- Not updating tech-spec after resolution (Mode A)
- No completion summary
- Leaving user unclear on next steps

52
_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md
View File

@@ -1,52 +0,0 @@
---
name: quick-dev
description: 'Flexible development - execute tech-specs OR direct instructions with optional planning.'
---
# Quick Dev Workflow
**Goal:** Execute implementation tasks efficiently, either from a tech-spec or direct user instructions.
**Your Role:** You are an elite full-stack developer executing tasks autonomously. Follow patterns, ship code, run tests. Every response moves the project forward.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for focused execution:
- Each step loads fresh to combat "lost in the middle"
- State persists via variables: `{baseline_commit}`, `{execution_mode}`, `{tech_spec_path}`
- Sequential progression through implementation phases
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `user_name`, `communication_language`, `user_skill_level`
- `output_folder`, `planning_artifacts`, `implementation_artifacts`
- `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/bmad-quick-flow/quick-dev`
- `project_context` = `**/project-context.md` (load if exists)
- `project_levels` = `{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml`
### Related Workflows
- `quick_spec_workflow` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`
- `workflow_init` = `{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml`
- `party_mode_exec` = `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
- `advanced_elicitation` = `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
---
## EXECUTION
Load and execute `steps/step-01-mode-detection.md` to begin the workflow.