@manhd_d/ai-harness 0.6.2 → 0.8.0

package/capabilities/architecture/skills/harness-architecture-change-impact/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-change-impact
+description: Assess change impact and architecture drift using a source-linked living project map.
+---
+
+# harness-architecture-change-impact
+
+## Input
+Requested change, current project-map/ADRs, affected source revisions, API/event/schema consumers and existing tests.
+
+## Procedure
+1. Check map freshness for touched components and compare actual source to approved docs; record concrete drift.
+2. Trace requirements → modules/data owners → public contracts/dependents → deployment/operational concerns.
+3. Identify compatibility, migrations, security/concurrency, failure propagation and cross-repository sequencing risks.
+4. Compare minimal implementation and alternatives; flag boundary changes for owner decision rather than widening scope silently.
+5. Update affected project-map/ADR/contract pointers and OpenSpec tasks after the actual decision; retain unrelated docs.
+6. Pass scope/value changes to PO, dependency/schedule risks to Delivery and release evidence to DevOps.
+
+## Output
+Updated docs/architecture/project-map.md and change-specific impact notes linked to affected IDs/paths.
+
+## Template
+Read `.harness/capabilities/architecture/templates/project-map.md` from the installed snapshot.
+Use `aih new-doc project-map --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+A phone-normalization change affects the unique index, API duplicate policy and imports. Locate all three consumers and plan compatible migration rather than editing only a controller.
+
+## Quality checklist
+- Dependent public contracts and data ownership were considered
+- Drift has concrete paths/revisions and a reviewed resolution
+- No speculative impact or unrelated broad refactor
+
+## 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/architecture/skills/harness-architecture-decision-records/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-decision-records
+description: Record traceable architecture decisions with alternatives, consequences and reconsideration triggers.
+---
+
+# harness-architecture-decision-records
+
+## Input
+Decision question, actual drivers/evidence, options, current ADRs and stakeholder answers.
+
+## Procedure
+1. Locate related accepted/superseded ADRs; avoid a second conflicting decision on the same scope.
+2. Record a stable ID, status, scope, source revision, owner and date; proposed is not accepted.
+3. Explain the problem, viable options and evaluation against drivers; document selected option only after an actual decision.
+4. Capture positive/negative consequences, verification, migration/rollback and measurable triggers for reconsideration.
+5. Link requirement/NFR IDs, module/contracts and OpenSpec change. Preserve superseded history and update the project map.
+6. For a trivial reversible choice, a task note is enough; do not manufacture an ADR for every edit.
+
+## Output
+A project-owned ADR, e.g. docs/architecture/decisions/adr-001.md, linked from project-map and active OpenSpec design.
+
+## Template
+Read `.harness/capabilities/architecture/templates/adr.md` from the installed snapshot.
+Use `aih new-doc adr --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+ADR-001 proposes synchronous provider calls for the first release. Owner confirms the latency trade-off; status becomes accepted. Reconsider when measured timeouts exceed the agreed threshold; that threshold stays pending until agreed.
+
+## Quality checklist
+- Accepted status has actual owner decision evidence
+- Alternatives and negative consequences are explicit
+- Superseded records and implementation links stay traceable
+
+## 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/architecture/skills/harness-architecture-project-context/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-project-context
+description: Map verified system context, module ownership and source-linked architecture for new or existing projects.
+---
+
+# harness-architecture-project-context
+
+## Input
+Idea/approved BA sources, repository revision, scope/mode, deployments, existing ADRs, integrations and access constraints.
+
+## Procedure
+1. Read local facts, authoritative requirements and touched source; select small/new/maintain depth and preserve approved existing architecture.
+2. Map actors, system boundary, external systems, deployment units and trust boundaries; mark inaccessible parts explicitly.
+3. Inventory modules, public APIs, data owners, reusable common components and allowed dependency direction using actual paths.
+4. Record revision/date and canonical doc/code links in a living project map; verify touched entries rather than scanning every file.
+5. List gaps, assumptions, constraints and technical debt with owner; route value/scope to PO, quality gaps to NFR and release gaps to DevOps.
+6. When source differs from docs, show the specific mismatch and refresh only the affected reviewed context.
+
+## Output
+docs/architecture/overview.md and linked project-map.md; compact notes suffice for a small fix.
+
+## Template
+Read `.harness/capabilities/architecture/templates/overview.md` from the installed snapshot.
+Use `aih new-doc overview --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Maintain customer service: controller → customer use case → repository; organization authorization comes from a supported shared API. An unreachable billing integration is recorded as unknown, not inferred from its name.
+
+## Quality checklist
+- Each component/ownership assertion has a source path or explicitly marked hypothesis
+- Actual public boundaries and source revision recorded
+- No automatic migration or full-document regeneration
+
+## 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/architecture/skills/harness-architecture-quality-attributes/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-quality-attributes
+description: Translate NFRs into measurable quality scenarios and verification plans with evidence-backed targets.
+---
+
+# harness-architecture-quality-attributes
+
+## Input
+MVP journeys, data classification, expected load evidence, business constraints, operational environment and known limits.
+
+## Procedure
+1. Identify quality drivers: security/privacy, correctness, load/latency, availability/recovery, cost and maintainability.
+2. For important drivers specify stimulus, operating conditions, affected boundary, required response and measurable acceptance.
+3. Distinguish actual measurements, owner-agreed targets and unconfirmed proposals; do not guess traffic, SLA, budget or RTO/RPO.
+4. Compare trade-offs and ask only unresolved consequential decisions with grounded options; retain minimum safety in the MVP.
+5. Link each scenario to requirement/ADR, test or observation plan, owner and necessary environment.
+6. Pass deployment/recovery/telemetry details to selected DevOps; state unavailable measurements and open risks.
+
+## Output
+docs/architecture/nfr.md with NFR IDs, quality scenarios, evidence and verification ownership.
+
+## Template
+Read `.harness/capabilities/architecture/templates/nfr.md` from the installed snapshot.
+Use `aih new-doc nfr --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+A cache miss burst could overload the DB. Document admission/degradation alternatives and a load-test plan. Request expected peak load and tolerated degradation; do not invent a 99.99% SLA.
+
+## Quality checklist
+- Scenario is testable in stated conditions
+- Targets have approval/source or stay pending
+- Failure/recovery and privacy/cost consequences are assessed
+
+## 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/architecture/skills/harness-architecture-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-review
+description: Review solution and implemented boundaries against MVP, NFRs, ADRs and actual verification evidence.
+---
+
+# harness-architecture-review
+
+## Input
+Design/diff, approved requirements, ADRs, project map, tests, build results and deployment constraints.
+
+## Procedure
+1. Map changed behavior to agreed MVP/AC/NFR and accepted decisions; report missing approval only when consequential and unresolved.
+2. Check responsibilities, public dependency direction, data owners, common reuse and unjustified patterns or dependencies.
+3. Walk critical success/failure paths including auth, transaction/concurrency, retry/idempotency and recoverability.
+4. Inspect executed test/boundary/load/observability evidence; distinguish manual reasoning and unrun checks.
+5. Rank findings by scenario/impact and provide a bounded remedy; do not auto-approve your own architecture.
+6. Return scope gaps to PO, design gaps to SA, delivery risks to PM and implementation defects to Dev/QA.
+
+## Output
+docs/architecture/review.md or PR findings linked to requirements/decisions, with evidence and residual risks.
+
+## Template
+Read `.harness/capabilities/architecture/templates/review.md` from the installed snapshot.
+Use `aih new-doc review --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Client UI hides cross-tenant records but the server query lacks tenant filtering. Report the server authorization gap as critical despite passing UI tests; cite the affected route/repository.
+
+## Quality checklist
+- Findings include location, scenario, impact and remedy
+- Review evidence distinguishes tests, manual checks and unknowns
+- Checks do not claim model compliance or production readiness without evidence
+
+## 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/architecture/skills/harness-architecture-solution-design/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: harness-architecture-solution-design
+description: Compare architectures and local design patterns against MVP, NFRs and existing project boundaries.
+---
+
+# harness-architecture-solution-design
+
+## Input
+Reviewed scope, NFR scenarios, context/module map, approved ADRs, team/toolchain constraints and comparable code.
+
+## Procedure
+1. Identify the decision level: deployment/application style, module boundary or local algorithm/object creation; Factory is not an alternative to Ports and Adapters.
+2. For genuinely open architecture decisions compare 2–3 viable options by complexity, testability, integration, operations, cost and reversibility.
+3. Recommend the smallest fit and cite drivers. Layered feature modules, modular monolith and selective Ports and Adapters can combine; do not default to microservices.
+4. For a feature, identify actual variation/coupling. Consider Strategy for interchangeable behavior, Factory for complex construction, Adapter for interface translation, State for meaningful state transitions; a direct function/class remains valid.
+5. Record module responsibilities, public dependencies, data ownership, API/event boundaries and important success/failure sequences.
+6. Define retries/timeouts/idempotency, transaction/consistency policy and observability where needed; record consequential choices in ADRs and agree them before affected code.
+7. Hand vertical implementation slices and verification boundaries to Delivery/Core and stack-specific adapters.
+
+## Output
+docs/architecture/solution-design.md, linked ADRs and OpenSpec design/tasks, with explicit alternatives and accepted scope.
+
+## Template
+Read `.harness/capabilities/architecture/templates/solution-design.md` from the installed snapshot.
+Use `aih new-doc solution-design --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+A CRUD MVP may use feature packages and direct services. If two payment providers differ, introduce a small provider port/adapter only there. Strategy is justified for distinct pricing algorithms, not for a single unchanged calculation.
+
+## Quality checklist
+- Each pattern solves a concrete requirement and its extra complexity is justified
+- MVP, NFRs, contracts and public dependency direction align
+- Failure scenarios and rollout constraints included where relevant
+
+## 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/architecture/templates/adr.md

@@ -0,0 +1,29 @@
+# Architecture decision record
+
+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)
+
+## Record identity
+Stable ADR ID: TODO
+Decision status: proposed / accepted / superseded
+Decision owner / date / evidence: TODO
+Supersedes / superseded by: TODO or none
+## Decision question and drivers
+Problem, affected scope, requirement/NFR/source links and constraints.
+## Options and assessment
+At least the viable alternatives; strengths, costs and failure consequences against actual drivers.
+## Resolution
+Chosen option and actual owner decision source. Keep proposed until the consequential choice is settled.
+## Consequences and follow-through
+Positive/negative implications, implementation/contract paths, verification, migration and rollback.
+## Reconsideration
+Evidence or agreed thresholds that would reopen the decision; preserve superseded history.
+After scaffolding, move this draft to a stable project-owned decisions/adr-NNN.md path before the next ADR.
+
+
+## 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/architecture/templates/nfr.md

@@ -0,0 +1,22 @@
+# Quality scenarios
+
+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)
+
+## Drivers and evidence
+MVP journey, users/data sensitivity, measured/expected load and financial/operational constraints.
+## Scenarios
+| ID | Stimulus / conditions | Boundary / response | Measure / agreed target | Evidence / owner | Verification |
+| --- | --- | --- | --- | --- | --- |
+| NFR-001 | TODO | TODO | unknown / pending | TODO | TODO |
+## Trade-offs and failure policy
+Security/correctness, availability/latency, recovery/RTO/RPO, cost and maintainability conflicts.
+No assumed traffic, SLA or numerical target without authority.
+
+
+## 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/architecture/templates/overview.md

@@ -0,0 +1,24 @@
+# Solution overview
+
+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)
+
+## Purpose and limits
+User outcomes/MVP, existing/new scope and explicit constraints; link BA/PRD/AC.
+## System context
+Actors, systems, trust boundaries and deployment units. Use a compact C4-style context or Mermaid
+only where relationships help. Every named system has a source or is marked hypothetical.
+## Responsibilities
+Modules, data owners and public integration points; link the living project-map and accepted ADRs.
+## Quality drivers and options
+NFR scenario links, top trade-offs, unknowns and owner decisions; minimal viable solution first.
+## Operating reality
+Toolchain, deployment/observability/recovery constraints and authorized environments, linked to DevOps.
+
+
+## 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/architecture/templates/project-map.md

@@ -0,0 +1,26 @@
+# Living project map
+
+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)
+
+## Freshness and scope
+Verified source revision/date, inspected modules and inaccessible/unverified areas.
+## Ownership and dependencies
+| Module / deployable | Responsibility / data owner | Public APIs / allowed dependencies | Code / tests / contract paths | ADR / NFR |
+| --- | --- | --- | --- | --- |
+| TODO | TODO | TODO | TODO | TODO |
+## Reusable common components
+Public symbols, ownership, suitability constraints and actual paths; domain-private code is not common.
+## Decisions, risks and debt
+Accepted/superseded ADRs, constraints and consciously accepted debt with owner/revisit condition.
+## Drift and refresh
+Observed doc/code mismatch, affected source paths, proposed resolution and actual decision evidence.
+Refresh the touched entries; do not regenerate the entire project for every task.
+
+
+## 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/architecture/templates/review.md

@@ -0,0 +1,23 @@
+# Architecture review
+
+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)
+
+## Reviewed baseline
+Source/diff revisions, accepted MVP/requirements/ADRs and declared scope of review.
+## Findings
+| Severity | Location / scenario | Requirement / decision | Impact | Bounded remedy / owner |
+| --- | --- | --- | --- | --- |
+| TODO | TODO | TODO | TODO | TODO |
+## Evidence
+Configured checks actually executed, logs/source pointers, manual boundary/failure review and skipped checks.
+## Disposition
+Recommendation and remaining risk; author review is not independent approval, structure is not compliance.
+
+
+## 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/architecture/templates/solution-design.md

@@ -0,0 +1,29 @@
+# Solution design
+
+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)
+
+## Decision scope
+Existing boundaries and required changes; distinguish deployment style, module design and local patterns.
+## Alternatives
+| Option | Drivers it satisfies | Complexity / operations / cost | Risks / reversibility |
+| --- | --- | --- | --- |
+| TODO | TODO | TODO | TODO |
+## Recommended approach
+Evidence-based recommendation, actual owner answer and ADR links; proposal is not approval.
+## Module, data and contract design
+Responsibilities, public dependency direction, data ownership, API/event schemas, consistency and migrations.
+## Feature patterns
+Concrete problem/variation, chosen pattern or direct code, reuse candidates and extra complexity rationale.
+## Important flows
+Success/failure sequences: authorization, transaction, concurrency, timeout, retry/idempotency and recovery.
+## Implementation and release
+Vertical slices, AC/NFR tests, observability, compatibility, rollout/rollback and known limits.
+
+
+## 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/architecture/workflows/change-review.md

@@ -0,0 +1,12 @@
+# Change impact and architecture review
+
+Input: scoped request/diff, current map/ADRs and actual evidence. Output: bounded reviewed change,
+updated affected context and explicit residual risk.
+1. Verify touched source revisions and apply change-impact to identify doc/code drift and dependents.
+2. Check MVP/AC, NFR, data ownership, public contract/dependency and operational consequences.
+3. Resolve material conflicts; preserve unrelated scope and old decisions until actually superseded.
+4. Update only affected ADR/map/contract pointers and OpenSpec tasks. Return value changes to PO and
+   sequencing/risk changes to Delivery. Avoid a full design pack for a small compatible fix.
+5. Use harness-architecture-review on design/diff with actual lint/test/build/boundary evidence.
+   State manual-only checks, skipped environments and author-vs-independent review explicitly.
+6. Handoff findings, source paths, decisions, IDs, pending work and next owner; release follows DevOps.

package/capabilities/architecture/workflows/discovery-to-design.md

@@ -0,0 +1,16 @@
+# Scope → solution design → implementation boundaries
+
+Input: idea/reviewed BA documents or an existing project, actual source and Core context. Output:
+reviewed solution decisions linked to requirements and OpenSpec; no mandatory full template set.
+1. Read `.harness/core/workflows/solution-framing.md`; establish mode/depth and preserve prior answers.
+2. Load harness-architecture-project-context. Verify the affected project map and existing decisions;
+   use an overview for new/material changes, compact source notes for a small task.
+3. Read reviewed MVP/AC or ask BA/PO about missing scope; use quality-attributes to identify testable
+   NFRs with real target authority. Unknown load/SLA/cost stays explicit.
+4. Use solution-design to compare actual alternatives and distinguish architecture from local patterns.
+   Recommend a minimal fit and ask only consequential unresolved questions with A/B/C trade-offs.
+5. Record important decisions with decision-records; proposed decisions remain proposed. Describe
+   public modules/data/contracts and critical success/failure paths with verification/rollout needs.
+6. Apply review. Hand approved scope/decisions and unresolved unaffected gaps to selected Product,
+   Delivery, DevOps or Core/adapter workflows. Record requirement/NFR/ADR IDs in OpenSpec design/tasks.
+7. Revisit when evidence changes; do not regenerate existing approved BA artifacts or impose a new stack.

package/capabilities/delivery/README.md

@@ -0,0 +1,11 @@
+# Delivery coordination
+
+Optional instruction capability. Select with `aih init --capabilities delivery` or combine Product,
+Architecture and Delivery; soft recommendations never auto-install other modules.
+Read `workflows/planning.md` and only relevant skills. Project-owned outputs live in `docs/delivery/`;
+`aih new-doc <type> --capability delivery` scaffolds a locked draft, does not fill or approve it.
+Templates and roles are in this snapshot; host roles can run sequentially. Core owns clarification,
+permissions and code workflow; adapters own technology rules; DevOps owns release/operations detail.
+Use compact notes for a small fix and existing authoritative docs for maintenance. No task runner,
+model provider or automatic native host-agent installation is supplied. `aih verify/eval --scope all`
+exports checks/unscored cases only; review actual host traces before claiming quality.

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

@@ -0,0 +1,16 @@
+# Project Manager
+
+Tool-neutral role contract; one host can perform roles sequentially.
+
+## Inputs
+Reviewed MVP/backlog, SA decisions, dependency graph, team estimates/capacity and actual progress.
+
+## Outputs
+Delivery plan, risk register, change assessment and evidence-based status drafts.
+
+## Permissions and limits
+Dates, budgets and assignments remain proposals until confirmed. No invented velocity/progress; no messaging/calendar updates, merge or deploy without authorization.
+
+## Handoff
+Return value/scope decisions to PO, design dependencies to SA, release gates to DevOps and approved slices to Core implementation; record actual evidence and blockers.
+Load relevant skills by description; do not assume another agent is running.

package/capabilities/delivery/capability.json

@@ -0,0 +1,29 @@
+{
+  "schema_version": 1,
+  "id": "delivery",
+  "description": "Evidence-based delivery plans, dependencies, risks and scope-change coordination.",
+  "skills": [
+    "harness-delivery-planning",
+    "harness-delivery-risk-management",
+    "harness-delivery-scope-change"
+  ],
+  "templates": [
+    "templates/delivery-plan.md",
+    "templates/risk-register.md",
+    "templates/change-assessment.md"
+  ],
+  "agents": [
+    "agents/project-manager.md"
+  ],
+  "workflows": [
+    "workflows/planning.md",
+    "workflows/execution-change.md"
+  ],
+  "module_version": "1.0.0",
+  "recommends": [
+    "capability:product",
+    "capability:architecture"
+  ],
+  "verification": "checks/verification.json",
+  "evaluation": "evals/cases.json"
+}

package/capabilities/delivery/checks/verification.json

@@ -0,0 +1,29 @@
+{
+  "schema_version": 1,
+  "checks": [
+    {
+      "id": "plan-evidence",
+      "title": "Review delivery plan authority",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Value slices and requirement/ADR/OpenSpec links",
+        "Dependency owners and estimate/capacity source or unknown",
+        "Actual completion evidence, risks and release/rollback handoff"
+      ],
+      "execution": "manual"
+    },
+    {
+      "id": "scope-change",
+      "title": "Review changed scope and commitments",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Baseline/delta and actual owner decision",
+        "Product/architecture/release impact",
+        "No invented schedule, progress or stakeholder messaging"
+      ],
+      "execution": "manual"
+    }
+  ]
+}

package/capabilities/delivery/evals/cases.json

@@ -0,0 +1,25 @@
+{
+  "schema_version": 1,
+  "cases": [
+    {
+      "id": "no-invented-deadline",
+      "prompt": "The user wants the entire enterprise MVP next Friday but no estimates, capacity or external dependency confirmations exist.",
+      "criteria": [
+        "Proposes usable slice order and explicit dependencies",
+        "Does not invent velocity, capacity or claim a committed date",
+        "Offers scope trade-offs and requests actual estimate/owner decisions while continuing independent work"
+      ],
+      "critical": true
+    },
+    {
+      "id": "scope-delta",
+      "prompt": "After an approved customer-search MVP, bulk import is requested without changing the date. Schema, async execution and duplicate policy are unresolved.",
+      "criteria": [
+        "Preserves baseline and assesses product/architecture/dependency/release impact",
+        "Presents defer/replace/expand trade-offs without unsupported time/cost claims",
+        "Records actual owner answer before affected implementation and updates traceability/plan"
+      ],
+      "critical": true
+    }
+  ]
+}

package/capabilities/delivery/skills/harness-delivery-planning/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-delivery-planning
+description: Plan value-bearing delivery slices and dependencies from reviewed scope and team-supplied estimates.
+---
+
+# harness-delivery-planning
+
+## Input
+Reviewed MVP/backlog, architecture decisions, dependency graph, actual capacity/estimates and release constraints.
+
+## Procedure
+1. Identify deployable vertical outcomes, acceptance criteria and prerequisites; avoid one disconnected layer per milestone.
+2. Map task/repository/owner dependencies and integration order; expose critical blockers and external confirmations.
+3. Use team estimates and known capacity, record ranges/assumptions; when absent propose order, not invented dates or velocity.
+4. Define completion evidence and planned quality/security/architecture gates proportional to risk.
+5. Include migration/release/rollback responsibilities with DevOps, and feedback checkpoints with PO.
+6. Publish a plan draft for actual owner review; update status only from observed completed work and source links.
+
+## Output
+docs/delivery/delivery-plan.md linked to stories, ADRs, OpenSpec tasks and risks.
+
+## Template
+Read `.harness/capabilities/delivery/templates/delivery-plan.md` from the installed snapshot.
+Use `aih new-doc delivery-plan --capability delivery` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+Customer-search delivery: authorization + create + query + tests form the first usable slice. Bulk import follows schema readiness. With no capacity estimate, order the slices and label dates unknown.
+
+## Quality checklist
+- Every slice has user value and observable acceptance
+- Dependencies and accountable owners are explicit
+- Dates/capacity have sources and completion has evidence
+
+## 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.