feat(bmvcs): add VCS workflow templates
Add 5 VCS adaptation templates for different workflows: - git-github-flow.yaml: Simple feature branches (40% of users) - git-gitflow.yaml: Structured releases (20% of users) - git-trunk-based.yaml: Continuous deployment (15% of users) - no-vcs.yaml: Prototypes and one-time scripts (5% of users) - custom-generic.yaml: Custom/legacy VCS systems (10% of users) Templates support VCS-agnostic artifact generation across all BMAD agents. Part 2/5 of BMVCS migration (#661) Completes core VCS discovery functionality 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Serhii
parent
2137a7790b
commit
8d342f3bd7
|
|
@ -0,0 +1,117 @@
|
|||
# Custom/Generic VCS Template
|
||||
# For ~10% of users - SVN, Perforce, custom workflows, complex setups
|
||||
|
||||
name: Custom/Generic VCS
|
||||
description: Adaptable template for non-standard version control systems
|
||||
optimized_for: "Legacy systems, enterprise custom workflows, specialized VCS tools"
|
||||
|
||||
discovery_required:
|
||||
questions_to_ask:
|
||||
- "What commands do you use to save changes?"
|
||||
- "How do you mark versions or milestones?"
|
||||
- "How do team members share code?"
|
||||
- "What's your review process?"
|
||||
- "Any specific naming conventions?"
|
||||
|
||||
artifact_patterns:
|
||||
architecture:
|
||||
structure: "flexible"
|
||||
format: |
|
||||
- Ask: "What format works best with your system?"
|
||||
- Default to markdown if no preference
|
||||
- Avoid Git-specific terminology
|
||||
terminology_mapping:
|
||||
- instead_of: "branch"
|
||||
use: "workspace/stream/variant"
|
||||
- instead_of: "commit"
|
||||
use: "changeset/submission/check-in"
|
||||
- instead_of: "merge"
|
||||
use: "integrate/incorporate/combine"
|
||||
stories:
|
||||
format: |
|
||||
- Ask about existing story/task tracking
|
||||
- Adapt to their terminology
|
||||
- Focus on deliverables, not process
|
||||
|
||||
code:
|
||||
delivery: "aligned-to-vcs"
|
||||
format: |
|
||||
- Ask: "How should code changes be packaged?"
|
||||
- Follow their existing patterns
|
||||
- Document changes clearly
|
||||
|
||||
agent_adaptations:
|
||||
architect:
|
||||
- Use VCS-neutral language
|
||||
- Ask about their documentation standards
|
||||
- Adapt diagrams to their tooling
|
||||
|
||||
pm:
|
||||
- Align with existing requirement formats
|
||||
- Use their project terminology
|
||||
- No assumptions about workflow
|
||||
|
||||
sm:
|
||||
- Match their task breakdown approach
|
||||
- Use their status terminology
|
||||
- Respect existing processes
|
||||
|
||||
dev:
|
||||
- Follow their code organization
|
||||
- Match their change description format
|
||||
- No Git-specific suggestions
|
||||
|
||||
qa:
|
||||
- Align with their testing workflow
|
||||
- Use their defect tracking terms
|
||||
- Respect existing procedures
|
||||
|
||||
generic_terminology:
|
||||
version_control_neutral:
|
||||
- 'Use "Save changes" instead of "commit"'
|
||||
- 'Use "Code variant" instead of "branch"'
|
||||
- 'Use "Combine changes" instead of "merge"'
|
||||
- 'Use "Change history" instead of "git log"'
|
||||
- 'Use "Revert changes" instead of "git revert"'
|
||||
|
||||
svn_specific:
|
||||
if_detected: "Subversion/SVN"
|
||||
adaptations:
|
||||
- 'Use "revision" instead of "commit"'
|
||||
- "Trunk/branches/tags structure"
|
||||
- "Revision numbers, not hashes"
|
||||
- '"svn update" before changes'
|
||||
|
||||
perforce_specific:
|
||||
if_detected: "Perforce"
|
||||
adaptations:
|
||||
- 'Use "changelist" instead of "commit"'
|
||||
- "Workspace/depot terminology"
|
||||
- "Client specs consideration"
|
||||
- "Large binary file handling"
|
||||
|
||||
adaptation_strategy: |
|
||||
1. Never assume - always ask
|
||||
2. Learn their terminology first
|
||||
3. Mirror their existing patterns
|
||||
4. Document in their style
|
||||
5. Deliver in their format
|
||||
|
||||
example_interactions:
|
||||
discovering_process: |
|
||||
BMAD: "How do you typically save and share code changes?"
|
||||
User: "We use Perforce with numbered changelists"
|
||||
BMAD: "Got it! I'll use Perforce terminology. Should I organize
|
||||
changes as separate changelists or group them?"
|
||||
|
||||
adapting_output: |
|
||||
Instead of: "Create a feature branch and commit changes"
|
||||
Generate: "Create a workspace and submit a changelist"
|
||||
|
||||
best_practices:
|
||||
- "Listen more than suggest"
|
||||
- "Use their language, not ours"
|
||||
- "Ask when uncertain"
|
||||
- "Document their process, don't change it"
|
||||
- "Be flexible in output format"
|
||||
- "Respect existing workflows"
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
# Git GitFlow Adaptation Template
|
||||
# For ~20% of users - versioned releases
|
||||
|
||||
name: GitFlow
|
||||
description: Structured branches with develop, release, and hotfix flows
|
||||
optimized_for: "Desktop software, mobile apps, versioned APIs, scheduled releases"
|
||||
|
||||
artifact_patterns:
|
||||
architecture:
|
||||
structure: "version-aligned"
|
||||
location: "docs/architecture/"
|
||||
format: |
|
||||
- Main architecture in docs/architecture/
|
||||
- Version-specific changes in docs/releases/v{version}/
|
||||
- Comprehensive planning documents
|
||||
|
||||
stories:
|
||||
granularity: "medium"
|
||||
size: "3-5 days of work"
|
||||
format: |
|
||||
- Stories grouped by release version
|
||||
- Located in docs/releases/v{version}/stories/
|
||||
- Can span multiple commits in feature branch
|
||||
|
||||
commits:
|
||||
style: "descriptive"
|
||||
branch_prefixes:
|
||||
feature: "feature/"
|
||||
release: "release/"
|
||||
hotfix: "hotfix/"
|
||||
bugfix: "bugfix/"
|
||||
examples:
|
||||
- "feature/user-auth: implement OAuth2 flow"
|
||||
- "release/2.1.0: prepare release notes"
|
||||
- "hotfix/critical-payment-bug: fix decimal handling"
|
||||
|
||||
agent_adaptations:
|
||||
architect:
|
||||
- Generate comprehensive release-oriented architecture
|
||||
- Include version migration guides
|
||||
- Document breaking changes clearly
|
||||
|
||||
pm:
|
||||
- Create release-scoped PRDs
|
||||
- Define features by target version
|
||||
- Maintain product roadmap document
|
||||
|
||||
sm:
|
||||
- Group stories by release milestone
|
||||
- Create epic-level organization
|
||||
- Track story status across branches
|
||||
|
||||
dev:
|
||||
- Follow branch naming conventions strictly
|
||||
- Include version tags in code comments
|
||||
- Generate migration scripts when needed
|
||||
|
||||
qa:
|
||||
- Comprehensive test plans per release
|
||||
- Regression test suites for versions
|
||||
- Hotfix validation procedures
|
||||
|
||||
version_management:
|
||||
develop_branch: "Latest development work"
|
||||
main_branch: "Production-ready releases only"
|
||||
release_process: |
|
||||
1. Branch release/x.y.z from develop
|
||||
2. Fix bugs in release branch
|
||||
3. Merge to main and tag
|
||||
4. Merge back to develop
|
||||
|
||||
best_practices:
|
||||
- "Never commit directly to main"
|
||||
- "Feature branches from develop, not main"
|
||||
- "Hotfixes from main, merge to both main and develop"
|
||||
- "Release branches for final preparations"
|
||||
- "Semantic versioning (MAJOR.MINOR.PATCH)"
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Git GitHub Flow Adaptation Template
|
||||
# For ~40% of users - the most common workflow
|
||||
|
||||
name: GitHub Flow
|
||||
description: Simple feature branches with pull requests
|
||||
optimized_for: "Web applications, continuous deployment, small to medium teams"
|
||||
|
||||
artifact_patterns:
|
||||
architecture:
|
||||
structure: "feature-aligned"
|
||||
location: "docs/architecture/features/{feature-name}/"
|
||||
format: |
|
||||
- Main architecture in docs/architecture/README.md
|
||||
- Feature additions in feature branches
|
||||
- Lightweight, PR-friendly documents
|
||||
|
||||
stories:
|
||||
granularity: "small"
|
||||
size: "1-3 days of work"
|
||||
format: |
|
||||
- One story per PR ideal
|
||||
- Story file travels with code changes
|
||||
- Located in docs/stories/{story-id}.md
|
||||
|
||||
commits:
|
||||
style: "conventional"
|
||||
examples:
|
||||
- "feat: add user authentication"
|
||||
- "fix: resolve login timeout issue"
|
||||
- "docs: update API documentation"
|
||||
pr_description: |
|
||||
## What
|
||||
Brief description of changes
|
||||
|
||||
## Why
|
||||
Context from story: {story-id}
|
||||
|
||||
## Testing
|
||||
- [ ] Unit tests pass
|
||||
- [ ] Manual testing completed
|
||||
|
||||
agent_adaptations:
|
||||
architect:
|
||||
- Generate lightweight, modular architecture docs
|
||||
- Focus on changed components only
|
||||
- Include "Impact Analysis" section for features
|
||||
|
||||
pm:
|
||||
- Create feature-scoped PRDs when needed
|
||||
- Keep requirements atomic and PR-sized
|
||||
|
||||
sm:
|
||||
- Generate small, independent stories
|
||||
- Each story should map to one PR
|
||||
- Include acceptance criteria for PR review
|
||||
|
||||
dev:
|
||||
- Suggest feature branch names: feature/story-{id}
|
||||
- Generate atomic commits
|
||||
- Include PR template in first commit
|
||||
|
||||
qa:
|
||||
- Test plans per PR
|
||||
- Focus on regression in changed areas
|
||||
- Checklist format for PR reviews
|
||||
|
||||
best_practices:
|
||||
- "Keep PRs small - under 400 lines ideal"
|
||||
- "One story = One PR when possible"
|
||||
- "Branch from main, merge to main"
|
||||
- "Delete branches after merge"
|
||||
- "Deploy immediately after merge (if CI passes)"
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
# Git Trunk-Based Development Template
|
||||
# For ~15% of users - mature CI/CD teams
|
||||
|
||||
name: Trunk-Based Development
|
||||
description: Direct commits or very short-lived branches to main
|
||||
optimized_for: "Continuous deployment, mature DevOps teams, microservices"
|
||||
|
||||
prerequisites:
|
||||
required:
|
||||
- "Comprehensive automated testing"
|
||||
- "Feature flags system"
|
||||
- "CI/CD pipeline with automatic rollback"
|
||||
recommended:
|
||||
- "Monitoring and alerting"
|
||||
- "Blue-green or canary deployments"
|
||||
|
||||
artifact_patterns:
|
||||
architecture:
|
||||
structure: "incrementally-evolving"
|
||||
location: "docs/architecture/"
|
||||
format: |
|
||||
- Living documents that evolve with each change
|
||||
- Feature flags documented inline
|
||||
- ADRs (Architecture Decision Records) for changes
|
||||
|
||||
stories:
|
||||
granularity: "tiny"
|
||||
size: "Hours to 1 day maximum"
|
||||
format: |
|
||||
- Ultra-small, immediately mergeable
|
||||
- Flag-gated feature development
|
||||
- Located in docs/stories/current/
|
||||
|
||||
commits:
|
||||
style: "atomic"
|
||||
frequency: "Multiple per day"
|
||||
examples:
|
||||
- "add user email validation behind flag:validate-email"
|
||||
- "refactor payment service for performance"
|
||||
- "enable feature flag:new-checkout-flow for 10% users"
|
||||
flag_convention: "flag:{feature-name}"
|
||||
|
||||
agent_adaptations:
|
||||
architect:
|
||||
- Design for feature flags from start
|
||||
- Document flag dependencies
|
||||
- Create rollback procedures
|
||||
|
||||
pm:
|
||||
- Define features as flag-gated increments
|
||||
- Specify rollout percentages
|
||||
- Create flag retirement timeline
|
||||
|
||||
sm:
|
||||
- Generate tiny, atomic stories
|
||||
- Each story deployable behind flag
|
||||
- Include flag configuration in story
|
||||
|
||||
dev:
|
||||
- Implement feature flags first
|
||||
- Keep changes small and isolated
|
||||
- Include flag cleanup tasks
|
||||
- Commit directly or PR within hours
|
||||
|
||||
qa:
|
||||
- Test with flags on/off
|
||||
- Automated test coverage mandatory
|
||||
- Performance testing for each change
|
||||
|
||||
feature_flags:
|
||||
naming: "kebab-case-descriptive"
|
||||
structure: |
|
||||
{
|
||||
"flag": "new-user-dashboard",
|
||||
"description": "Redesigned dashboard for users",
|
||||
"rollout": {
|
||||
"dev": 100,
|
||||
"staging": 100,
|
||||
"production": 10
|
||||
},
|
||||
"expiry": "2024-Q2"
|
||||
}
|
||||
|
||||
ci_cd_requirements:
|
||||
pipeline: |
|
||||
1. Automated tests (must pass)
|
||||
2. Security scanning
|
||||
3. Deploy to staging
|
||||
4. Smoke tests
|
||||
5. Deploy to production (behind flag)
|
||||
6. Progressive rollout
|
||||
|
||||
best_practices:
|
||||
- "Main branch always deployable"
|
||||
- "No long-lived branches (max 24 hours)"
|
||||
- "Feature flags for all new functionality"
|
||||
- "Small, frequent commits"
|
||||
- "Pair programming or immediate review"
|
||||
- "Rollback is always an option"
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
# No Version Control Template
|
||||
# For ~5% of users - prototypes, one-time scripts, POCs
|
||||
|
||||
name: No Version Control
|
||||
description: Single deliverable packages without version tracking
|
||||
optimized_for: "Prototypes, data migrations, one-time scripts, proof of concepts"
|
||||
|
||||
artifact_patterns:
|
||||
architecture:
|
||||
structure: "monolithic"
|
||||
location: "deliverables/"
|
||||
format: |
|
||||
- Single comprehensive document
|
||||
- All requirements embedded
|
||||
- Self-contained package
|
||||
naming: "{project}_{type}_YYYYMMDD.md"
|
||||
|
||||
stories:
|
||||
granularity: "complete-features"
|
||||
format: |
|
||||
- All stories in one document
|
||||
- Sequential implementation order
|
||||
- No branching considerations
|
||||
naming: "{project}_requirements_YYYYMMDD.md"
|
||||
|
||||
code:
|
||||
delivery: "complete-packages"
|
||||
format: |
|
||||
- All code in one deliverable
|
||||
- Extensive inline comments
|
||||
- Setup instructions included
|
||||
naming: "{project}_complete_YYYYMMDD.zip"
|
||||
|
||||
package_structure:
|
||||
example: |
|
||||
project_20240315/
|
||||
├── README.md # Complete instructions
|
||||
├── requirements.txt # All dependencies
|
||||
├── src/ # All source code
|
||||
│ └── main.py
|
||||
├── docs/ # All documentation
|
||||
│ ├── architecture.md
|
||||
│ └── requirements.md
|
||||
├── scripts/ # Setup/run scripts
|
||||
│ └── setup.sh
|
||||
└── tests/ # Test files if any
|
||||
|
||||
agent_adaptations:
|
||||
architect:
|
||||
- Generate single, complete architecture document
|
||||
- Include all diagrams inline (base64 or ASCII)
|
||||
- No references to branches or versions
|
||||
- Date-stamp all documents
|
||||
|
||||
pm:
|
||||
- Create comprehensive PRD upfront
|
||||
- All requirements in one document
|
||||
- Clear success criteria
|
||||
|
||||
sm:
|
||||
- Sequential story implementation plan
|
||||
- Dependencies clearly mapped
|
||||
- No parallel work assumptions
|
||||
|
||||
dev:
|
||||
- Generate complete, runnable code
|
||||
- Extensive comments explaining logic
|
||||
- No commit messages
|
||||
- Include all necessary files
|
||||
|
||||
qa:
|
||||
- Single test plan document
|
||||
- Manual test procedures
|
||||
- No regression considerations
|
||||
|
||||
documentation:
|
||||
readme_template: |
|
||||
# {Project Name}
|
||||
Generated: {Date}
|
||||
|
||||
## Quick Start
|
||||
1. Extract all files
|
||||
2. Run setup script: ./scripts/setup.sh
|
||||
3. Execute: python src/main.py
|
||||
|
||||
## Requirements
|
||||
- Python 3.8+
|
||||
- Dependencies in requirements.txt
|
||||
|
||||
## What This Does
|
||||
{Clear description}
|
||||
|
||||
## File Descriptions
|
||||
{List each file and its purpose}
|
||||
|
||||
## Notes
|
||||
- This is a complete, self-contained package
|
||||
- No version control required
|
||||
- For questions, refer to docs/
|
||||
|
||||
best_practices:
|
||||
- "Date-stamp everything"
|
||||
- "Over-document rather than under-document"
|
||||
- "Include all dependencies explicitly"
|
||||
- "Test the complete package before delivery"
|
||||
- "One ZIP/folder contains everything"
|
||||
- "No external references"
|
||||
Loading…
Reference in New Issue