bmad-method 6.10.1-next.8 → 6.11.0

package/src/bmm-skills/3-solutioning/bmad-generate-project-context/steps/step-03-complete.md

@@ -1,284 +0,0 @@
-# Step 3: Context Completion & Finalization
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative completion between technical peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on finalizing a lean, LLM-optimized project context
-- 🎯 ENSURE all critical rules are captured and actionable
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📝 Review and optimize content for LLM context efficiency
-- 📖 Update frontmatter with completion status
-- 🚫 NO MORE STEPS - this is the final step
-
-## CONTEXT BOUNDARIES:
-
-- All rule categories from step-2 are complete
-- Technology stack and versions are documented
-- Focus on final review, optimization, and completion
-- Ensure the context file is ready for AI agent consumption
-
-## YOUR TASK:
-
-Complete the project context file, optimize it for LLM efficiency, and provide guidance for usage and maintenance.
-
-## COMPLETION SEQUENCE:
-
-### 1. Review Complete Context File
-
-Read the entire project context file and analyze:
-
-**Content Analysis:**
-
-- Total length and readability for LLMs
-- Clarity and specificity of rules
-- Coverage of all critical areas
-- Actionability of each rule
-
-**Structure Analysis:**
-
-- Logical organization of sections
-- Consistency of formatting
-- Absence of redundant or obvious information
-- Optimization for quick scanning
-
-### 2. Optimize for LLM Context
-
-Ensure the file is lean and efficient:
-
-**Content Optimization:**
-
-- Remove any redundant rules or obvious information
-- Combine related rules into concise bullet points
-- Use specific, actionable language
-- Ensure each rule provides unique value
-
-**Formatting Optimization:**
-
-- Use consistent markdown formatting
-- Implement clear section hierarchy
-- Ensure scannability with strategic use of bolding
-- Maintain readability while maximizing information density
-
-### 3. Final Content Structure
-
-Ensure the final structure follows this optimized format:
-
-```markdown
-# Project Context for AI Agents
-
-_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
-
----
-
-## Technology Stack & Versions
-
-{{concise_technology_list}}
-
-## Critical Implementation Rules
-
-### Language-Specific Rules
-
-{{specific_language_rules}}
-
-### Framework-Specific Rules
-
-{{framework_patterns}}
-
-### Testing Rules
-
-{{testing_requirements}}
-
-### Code Quality & Style Rules
-
-{{style_and_quality_patterns}}
-
-### Development Workflow Rules
-
-{{workflow_patterns}}
-
-### Critical Don't-Miss Rules
-
-{{anti_patterns_and_edge_cases}}
-
----
-
-## Usage Guidelines
-
-**For AI Agents:**
-
-- Read this file before implementing any code
-- Follow ALL rules exactly as documented
-- When in doubt, prefer the more restrictive option
-- Update this file if new patterns emerge
-
-**For Humans:**
-
-- Keep this file lean and focused on agent needs
-- Update when technology stack changes
-- Review quarterly for outdated rules
-- Remove rules that become obvious over time
-
-Last Updated: {{date}}
-```
-
-### 4. Present Completion Summary
-
-Based on user skill level, present the completion:
-
-**Expert Mode:**
-"Project context complete. Optimized for LLM consumption with {{rule_count}} critical rules across {{section_count}} sections.
-
-File saved to: `{output_folder}/project-context.md`
-
-Ready for AI agent integration."
-
-**Intermediate Mode:**
-"Your project context is complete and optimized for AI agents!
-
-**What we created:**
-
-- {{rule_count}} critical implementation rules
-- Technology stack with exact versions
-- Framework-specific patterns and conventions
-- Testing and quality guidelines
-- Workflow and anti-pattern rules
-
-**Key benefits:**
-
-- AI agents will implement consistently with your standards
-- Reduced context switching and implementation errors
-- Clear guidance for unobvious project requirements
-
-**Next steps:**
-
-- AI agents should read this file before implementing
-- Update as your project evolves
-- Review periodically for optimization"
-
-**Beginner Mode:**
-"Excellent! Your project context guide is ready! 🎉
-
-**What this does:**
-Think of this as a 'rules of the road' guide for AI agents working on your project. It ensures they all follow the same patterns and avoid common mistakes.
-
-**What's included:**
-
-- Exact technology versions to use
-- Critical coding rules they might miss
-- Testing and quality standards
-- Workflow patterns to follow
-
-**How AI agents use it:**
-They read this file before writing any code, ensuring everything they create follows your project's standards perfectly.
-
-Your project context is saved and ready to help agents implement consistently!"
-
-### 5. Final File Updates
-
-Update the project context file with completion information:
-
-**Frontmatter Update:**
-
-```yaml
----
-project_name: '{{project_name}}'
-user_name: '{{user_name}}'
-date: '{{date}}'
-sections_completed:
-  ['technology_stack', 'language_rules', 'framework_rules', 'testing_rules', 'quality_rules', 'workflow_rules', 'anti_patterns']
-status: 'complete'
-rule_count: { { total_rules } }
-optimized_for_llm: true
----
-```
-
-**Add Usage Section:**
-Append the usage guidelines from step 3 to complete the document.
-
-### 6. Completion Validation
-
-Final checks before completion:
-
-**Content Validation:**
-✅ All critical technology versions documented
-✅ Language-specific rules are specific and actionable
-✅ Framework rules cover project conventions
-✅ Testing rules ensure consistency
-✅ Code quality rules maintain standards
-✅ Workflow rules prevent conflicts
-✅ Anti-pattern rules prevent common mistakes
-
-**Format Validation:**
-✅ Content is lean and optimized for LLMs
-✅ Structure is logical and scannable
-✅ No redundant or obvious information
-✅ Consistent formatting throughout
-
-### 7. Completion Message
-
-Present final completion to user:
-
-"✅ **Project Context Generation Complete!**
-
-Your optimized project context file is ready at:
-`{output_folder}/project-context.md`
-
-**📊 Context Summary:**
-
-- {{rule_count}} critical rules for AI agents
-- {{section_count}} comprehensive sections
-- Optimized for LLM context efficiency
-- Ready for immediate agent integration
-
-**🎯 Key Benefits:**
-
-- Consistent implementation across all AI agents
-- Reduced common mistakes and edge cases
-- Clear guidance for project-specific patterns
-- Minimal LLM context usage
-
-**📋 Next Steps:**
-
-1. AI agents will automatically read this file when implementing
-2. Update this file when your technology stack or patterns evolve
-3. Review quarterly to optimize and remove outdated rules
-
-Your project context will help ensure high-quality, consistent implementation across all development work. Great work capturing your project's critical implementation requirements!"
-
-## SUCCESS METRICS:
-
-✅ Complete project context file with all critical rules
-✅ Content optimized for LLM context efficiency
-✅ All technology versions and patterns documented
-✅ File structure is logical and scannable
-✅ Usage guidelines included for agents and humans
-✅ Frontmatter properly updated with completion status
-✅ User provided with clear next steps and benefits
-
-## FAILURE MODES:
-
-❌ Final content is too verbose for LLM consumption
-❌ Missing critical implementation rules or patterns
-❌ Not optimizing content for agent readability
-❌ Not providing clear usage guidelines
-❌ Frontmatter not properly updated
-❌ Not validating file completion before ending
-
-## WORKFLOW COMPLETE:
-
-This is the final step of the Generate Project Context workflow. The user now has a comprehensive, optimized project context file that will ensure consistent, high-quality implementation across all AI agents working on the project.
-
-The project context file serves as the critical "rules of the road" that agents need to implement code consistently with the project's standards and patterns.
-
-## On Complete
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
-
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/bmad-dev-auto/SKILL.md

@@ -1,103 +0,0 @@
----
-name: bmad-dev-auto
-description: 'One iteration of an unattended development loop. Use when invoked by name.'
----
-
-# Dev Auto Workflow
-
-**Goal:** Turn intent into a hardened, reviewable artifact, without human interaction.
-
-**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
-
-## HALT
-
-To HALT with a final status and optional blocking condition:
-
-1. If `{spec_file}` is known and exists, update `status` in frontmatter and append missing result details under `## Auto Run Result`.
-2. If `{spec_file}` is unknown or missing, create `{implementation_artifacts}/bmad-dev-auto-result-<slug-or-timestamp>.md` with:
-   ```markdown
-   ---
-   status: <final status>
-   ---
-
-   # BMad Dev Auto Result
-
-   Status: <final status>
-   Blocking condition: <blocking condition, if any>
-   ```
-3. Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
-4. If the resolved `workflow.on_complete` is non-empty, follow it as the final instruction before exiting.
-5. Stop the workflow.
-
-## Subagents
-
-Using subagents when instructed is mandatory. If you cannot, HALT with status `blocked` and blocking condition `no subagents`.
-
-Invoke every subagent **synchronously**: launch it, wait for it to return within the same turn, then continue with its result. When a step says to run subagents "in parallel" (e.g. the reviewers), that means several **blocking** calls awaited together in one turn — not detached execution. Never run a subagent in the background / detached / async (e.g. `run_in_background: true`), and never end your turn to "await a completion notification." This workflow runs unattended: there is no event loop to resume a yielded turn, so a backgrounded subagent never hands control back and the run stalls. The only sanctioned way to end a turn is the HALT protocol above with an explicit terminal `status`.
-
-## READY FOR DEVELOPMENT STANDARD
-
-A specification is "Ready for Development" when:
-
-- **Actionable**: Every task has a file path and specific action.
-- **Logical**: Tasks ordered by dependency.
-- **Testable**: All ACs use Given/When/Then.
-- **Surface-anchored**: ACs observe the outermost surface the intent references — never a more internal proxy for it (e.g. the API response, not the database row behind it).
-- **Complete**: No placeholders or TBDs.
-- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
-- **Coherent**: No unresolved ambiguities or internal contradictions.
-
-## Conventions
-
-- Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.
-- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` -- load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `project_context` = `**/project-context.md` (load if exists)
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Language MUST be tailored to `{user_skill_level}`
-- Generate all documents in `{document_output_language}`
-
-### Step 5: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete after all activation steps have run.
-
-## Workflow Execution
-
-Follow the step files in order. Read one step fully, execute it, then load the next step only when directed. Do not skip, reorder, or pre-load steps.
-
-## First workflow step
-
-Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.

package/src/bmm-skills/4-implementation/bmad-dev-auto/customize.toml

@@ -1,108 +0,0 @@
-# DO NOT EDIT -- overwritten on every update.
-#
-# Default customization values for bmad-dev-auto.
-# Override in _bmad/custom/bmad-dev-auto.toml or
-# _bmad/custom/bmad-dev-auto.user.toml.
-#
-# Merge rules:
-# - Strings replace the default.
-# - Lists append to the default list.
-# - Tables merge key by key.
-# - Arrays of tables merge by `id`: matching `id` replaces, new `id`s append.
-
-[workflow]
-
-# Extra instructions to run before config is loaded.
-
-activation_steps_prepend = []
-
-# Extra instructions to run after config is loaded and before step 01.
-
-activation_steps_append = []
-
-# Facts kept in context for the whole run.
-# Entries are literal text or file references prefixed with "file:".
-# File entries may use globs and are loaded during activation.
-
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
-
-# Instruction run by HALT after writing the terminal result.
-# Empty means no extra terminal behavior.
-
-on_complete = ""
-
-# Handoff for the implementation subagent in step 03. The whole execution
-# recipe — a subagent by default, but an override may run anything (e.g. an
-# external coding tool via bash). {spec_file} is substituted at run time.
-
-implementation_handoff = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Read {spec_file} fully and implement it. The spec is the sole source of truth for this change; its Spec Change Log entries are binding constraints, not history.
->
-> Guardrails:
->
-> - Work in the current project. Before starting, load every file listed in the spec frontmatter `context:`.
-> - Do not edit the spec file itself.
-> - Do not revert or overwrite changes unrelated to this spec.
-> - Run the verification described in the spec, plus focused checks for the code you touched.
->
-> When done, report: files changed with one line each, verification commands run and their outcomes, any files changed beyond the spec's tasks and why each was needed, anything you could not complete and why, and residual risks.
-"""
-
-# Review layers for the review step. `instruction` is the layer's whole
-# execution recipe — subagents by default, but an override may run anything
-# (e.g. an external reviewer via bash). {diff_output} is substituted at run
-# time. `when` (optional) gates a layer; empty `instruction` disables it.
-
-[[workflow.review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "edge-case-hunter"
-name = "Edge Case Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "verification-gap"
-name = "Verification Gap Reviewer"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-verification-gap` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "intent-alignment"
-name = "Intent Alignment Auditor"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> You are an intent-alignment auditor. You have no other context about how this change was produced. Here is the verbatim intent this work started from:
->
-> {verbatim_intent}
->
-> Here is the diff:
->
-> {diff_output}
->
-> Your task is strictly descriptive — do not prescribe additional work. Report: (1) the defensible readings of the intent, enumerated; (2) which reading this diff implements; (3) where the readings and the diff diverge — specifically, which surface the intent's expectations live at versus which surface the diff's changes and its tests exercise.
-"""

package/src/bmm-skills/4-implementation/bmad-dev-auto/step-01-clarify-and-route.md

@@ -1,66 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-spec_file: '' # set at runtime for both routes before leaving this step
----
-
-# Step 1: Clarify and Route
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Treat the invocation intent as workflow input, not as a substitute for step-02 investigation and spec generation.
-- **EARLY EXIT** means: stop this step immediately, then read and follow the target file. Return here only if a later step explicitly says to loop back.
-
-## Intent check (do this first)
-
-Use the invocation prompt as the intent.
-
-If the invocation prompt explicitly points to an existing spec file with recognized `status` frontmatter, set `spec_file`, then **EARLY EXIT** to the appropriate step:
-- `draft` → `./step-02-plan.md`
-- `ready-for-dev` or `in-progress` → `./step-03-implement.md`
-- `in-review` → `./step-04-review.md`
-- `blocked` → HALT with status `blocked` and blocking condition `blocked spec supplied`.
-- `done` → set `review_loop_iteration` to `0` in the frontmatter, then **EARLY EXIT** to `./step-04-review.md` for a fresh review pass. (A `done` spec is a completed run, so this starts a follow-up review, not a resumption.)
-
-Otherwise, treat the invocation prompt as starting intent. This may be a story ID, ticket ID, file path, short description, or longer free-form intent. Do not infer workflow state from non-spec files.
-If the invocation prompt does not contain enough intent to identify what to implement, HALT with status `blocked` and blocking condition `unclear intent`.
-
-## INSTRUCTIONS
-
-1. Load context.
-   - List files in `{planning_artifacts}` and `{implementation_artifacts}`.
-   - If the invocation prompt points to an unformatted spec or intent file, ingest that file. Do not scan for unrelated intent files.
-   - **Determine context strategy.** Using the intent and the artifact listing, infer whether the current work is a story from an epic. Do not rely on filename patterns or regex — reason about the intent, the listing, and any epics file content together.
-
-     **A) Epic story path** — if the intent is clearly an epic story:
-
-     1. Identify the epic number `{epic_num}` and (if present) the story number `{story_num}`. If you can't identify an epic number, use path B.
-
-     2. **Check for a valid cached epic context.** Look for `{implementation_artifacts}/epic-<N>-context.md` (where `<N>` is the epic number). A file is **valid** when it exists, is non-empty, starts with `# Epic <N> Context:` (with the correct epic number), and no file in `{planning_artifacts}` is newer.
-        - **If valid:** load it as the primary planning context. Do not load raw planning docs (PRD, architecture, UX, etc.).
-        - **If missing, empty, or invalid:** compile it in the next bullet.
-
-     3. **Compile epic context if needed.** If no valid cached epic context was loaded, produce `{implementation_artifacts}/epic-<N>-context.md` by spawning a subagent with `./compile-epic-context.md` as its prompt. Pass it the epic number, the epics file path, the `{planning_artifacts}` directory, and the output path `{implementation_artifacts}/epic-<N>-context.md`.
-
-     4. **Verify if compiled.** If epic context was compiled, verify the output file exists, is non-empty, and starts with `# Epic <N> Context:`. If valid, load it. If verification fails, HALT with status `blocked` and blocking condition `context compilation verification failed`.
-
-     5. **Previous story continuity.** Regardless of which context source succeeded above, scan `{implementation_artifacts}` for specs from the same epic with `status: done` and a lower story number. Load the most recent one (highest story number below current). Extract its **Code Map**, **Design Notes**, **Spec Change Log**, and **task list** as continuity context for step-02 planning. If no `done` spec is found but an `in-review` spec exists for the same epic with a lower story number, HALT with status `blocked` and blocking condition `missing previous-story continuity decision`.
-
-     **B) Freeform path** — if the intent is not an epic story:
-     - Planning artifacts are the output of BMAD phases 1-3. Typical files include:
-       - **PRD** (`*prd*`) — product requirements and success criteria
-       - **Architecture** (`*architecture*`) — technical design decisions and constraints
-       - **UX/Design** (`*ux*`) — user experience and interaction design
-       - **Epics** (`*epic*`) — feature breakdown into implementable stories
-       - **Product Brief** (`*brief*`) — project vision and scope
-     - Scan the listing for files matching these patterns. If any look relevant to the current intent, load them selectively — you don't need all of them, but you need the right constraints and requirements rather than guessing from code alone.
-2. Resolve intent from the invocation prompt and loaded artifacts. Do not fantasize or leave open questions. If the intent cannot be resolved, HALT with status `blocked` and the unresolved questions as blocking condition.
-3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT with status `blocked` and that condition as blocking condition. If version control is unavailable, skip this check.
-4. Multi-goal warning. If the intent appears to contain multiple independently shippable goals, carry `multiple-goals` forward so step-02 can add it to `{spec_file}` frontmatter `warnings`. Do not split or block.
-5. Route:
-
-   Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists: if its status is `draft`, treat it as the same work and resume it (set `spec_file` to that path, **EARLY EXIT** → `./step-02-plan.md`); otherwise append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
-
-## NEXT
-
-Read fully and follow `./step-02-plan.md`

package/src/bmm-skills/4-implementation/bmad-dev-auto/step-02-plan.md

@@ -1,31 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 2: Plan
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No human interaction: do not ask questions or wait for approval in this step.
-
-## INSTRUCTIONS
-
-1. Draft resume check. If `{spec_file}` exists with `status: draft`, read it and capture the verbatim `<intent-contract>...</intent-contract>` block as `preserved_intent_contract`. Otherwise `preserved_intent_contract` is empty.
-2. Investigate codebase. _Read the code yourself for narrow, localized tasks. Isolate deep exploration in subagents: instruct them to give you distilled summaries only, and plan from those summaries._
-3. Read `./spec-template.md` fully. Fill it out based on the intent and investigation. If `{preserved_intent_contract}` is non-empty, substitute it for the `<intent-contract>` block in your filled spec before writing. Write the result to `{spec_file}`.
-4. Self-review against READY FOR DEVELOPMENT standard.
-5. If intent gaps exist, do not fantasize and do not leave open questions. Multiple defensible readings of the intent that lead to observably different outcomes, with nothing in the intent to select between them, are an intent gap — do not resolve one by picking a reading. HALT with status `blocked`, blocking condition `intent gap`, and include the unanswered questions and evidence gathered.
-6. Warning check. If step-01 carried `multiple-goals`, add it to `{spec_file}` frontmatter `warnings`. If `{spec_file}` exceeds 1600 tokens, add `oversized` to frontmatter `warnings`. Continue either way.
-
-### READY-FOR-DEVELOPMENT GATE
-
-Re-read `./SKILL.md`, then re-read `{spec_file}` from disk and verify the spec meets the READY FOR DEVELOPMENT standard.
-
-- **If the file is missing:** HALT with status `blocked` and blocking condition `planned spec file disappeared before implementation`.
-- **If the spec meets the standard:** set `{spec_file}` frontmatter status to `ready-for-dev`, then continue to step 3.
-- **If the spec does not meet the standard:** repair it once, then re-read it from disk and verify again. If it still does not meet the standard, HALT with status `blocked`, blocking condition `spec failed ready-for-development standard`, and include the failing criteria and evidence gathered.
-
-## NEXT
-
-Read fully and follow `./step-03-implement.md`