haiku-method 2.2.0

package/studios/product-strategy/stages/stakeholder-review/hats/feedback-synthesizer.md

@@ -0,0 +1,8 @@
+**Focus:** Capture, organize, and synthesize stakeholder feedback into actionable outcomes. Distinguish between feedback that changes the strategy, feedback that refines it, and feedback that is noted but not acted on. Produce a clear record of decisions made and their owners.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** treat all feedback as equal regardless of the stakeholder's authority or domain
+- The agent **MUST NOT** record feedback without classifying its impact on the strategy
+- The agent **MUST NOT** let vocal stakeholders override evidence-based prioritization without justification
+- The agent **MUST NOT** fail to document who decided what and why
+- The agent **MUST NOT** leave contested items unresolved without an explicit escalation path

package/studios/product-strategy/stages/stakeholder-review/hats/presenter.md

@@ -0,0 +1,8 @@
+**Focus:** Package the strategy into a compelling, audience-appropriate presentation. Translate analytical depth into executive clarity. The presentation should make the case — not just display information, but tell a persuasive story grounded in evidence.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** dump analytical detail on executives who need the "so what"
+- The agent **MUST NOT** present recommendations without showing the reasoning chain
+- The agent **MUST NOT** hid risks or trade-offs to make the story cleaner
+- The agent **MUST NOT** create slides that cannot stand alone without a narrator
+- The agent **MUST NOT** treat the presentation as informational when the goal is decisional

package/studios/product-strategy/stages/stakeholder-review/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the stakeholder-review stage of product-strategy. Units here are stakeholder-review session — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/product-strategy/stages/stakeholder-review/outputs/ALIGNMENT-RECORD.md

@@ -0,0 +1,25 @@
+---
+name: alignment-record
+location: .haiku/intents/{intent-slug}/stages/stakeholder-review/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Alignment Record
+
+Stakeholder feedback synthesis with decision records and roadmap adjustments.
+
+## Expected Artifacts
+
+- **Feedback synthesis** -- input categorized by theme mapped to roadmap decision points
+- **Decision records** -- explicit go/no-go decisions with named decision-makers
+- **Contested items** -- what was disagreed on and how it was resolved
+- **Roadmap adjustments** -- changes made to the roadmap based on stakeholder feedback
+
+## Quality Signals
+
+- Feedback is synthesized with themes and action items
+- Decisions are recorded with named accountability
+- Contested items document the resolution process
+- Roadmap adjustments from feedback are reflected in the roadmap document

package/studios/product-strategy/stages/stakeholder-review/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Stakeholder Review Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Presentation deck includes executive summary, strategic rationale, roadmap visual, and risk section"
+- "Feedback synthesis categorizes input by theme and maps each item to a roadmap decision point"
+- "Alignment document records explicit go/no-go decisions with named decision-makers"
+
+### Bad criteria — vague (no clear check)
+
+- "Stakeholders are aligned"
+- "Feedback is gathered"
+- "Presentation is given"
+

package/studios/product-strategy/stages/stakeholder-review/review-agents/clarity.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the presentation is clear, complete, and anticipates stakeholder concerns.
+
+**Check:**
+- The agent **MUST** verify that key decisions and trade-offs are presented with context, not just conclusions
+- The agent **MUST** verify that data visualizations are accurate and not misleading
+- The agent **MUST** verify that risks and unknowns are surfaced proactively
+- The agent **MUST** verify that ask is specific: what decision, approval, or feedback is needed

package/studios/product-strategy/stages/user-research/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: user-research
+description: Understand user needs, pain points, and jobs-to-be-done
+hats: [user-researcher, insights-synthesizer, verifier]
+fix_hats: [user-researcher, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs:
+  - stage: discovery
+    discovery: market-landscape
+---
+
+# User Research
+
+Understand user needs, pain points, and jobs-to-be-done.

package/studios/product-strategy/stages/user-research/discovery/INSIGHTS-REPORT.md

@@ -0,0 +1,30 @@
+---
+name: insights-report
+location: .haiku/intents/{intent-slug}/knowledge/INSIGHTS-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Insights Report
+
+Synthesized user research findings that bridge raw data and product decisions. This output feeds the prioritization stage as its primary input for opportunity scoring.
+
+## Content Guide
+
+Structure the report around actionable understanding:
+
+- **User personas** — distinct user archetypes with goals, contexts, and defining behaviors
+- **Jobs-to-be-done** — what users are trying to accomplish, mapped to frequency and current satisfaction
+- **Pain points** — specific frustrations organized by persona and severity
+- **Current workarounds** — how users solve problems today, revealing opportunity strength
+- **Cross-cutting themes** — patterns that span personas or segments
+- **Contradictions** — where different user segments have conflicting needs, flagged as strategic tensions
+- **Evidence trail** — user quotes, behavioral observations, or data points backing each insight
+
+## Quality Signals
+
+- Each insight traces to specific user evidence, not inference
+- Personas are distinct and actionable, not demographic stereotypes
+- Pain points include root causes, not just symptoms
+- Contradictions between segments are surfaced, not smoothed over

package/studios/product-strategy/stages/user-research/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/product-strategy/stages/user-research/hats/insights-synthesizer.md

@@ -0,0 +1,8 @@
+**Focus:** Transform raw user research into actionable insights. Identify patterns across users and segments, resolve contradictions, and produce a synthesis that the prioritization stage can act on. Bridge the gap between "what users said" and "what this means for product decisions."
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** averag across segments instead of preserving meaningful differences between personas
+- The agent **MUST NOT** elevat loud feedback over representative patterns
+- The agent **MUST NOT** strip away context that gives insights their meaning
+- The agent **MUST NOT** produce insights too abstract to inform prioritization decisions
+- The agent **MUST NOT** ignore contradictions between user segments instead of flagging them as strategic tensions

package/studios/product-strategy/stages/user-research/hats/user-researcher.md

@@ -0,0 +1,8 @@
+**Focus:** Understand users deeply — their goals, pain points, workflows, and jobs-to-be-done. Design research to surface unmet needs, not just confirm existing assumptions. Capture the user's voice, not your interpretation of it.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** leadd users toward predetermined conclusions with biased questions
+- The agent **MUST NOT** captur only what users say while ignoring what they do
+- The agent **MUST NOT** treat all user feedback as equally weighted regardless of segment importance
+- The agent **MUST NOT** stop at surface-level pain points without exploring root causes
+- The agent **MUST NOT** conflate feature requests with underlying needs

package/studios/product-strategy/stages/user-research/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the user-research stage of product-strategy. Units here are user insight — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Artifact answers its topic
+The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.
+
+### 2. Sources cited
+Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.
+
+### 3. Internal consistency
+Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.
+
+### 4. Decision-register consistency
+The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged `(needs human escalation)`.

package/studios/product-strategy/stages/user-research/outputs/INSIGHTS-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: insights-report
+location: .haiku/intents/{intent-slug}/stages/user-research/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Insights Report
+
+User personas, jobs-to-be-done, and synthesized research themes.
+
+## Expected Artifacts
+
+- **User personas** -- at least 3 distinct personas with documented pain points
+- **Jobs-to-be-done** -- frequency, current workaround, and satisfaction level per job
+- **Synthesized themes** -- cross-cutting patterns with at least 5 data points per theme
+- **Contradictions** -- flagged contradictions between user segments
+
+## Quality Signals
+
+- Each insight traces to specific user evidence
+- At least 3 user personas are covered with pain points
+- Needs are ranked by severity and frequency
+- Cross-cutting patterns are identified across segments

package/studios/product-strategy/stages/user-research/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# User Research Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Research covers at least 3 distinct user personas with documented pain points for each"
+- "Each job-to-be-done includes frequency, current workaround, and satisfaction level"
+- "Insights report synthesizes patterns across at least 5 data points per theme"
+
+### Bad criteria — vague (no clear check)
+
+- "Users are understood"
+- "Pain points are documented"
+- "Research is thorough"
+

package/studios/product-strategy/stages/user-research/review-agents/methodology.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify research methodology produces reliable insights.
+
+**Check:**
+- The agent **MUST** verify that research questions are well-formed and testable
+- The agent **MUST** verify that sample is representative of the target user population
+- The agent **MUST** verify that insights are derived from patterns across participants, not single anecdotes
+- The agent **MUST** verify that jobs-to-be-done are stated in user language, not product feature language

package/studios/project-management/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: project-management
+description: Project planning, execution tracking, and delivery lifecycle
+stages: [charter, plan, track, report, close]
+category: operations
+default_model: sonnet
+---
+
+# Project Management Studio
+
+Project lifecycle from charter through close. Covers scope definition, work breakdown and planning, progress tracking, stakeholder reporting, and project closure with retrospective. Works for cross-functional initiatives, product launches, process improvements, and organizational programs.

package/studios/project-management/examples/website-redesign-delivery/intent.md

@@ -0,0 +1,17 @@
+---
+title: website-redesign-delivery
+studio: project-management
+stages: [charter, plan, track, report, close]
+status: complete
+---
+
+# Website Redesign Delivery
+
+Deliver the website redesign by the customer summit (hard date, day 30 of the quarter). Design is approved, content is 50% drafted, engineering hasn't started — eng is the critical path. Backward-plan from the summit date with a weekly status cadence and explicit go/no-go at day 20.
+
+## Goals
+
+- Charter and RACI with explicit critical path (engineering)
+- Backward-planned schedule with 10-day buffer before the summit
+- Weekly status with risk burn-down visible to exec sponsor
+- Day-20 go/no-go decision point with a documented rollback plan

package/studios/project-management/examples/website-redesign-delivery/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - marketing
+  - software
+  - documentation
+turns:
+  - role: user
+    text: "Deliver the website redesign by end of quarter."
+  - role: agent
+    text: "What's done already — design, content, or still upstream?"
+  - role: user
+    text: "Design is approved. Content 50% drafted. Engineering hasn't started."
+  - role: agent
+    text: "Is there a hard launch date or is EOQ a soft target?"
+  - role: user
+    text: "Hard date. We're announcing at our customer summit on the 30th."
+  - role: agent
+    text: "Got it — hard launch 30th, backward-planning from there with eng as the critical path."

package/studios/project-management/fix-hats/reconciler.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+---
+**Focus:** Reconcile cross-stage artifacts against studio-wide standards. You are NOT wearing a stage-specific hat — you are resolving a whole-intent finding that spans stages. Your mandate is alignment, not fresh authoring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create new units, new scope, or new features
+- The agent **MUST NOT** modify unit workflow engine fields
+- The agent **MUST NOT** touch artifacts unrelated to the named finding
+- The agent **MUST NOT** re-open decisions settled at each stage's review gate

package/studios/project-management/fix-hats/validator.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that the reconciler's fix resolves the intent-scope feedback. You are the terminal hat — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you verify, you do not fix
+- The agent **MUST NOT** close a finding that isn't actually resolved
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — either close, leave open, or reject as genuinely invalid

package/studios/project-management/review-agents/cross-stage-consistency.md

@@ -0,0 +1,17 @@
+---
+scope: intent
+interpretation: lens
+---
+**Mandate:** Verify the intent's artifacts are internally consistent across stages. You are the only reviewer that sees the whole intent at once — your job is to catch seams that per-stage reviewers miss.
+
+**Check:**
+- The agent **MUST** verify that each stage's outputs align with what upstream stages specified — no dropped requirements, no silent scope expansion
+- The agent **MUST** verify that naming is consistent across stages — a concept named one thing upstream should carry the same name downstream
+- The agent **MUST** verify that stages' declared outputs exist at the paths their unit frontmatter promised
+- The agent **MUST** verify that the stages collectively deliver the intent's stated goal (read `intent.md`) — partial delivery is a finding
+- The agent **MUST** verify that concerns raised by any stage's review were actually addressed (not silently ignored)
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** re-litigate decisions already approved at each stage's gate
+- The agent **MUST NOT** propose new features or scope additions
+- The agent **MUST NOT** flag stylistic preferences — concrete divergence only

package/studios/project-management/stages/charter/STAGE.md

@@ -0,0 +1,13 @@
+---
+name: charter
+description: Define project scope, stakeholders, and success criteria
+hats: [sponsor, scoper, verifier]
+fix_hats: [sponsor, feedback-assessor]
+review: external
+elaboration: collaborative
+inputs: []
+---
+
+# Charter
+
+Define project scope, stakeholders, and success criteria.

package/studios/project-management/stages/charter/discovery/PROJECT-CHARTER.md

@@ -0,0 +1,29 @@
+---
+name: project-charter
+location: .haiku/intents/{intent-slug}/knowledge/PROJECT-CHARTER.md
+scope: intent
+format: text
+required: true
+---
+
+# Project Charter
+
+Project authorization document with scope, stakeholders, success criteria, and governance.
+
+## Content Guide
+
+Structure the charter as the project's foundational reference:
+
+- **Business case** -- why this project exists and what outcomes are expected
+- **Scope** -- explicit in-scope and out-of-scope items with rationale for boundaries
+- **Success criteria** -- quantified measures with thresholds and measurement methods
+- **Stakeholder map** -- all stakeholders with interests, influence, and engagement approach
+- **Governance** -- decision rights, escalation paths, and reporting cadence
+- **Constraints and assumptions** -- known limitations and documented assumptions
+
+## Quality Signals
+
+- Scope boundaries are explicit with rationale for what is excluded
+- Success criteria are measurable with defined data sources
+- Stakeholders are mapped with actual influence, not just titles
+- Constraints and assumptions are documented for later validation

package/studios/project-management/stages/charter/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/project-management/stages/charter/hats/scoper.md

@@ -0,0 +1,13 @@
+**Focus:** Define the project boundaries, identify constraints and assumptions, and map stakeholders.
+
+**Responsibilities:**
+- Define explicit in-scope and out-of-scope items with rationale for each boundary
+- Identify constraints (budget, technology, timeline, regulatory)
+- Document assumptions that underpin the project scope
+- Map all stakeholders with their interests, influence, and engagement needs
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** define scope only by what is included without explicitly stating exclusions
+- The agent **MUST NOT** ignore constraints that will surface during execution
+- The agent **MUST NOT** make assumptions without documenting them for later validation
+- The agent **MUST NOT** map stakeholders superficially without understanding their actual influence

package/studios/project-management/stages/charter/hats/sponsor.md

@@ -0,0 +1,13 @@
+**Focus:** Define the business case, authorize the project, and establish the governance structure.
+
+**Responsibilities:**
+- Articulate the business need and expected outcomes for the project
+- Define success criteria with measurable thresholds
+- Establish governance structure including decision rights and escalation paths
+- Authorize resource commitment and project boundaries
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** charter a project without a clear business case
+- The agent **MUST NOT** define success in terms that cannot be measured or verified
+- The agent **MUST** establish decision rights, leading to unclear authority during execution
+- The agent **MUST NOT** approve scope without confirming resource availability

package/studios/project-management/stages/charter/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the charter stage of project-management. Units here are charter artifact — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Artifact answers its topic
+The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.
+
+### 2. Sources cited
+Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.
+
+### 3. Internal consistency
+Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.
+
+### 4. Decision-register consistency
+The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged `(needs human escalation)`.

package/studios/project-management/stages/charter/outputs/PROJECT-CHARTER.md

@@ -0,0 +1,25 @@
+---
+name: project-charter
+location: .haiku/intents/{intent-slug}/stages/charter/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Project Charter
+
+Scope boundaries, success criteria, stakeholder map, and governance structure.
+
+## Expected Artifacts
+
+- **Scope definition** -- explicit in-scope and out-of-scope items with exclusion rationale
+- **Success criteria** -- quantified with measurement methods, data sources, and target thresholds
+- **Stakeholder map** -- each stakeholder's interest, influence level, and engagement approach
+- **Governance structure** -- decision-making authority and escalation paths
+
+## Quality Signals
+
+- Scope boundaries have explicit inclusion/exclusion rationale
+- Success criteria are quantified with measurement methods
+- Stakeholder map identifies interest, influence, and required engagement
+- Charter reflects the business intent and resource commitment is authorized

package/studios/project-management/stages/charter/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Charter Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Project charter defines scope boundaries with explicit in-scope and out-of-scope items and rationale for each exclusion"
+- "Success criteria are quantified with measurement methods, data sources, and target thresholds"
+- "Stakeholder map identifies each stakeholder's interest, influence level, and required engagement approach"
+
+### Bad criteria — vague (no clear check)
+
+- "Charter is written"
+- "Scope is defined"
+- "Stakeholders are identified"
+

package/studios/project-management/stages/charter/review-agents/feasibility.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify project scope is feasible and success criteria are measurable.
+
+**Check:**
+- The agent **MUST** verify that scope boundaries clearly distinguish in-scope from out-of-scope items
+- The agent **MUST** verify that success criteria have measurable thresholds and defined measurement methods
+- The agent **MUST** verify that resource commitments are validated against actual availability
+- The agent **MUST** verify that assumptions are explicitly documented for later validation

package/studios/project-management/stages/close/STAGE.md

@@ -0,0 +1,19 @@
+---
+name: close
+description: Conduct retrospective, capture lessons learned, and handoff
+hats: [closer, archivist, verifier]
+fix_hats: [closer, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: report
+    output: project-dashboard
+  - stage: track
+    discovery: status-report
+  - stage: charter
+    discovery: project-charter
+---
+
+# Close
+
+Conduct retrospective, capture lessons learned, and handoff.

package/studios/project-management/stages/close/discovery/LESSONS-LEARNED.md

@@ -0,0 +1,30 @@
+---
+name: lessons-learned
+location: .haiku/intents/{intent-slug}/knowledge/LESSONS-LEARNED.md
+scope: intent
+format: text
+required: true
+---
+
+# Lessons Learned
+
+Retrospective findings, categorized learnings, and project closure documentation.
+
+## Content Guide
+
+Structure for future project benefit:
+
+- **What went well** -- top successes with specific examples and contributing factors
+- **What to improve** -- top improvement areas with specific examples and root causes
+- **Process lessons** -- learnings about project management processes
+- **Technical lessons** -- learnings about technical approaches or tools
+- **Organizational lessons** -- learnings about stakeholder management, communication, or governance
+- **Actionable recommendations** -- specific changes recommended for future projects
+- **Closure checklist** -- deliverable acceptance, ownership transfer, and documentation status
+
+## Quality Signals
+
+- Lessons cite specific project experiences, not generic advice
+- Both successes and failures are documented with honesty
+- Recommendations are actionable by future project teams
+- Documentation is organized for easy retrieval by others

package/studios/project-management/stages/close/hats/archivist.md

@@ -0,0 +1,13 @@
+**Focus:** Capture lessons learned and ensure project documentation is complete, organized, and accessible for future reference.
+
+**Responsibilities:**
+- Facilitate retrospective to capture what went well and what to improve
+- Categorize lessons learned as process, technical, or organizational
+- Ensure all project documentation is organized and stored accessibly
+- Create a project summary that future teams can reference
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** captur only positive lessons without documenting what went wrong
+- The agent **MUST NOT** write generic lessons that do not reference specific project experiences
+- The agent **MUST NOT** archiv documentation without organizing it for retrievability
+- The agent **MUST NOT** skip the retrospective because the team has moved on to other work

package/studios/project-management/stages/close/hats/closer.md

@@ -0,0 +1,13 @@
+**Focus:** Confirm all deliverables are accepted, transfer ownership, and close out open items.
+
+**Responsibilities:**
+- Verify all deliverables against the charter's scope and success criteria
+- Obtain formal acceptance from the sponsor and key stakeholders
+- Transfer ongoing ownership with documented support contacts
+- Close out open items with owners and target dates or documented deferral
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** declare the project complete without formal deliverable acceptance
+- The agent **MUST NOT** leave open items without assigned owners or resolution plans
+- The agent **MUST** transfer knowledge to the team that will own the deliverables going forward
+- The agent **MUST NOT** close the project before all contractual or compliance obligations are fulfilled

package/studios/project-management/stages/close/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against