@schilling.mark.a/software-methodology 1.0.0

package/package.json

@@ -0,0 +1,57 @@
+{
+  "name": "@schilling.mark.a/software-methodology",
+  "version": "1.0.0",
+  "description": "Comprehensive software development methodology from product strategy through production deployment. Eleven skills covering Business Model Canvas, UX research, story mapping, BDD/ATDD, clean code, CI/CD, and continuous improvement.",
+  "keywords": [
+    "methodology",
+    "agile",
+    "bdd",
+    "tdd",
+    "atdd",
+    "clean-code",
+    "software-development",
+    "product-strategy",
+    "ux-research",
+    "story-mapping",
+    "cicd",
+    "continuous-improvement",
+    "claude-code",
+    "github-copilot"
+  ],
+  "author": "Mark Schilling",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/MarkSchilling/software-methodology.git"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/MarkSchilling/software-methodology#readme",
+  "bugs": {
+    "url": "https://github.com/MarkSchilling/software-methodology/issues"
+  },
+  "files": [
+    "dist/",
+    "docs/",
+    "project-templates/",
+    ".github/copilot-instructions.md",
+    "README.md",
+    "LICENSE",
+    "atdd-workflow/",
+    "bdd-specification/",
+    "cicd-pipeline/",
+    "clean-code/",
+    "continuous-improvement/",
+    "green-implementation/",
+    "product-strategy/",
+    "story-mapping/",
+    "ui-design-system/",
+    "ui-design-workflow/",
+    "ux-design/",
+    "ux-research/"
+  ],
+  "engines": {
+    "node": ">=14.0.0"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/product-strategy/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: product-strategy
+description: Product strategy skill for creating and maintaining the Business Model Canvas and Value Proposition Canvas. Use at the start of a new product, when entering a new market or user segment, when the user says "create the business model canvas", "define the value proposition", "set up the product strategy", or "update the canvases". These two documents are the foundation that six other skills read from — story-mapping, ux-research, bdd-specification, ui-design-workflow, atdd-workflow, and continuous-improvement all depend on them. This skill creates them, keeps them in sync with each other, and updates them when ux-research or continuous-improvement findings change the picture.
+---
+
+# Product Strategy
+
+## Overview
+
+The Business Model Canvas and Value Proposition Canvas are the two foundation documents of the methodology. Every other skill reads from them. Nothing else creates them. This skill fills that gap — it creates both canvases at project start, keeps them aligned with each other, and updates them when research or post-release learning changes the picture.
+
+## When to Run This Skill
+
+- **New product:** Create both canvases before any other skill runs. Nothing downstream can start without them.
+- **New market or user segment:** Update the VPC for the new segment. Check BMC alignment.
+- **ux-research returns findings:** Personas and journey maps may reveal that Customer Jobs, Pains, or Gains need updating. Update VPC, then check BMC alignment.
+- **continuous-improvement flags a strategy drift:** If post-release measurement reveals that the product is not delivering the value proposition as designed, the canvases need revisiting.
+
+## Workflow
+
+### Step 1: Create or Update the Business Model Canvas
+
+The BMC defines how the business works — the full system of value creation, delivery, and capture. It changes rarely, but it must exist before anything else begins.
+
+See `references/business-model-canvas.md` for the nine blocks, how to populate each one, and the file format.
+
+Create: `/docs/business-model-canvas.md`
+
+### Step 2: Create or Update the Value Proposition Canvas
+
+The VPC zooms into one side of the BMC — the relationship between what the product offers and what a specific customer segment needs. It is the primary source that story-mapping, ux-research, and bdd-specification read from.
+
+See `references/value-proposition-canvas.md` for the two sides, how to populate each, the output contract that downstream skills depend on, and the file format.
+
+Create: `/docs/value-proposition-canvas.md`
+
+### Step 3: Validate Alignment
+
+The two canvases must be consistent. A VPC that targets a customer segment not in the BMC is a strategy conflict. A BMC revenue stream that no VPC supports is an unfunded promise.
+
+See `references/canvas-alignment.md` for the alignment checks, how to detect drift, and how to resolve conflicts.
+
+## Output Contract
+
+Downstream skills depend on specific fields existing in the VPC. The VPC must expose these, grouped by customer segment:
+
+- **Customer Jobs** — what the customer is trying to accomplish. Story-mapping reads these to derive backbone activities.
+- **Pains** — what frustrates them about the current way. Personas pull frustrations from here. Task templates and release plans reference these.
+- **Gains** — what they want to achieve. Personas pull goals from here. Release plans and Gherkin "So that" clauses reference these.
+
+If any of these are missing or ambiguous, the downstream skills will produce work that is not grounded in customer value.
+
+## Integration
+
+```
+product-strategy (this skill)  →  creates BMC and VPC
+    ↓
+ux-research                    →  reads VPC, writes findings back into VPC
+    ↓
+story-mapping                  →  reads VPC Customer Jobs → backbone activities
+    ↓
+bdd-specification              →  reads VPC for business value context
+    ↓
+ui-design-workflow             →  reads VPC for user goals and pain points
+    ↓
+atdd-workflow                  →  reads both BMC and VPC for business context
+    ↓
+continuous-improvement         →  may trigger VPC/BMC updates if strategy drift detected
+    ↓
+product-strategy (this skill)  →  updates canvases, re-validates alignment
+```

package/product-strategy/references/business-model-canvas.md

@@ -0,0 +1,199 @@
+# Business Model Canvas
+
+## What Is the BMC?
+
+A single-page strategic view of how a business creates, delivers, and captures value. It is not a financial plan or a roadmap — it is a map of the system. It shows how every part of the business connects to every other part.
+
+The BMC changes rarely. It is created once at project start and revisited when the business fundamentally changes direction — entering a new market, adding a new revenue model, or discovering that a core assumption was wrong.
+
+## The Nine Blocks
+
+The blocks are not independent. They form a system. Populate them in the order below — each block's answers inform the next.
+
+### 1. Customer Segments
+**Who are we creating value for?**
+
+Define distinct groups of people or organizations the business intends to serve. Each segment has meaningfully different needs, behaviors, or economics.
+
+- List segments, not job titles. A segment is a group with shared characteristics that affect how they buy, use, and value the product.
+- Each segment here must have a corresponding Value Proposition (Block 2) and a corresponding customer profile in the VPC.
+- 2–4 segments maximum. More means the business is unfocused.
+
+**Questions:**
+- Who are the most important customers?
+- What are the different customer groups we serve?
+- Which segments are most profitable to serve?
+- Which segments validate our core value proposition?
+
+### 2. Value Propositions
+**What value do we deliver to each segment?**
+
+For each Customer Segment, state what problem the product solves and what benefit it delivers. This is the bridge between the BMC and the VPC — each value proposition here has a full VPC that details the customer jobs, pains, and gains.
+
+- One value proposition per customer segment.
+- State the value in terms the customer would use, not internal terminology.
+- Be specific. "Saves time" is not a value proposition. "Eliminates 30 minutes of manual invoice entry per week" is.
+
+**Questions:**
+- What value do we deliver to the customer?
+- Which customer problems are we solving?
+- Which customer needs are we satisfying?
+- Why should they choose us over alternatives?
+
+### 3. Channels
+**How do we reach and deliver to each segment?**
+
+The touchpoints through which customers discover, evaluate, purchase, and receive the product.
+
+- Include both acquisition channels (how they find us) and delivery channels (how they get the product).
+- For a software product, delivery is typically self-service (web, app store, direct download). Acquisition may be organic, paid, referral, or partnership.
+
+**Questions:**
+- How do customers want to be reached?
+- How are we reaching them now? How effectively?
+- Which channels are most cost-efficient?
+- How do channels integrate with the customer's routine?
+
+### 4. Customer Relationships
+**What type of relationship does each segment expect?**
+
+The nature of the ongoing interaction between the business and each customer segment.
+
+- For most software products: self-service with community support. Some segments may expect white-glove onboarding or dedicated account management.
+- The relationship type directly affects onboarding strategy (see ux-design onboarding.md) and support costs.
+
+**Questions:**
+- What relationship does each segment expect?
+- Which relationships have we established?
+- How costly are these relationships to maintain?
+- How do relationships integrate with the rest of the business model?
+
+### 5. Revenue Streams
+**How does revenue flow from each segment?**
+
+The pricing model and payment structure for each customer segment.
+
+- Each revenue stream must map to at least one Customer Segment and at least one Value Proposition. A revenue stream with no supporting value proposition is an unfunded promise — catch this in canvas-alignment.md.
+- Common models for software: subscription (recurring), freemium (conversion-based), usage-based, one-time license.
+
+**Questions:**
+- What are customers willing to pay for?
+- How do they currently pay for similar value?
+- What pricing model fits the value delivered?
+- What is the revenue potential per segment?
+
+### 6. Key Resources
+**What assets do we need to deliver the value proposition?**
+
+The critical resources required to make the business model work.
+
+- For a software product: engineering talent, infrastructure, data, brand, and distribution partnerships.
+- Resources that are scarce or expensive to acquire are risk points. Flag them.
+
+**Questions:**
+- What key resources do our value propositions require?
+- What resources do our channels, customer relationships, and revenue streams require?
+- Which resources are hardest to acquire or replace?
+
+### 7. Key Activities
+**What critical things must we do?**
+
+The most important actions the business must take to deliver its value propositions.
+
+- For a software product: product development, customer acquisition, data operations, and customer success.
+- Activities that are on the critical path to delivering value are risk points if delayed or under-resourced.
+
+**Questions:**
+- What key activities do our value propositions require?
+- What activities do our channels, customer relationships, and revenue streams require?
+- Which activities are hardest to execute well?
+
+### 8. Key Partnerships
+**Who are our most important partners and suppliers?**
+
+External entities the business depends on to deliver its model.
+
+- For a software product: cloud infrastructure providers, payment processors, app store platforms, data providers, and distribution partners.
+- A dependency on a single partner with no alternative is a risk point. Flag it.
+
+**Questions:**
+- Who are our key partners and suppliers?
+- Which key resources do we acquire from partners?
+- Which key activities do partners perform for us?
+- Why would we want to make this partnership?
+
+### 9. Cost Structure
+**What are the costs of operating this business model?**
+
+The major costs incurred in delivering the value propositions, maintaining channels, and sustaining key activities.
+
+- For a software product: engineering salaries, infrastructure costs, marketing spend, and customer support costs.
+- Understand whether the model is cost-driven (competing on price) or value-driven (competing on premium value). This affects every pricing and positioning decision.
+
+**Questions:**
+- What are the most expensive aspects of our business model?
+- Which key resources and activities are most expensive?
+- Is our model cost-driven or value-driven?
+- Are costs fixed or variable as we scale?
+
+## File Format
+
+Create: `/docs/business-model-canvas.md`
+
+```markdown
+# Business Model Canvas
+
+**Created:** [Date]
+**Last updated:** [Date]
+**Product:** [Product name]
+
+## Customer Segments
+- **[Segment name]:** [2–3 sentence description of who they are and why they matter]
+- **[Segment name]:** [description]
+
+## Value Propositions
+- **For [Segment name]:** [What problem we solve and what benefit we deliver. Specific, not generic.]
+- **For [Segment name]:** [description]
+
+## Channels
+- **Acquisition:** [How customers discover and evaluate the product]
+- **Delivery:** [How customers access and receive the product]
+
+## Customer Relationships
+- **[Segment name]:** [What type of relationship this segment expects]
+- **[Segment name]:** [description]
+
+## Revenue Streams
+- **[Stream name]:** [Pricing model, target segment, expected revenue characteristics]
+- **[Stream name]:** [description]
+
+## Key Resources
+- [Resource 1 — and why it is critical]
+- [Resource 2]
+
+## Key Activities
+- [Activity 1 — and why it is critical]
+- [Activity 2]
+
+## Key Partnerships
+- [Partner 1 — what we depend on them for, and whether alternatives exist]
+- [Partner 2]
+
+## Cost Structure
+- **Model type:** Cost-driven / Value-driven
+- [Cost category 1 — relative magnitude: high / medium / low]
+- [Cost category 2]
+
+## Risk Points
+[Flag any single points of failure identified while populating the blocks above:
+partnerships with no alternatives, revenue streams with no supporting value proposition, etc.]
+- [Risk 1]
+- [Risk 2]
+```
+
+## Rules
+
+- The BMC is a strategy document, not a specification. It describes the system at a high level. Detail lives in the VPC, story map, and feature files.
+- Every Customer Segment must have a corresponding Value Proposition. If a segment exists with no value proposition, remove the segment or define the proposition.
+- Every Revenue Stream must map to at least one Value Proposition. Validate this in canvas-alignment.md.
+- Revisit the BMC when: a new market is entered, a revenue model changes, a key partnership is lost, or continuous-improvement flags that the product is not delivering the stated value.

package/product-strategy/references/canvas-alignment.md

@@ -0,0 +1,108 @@
+# Canvas Alignment
+
+## Why Alignment Matters
+
+The BMC and VPC are two views of the same strategy. The BMC is the full system. The VPC zooms into one relationship within that system. If they disagree, the product is being built toward contradictory goals. Downstream skills will not catch this — they read each canvas independently. Only this check catches the conflict.
+
+Alignment is not a one-time verification. It is checked every time either canvas changes.
+
+## The Alignment Checks
+
+Run all five checks whenever a canvas is created or updated.
+
+### Check 1: Every Customer Segment Has a VPC
+
+**Rule:** Every segment listed in BMC → Customer Segments must have a corresponding section in the VPC.
+
+**What a failure looks like:** The BMC lists "Enterprise IT Departments" as a segment. No VPC section exists for them. The business model assumes this segment generates revenue, but no one has defined what value the product delivers to them or what problems it solves for them.
+
+**How to resolve:** Either create the VPC for the missing segment, or remove the segment from the BMC if it is aspirational and not yet being served.
+
+### Check 2: Every Revenue Stream Has a Supporting Value Proposition
+
+**Rule:** Every stream listed in BMC → Revenue Streams must map to at least one Value Proposition in BMC → Value Propositions, which must map to at least one VPC.
+
+**What a failure looks like:** The BMC lists "Enterprise consulting revenue" as a revenue stream. The Value Propositions block has no corresponding proposition. No VPC defines what value consulting delivers. This is an unfunded promise — the business model assumes income from a value the product does not yet deliver.
+
+**How to resolve:** Either define the value proposition and VPC that supports this revenue stream, or remove the revenue stream from the BMC until the value proposition is defined.
+
+### Check 3: VPC Customer Jobs Map to BMC Customer Segments
+
+**Rule:** Every Customer Job in the VPC must belong to a segment that exists in the BMC.
+
+**What a failure looks like:** The VPC defines a job "Generate tax reports for quarterly filing" under a segment called "Small Business Owners." The BMC does not list Small Business Owners as a Customer Segment — it lists "Freelancers" and "Agency Owners." The VPC is targeting a segment the business model does not serve.
+
+**How to resolve:** Either add the segment to the BMC (with corresponding value proposition, channels, and revenue stream), or move the job to an existing segment that actually performs it.
+
+### Check 4: Pain Relievers and Gain Creators Cover the Core Value Proposition
+
+**Rule:** The BMC's Value Proposition for each segment must be supported by specific Pain Relievers and Gain Creators in the VPC. The stated value proposition cannot be vaguer than what the VPC promises.
+
+**What a failure looks like:** The BMC states "Eliminates manual invoice entry entirely." The VPC's Pain Relievers say "Reduces invoice entry time by providing templates." The BMC promises elimination. The VPC delivers reduction. The product cannot deliver what the BMC promises — either the BMC overstates the value or the VPC understates what the product does.
+
+**How to resolve:** Align the language. If the product truly eliminates manual entry, update the VPC. If it only reduces it, update the BMC. The canvases must agree on what the product actually delivers.
+
+### Check 5: Unaddressed Pains and Gains Are Explicitly Dispositioned
+
+**Rule:** Every pain with no pain reliever and every gain with no gain creator must have a documented disposition in the VPC's "Unaddressed" section.
+
+**What a failure looks like:** The VPC lists "Worried about missing payment deadlines" as a pain. No pain reliever addresses it. The Unaddressed section is empty. Story-mapping will not flag this — it will simply not create a task for it. The pain exists, the customer feels it, and the product ignores it silently.
+
+**How to resolve:** Disposition each unaddressed item. Either "Must Have — target Release [N]" or "Out of scope — because [reason]." If it is Must Have, it must appear in the next release plan.
+
+## How Findings Trigger Updates
+
+Two skills feed findings back into the canvases. Each has a specific trigger and a specific update pattern.
+
+### When ux-research Returns Findings
+
+ux-research produces personas, mental models, and journey maps. These may reveal:
+
+- **A new Customer Job** the VPC did not capture. A persona's goals include something not listed as a job.
+  - **Action:** Add the job to the VPC. Check if it maps to an existing BMC segment or requires a new one (Check 3).
+
+- **A pain more severe than expected.** A journey map shows a pain point with high frustration that the VPC listed but did not prioritize.
+  - **Action:** Re-order the VPC's Pains list. Check if the most painful pain is being addressed by the product (Check 5). If not, escalate to Must Have in the next release plan.
+
+- **A gain the customer values that the VPC did not list.** A persona's goals include something not in the VPC's Gains.
+  - **Action:** Add the gain to the VPC. Disposition it — is it something the product should create, or is it out of scope?
+
+- **A mental model conflict.** The product's structure conflicts with how users think about the domain.
+  - **Action:** This does not change the canvases directly. It changes IA and interaction design (ux-design). But if the conflict is severe enough that the product's core value proposition is undermined, it may require revisiting the VPC's Products & Services section.
+
+### When continuous-improvement Flags Strategy Drift
+
+Post-release measurement may reveal:
+
+- **Users are not experiencing the gain the VPC promises.** The gain creator exists in the VPC, but users report they are not experiencing the gain in practice.
+  - **Action:** The value proposition may be wrong, or the implementation may not deliver what the VPC describes. Investigate whether the VPC needs updating (the gain is aspirational, not current) or whether the implementation needs fixing (the gain should be current but isn't).
+
+- **A pain the VPC says is relieved keeps appearing in support tickets.** The pain reliever exists on paper but does not work in practice.
+  - **Action:** Either the pain reliever is insufficient (update the VPC to be honest about what the product actually does) or the implementation has a bug (fix the implementation, not the canvas).
+
+- **A revenue stream is underperforming.** The BMC assumes revenue from a segment, but conversion or retention is low.
+  - **Action:** Check whether the value proposition for that segment is compelling enough. The VPC may need revisiting — is the product actually delivering enough value to justify the price?
+
+## Alignment Checklist
+
+Run after every canvas creation or update:
+
+```markdown
+## Alignment Check — [Date]
+
+- [ ] Check 1: Every BMC Customer Segment has a VPC section
+- [ ] Check 2: Every BMC Revenue Stream maps to a Value Proposition with a supporting VPC
+- [ ] Check 3: Every VPC Customer Job belongs to a segment in the BMC
+- [ ] Check 4: BMC Value Propositions and VPC Pain Relievers/Gain Creators agree on what the product delivers
+- [ ] Check 5: Every unaddressed pain and gain in the VPC has a documented disposition
+
+### Conflicts Found
+[List any check that failed, what the conflict is, and how it was resolved.]
+- Check [N]: [Conflict description] → [Resolution]
+
+### Updates Made
+[List any changes made to either canvas as a result of this alignment check.]
+- [Canvas]: [What changed and why]
+```
+
+Append this checklist to the bottom of `/docs/business-model-canvas.md` each time alignment is validated. It is the audit trail showing the canvases were checked and are in sync.

package/product-strategy/references/value-proposition-canvas.md

@@ -0,0 +1,159 @@
+# Value Proposition Canvas
+
+## What Is the VPC?
+
+The VPC zooms into one specific relationship from the BMC: what a specific customer segment needs and what the product offers them. It is the most frequently read document in the methodology — six skills consume it directly. Getting it wrong means every downstream skill builds on a faulty foundation.
+
+One VPC per customer segment. If the BMC defines three segments, there are three VPCs. Each lives in the same file, clearly separated by segment.
+
+## The Two Sides
+
+### Side 1: Customer Profile (what the customer needs)
+
+Three categories, populated from research — not from assumptions about what the product will do.
+
+#### Customer Jobs
+What the customer is trying to accomplish. Jobs are activities, not features. They are stated in the customer's language, not the product's.
+
+- **Functional jobs:** Tasks they need to complete. "Send an invoice to a client." "Know how much money I owe in taxes."
+- **Social jobs:** How they want to be perceived. "Look professional to my clients." "Demonstrate financial responsibility to my accountant."
+- **Emotional jobs:** How they want to feel. "Feel confident my finances are under control." "Stop worrying about unpaid invoices."
+
+**Rules:**
+- Jobs are statements of intent, not descriptions of pain. "Track unpaid invoices" is a job. "Frustrated by losing track of invoices" is a pain.
+- Order jobs by importance to the customer. The top job is the one the product must solve to deliver core value.
+- Each job here becomes a backbone activity in story-mapping. The mapping is direct — do not invent activities that have no corresponding job.
+
+#### Pains
+What frustrates the customer when trying to accomplish their jobs. Pains are specific, observable problems — not vague dissatisfaction.
+
+- **Emotional pains:** Anxiety, frustration, fear. "Worried I'll miss a payment deadline."
+- **Functional pains:** Obstacles and inefficiencies. "Spends 45 minutes manually entering invoice data into a spreadsheet every Friday."
+- **Social pains:** How current solutions make them feel. "Embarrassed to send invoices that look unprofessional."
+
+**Rules:**
+- Pains map to frustrations in persona documents (ux-research). The same pain appears in both places — the VPC names it, the persona contextualizes it.
+- Pains map to Must Have features in release planning. The most painful pain is the first problem the product must solve.
+- Be specific about magnitude. "Takes too long" is vague. "Takes 45 minutes" is measurable and testable.
+
+#### Gains
+What the customer wants to achieve or experience as a result of accomplishing their jobs. Gains are the definition of success.
+
+- **Functional gains:** What they want the product to do. "Send invoices in under 2 minutes."
+- **Social gains:** How they want to be seen. "Clients perceive me as organized and professional."
+- **Emotional gains:** How they want to feel. "Confident that all invoices are tracked and followed up on automatically."
+- **Strategic gains:** Long-term outcomes. "Spend less time on admin, more time on client work."
+
+**Rules:**
+- Gains map to goals in persona documents (ux-research). The same gain appears in both places.
+- Gains map to "So that" clauses in Gherkin scenarios (bdd-specification). Every scenario's business value statement traces back to a gain defined here.
+- Order gains by importance. The top gain is what the product delivers when it is working perfectly.
+
+### Side 2: Value Proposition (what the product offers)
+
+Three categories, each directly responding to the customer profile on the other side.
+
+#### Products & Services
+What the product actually is and does. The concrete offering.
+
+- List the product itself and any services that accompany it (onboarding, support, integrations).
+- Each product or service must respond to at least one Customer Job. If a feature exists that serves no job, it is waste.
+
+#### Pain Relievers
+How the product addresses each pain. Each pain reliever maps to a specific pain.
+
+- Be explicit about the mapping: "Relieves [pain name] by [how]."
+- If a pain has no pain reliever, it is an unaddressed problem. Either the product must address it (becomes a Must Have feature) or the pain is out of scope (document why).
+
+#### Gain Creators
+How the product delivers each gain. Each gain creator maps to a specific gain.
+
+- Be explicit about the mapping: "Creates [gain name] by [how]."
+- If a gain has no gain creator, it is an unmet expectation. Either the product must create it or the gain is aspirational for a future release (document when).
+
+## Output Contract
+
+This is what downstream skills read. Every field below must be populated. Ambiguous or missing fields break the chain.
+
+```
+Customer Jobs    → story-mapping reads to derive backbone activities
+                 → ux-research reads to identify persona segments
+Pains            → ux-research pulls into persona frustrations
+                 → story-mapping references in task templates
+                 → story-mapping references in release plans
+Gains            → ux-research pulls into persona goals
+                 → bdd-specification uses for "So that" clauses
+                 → story-mapping references in task templates
+                 → story-mapping references in release plans
+                 → ui-design-workflow reads for user goals context
+```
+
+## File Format
+
+Create: `/docs/value-proposition-canvas.md`
+
+If multiple customer segments exist, each segment gets its own clearly separated section. All segments live in the same file.
+
+```markdown
+# Value Proposition Canvas
+
+**Created:** [Date]
+**Last updated:** [Date]
+**Product:** [Product name]
+
+---
+
+## Segment: [Segment Name]
+
+**BMC reference:** Customer Segments → [Segment name]
+
+### Customer Profile
+
+#### Customer Jobs
+1. **[Job name]** — [Description in customer's language. What they are trying to accomplish.]
+2. **[Job name]** — [Description]
+
+#### Pains
+1. **[Pain name]** — [Specific, observable problem. Include magnitude where possible.]
+2. **[Pain name]** — [Description]
+
+#### Gains
+1. **[Gain name]** — [What success looks like for the customer. Specific, not vague.]
+2. **[Gain name]** — [Description]
+
+### Value Proposition
+
+#### Products & Services
+- **[Product/service name]:** [What it is and what it does. Maps to which Customer Job(s).]
+- **[Product/service name]:** [Description]
+
+#### Pain Relievers
+- **Relieves [Pain name]** by [How the product addresses this specific pain]
+- **Relieves [Pain name]** by [How]
+
+#### Gain Creators
+- **Creates [Gain name]** by [How the product delivers this specific gain]
+- **Creates [Gain name]** by [How]
+
+### Unaddressed
+[Document any pains with no pain reliever and any gains with no gain creator.
+Each must have a disposition: "Must Have — target Release [N]" or "Out of scope — because [reason]".]
+
+- Pain: [Pain name] — [disposition]
+- Gain: [Gain name] — [disposition]
+
+---
+
+## Segment: [Next Segment Name]
+
+[Same structure as above]
+```
+
+## Rules
+
+- Customer Jobs are ordered by importance. The first job is the one the product must solve to deliver core value. Story-mapping will derive the backbone in this order.
+- Pains and Gains are ordered by severity and importance respectively. The first pain is the most painful. The first gain is the most valued.
+- Every pain must have a disposition: relieved by the product, or explicitly out of scope with a reason.
+- Every gain must have a disposition: created by the product, or explicitly aspirational with a target release.
+- The VPC is updated whenever ux-research returns findings. Personas and journey maps may reveal jobs, pains, or gains that were not visible at canvas creation time.
+- Do not populate the Value Proposition side (Products & Services, Pain Relievers, Gain Creators) until the Customer Profile side is complete. The value proposition must respond to real customer needs, not the other way around.

package/project-templates/context.md.template

@@ -0,0 +1,56 @@
+# Project Context for Claude Code
+
+## Project Overview
+- **Name**: [PROJECT_NAME]
+- **Purpose**: [BUSINESS_PURPOSE]
+- **Tech Stack**: [LANGUAGES, FRAMEWORKS, DATABASES]
+
+## Methodology
+This project uses ATDD + Red-Green-Refactor workflow.
+
+**Skills available at `/mnt/skills/user/`:**
+- `product-strategy/SKILL.md` — business model canvas and value proposition canvas (foundation — run first)
+- `ux-research/SKILL.md` — personas, mental models, and user journey maps
+- `story-mapping/SKILL.md` — organizing user activities and tasks
+- `bdd-specification/SKILL.md` — writing Gherkin specifications
+- `ux-design/SKILL.md` — information architecture, interaction patterns, usability evaluation, onboarding
+- `ui-design-workflow/SKILL.md` — screen flows, component selection, acceptance targets
+- `ui-design-system/SKILL.md` — design tokens, layout, typography, components, accessibility (reference — consulted during UI design)
+- `atdd-workflow/SKILL.md` — RED-GREEN-REFACTOR implementation workflow
+- `clean-code/SKILL.md` — SOLID principles and design patterns (reference — consulted during GREEN and REFACTOR)
+- `cicd-pipeline/SKILL.md` — CI/CD pipeline stages, environment promotion, deployment and rollback (bridge from commit to production)
+- `continuous-improvement/SKILL.md` — post-release measurement, root cause analysis, process updates (run after each release)
+
+**Read the relevant skill BEFORE starting any work.**
+
+## Context Files (Read Before Implementation)
+1. `/docs/test-strategy.md` — testing tools and commands
+2. `/docs/business-model-canvas.md` — business model
+3. `/docs/value-proposition-canvas.md` — customer value propositions
+4. `/docs/story-map/backbone.md` — user activities
+5. `/docs/ubiquitous-language.md` — domain terminology
+
+## Project-Specific Rules
+[Add constraints, naming conventions, patterns specific to this project]
+
+Examples:
+- All monetary values use Money value object (never raw numbers)
+- Dates in ISO 8601 format
+- All user-facing text supports i18n
+
+## Architecture
+[Describe your layer structure and folder organization]
+
+Examples:
+- `/src/domain/` — pure business logic, no external dependencies
+- `/src/application/` — use cases and orchestration
+- `/src/infrastructure/` — databases, APIs, adapters
+- `/src/presentation/` — UI layer
+
+## Current Focus
+- **Release:** [RELEASE_NAME]
+- **Target:** [DATE]
+- **Story Map:** `/docs/story-map/releases/[release].md`
+
+## Additional Notes
+[Any other context Claude Code needs to know]