@schilling.mark.a/software-methodology 1.0.0 → 1.0.1

package/docs/story-map/walking-skeleton.md

@@ -0,0 +1,95 @@
+# Walking Skeleton — Minimum Viable Journey
+
+**Created:** February 16, 2026
+**Product:** Software Methodology
+
+---
+
+## Goal
+
+Enable a developer to go from "I have a feature idea" to "I have working, tested code in production" using the methodology for the first time.
+
+---
+
+## User Journey
+
+### 1. Define Business Value — Simplified
+- ✅ **ACT-001-task-002**: Create Value Proposition Canvas
+  - **Included:** One customer segment, core jobs/pains/gains, basic pain relievers and gain creators
+  - **Excluded:** Business Model Canvas (can use VPC alone for single-feature validation), multiple segments, unaddressed pains/gains analysis
+
+### 2. Understand User Needs — Deferred
+- ❌ **Reason:** Can start with VPC customer jobs. Personas and journey maps add depth but aren't required for minimum viable methodology usage.
+
+### 3. Plan Features — Simplified
+- ✅ **ACT-003-task-001**: Create story map backbone
+  - **Included:** 2-4 core activities derived from VPC customer jobs, basic task breakdown
+  - **Excluded:** Walking skeleton document itself (meta!), detailed release planning, MoSCoW prioritization
+
+### 4. Specify Behavior — Simplified
+- ✅ **ACT-004-task-002**: Write Gherkin scenarios
+  - **Included:** One feature file with 2-3 happy path scenarios, basic Given-When-Then structure
+  - **Excluded:** Example mapping workshop, comprehensive edge cases, multiple stakeholder reviews
+
+### 5. Design User Experience — Deferred
+- ❌ **Reason:** Not all features require UX design (e.g., APIs, CLIs, backend services). Can be added when needed for UI-heavy features.
+
+### 6. Implement Features — Simplified
+- ✅ **ACT-006-task-001**: Write failing acceptance test (RED)
+  - **Included:** Automated test that verifies one Gherkin scenario fails
+  - **Excluded:** Full test strategy document, comprehensive test coverage, multiple test types
+  
+- ✅ **ACT-006-task-002**: Make test pass with minimum code (GREEN)
+  - **Included:** Simplest implementation that passes the test
+  - **Excluded:** Production-ready error handling, edge cases, optimization
+  
+- ✅ **ACT-006-task-003**: Refactor for maintainability
+  - **Included:** Apply one SOLID principle, extract one method/class for clarity
+  - **Excluded:** Comprehensive design pattern application, full clean code review
+
+### 7. Deploy Safely — Simplified
+- ✅ **ACT-007-task-001**: Set up pipeline stages
+  - **Included:** Build → Test → Deploy to one environment, basic success/failure reporting
+  - **Excluded:** Multiple environments, blue-green deployment, automated rollback, performance testing
+
+### 8. Measure and Improve — Deferred
+- ❌ **Reason:** Requires multiple delivery cycles to collect meaningful data. Add after establishing baseline workflow.
+
+---
+
+## What's NOT in the Walking Skeleton
+
+- **UX Research artifacts** (personas, journey maps, mental models) — deferred to R2
+- **Business Model Canvas** — VPC sufficient for feature-level work
+- **Example mapping workshops** — can write scenarios directly for simple features
+- **UI design workflow** — add when building UI-heavy features
+- **Comprehensive test strategy** — start with acceptance tests, expand in R2
+- **Multiple deployment environments** — single environment sufficient to prove value
+- **Continuous improvement data collection** — requires established baseline first
+
+---
+
+## Success Criteria
+
+Developer can:
+1. ✅ Define business value for a feature using VPC
+2. ✅ Identify 2-4 user activities from VPC customer jobs
+3. ✅ Write 2-3 Gherkin scenarios that trace to VPC gains
+4. ✅ Write failing acceptance test for one scenario
+5. ✅ Implement minimum code to pass the test
+6. ✅ Refactor code with one SOLID principle
+7. ✅ Deploy to production via automated pipeline
+8. ✅ Trace deployed code back to VPC gain
+
+---
+
+## Rationale
+
+This skeleton is intentionally minimal. It:
+- Proves the methodology works end-to-end
+- Delivers real value (working code in production)
+- Establishes muscle memory for RED-GREEN-REFACTOR
+- Creates traceability from business value to code
+- Takes hours, not days, to complete first time through
+
+Depth and sophistication come in subsequent releases.

package/docs/value-proposition-canvas.md

@@ -0,0 +1,171 @@
+# Value Proposition Canvas
+
+**Created:** February 16, 2026
+**Last updated:** February 16, 2026
+**Product:** Software Methodology
+
+---
+
+## Segment: Individual Developer
+
+**BMC reference:** Customer Segments → Individual developers and engineers who want to ship quality software
+
+### Customer Profile
+
+#### Customer Jobs
+1. **Ship working software that delivers business value** — Build features that solve real problems and get used by actual users.
+2. **Write maintainable code that others can understand** — Create code that teammates can read, extend, and modify without extensive handoff.
+3. **Validate that built features solve real problems** — Confirm that what's being built addresses actual user needs before investing significant time.
+4. **Collaborate effectively with product and design stakeholders** — Communicate clearly about what's being built, why, and how it maps to user needs.
+5. **Make confident changes without breaking existing functionality** — Refactor and extend code knowing that regressions will be caught early.
+6. **Improve software engineering craft** — Develop skills and practices that transfer across projects, teams, and domains.
+
+#### Pains
+1. **Unclear or changing requirements lead to rework** — Spend days building a feature only to discover it's not what was actually needed. Wastes 30-40% of development time on rework and clarification cycles.
+2. **No shared language between developers, product, and stakeholders** — Conversations turn into translations. Product says "users need to feel confident," developers ask "what button do I add?" Misalignment is only discovered after deployment.
+3. **Writing tests after code feels like extra work and is often skipped** — Under deadline pressure, tests are cut first. Technical debt accumulates. Fear of changing existing code grows over time.
+4. **Hard to know what to build first or how to prioritize** — Every feature seems equally important. No clear framework for deciding what delivers most value with least effort.
+5. **Code becomes messy over time without clear patterns** — Initial implementation is clean, but as features accumulate, structure degrades. No consistent approach to applying design patterns or SOLID principles.
+6. **Disconnect between "what we built" and "what users needed"** — Features ship on time but get poor adoption or negative feedback. Unclear how to trace delivered code back to original user problem.
+7. **Context switching between different methodologies per project** — Each team uses different approaches. Skills and muscle memory don't transfer. Every new project requires relearning how things work.
+
+#### Gains
+1. **Deliver features users actually want and use** — See adoption metrics and user feedback validate that built features solve real problems.
+2. **Spend less time debugging and more time building** — Catch issues during development instead of in production. Reduce time spent firefighting.
+3. **Have clear criteria for "done" before starting work** — Know exactly what success looks like before writing the first line of code. Avoid scope creep and ambiguity.
+4. **Ship smaller increments more frequently** — Break large features into valuable slices that deliver partial value quickly. Reduce time between user feedback cycles.
+5. **Feel confident refactoring and extending code** — Make changes with safety nets in place. Improve code structure without fear of breaking hidden dependencies.
+6. **Build transferable skills that work across projects** — Develop a consistent approach that applies whether building mobile apps, web services, or enterprise systems.
+7. **Trace code back to business value** — Explain why any line of code exists and what user problem it solves. Justify technical decisions with business context.
+
+### Value Proposition
+
+#### Products & Services
+- **11-skill methodology chain:** End-to-end process from product strategy through continuous improvement. Maps to all Customer Jobs.
+- **Reference documents:** On-demand guidance for patterns, principles, and practices. Supports "Write maintainable code" and "Improve craft" jobs.
+- **Artifact templates:** Pre-structured formats for story maps, feature files, test strategies. Supports "Collaborate effectively" and "Have clear criteria" jobs.
+- **Integration guidance:** Shows how skills connect and feed each other. Supports "Validate features solve problems" and "Trace code to business value" jobs.
+
+#### Pain Relievers
+- **Relieves "Unclear or changing requirements"** by starting with Value Proposition Canvas that defines customer jobs, pains, and gains before any code is written. BDD specifications use concrete examples that become shared understanding between all roles.
+- **Relieves "No shared language"** by establishing ubiquitous language from product strategy through code. Gherkin scenarios use domain terms that appear in both stakeholder conversations and variable names.
+- **Relieves "Writing tests after code"** by using ATDD workflow with RED-GREEN-REFACTOR cycle. Tests define "done" before implementation starts, making them essential rather than extra.
+- **Relieves "Hard to prioritize"** by using story mapping to organize features by user journey backbone and release planning to identify Must Have vs Should Have features based on pain severity.
+- **Relieves "Code becomes messy"** by providing clean-code references during REFACTOR phase. Design patterns and SOLID principles applied at the right time with clear guidance on when to use which pattern.
+- **Relieves "Disconnect between built vs needed"** by tracing every feature file back to specific gains in the VPC. Continuous improvement skill measures actual outcomes and feeds findings back upstream.
+- **Relieves "Context switching between methodologies"** by providing a single consistent approach that works across all project types. Once learned, the methodology transfers to every new project.
+
+#### Gain Creators
+- **Creates "Deliver features users want"** by starting with UX research (personas, journey maps) that identify real user needs before any design or code. Story mapping organizes work by user activities, not technical components.
+- **Creates "Spend less time debugging"** by catching issues at multiple stages: acceptance tests (RED phase), automation tests, and CI/CD pipeline validation. Issues found in minutes, not days.
+- **Creates "Clear criteria for done"** by writing Gherkin scenarios via example mapping before implementation. Each scenario becomes acceptance criteria and executable specification.
+- **Creates "Ship smaller increments"** by using walking skeleton pattern and release planning that identifies smallest valuable delivery. Story map tasks represent testable slices, not full features.
+- **Creates "Confident refactoring"** by providing test coverage from acceptance tests and unit tests. Clean-code references guide improvements with specific before/after patterns.
+- **Creates "Transferable skills"** by teaching principles, not tools. SOLID principles, BDD thinking, and user-centered design work in any language or framework.
+- **Creates "Trace code to business value"** by maintaining direct links: VPC gains → Gherkin "So that" clauses → test names → production code. Every method can be traced to a specific user need.
+
+### Unaddressed
+- **Pain: Learning curve for full methodology** — Out of scope for v1. Mitigated by: skills can be adopted incrementally; each SKILL.md is self-contained; quickstart guide provides entry point.
+- **Gain: Automated tooling integration** — Aspirational for future release. Current state: human-readable markdown files that can be read by AI assistants. Future: CLI tools, IDE integrations, automated validation.
+- **Gain: Team adoption and coaching support** — Out of scope. Methodology provides the content; organizational change management is separate concern.
+
+---
+
+## Segment: Development Team
+
+**BMC reference:** Customer Segments → Teams that need a shared approach and consistent practices
+
+### Customer Profile
+
+#### Customer Jobs
+1. **Align on what "done" means across team members** — Ensure everyone understands acceptance criteria and quality standards before and during work.
+2. **Onboard new team members quickly** — Get new developers productive without extensive pairing or knowledge transfer sessions.
+3. **Make collective technical decisions** — Choose patterns, practices, and architecture with shared understanding of tradeoffs.
+4. **Review code efficiently** — Evaluate pull requests against consistent standards and patterns.
+5. **Maintain consistent quality across the codebase** — Prevent code quality from varying based on which team member wrote it.
+
+#### Pains
+1. **Different team members use different approaches** — One developer writes tests first, another writes tests last. One uses design patterns, another doesn't. Code review becomes subjective opinion.
+2. **Long onboarding time for new team members** — Takes 2-3 months for new developers to become productive. Heavy burden on experienced team members to explain implicit practices.
+3. **Debates about "the right way" consume time** — Every technical decision becomes a discussion. No shared reference for when to use which pattern or practice.
+4. **Inconsistent artifact quality** — Some features have detailed specs, others have one-line tickets. Some have test coverage, others don't. Depends entirely on who picked up the work.
+
+#### Gains
+1. **New team members productive in days, not months** — Provide clear process and references that new developers can follow independently.
+2. **Code reviews focus on logic, not style** — Shared methodology means structural choices are consistent. Reviews evaluate business logic and edge cases.
+3. **Technical decisions reference shared vocabulary** — Discussions use common language and principles. Decisions are documented with methodology references.
+4. **Predictable delivery velocity** — Consistent practices mean less variability in estimation and delivery. Team throughput stabilizes.
+
+### Value Proposition
+
+#### Products & Services
+- **Shared skill references:** Single source of truth for how the team works. All team members access same guidance.
+- **Consistent artifact templates:** Story maps, feature files, test strategies use same structure regardless of author.
+- **Common vocabulary:** Ubiquitous language established in product-strategy skill and used throughout all skills.
+
+#### Pain Relievers
+- **Relieves "Different approaches"** by defining the methodology as team agreement. All team members follow RED-GREEN-REFACTOR. All test files follow patterns in test-strategy.md.
+- **Relieves "Long onboarding"** by providing SKILL.md entry points and reference documents new team members can read. Practices are documented, not tribal knowledge.
+- **Relieves "Debates consume time"** by providing default answers in reference documents. "When do I use Strategy pattern?" → clean-code/references/behavioral-patterns.md has decision criteria.
+- **Relieves "Inconsistent artifacts"** by providing templates and examples. Every feature file follows gherkin-patterns.md. Every story map follows task-template.md structure.
+
+#### Gain Creators
+- **Creates "New members productive quickly"** by providing self-service learning path. Read SKILL.md → follow references → produce artifact matching template.
+- **Creates "Reviews focus on logic"** by establishing methodology compliance as baseline. Reviewer can assume SOLID principles were considered; review evaluates specific implementation choices.
+- **Creates "Shared vocabulary"** by establishing ubiquitous language in VPC and BMC that flows through all artifacts. Team speaks same language as product and users.
+- **Creates "Predictable velocity"** by reducing variation in how work is approached. Consistent RED-GREEN-REFACTOR cycle means estimates become more accurate over time.
+
+### Unaddressed
+- **Gain: Collective ownership and pair programming guidance** — Out of scope. Methodology defines what artifacts exist and how to create them, not team working agreements about pairing or mob programming.
+- **Pain: Resistance to process change** — Out of scope. Change management is separate from methodology content.
+
+---
+
+## Segment: Engineering Leader / Coach
+
+**BMC reference:** Customer Segments → Leaders responsible for team effectiveness and software quality
+
+### Customer Profile
+
+#### Customer Jobs
+1. **Ensure team delivers business value, not just features** — Verify that engineering effort aligns with actual user needs and business outcomes.
+2. **Improve team practices without disrupting delivery** — Introduce better approaches incrementally without halting current work.
+3. **Make quality visible and measurable** — Show stakeholders and leadership that quality practices produce business results.
+4. **Scale team skills as organization grows** — Transfer knowledge and practices to new teams and new hires efficiently.
+5. **Reduce technical debt accumulation** — Prevent quality degradation over time while maintaining delivery pace.
+
+#### Pains
+1. **Hard to prove ROI of quality practices** — Stakeholders see testing and refactoring as "slowing down delivery." Difficult to demonstrate that quality practices accelerate long-term velocity.
+2. **Piecemeal methodology adoption creates confusion** — Team adopts TDD but not BDD. Uses story mapping but skips UX research. Partial adoption misses integration points and reduces effectiveness.
+3. **No clear starting point for improvement** — Team has problems but unclear where to start. Which practice to introduce first? How to sequence changes?
+4. **Coaching is repetitive and doesn't scale** — Explaining same concepts to each new team member. Limited by availability to sit with developers and guide them.
+
+#### Gains
+1. **Demonstrate that quality practices increase delivery speed** — Show data connecting test coverage, refactoring, and velocity. Make business case for investing in quality.
+2. **Provide self-service learning resources** — Team members can learn and improve without requiring coaching hours.
+3. **See consistent practices across all teams** — All teams use same approach. Knowledge transfer between teams is frictionless.
+4. **Connect engineering practices to business outcomes** — Trace deployed features back to VPC gains. Show executives how engineering choices support business strategy.
+
+### Value Proposition
+
+#### Products & Services
+- **Complete methodology chain:** Shows how all skills integrate from strategy through deployment. Prevents piecemeal adoption gaps.
+- **Skill sequencing:** INTEGRATION.md and SKILLS.md show dependencies and recommended order. Provides clear starting point.
+- **Traceability model:** Documents how VPC flows through story mapping, BDD, ATDD, and into code. Makes business value visible.
+
+#### Pain Relievers
+- **Relieves "Hard to prove ROI"** by establishing traceability from VPC gains through Gherkin scenarios to production code. Every feature has documented business value.
+- **Relieves "Piecemeal adoption"** by showing skill dependencies and integration points. INTEGRATION.md explains what breaks when skills are skipped.
+- **Relieves "No clear starting point"** by providing QUICKSTART.md with recommended entry points. Product-strategy skill is always first; subsequent skills depend on project context.
+- **Relieves "Coaching doesn't scale"** by externalizing coaching content into SKILL.md and reference documents. Coach points developers to specific references rather than repeating explanations.
+
+#### Gain Creators
+- **Creates "Quality practices increase speed"** by using continuous-improvement skill to measure cycle time, defect rates, and rework. Data collection built into methodology.
+- **Creates "Self-service learning"** by structuring each skill with SKILL.md entry point and on-demand references. Developers learn independently while coach provides review and feedback.
+- **Creates "Consistent practices across teams"** by providing single methodology that all teams adopt. Same vocabulary, same artifacts, same quality standards.
+- **Creates "Engineering connects to business"** by starting with product-strategy skill (BMC and VPC). Every downstream skill maintains traceability to business value.
+
+### Unaddressed
+- **Gain: Customization for specific tech stacks** — Partially addressed. Green-implementation skill has Angular, RxJS, and Playwright patterns. Additional framework-specific guidance aspirational for future releases.
+- **Pain: Organizational resistance to methodology adoption** — Out of scope. Methodology provides the content; organizational change strategy is separate.
+

package/features/mcp-server/query-vpc.feature

@@ -0,0 +1,48 @@
+# Story Map: MCP-003
+# Value Prop: Individual Developer - Gain: "Trace code back to business value"
+
+Feature: Query Value Proposition Canvas
+  As a developer implementing a feature
+  I want to query the VPC to understand business value
+  So that I can make decisions aligned with user needs
+
+  Background:
+    Given the software-methodology MCP server is running
+    And the VPC exists at "/docs/value-proposition-canvas.md"
+    And the VPC has 3 customer segments
+
+  Scenario: Get all customer segments
+    Given I need to understand who the users are
+    When I request all customer segments from the VPC
+    Then I should receive 3 segments
+    And the segments should include "Individual Developer"
+    And the segments should include "Development Team"
+    And the segments should include "Engineering Leader / Coach"
+
+  Scenario: Get customer jobs for a segment
+    Given I am building features for individual developers
+    When I request customer jobs for "Individual Developer" segment
+    Then I should receive 6 customer jobs
+    And the first job should be "Ship working software that delivers business value"
+    And each job should be ordered by importance
+
+  Scenario: Get pains for a segment
+    Given I need to understand user frustrations
+    When I request pains for "Individual Developer" segment
+    Then I should receive at least 5 pains
+    And the pains should include specific magnitude where available
+    And the first pain should be the most severe
+
+  Scenario: Get gains for a segment
+    Given I want to validate feature value
+    When I request gains for "Individual Developer" segment
+    Then I should receive at least 5 gains
+    And the gains should include success criteria
+    And the first gain should be the most important
+
+  Scenario: Search for specific pain or gain
+    Given I am working on test-first development
+    When I search the VPC for "tests"
+    Then I should find pain "Writing tests after code feels like extra work"
+    And I should find gain "Spend less time debugging and more time building"
+    And each result should indicate which segment it belongs to

package/features/mcp-server/read-reference.feature

@@ -0,0 +1,41 @@
+# Story Map: MCP-002
+# Value Prop: Individual Developer - Pain relieved: "Code becomes messy over time without clear patterns"
+
+Feature: Read Reference Documentation
+  As a developer needing design pattern guidance
+  I want to retrieve specific reference documents from a skill
+  So that I can apply the right pattern at the right time
+
+  Background:
+    Given the software-methodology MCP server is running
+    And the "clean-code" skill has 4 reference documents
+
+  Scenario: Retrieve specific reference document
+    Given I need to understand SOLID principles
+    When I request "clean-code/solid.md" reference
+    Then I should receive the SOLID principles content
+    And the content should include Single Responsibility Principle
+    And the content should include examples for each principle
+
+  Scenario: List references for a skill
+    Given I want to see what guidance is available
+    When I request references for the "clean-code" skill
+    Then I should receive a list of 4 references
+    And the list should include "solid.md"
+    And the list should include "creational-patterns.md"
+    And the list should include "structural-patterns.md"
+    And the list should include "behavioral-patterns.md"
+
+  Scenario: Retrieve behavioral pattern guidance
+    Given I am implementing a feature with complex state transitions
+    When I request "clean-code/behavioral-patterns.md" reference
+    Then I should receive the behavioral patterns content
+    And the content should include State pattern
+    And the content should include Strategy pattern
+    And the content should include when to use each pattern
+
+  Scenario: Request reference from skill without references
+    Given I request a reference for a skill with no reference documents
+    When I request "nonexistent-skill/reference.md" reference
+    Then I should receive an error message
+    And the error should indicate the skill or reference doesn't exist

package/features/mcp-server/read-skill.feature

@@ -0,0 +1,33 @@
+# Story Map: MCP-001
+# Value Prop: Individual Developer - Gain: "Build transferable skills that work across projects"
+
+Feature: Read Skill Documentation
+  As a developer using an AI assistant
+  I want to retrieve specific skill documentation from the methodology
+  So that I get focused guidance without loading entire files
+
+  Background:
+    Given the software-methodology MCP server is running
+    And the methodology contains 11 skills
+
+  Scenario: Retrieve main skill documentation
+    Given I am working on a feature implementation
+    When I request the "atdd-workflow" skill documentation
+    Then I should receive the SKILL.md content
+    And the content should include the workflow overview
+    And the content should reference the RED-GREEN-REFACTOR cycle
+
+  Scenario: List all available skills
+    Given I need to understand what skills are available
+    When I request the list of all skills
+    Then I should receive 11 skill names
+    And each skill should include its description
+    And the list should include "product-strategy"
+    And the list should include "atdd-workflow"
+    And the list should include "clean-code"
+
+  Scenario: Retrieve skill that doesn't exist
+    Given I request a skill that doesn't exist
+    When I request the "non-existent-skill" skill documentation
+    Then I should receive an error message
+    And the error should suggest available skills

package/features/mcp-server/search-guidance.feature

@@ -0,0 +1,42 @@
+# Story Map: MCP-004
+# Value Prop: Development Team - Pain relieved: "Debates about 'the right way' consume time"
+
+Feature: Search for Guidance
+  As a developer facing a specific challenge
+  I want to search across all skills and references
+  So that I can find relevant guidance without knowing which skill to check
+
+  Background:
+    Given the software-methodology MCP server is running
+    And the methodology contains 11 skills with references
+
+  Scenario: Search for design pattern by scenario
+    Given I need to implement object creation with many parameters
+    When I search for "many parameters object creation"
+    Then I should receive the Builder pattern from "clean-code/creational-patterns.md"
+    And the result should explain when to use Builder pattern
+
+  Scenario: Search for testing guidance
+    Given I want to understand test-first development
+    When I search for "write test before code"
+    Then I should receive results from "atdd-workflow/SKILL.md"
+    And I should receive results from "atdd-workflow/red-phase.md"
+    And the results should be ranked by relevance
+
+  Scenario: Search for BDD specification patterns
+    Given I need to write Gherkin scenarios
+    When I search for "Given When Then"
+    Then I should receive "bdd-specification/gherkin-patterns.md"
+    And the result should include Given-When-Then rules
+
+  Scenario: Search returns no results
+    Given I search for something not in the methodology
+    When I search for "quantum computing algorithms"
+    Then I should receive an empty result set
+    And I should receive a suggestion to check available skills
+
+  Scenario: Search for SOLID principle by symptom
+    Given I have a class that's hard to test
+    When I search for "hard to test dependencies"
+    Then I should receive Dependency Inversion Principle from "clean-code/solid.md"
+    And the result should explain how DIP improves testability

package/features/mcp-server/suggest-next-step.feature

@@ -0,0 +1,61 @@
+# Story Map: MCP-005
+# Value Prop: Individual Developer - Gain: "Have clear criteria for 'done' before starting work"
+
+Feature: Suggest Next Steps
+  As a developer using the methodology
+  I want to know what to do next based on current context
+  So that I follow the correct sequence without memorizing the workflow
+
+  Background:
+    Given the software-methodology MCP server is running
+    And the methodology follows a skill chain
+
+  Scenario: Starting from scratch
+    Given no methodology artifacts exist yet
+    When I request the next step
+    Then I should be told to create the Value Proposition Canvas
+    And the suggestion should reference "product-strategy/SKILL.md"
+
+  Scenario: VPC exists, planning features
+    Given the VPC exists
+    And no story map exists
+    When I request the next step
+    Then I should be told to create the story map backbone
+    And the suggestion should reference "story-mapping/SKILL.md"
+    And the suggestion should explain that backbone derives from VPC customer jobs
+
+  Scenario: Story map exists, need scenarios
+    Given the VPC exists
+    And the story map backbone exists
+    And no feature files exist
+    When I request the next step
+    Then I should be told to write Gherkin scenarios
+    And the suggestion should reference "bdd-specification/SKILL.md"
+
+  Scenario: Scenarios exist, ready to implement
+    Given feature files exist with Gherkin scenarios
+    And no tests exist
+    When I request the next step
+    Then I should be told to write failing acceptance test (RED phase)
+    And the suggestion should reference "atdd-workflow/red-phase.md"
+
+  Scenario: Tests failing (RED), make them pass
+    Given acceptance tests exist and are failing
+    When I request the next step
+    Then I should be told to implement minimum code to pass tests (GREEN phase)
+    And the suggestion should reference "atdd-workflow/green-phase.md"
+
+  Scenario: Tests passing (GREEN), improve code
+    Given acceptance tests exist and are passing
+    And the code has not been refactored
+    When I request the next step
+    Then I should be told to refactor for maintainability
+    And the suggestion should reference "atdd-workflow/refactor-phase.md"
+    And the suggestion should reference "clean-code/SKILL.md"
+
+  Scenario: Feature complete, ready to deploy
+    Given a feature is implemented and tested
+    And no CI/CD pipeline exists
+    When I request the next step
+    Then I should be told to set up the deployment pipeline
+    And the suggestion should reference "cicd-pipeline/SKILL.md"

package/features/mcp-server/validate-gherkin.feature

@@ -0,0 +1,54 @@
+# Story Map: MCP-006
+# Value Prop: Individual Developer - Pain relieved: "No shared language between developers, product, and stakeholders"
+
+Feature: Validate Gherkin Scenarios
+  As a developer writing BDD specifications
+  I want to validate my Gherkin files against best practices
+  So that my scenarios are well-formed and trace to business value
+
+  Background:
+    Given the software-methodology MCP server is running
+    And Gherkin pattern rules exist in "bdd-specification/gherkin-patterns.md"
+
+  Scenario: Validate well-formed feature file
+    Given I have written a feature file with proper structure
+    And the feature has a user story
+    And scenarios use Given-When-Then format
+    And the "So that" clause traces to a VPC gain
+    When I validate the feature file
+    Then validation should pass
+    And I should receive confirmation of proper structure
+
+  Scenario: Detect missing VPC traceability
+    Given I have a feature file
+    But the "So that" clause doesn't reference any VPC gain
+    When I validate the feature file
+    Then validation should fail
+    And I should receive a warning about missing VPC traceability
+    And the warning should suggest reviewing the VPC
+
+  Scenario: Detect improper Given-When-Then usage
+    Given I have a scenario with a Given step in future tense
+    When I validate the feature file
+    Then validation should warn about tense usage
+    And the warning should reference "Given should be past tense"
+
+  Scenario: Detect missing user story
+    Given I have a feature file without the "As a... I want... So that..." header
+    When I validate the feature file
+    Then validation should fail
+    And I should receive an error about missing user story
+
+  Scenario: Suggest Scenario Outline for repeated scenarios
+    Given I have multiple scenarios with the same structure
+    But different data values
+    When I validate the feature file
+    Then validation should suggest using Scenario Outline
+    And the suggestion should reference "bdd-specification/gherkin-patterns.md"
+
+  Scenario: Check for observable outcomes in Then steps
+    Given I have a Then step that references internal system state
+    Such as "Then the database should contain record X"
+    When I validate the feature file
+    Then validation should warn about non-observable outcomes
+    And the warning should suggest user-observable alternatives