@the-bearded-bear/claude-craft 8.23.3 → 8.26.0-next.2a54921

package/Dev/i18n/en/Workflow/commands/analyze.md

@@ -1,208 +1,9 @@
 ---
-name: workflow-analyze
-description: Execute the Analysis phase - research, exploration, and constraint identification
-arguments:
-  - name: focus
-    description: Specific area to analyze (market, technical, competitors)
-    required: false
+description: "Deprecated (removed in 9.0): use /workflow:plan --research"
+deprecated: true
+replaced-by: /workflow:plan
 ---
 
-# /workflow:analyze
+> ⚠️ `/workflow:analyze` is deprecated and will be removed in 9.0. Use `/workflow:plan --research`.
 
-## Mission
-
-Execute the Analysis phase of the Enterprise workflow track. This phase focuses on research, exploration, and identifying constraints before detailed planning begins.
-
-## When to Use
-
-- **Enterprise track** projects
-- New platforms or major initiatives
-- When domain knowledge is limited
-- Before committing to a technical approach
-
-## Plan Mode
-
-> Plan mode is activated automatically when the scope spans multiple modules or requires cross-cutting investigation.
-
-## Workflow
-
-### Step 1: Analysis Setup
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            ANALYSIS PHASE - STARTING                      ║
-╠══════════════════════════════════════════════════════════╣
-║ Track: Enterprise                                         ║
-║ Phase: 1 of 4 - Analysis                                  ║
-║                                                           ║
-║ Objectives:                                               ║
-║ • Understand the problem domain                           ║
-║ • Research existing solutions                             ║
-║ • Identify technical constraints                          ║
-║ • Document risks and opportunities                        ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Step 2: Research Areas
-
-**Guided Research Questions:**
-
-```
-┌─────────────────────────────────────────────────────────┐
-│ DOMAIN RESEARCH                                          │
-├─────────────────────────────────────────────────────────┤
-│ 1. What problem are we solving?                          │
-│ 2. Who are the key stakeholders?                         │
-│ 3. What are the business drivers?                        │
-│ 4. What does success look like?                          │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│ MARKET RESEARCH                                          │
-├─────────────────────────────────────────────────────────┤
-│ 1. What existing solutions exist?                        │
-│ 2. What are competitors doing?                           │
-│ 3. What are industry best practices?                     │
-│ 4. What are emerging trends?                             │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│ TECHNICAL RESEARCH                                       │
-├─────────────────────────────────────────────────────────┤
-│ 1. What technologies could we use?                       │
-│ 2. What are the integration requirements?                │
-│ 3. What are the scalability needs?                       │
-│ 4. What security/compliance requirements exist?          │
-└─────────────────────────────────────────────────────────┘
-```
-
-### Step 3: Context7 Research (Optional)
-
-If MCP Context7 is configured, use it for technical research:
-
-```
-Using Context7 MCP for up-to-date documentation...
-
-Researching:
-• Latest Stripe API best practices
-• Current security standards for payment processing
-• PCI DSS compliance requirements
-```
-
-### Step 4: Constraint Identification
-
-Document constraints discovered:
-
-```
-╔══════════════════════════════════════════════════════════╗
-║               CONSTRAINTS IDENTIFIED                      ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ TECHNICAL CONSTRAINTS:                                    ║
-║ • Must integrate with existing Symfony 7.x backend        ║
-║ • Database: PostgreSQL (existing, cannot change)          ║
-║ • Must support mobile apps via existing API               ║
-║                                                           ║
-║ BUSINESS CONSTRAINTS:                                     ║
-║ • Budget: Limited to existing team                        ║
-║ • Timeline: MVP needed in Q2 2026                         ║
-║ • Must maintain backward compatibility                    ║
-║                                                           ║
-║ REGULATORY CONSTRAINTS:                                   ║
-║ • GDPR compliance required (EU users)                     ║
-║ • PCI DSS for payment processing                          ║
-║                                                           ║
-║ RESOURCE CONSTRAINTS:                                     ║
-║ • Team: 2 backend, 1 frontend developer                   ║
-║ • No dedicated DevOps resource                            ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Step 5: Risk & Opportunity Analysis
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            RISKS & OPPORTUNITIES                          ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ RISKS:                                                    ║
-║ ┌─────────┬──────────┬────────────┬───────────────────┐  ║
-║ │ Risk    │ Impact   │ Likelihood │ Mitigation        │  ║
-║ ├─────────┼──────────┼────────────┼───────────────────┤  ║
-║ │ Stripe  │ High     │ Low        │ Fallback provider │  ║
-║ │ downtime│          │            │                   │  ║
-║ ├─────────┼──────────┼────────────┼───────────────────┤  ║
-║ │ Timeline│ Medium   │ Medium     │ MVP scope         │  ║
-║ │ slip    │          │            │ reduction         │  ║
-║ └─────────┴──────────┴────────────┴───────────────────┘  ║
-║                                                           ║
-║ OPPORTUNITIES:                                            ║
-║ • Can leverage Stripe's new Payment Elements              ║
-║ • Potential for subscription model expansion              ║
-║ • Mobile payment (Apple Pay, Google Pay) ready            ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Step 6: Generate Analysis Artifacts
-
-Create analysis documents:
-
-```
-project-management/
-└── analysis/
-    ├── research-summary.md      # Key findings
-    ├── constraints.md           # All identified constraints
-    ├── risks-opportunities.md   # Risk register & opportunities
-    └── technical-options.md     # Technology evaluation
-```
-
-### Step 7: Phase Completion
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            ANALYSIS PHASE COMPLETE                        ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ Artifacts Created:                                        ║
-║ ✅ research-summary.md                                    ║
-║ ✅ constraints.md                                         ║
-║ ✅ risks-opportunities.md                                 ║
-║ ✅ technical-options.md                                   ║
-║                                                           ║
-║ Key Findings:                                             ║
-║ • 4 technical constraints identified                      ║
-║ • 3 business constraints identified                       ║
-║ • 5 risks documented with mitigations                     ║
-║ • 3 opportunities for consideration                       ║
-║                                                           ║
-║ ─────────────────────────────────────────────────────────║
-║ NEXT PHASE: Planning                                      ║
-║ Command: /workflow:plan                                   ║
-║ ─────────────────────────────────────────────────────────║
-║                                                           ║
-║ The analysis will inform PRD creation and architecture.   ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-## Agents Involved
-
-- **research-assistant**: Technical research and documentation lookup
-- **product-owner**: Business context and stakeholder analysis
-
-## Output Files
-
-| File | Purpose |
-|------|---------|
-| `analysis/research-summary.md` | Consolidated research findings |
-| `analysis/constraints.md` | Technical, business, regulatory constraints |
-| `analysis/risks-opportunities.md` | Risk register with mitigations |
-| `analysis/technical-options.md` | Technology evaluation and recommendations |
-
-## Related Commands
-
-- `/workflow:init` - Initialize workflow (must run first)
-- `/workflow:plan` - Next phase: Planning
-- `/workflow:status` - Check progress
-- `/common:research-context7` - Deep research with Context7 MCP
+Run `/workflow:plan --research $ARGUMENTS`: read `.claude/commands/workflow/plan.md` and follow it with these arguments.

package/Dev/i18n/en/Workflow/commands/auto-sprint.md

@@ -1,6 +1,6 @@
 ---
 description: End-to-end sprint orchestrator (start -> decompose -> validate -> implement -> PR -> CI -> review -> retro -> merge)
-argument-hint: "<N> [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
+argument-hint: "<N> [--from-prd] [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
 ---
 
 # Auto Sprint — End-to-End Sprint Orchestrator
@@ -14,8 +14,8 @@ stays lean. The implementation phase is run by **you as conductor** (same logic
 This automates what was previously six manual commands with a `/clear` in between:
 
 ```
-/workflow:start N -> /project:decompose-tasks 00N -> /gate:validate-sprint 00N
--> /team:sprint "sprint-00N" -> /workflow:review N -> /workflow:retro N
+/workflow:start N -> /workflow:start N --tasks-only -> /gate:check sprint 00N
+-> /workflow:implement N -> /workflow:review N -> /workflow:retro N
 ```
 
 …and adds: branch, commit, Pull Request, CI watch, and merge.
@@ -25,6 +25,7 @@ This automates what was previously six manual commands with a `/clear` in betwee
 $ARGUMENTS
 
 - `<N>` : Sprint number (e.g. `5`). **Required.**
+- `--from-prd` : Before Phase 1, run `/workflow:plan --only=backlog` (sub-agent) to generate the backlog from `project-management/prd.md`, then continue the normal pipeline.
 - `--auto-merge` : Merge automatically once CI is green and DoD passes. **Default: OFF** — the
   command pauses and waits for an explicit human GO before merging (honors "review obligatoire",
   rule 09, and the Karpathy "no auto-merge without human review" principle).
@@ -52,7 +53,7 @@ to each phase:
 | Phase | Expected form |
 |-------|---------------|
 | `start`, `review`, `retro` | bare `N` (e.g. `5`) |
-| `decompose-tasks` | zero-padded `00N` (e.g. `005`) |
+| `start --tasks-only` | bare `N` (e.g. `5`) |
 | `team:sprint` (implementation) | free-form sprint name resolved from the folder / status file |
 
 Resolve the sprint folder by globbing `project-management/sprints/sprint-{N}-*/` and read
@@ -64,12 +65,16 @@ Resolve the sprint folder by globbing `project-management/sprints/sprint-{N}-*/`
 
 1. Parse `<N>` and flags. Derive `N`, `00N`, sprint slug, and sprint name.
 2. Resolve `project-management/sprints/sprint-{N}-*/` and `.bmad/sprint-status.yaml`.
-   **Abort** if neither exists (nothing to orchestrate).
+   If neither exists, the sprint is new: Phase 1 creates both (no abort).
 3. Verify the working tree is clean and `--base` is up to date. **Abort** if dirty.
 4. Create / checkout the feature branch `feature/sprint-{N}-<slug>` from `--base`
    (rule 09: `main` always deployable — never work directly on the base branch).
 5. If `--dry-run`: print the resolved context + the 9 planned phases and **stop here**.
 
+### Phase 0b — Backlog from PRD (sub-agent, only with `--from-prd`)
+
+> "Read `.claude/commands/workflow/plan.md` and execute `/workflow:plan --only=backlog` (input: `project-management/prd.md`). Return a terse summary and the files created."
+
 ### Phase 1 — Start (sub-agent)
 
 Spawn one isolated sub-agent:
@@ -80,13 +85,13 @@ Spawn one isolated sub-agent:
 
 ### Phase 2 — Decompose (sub-agent)
 
-> "Read `.claude/commands/project/decompose-tasks.md` and execute it for sprint **00N**.
-> Generate the per-US task files, `task-board.md`, and the dependency graph.
+> "Read `.claude/commands/workflow/start.md` (`/workflow:start {N} --tasks-only`) and execute it for sprint **N**.
+> Generate the `tasks/TASK-*.md` files, `board.md`, and the dependency graph.
 > Return a terse summary and the files created."
 
 ### Phase 3 — Validate gate (sub-agent + auto-fix loop)
 
-> "Read `.claude/commands/gate/validate-sprint.md` and run it for sprint **00N**.
+> "Read `.claude/commands/gate/check.md` (gate `sprint`) and run it for sprint **00N**.
 > Return PASS/FAIL, the score, and the list of failing criteria."
 
 **On FAIL → auto-fix loop** (up to `--max-fix-attempts`):
@@ -97,6 +102,8 @@ Spawn one isolated sub-agent:
 
 ### Phase 4 — Implement (you = conductor)
 
+> Equivalent to `/workflow:implement --parallel N` (which delegates to `/team:sprint`).
+
 Assume the **`/team:sprint` conductor role directly** (do **not** spawn a nested Agent Team):
 
 1. Read `.bmad/sprint-status.yaml`; filter stories at `ready-for-dev`.
@@ -196,3 +203,4 @@ Phase            | Status | Notes
 - **Auto-merge is opt-in** and intentionally gated behind a flag.
 - **Docker is mandatory** for tests (project CLAUDE.md).
 - Sub-agent isolation is what replaces `/clear` — keep each sub-agent report terse.
+- For the parallel Agent Teams variant that also writes the stories with cross-review, use `/team:delivery`.