@manhd_d/ai-harness 0.6.2 → 0.8.0

package/capabilities/delivery/skills/harness-delivery-risk-management/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: harness-delivery-risk-management
+description: Maintain owned delivery risks, assumptions, blockers and dependencies with response triggers.
+---
+
+# harness-delivery-risk-management
+
+## Input
+Plan, stakeholder/source constraints, technical/operational findings and actual progress evidence.
+
+## Procedure
+1. Identify risks versus current issues, assumptions and dependencies; link each to source and affected outcome.
+2. Assess impact and likelihood qualitatively or with actual evidence; do not invent numerical risk scores.
+3. Assign proposed/confirmed owner, mitigation, trigger, contingency and decision needed; clarify critical gaps.
+4. Track unresolved external dependencies and review cadence; no autonomous stakeholder messages or calendar writes.
+5. Update risk state only with evidence; carry accepted residual risks to release/PO decision and architecture review.
+
+## Output
+docs/delivery/risk-register.md and evidence-based status draft.
+
+## Template
+Read `.harness/capabilities/delivery/templates/risk-register.md` from the installed snapshot.
+Use `aih new-doc risk-register --capability delivery` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Internal provider sandbox is unreachable: current blocker, not a completed test. Owner confirms access plan; integration milestone remains at risk until an observed connectivity check succeeds.
+
+## Quality checklist
+- Risk and observed issue are distinguished
+- Owner, trigger, response and source are present
+- Status does not fabricate progress or communicate externally
+
+## Handoff
+State source revisions, requirement/decision IDs, approval status, unresolved questions, output paths,
+actual checks and next role. Use the module workflow; role names are not human authorization.
+
+## Constraints
+Follow Core permissions, clarification and project-conventions. Ask only consequential unknowns with
+2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
+No invented source, measured result, target, estimate or approval. No external messaging/publishing,
+paid tool use or production changes beyond the user's explicit authorization.

package/capabilities/delivery/skills/harness-delivery-scope-change/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-delivery-scope-change
+description: Evaluate scope changes across product value, architecture, dependencies and delivery before re-planning.
+---
+
+# harness-delivery-scope-change
+
+## Input
+Change request, reviewed baseline scope/MVP, affected requirements/ADRs, plan and available estimates.
+
+## Procedure
+1. Preserve the baseline and describe the proposed delta and motivation; identify decision owner.
+2. Ask BA/PO for requirement/value/AC impact, SA for contract/NFR/data impact and DevOps for release impact as applicable.
+3. Compare defer, replace and expand options with explicit trade-offs; avoid invented cost/dates.
+4. Resolve consequential owner decisions before implementing affected behavior; continue independent authorized work.
+5. Update only affected scope/traceability/ADR/plan records and OpenSpec tasks after the real decision.
+6. Report revised dependencies, acceptance, risks and rollback considerations; preserve history.
+
+## Output
+docs/delivery/change-assessment.md and reviewed updates to existing plan/requirements/design.
+
+## Template
+Read `.harness/capabilities/delivery/templates/change-assessment.md` from the installed snapshot.
+Use `aih new-doc change-assessment --capability delivery` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Adding bulk import to the search MVP requires async jobs, limits and duplicate policy. Present defer or replace a lower-value feature; do not quietly promise the same release date.
+
+## Quality checklist
+- Baseline and delta are explicit and source-linked
+- Cross-role impacts and options are assessed
+- Scope/date approval is from the actual owner
+
+## Handoff
+State source revisions, requirement/decision IDs, approval status, unresolved questions, output paths,
+actual checks and next role. Use the module workflow; role names are not human authorization.
+
+## Constraints
+Follow Core permissions, clarification and project-conventions. Ask only consequential unknowns with
+2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
+No invented source, measured result, target, estimate or approval. No external messaging/publishing,
+paid tool use or production changes beyond the user's explicit authorization.

package/capabilities/delivery/templates/change-assessment.md

@@ -0,0 +1,23 @@
+# Scope change assessment
+
+Status: draft / pending review
+Owner: TODO
+Sources and revisions: TODO
+Scope / related requirement and decision IDs: TODO
+Last verified against code: TODO (or not applicable with reason)
+
+## Baseline and requested delta
+Approved scope/version, request/source, motivation and actual decision owner.
+## Cross-role impact
+BA requirements/AC, PO value/MVP, SA NFR/module/data/contracts, PM dependency/estimate and DevOps release.
+## Options
+Defer, replace or expand where viable; value, risk, estimate confidence and rollback trade-offs.
+## Resolution and updates
+Actual owner answer/source; impacted docs, traceability, ADRs, tasks and plan updates after agreement.
+## Remaining uncertainty
+Unknown estimates/targets, external dependencies, blockers and independent work that can proceed.
+
+
+## Review and handoff
+Record actual owner decisions, unresolved consequential questions, verification performed/skipped,
+next role, source/output paths and affected OpenSpec change. Draft text is not an accepted decision.

package/capabilities/delivery/templates/delivery-plan.md

@@ -0,0 +1,25 @@
+# Delivery plan
+
+Status: draft / pending review
+Owner: TODO
+Sources and revisions: TODO
+Scope / related requirement and decision IDs: TODO
+Last verified against code: TODO (or not applicable with reason)
+
+## Baseline and authority
+Reviewed MVP/AC, architecture/source revisions, confirmed estimates/capacity or explicitly unknown.
+## Value slices and dependencies
+| Slice / user outcome | AC / OpenSpec tasks | Prerequisites / owner | Estimate source / range | Completion evidence |
+| --- | --- | --- | --- | --- |
+| TODO | TODO | TODO | unknown | pending |
+## Milestones
+Order and integration/repository merge sequence; dates are proposals with sources, not invented commitments.
+## Verification and release
+Quality gates, migration, deployment/rollback owners and feedback checkpoints; link DevOps plan.
+## Status and risks
+Actual completed evidence, blocked/pending work, risk-register links and next owner.
+
+
+## Review and handoff
+Record actual owner decisions, unresolved consequential questions, verification performed/skipped,
+next role, source/output paths and affected OpenSpec change. Draft text is not an accepted decision.

package/capabilities/delivery/templates/risk-register.md

@@ -0,0 +1,19 @@
+# Delivery risks and blockers
+
+Status: draft / pending review
+Owner: TODO
+Sources and revisions: TODO
+Scope / related requirement and decision IDs: TODO
+Last verified against code: TODO (or not applicable with reason)
+
+## Risk / issue / assumption / dependency register
+| ID / kind | Source / affected outcome | Impact / likelihood evidence | Owner status | Response / trigger / contingency | State / evidence |
+| --- | --- | --- | --- | --- | --- |
+| RISK-001 / TODO | TODO | unknown | proposed | TODO | pending |
+## Review cadence and decisions
+Actual confirmations, residual risk acceptances and decisions needed; no automatic stakeholder communication.
+
+
+## Review and handoff
+Record actual owner decisions, unresolved consequential questions, verification performed/skipped,
+next role, source/output paths and affected OpenSpec change. Draft text is not an accepted decision.

package/capabilities/delivery/workflows/execution-change.md

@@ -0,0 +1,9 @@
+# Progress, feedback and scope changes
+
+1. Read actual completed check/PR evidence against the current plan; do not infer completion from tasks alone.
+2. Maintain risk-register with source, confirmed/proposed owners, triggers and unresolved external dependencies.
+3. For changed scope load scope-change: preserve baseline, consult BA/PO/SA/DevOps as relevant, compare
+   defer/replace/expand and resolve material choices. Continue independent already-authorized work.
+4. Update affected plan, requirements, ADRs and OpenSpec only after the actual decision; keep history.
+5. Produce a status draft with completed/pending/blocked work and evidence. Release ownership/gates
+   remain in DevOps; PM proposals do not approve delivery or production changes.

package/capabilities/delivery/workflows/planning.md

@@ -0,0 +1,12 @@
+# Reviewed outcome → delivery plan
+
+Input: agreed scope/MVP, acceptance, solution boundaries and known team constraints.
+1. Read Core solution-framing and existing approved plan; choose compact or full depth.
+2. Load harness-delivery-planning for usable vertical slices, dependencies, repository order and gates.
+3. Use actual team estimates/capacity; without them document sequencing and missing estimate owners,
+   not fabricated milestones. Compare scope trade-offs with PO and technical dependencies with SA.
+4. Load risk-management for owned risks/blockers/assumptions/dependencies and response triggers.
+5. Link plan to requirements/ADRs/OpenSpec tasks and DevOps rollout/rollback. Actual owner reviews
+   consequential commitments; explicit authorization already covering routine tasks remains valid.
+6. Handoff approved slice, acceptance, prerequisites, verification, risks and next owner to Core/adapter.
+No automatic issue assignment, messaging, calendar entries, merge or deployment.

package/capabilities/product/README.md

@@ -76,3 +76,10 @@ After documented approval, UI/UX reads approved PRD, flows, stories and AC rathe
 ## Cross-capability walkthrough
 
 The complete path from source/idea to production is documented in [Full SDLC](../../docs/end-to-end-workflow.md). The [Skill matrix](../../docs/skill-matrix.md) maps all Product skills and outputs, and [Agent handoffs](../../docs/agent-handoffs.md) shows how approved requirements pass to UI/UX and OpenSpec. For an example, see [Full-stack web](../../docs/examples/fullstack-web.md).
+
+## MVP and solution handoff
+
+Use product-to-solution workflow, MVP/outcomes skills and their templates; load only relevant skills.
+Optional Architecture/Delivery provides SA/PM depth. Existing Product project-manager and delivery-plan
+remain compatibility entries; no automatic migration or stakeholder approval. All Product skills now
+include template/example/quality/handoff sections.

package/capabilities/product/agents/business-analyst.md

@@ -13,3 +13,6 @@ Read approved business sources only. Cannot invent stakeholder decisions or mark
 
 ## Handoff
 Hand reviewed requirements and source references to Product Manager and Product Owner; unresolved contradictions to decision owner.
+
+Pass source revisions, business rules, FR/US/AC/NFR IDs, contradictions and approval status to PO;
+use product-to-solution for accepted scope and return technical assumptions to Architecture.

package/capabilities/product/agents/product-owner.md

@@ -6,10 +6,14 @@ Owns proposed backlog structure, story readiness, acceptance coverage and priori
 Reviewed PRD, business rules, personas, constraints and team capacity signals.
 
 ## Outputs
-Epics, user stories, Gherkin acceptance criteria, backlog priority recommendations and release dependencies.
+Reviewed-scope proposals for complete MVP journeys, in/out scope, minimum quality, product outcome
+measures, epics/stories, Gherkin AC, priorities and release dependencies.
 
 ## Permissions and limits
 Do not self-approve or silently change stakeholder priorities; no invented sprint velocity or technical guarantees.
 
 ## Handoff
 Hand approved stories and traceable AC to UI/UX and OpenSpec; return gaps to BA/PM.
+
+Use product-to-solution workflow and MVP/outcomes skills; actual stakeholder decisions remain required
+for consequential scope choices. Send requirement/AC/NFR IDs and decision evidence to Architecture/Delivery.

package/capabilities/product/agents/project-manager.md

@@ -13,3 +13,8 @@ Schedules are proposals without team estimates and confirmations. No calendar/ev
 
 ## Handoff
 Send dependencies and risks to responsible owners, and scope-change impacts to Product Owner.
+
+Compatibility entry point: retain this role and the existing Product delivery-plan template for older
+consumers. For richer delivery planning, use the installed Delivery project-manager role/workflows
+when selected; otherwise keep sequencing/risks in existing project-owned docs. Do not auto-install it
+or migrate/overwrite the old plan. Project Manager manages delivery; Product Manager owns product value.

package/capabilities/product/capability.json

@@ -15,14 +15,17 @@
     "harness-product-idea-discovery",
     "harness-product-product-research",
     "harness-product-srs-generation",
-    "harness-product-use-case-generation"
+    "harness-product-use-case-generation",
+    "harness-product-mvp-definition",
+    "harness-product-product-outcomes"
   ],
   "workflows": [
     "workflows/idea-to-prd.md",
     "workflows/confluence-to-spec.md",
     "workflows/change-impact-analysis.md",
     "workflows/idea-driven.md",
-    "workflows/document-driven.md"
+    "workflows/document-driven.md",
+    "workflows/product-to-solution.md"
   ],
   "agents": [
     "agents/business-analyst.md",
@@ -47,9 +50,11 @@
     "templates/research.md",
     "templates/prd-lite.md",
     "templates/srs.md",
-    "templates/use-cases.md"
+    "templates/use-cases.md",
+    "templates/mvp.md",
+    "templates/outcomes.md"
   ],
-  "module_version": "1.1.0",
+  "module_version": "1.2.0",
   "verification": "checks/verification.json",
   "evaluation": "evals/cases.json"
 }

package/capabilities/product/checks/verification.json

@@ -36,6 +36,18 @@
         "OpenSpec handoff references approved scope only"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "mvp-outcome",
+      "title": "MVP completeness and product outcome authority",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Usable end-to-end journey, explicit in/out scope and requirement/AC links",
+        "Minimum security/data integrity included",
+        "Metrics/targets and scope approval source or unresolved owner"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/capabilities/product/evals/cases.json

@@ -30,6 +30,16 @@
         "Hands off only approved FR/NFR/US/AC and explicit source versions to OpenSpec"
       ],
       "critical": true
+    },
+    {
+      "id": "mvp-not-feature-count",
+      "prompt": "A user wants a customer search MVP, suggests skipping authorization and duplicate handling until later, and provides no approved success target.",
+      "criteria": [
+        "Defines a usable journey and explicit in/out scope with acceptance",
+        "Keeps minimum access control/data integrity and clarifies duplicate policy",
+        "Does not invent success metrics or approve the MVP on behalf of the owner"
+      ],
+      "critical": true
     }
   ]
 }

package/capabilities/product/skills/harness-product-acceptance-criteria/SKILL.md

@@ -23,3 +23,20 @@ description: Write verifiable acceptance criteria in Given/When/Then for each st
 ## Constraints
 - Never claim that acceptance tests have run; these are specifications, not execution evidence.
 - Avoid arbitrary time, availability and performance thresholds.
+
+## Template
+Read `.harness/capabilities/product/templates/acceptance-criteria.md`; `aih new-doc acceptance-criteria` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: Given an employee outside the organization, when searching its customer, then access is denied without leaking existence.
+
+## Quality checklist
+- Happy, negative and boundary cases are observable.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-backlog-prioritization/SKILL.md

@@ -23,3 +23,20 @@ description: Rank proposed requirements transparently using explicit scoring ass
 ## Constraints
 - AI ranking is advisory; only the authorized PO/PM sets accepted priorities.
 - Do not equate an estimate with a delivery commitment.
+
+## Template
+Read `.harness/capabilities/product/templates/backlog.md`; `aih new-doc backlog` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: Rank secure create/search before optional import using agreed value/dependencies; effort stays unknown without team input.
+
+## Quality checklist
+- Priority rationale uses evidence instead of fabricated effort scores.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-brd-generation/SKILL.md

@@ -23,3 +23,20 @@ description: Produce a Business Requirements Document with actors, business rule
 ## Constraints
 - Never self-approve a BRD or invent evidence.
 - Avoid treating template placeholders as finished decisions.
+
+## Template
+Read `.harness/capabilities/product/templates/brd.md`; `aih new-doc brd` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: BRD links the customer-search goal to BR-001; cost/benefit values remain unknown without financial evidence.
+
+## Quality checklist
+- Business outcomes and stakeholder decisions are traceable.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-business-analysis/SKILL.md

@@ -24,3 +24,20 @@ description: Elicit actors, existing versus future processes, business rules, re
 ## Constraints
 - No unapproved product scope expansion; no fabricated regulation or SLA.
 - Do not reveal internal source material or imply stakeholder acceptance without a decision record.
+
+## Template
+Read `.harness/capabilities/product/templates/business-rules.md`; `aih new-doc business-rules` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: BR-001 requires organization-scoped search; AS-IS behavior and proposed TO-BE duplicate handling remain distinct.
+
+## Quality checklist
+- Business rules and AS-IS/TO-BE preserve source authority.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-document-review/SKILL.md

@@ -24,3 +24,20 @@ description: Review generated BRD/PRD/stories for traceability, completeness, co
 ## Constraints
 - Do not invent reviewer signatures, user research, tests or approvals.
 - Do not treat missing information as implicit consent.
+
+## Template
+Read `.harness/capabilities/product/templates/review-report.md`; `aih new-doc review-report` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: Flag conflicting duplicate policies with exact source references; do not turn the reviewed draft into owner approval.
+
+## Quality checklist
+- Findings include source, impact and decision owner.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-idea-discovery/SKILL.md

@@ -25,3 +25,20 @@ description: Collaboratively refine a developer's rough software idea into an ev
 - A solo developer may be the approval owner; never invent other stakeholders.
 - No fabricated user interviews, market sizes, competitor prices, dates, sources, or approvals.
 - An idea can remain a draft indefinitely; do not force implementation.
+
+## Template
+Read `.harness/capabilities/product/templates/idea.md`; `aih new-doc idea` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: Original idea is preserved; clarify prototype versus usable MVP and choose the smallest end-to-end journey with the user.
+
+## Quality checklist
+- Original words, assumptions, actual answers and non-goals stay visible.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-knowledge-analysis/SKILL.md

@@ -26,3 +26,20 @@ description: Catalog product ideas and authorized Confluence, PDF, meeting-note
 - Do not pretend to have opened a link if no connected connector or file access exists.
 - Do not store access tokens, private customer records or restricted source contents in a public repository.
 - Record missing or inaccessible sources explicitly; never invent citations.
+
+## Template
+Read `.harness/capabilities/product/templates/source-register.md`; `aih new-doc source-register` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: SRC-001 points to the approved SRS revision; a contradictory unapproved page is recorded as a gap, not merged as fact.
+
+## Quality checklist
+- Source authority/version and missing access are explicit.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-mvp-definition/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-product-mvp-definition
+description: Define a usable MVP with in/out scope, acceptance, minimum safeguards and explicit owner decisions.
+---
+
+# harness-product-mvp-definition
+
+## Input
+Original idea or approved requirements, users, constraints, business rules, known alternatives and decision sources.
+
+## Procedure
+1. Identify one target actor, problem and observable user outcome; distinguish prototype, MVP and later release goals.
+2. Map the end-to-end journey, including required authorization, data integrity and recoverable failure behavior.
+3. Compare a few viable scope cuts by value, feasibility, dependency and evidence. Resolve material scope choices with the actual owner; do not accept your own recommendation.
+4. List in/out scope, AC IDs, required NFRs, validation method, success signals and unknown baselines/targets.
+5. Trace each included capability to the journey; defer optional analytics or bulk tools without deferring necessary security.
+6. Check against existing PRD/BA sources, record the agreed version and pass gaps to BA or Architecture.
+
+## Output
+Project-owned docs/product/mvp.md or an MVP section linked from PRD, with scope owner and review status.
+
+## Template
+Read `.harness/capabilities/product/templates/mvp.md` from the installed snapshot.
+Use `aih new-doc mvp` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Customer-search MVP: an authorized employee creates and finds customers within permitted organization scope. Bulk import is deferred; tenant access checks and duplicate policy are required. Usage target stays unknown until owner confirmation.
+
+## Quality checklist
+- A complete user outcome, not an arbitrary count of features
+- Each scope item links AC and minimum quality constraints
+- Explicit exclusions, decision source and unresolved owner questions
+
+## Handoff
+State source revisions, requirement/decision IDs, approval status, unresolved questions, output paths,
+actual checks and next role. Use the module workflow; role names are not human authorization.
+
+## Constraints
+Follow Core permissions, clarification and project-conventions. Ask only consequential unknowns with
+2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
+No invented source, measured result, target, estimate or approval. No external messaging/publishing,
+paid tool use or production changes beyond the user's explicit authorization.

package/capabilities/product/skills/harness-product-prd-generation/SKILL.md

@@ -24,3 +24,20 @@ description: Produce a Product Requirements Document with user value, measurable
 ## Constraints
 - Estimates, success targets and roadmap dates are proposals until stakeholders approve them.
 - Do not silently change BRD scope or promise unverified capabilities.
+
+## Template
+Read `.harness/capabilities/product/templates/prd.md`; `aih new-doc prd` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: PRD includes authorized create/search and defers import; it links MVP/AC and leaves numeric adoption targets pending.
+
+## Quality checklist
+- MVP journey, exclusions and minimum quality are explicit.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-product-outcomes/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: harness-product-product-outcomes
+description: Define product success measures and experiments without inventing baselines or analytics evidence.
+---
+
+# harness-product-product-outcomes
+
+## Input
+Reviewed problem/MVP, personas, source evidence, available instrumentation and authorized research.
+
+## Procedure
+1. Identify user value and one primary outcome; keep activity/output measures separate from actual success.
+2. List assumptions, known baselines, evidence strength and measurement access; unknown values stay unknown.
+3. Propose metrics, definitions, event/source, owner and evaluation period; numeric targets need stakeholder evidence or approval.
+4. Choose a bounded experiment or feedback loop; account for privacy, cost and negative outcomes.
+5. Connect results to continue/pivot/stop proposals and backlog updates; only the owner decides scope changes.
+
+## Output
+Project-owned docs/product/outcomes.md linked to MVP and PRD.
+
+## Template
+Read `.harness/capabilities/product/templates/outcomes.md` from the installed snapshot.
+Use `aih new-doc outcomes` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+For customer lookup, propose task completion and observed latency as measures. Without real telemetry, label both baseline and target pending instead of claiming a 30% improvement.
+
+## Quality checklist
+- Metric has definition/source/owner and review period
+- Hypothesis and actual measurement are distinct
+- Experiment does not silently expand collection or release scope
+
+## Handoff
+State source revisions, requirement/decision IDs, approval status, unresolved questions, output paths,
+actual checks and next role. Use the module workflow; role names are not human authorization.
+
+## Constraints
+Follow Core permissions, clarification and project-conventions. Ask only consequential unknowns with
+2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
+No invented source, measured result, target, estimate or approval. No external messaging/publishing,
+paid tool use or production changes beyond the user's explicit authorization.

package/capabilities/product/skills/harness-product-product-research/SKILL.md

@@ -25,3 +25,20 @@ description: Research comparable products, user needs and implementation feasibi
 - Do not scrape inaccessible services, bypass document permissions or claim browsing occurred when it did not.
 - No fabricated references, metrics, reviews or user interviews.
 - Research is advisory, not an approval or an instruction to change the codebase.
+
+## Template
+Read `.harness/capabilities/product/templates/research.md`; `aih new-doc research` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: With no browsing access, competitor claims are UNKNOWN and research questions are proposed rather than citations invented.
+
+## Quality checklist
+- Retrieved facts, inferences and forecasts have provenance.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-srs-generation/SKILL.md

@@ -26,3 +26,20 @@ description: Produce a testable Software Requirements Specification linked to ap
 - Do not invent protocol guarantees, SLAs, security requirements or existing integrations.
 - Keep product intent separate from chosen technical implementation.
 - Never change code or claim stakeholder approval solely because a document was generated.
+
+## Template
+Read `.harness/capabilities/product/templates/srs.md`; `aih new-doc srs` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: FR-001 defines search behavior; NFR-001 target is pending until agreed and is passed to Architecture for a scenario/test plan.
+
+## Quality checklist
+- FR/NFR contracts, exception paths and trace IDs remain consistent.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.

package/capabilities/product/skills/harness-product-traceability/SKILL.md

@@ -22,3 +22,20 @@ description: Maintain bidirectional links from document sources through BRD/PRD/
 ## Constraints
 - Links are evidence pointers, not authorization to modify external systems.
 - Never rewrite approved artifacts automatically based on Confluence updates.
+
+## Template
+Read `.harness/capabilities/product/templates/traceability.md`; `aih new-doc traceability` creates only a missing
+draft. Reuse canonical existing documents and source pointers; never regenerate approved content by default.
+
+## Example
+Synthetic illustration: SRC-001 → FR-001 → US-001 → AC-US-001-01 → ADR-001/OpenSpec task/test links form a checkable chain.
+
+## Quality checklist
+- Stable IDs, source versions and downstream gaps are maintained.
+- Actual decisions/status and source revisions distinguish approved facts from proposals.
+- Scope, relevant IDs, unresolved questions and verification limits are recorded.
+
+## Handoff
+Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
+IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
+to their owner; a single host may perform roles sequentially without claiming independent approval.