openwish 0.3.1__py3-none-any.whl

openwish/__init__.py

@@ -0,0 +1,3 @@
+"""OpenWish: durable needs, bounded context, deliberate change."""
+
+__version__ = "0.3.1"

openwish/__main__.py

@@ -0,0 +1,3 @@
+from .cli import main
+
+raise SystemExit(main())

openwish/assets/artifacts.md

@@ -0,0 +1,168 @@
+# OW artifact reference
+
+OW operates on need IDs. Asks stay in conversation. Stable IDs are `N-001`,
+`S-001`, and `E-001`; Markdown records use TOML headers between `+++` lines.
+
+```text
+openwish/
+  config.json                 # product and budgets (schema version 2)
+  installation.json           # installed harnesses and per-file OW versions
+  policy.md                   # workflow and human communication
+  artifacts.md                # this reference
+  needs/N-001.md              # durable outcome and lifecycle
+  needs/N-001.state.json      # current implementation revision and decisions
+  needs/N-001.review.json     # latest direct verification results
+  specs/S-001/spec.md         # behavioral contract, prerequisite/parent links
+  specs/S-001/design.md       # technical design and authoritative need references
+  epics/E-001/design.md       # bounded implementation increment, linked to specs
+  epics/E-001/tasks.json      # ordered, verifiable work
+  knowledge/environment.md    # current operational facts
+```
+
+Run `ow init` for a terminal harness multi-select or `ow init --harness opencode
+claude` for explicit selection. Re-running installs missing skills, overwrites
+older versions, preserves equal versions, and asks before downgrading newer ones.
+Existing project knowledge is preserved. `installation.json` is a bounded current
+inventory, not a history; generated skills and adapters also carry version stamps.
+
+## Needs
+
+Create with `ow new need N-001 --title "Monthly reconciliation"` and fill in:
+
+```toml
++++
+id = "N-001"
+title = "Monthly reconciliation"
+currency = "current"
+implementation = "open"
+actor = "Operations staff"
+outcome = "Reconcile a month's transactions without manually copying records."
+acceptance = ["Representative reconciliation completes without retyping rows."]
+confirmed_at = ""
+verified_at = ""
++++
+```
+
+Use an optional short body for essential constraints. Everything in a current
+need enters the global context. Do not add an `ask` field or duplicate spec links.
+
+If a need requires more implementation, run `ow reopen N-001`. Its ID and history
+survive; implementation becomes open, revision increases, gates reset, and mode
+returns to default. Reopening a retired need also reactivates it, so confirm that
+intent first. Existing task results remain evidence; Plan assesses what now remains.
+
+## Specs and need references
+
+`ow new spec S-001 --title "Transaction export"` creates both files. The contract
+header in `spec.md` contains `id`, `title`, `implementation`, `depends_on = []`,
+and `parent = ""`. The body states behavior and observable acceptance scenarios.
+
+The **design** contains the need references:
+
+```toml
++++
+id = "S-001"
+needs = ["N-001"]
++++
+```
+
+Below that header, explain how the design satisfies N-001 and preserves affected
+constraints. The reference is authoritative here; the CLI derives the need's spec
+list and all task lineage from it. Designs can reference multiple needs.
+Prerequisite and containment graphs are separate and acyclic.
+
+## Epics and tasks
+
+`ow new epic E-001 --title "Export implementation"` creates `design.md` with
+`id`, `title`, and `specs = ["S-001"]`. Describe only this bounded increment.
+Split larger work into multiple task groups or epics; retain durable design in specs.
+
+```json
+{
+  "tasks": [
+    {
+      "id": "E-001/T-001",
+      "title": "Export the selected month's transactions",
+      "group": 1,
+      "order": 1,
+      "depends_on": [],
+      "kind": "agent",
+      "status": "open",
+      "files": ["src/transactions/export.py"],
+      "acceptance": "Export contains exactly the selected month's records.",
+      "evidence": ""
+    }
+  ]
+}
+```
+
+Task status is `open | in-progress | blocked | done`; kind is `agent | manual`.
+Task IDs are globally qualified, e.g. `E-002/T-001` can depend on `E-001/T-001`.
+Group/order pairs are unique within work supporting a need, including across epics.
+Prerequisites must have lower pairs; independent needs may reuse ordinal pairs.
+`done` needs concise direct evidence. Do not invent human observations.
+
+## Need-owned decisions and review
+
+A need's state contains only `revision`, `mode`, `no_work_reason`, and `gates`.
+It has no title, ask, independent identity, stored need group, or copied work list.
+Specs/epics/tasks are derived from need → spec design → epic links at read time.
+Missing state for an imported need defaults to revision 1 with no approvals.
+
+```sh
+ow context N-001 N-002
+ow gate needs N-001 N-002 --by human
+ow gate align N-001 N-002 --by human
+ow gate implement N-001 N-002 --by human
+ow ready N-001 N-002
+```
+
+The IDs select needs for that command; they do not create a persistent grouping.
+Human-facing confirmations discuss only the current decision, using policy's
+numbered questions and lettered choices. Do not preview later gates in Propose.
+
+For explicit fast-forward, use `ow new need ... --fast-forward`, `ow reopen
+N-001 --fast-forward`, or `ow mode fast-forward N-001 N-002` for already-open
+needs. Then record gates with `--by fast-forward`. Changing mode invalidates
+authority; reopening never inherits fast-forward implicitly.
+
+If existing implementation already satisfies a need, set its state's concise
+`no_work_reason` before alignment rather than inventing epics. This does not waive
+existing unfinished tasks or verification. Redundant asks require no records at all.
+
+```sh
+ow record-review N-001 --summary "Monthly reconciliation no longer requires copying rows" \
+  --check "python -m unittest tests.test_export: 6 passed in 0.4s" --covered-need N-001
+ow summary N-001
+ow gate review N-001 --by human
+ow approve N-001
+```
+
+Include every ID in `ow context N-001`'s `review_needs` with repeated
+`--covered-need` flags. They include affected adjacent current needs. One command
+can review multiple selected needs; each keeps its own latest bounded result.
+Use `--verdict blocked` for unresolved findings. Passing review requires all
+relevant tasks done and is bound to plan, source content, and task evidence.
+
+`approve` preserves currency. A shared spec becomes approved only when every
+linked current need is approved. `ready` exposes missing authority per task and
+continues to list other authorized work. It includes spec titles and the needs
+they address. `summary` provides need → spec → outcome context for final updates.
+
+## Bounds and consolidation
+
+Config has `version: 2`, `product`, `needs_token_budget` (6000), `epic_limit` (8),
+and `code_exceptions`. A source exception is an exact path with a reason:
+
+```json
+{"path": "src/routes.py", "kind": "low-complexity", "reason": "Flat declarative dispatch with no nested logic."}
+```
+
+Source data formats are exempt. A `data` exception must name a data-format file.
+No exception permits an OW artifact of 500 or more lines.
+
+After completion, promote durable facts and remove obsolete completed epics once
+active references and prerequisites are reconciled. Preserve the only historical
+copy in Git before removing it. Keep needs, one current state, and one latest
+review; never append requests, episodes, or review histories. Retired needs and
+their sidecars can leave the working tree once live references are reconciled.

openwish/assets/legacy-skills.json

@@ -0,0 +1,24 @@
+{
+  "version": "0.2.0",
+  "sha256": [
+    "099e7908eafe41baa97a10c34d43a6bcdf99ac83d785ca54a2c25d12cdae469d",
+    "0cde8dd1021e96ab95d72a5cb43cece316a3703812bbf7dfb52af67d99ec4ce5",
+    "1961563ab726496ccc91f192a140d8678a81be3ae7303649f33d2f057018089e",
+    "19b64dc65bb57c5c0c4ce200dd894b6034ade71fa2ad5407c2bfc1b95955b778",
+    "268108635a9551ffb773f41a2fa51c58de0008d5cbcdbb4e2cd02b14761d616e",
+    "36605a0ddbe29cdf33009b1a0b1575a5ed19ed2169c540394aadc5273a38d2e0",
+    "368a1aef5f08f10d789b3b8004503d38c63b857b4ba8e19a9ab57c8835563880",
+    "525954e9d63f47e95daef7225dc61fbb6738d97f64a5108af65f3e9eb8304ca2",
+    "5588e1ec649089d2581df5e6c08d1dbec5d5628548a4db051fb7c019c68fca90",
+    "6759ce71fd3476cf9ce03d9151acad8a4d5a50007dbcf04b2bd27e2de6b4bf40",
+    "82f0fef476d6458dda274b0785c3e05e8c5df5d9d9e37e799d6fc74af0fd0f92",
+    "9623eddcbe97444bf212f235bbc04b42963fc146c3fe72b828639327466588ca",
+    "a1499d95abd8447558c535fe5554adcc3c9b988a0a39264a6283d430effe1e94",
+    "a5a72ea6b86fb9a1bcb325b64658fa919d70c844da1ae994ea1f6f37ea5d9015",
+    "b6d86caf1fc99a3a2d1cace882a771c5d5aa14058e6a042942f07b5ae65ad8f5",
+    "c37a168c722867133ce22bb3b66ed3eae0466831f809492b8a2ae42b5f563a34",
+    "c50f9751f380835a3f79f90355ab5ea7de92a6abd4f7849fb7f6bb395129573a",
+    "e14839c5cc26ba1ba2d9a8db92df4e4d98f6c95e8d5c90b5622e9777247e9d66",
+    "e8cc262493457910e6a44d09b02b77c6359dc8f8b377353f362bcb65654b6c43"
+  ]
+}

openwish/assets/policy.md

@@ -0,0 +1,125 @@
+# OpenWish policy
+
+OpenWish (OW) practices Need-Driven Development (NDD). Its durable unit is a
+need. Humans express asks in conversation; OW creates, revises, or reopens needs.
+Do not persist asks, ask summaries, request logs, or separate change records.
+Default scope is one product/domain in one repository, including a monorepo.
+
+## Needs and current truth
+
+- Capture actor, desired outcome, pain reduced/gain delivered, and observable
+  acceptance. Distinguish suggested solutions from genuine constraints.
+- Currency is `current | retired`. Implementation is
+  `open | in-progress | review | approved`. These dimensions are independent.
+- An approved implementation does not retire its need. Load **all current needs**,
+  including approved ones, with `ow context`. Retrieve relevant retired needs
+  when interpreting history. Never silently retire or weaken a need.
+- Match existing intent before creating a need. If the outcome is already met,
+  explain that; do not invent work or create a duplicate need to represent an ask.
+- Reopen an existing need when its outcome requires further implementation.
+  Preserve its ID. Create a new need only for a distinct durable outcome.
+- `confirmed_at` records human confirmation of intent; `verified_at` records the
+  latest accepted implementation check. Reading a file does not advance either.
+- Existing behavior is evidence of what exists, not proof of what humans want.
+  Passing tests establish delivery evidence, not automatically real-world benefit.
+
+## Human communication
+
+Show only the decision relevant to the current stage. In Propose, confirm the
+need interpretation without announcing later approval gates or asking about Plan.
+Keep process instructions internal unless the human asks how the workflow works.
+
+For every clarification or confirmation:
+
+1. Number questions `1.`, `2.`, `3.` and state the relevant need IDs and conflict.
+2. Offer the best two or three meaningful choices labeled `A.`, `B.`, `C.`.
+   In documentation, indent these choice lines by two spaces.
+3. Put `(Recommended)` **before the preferred choice text**, after its letter.
+4. Add a concise effect clause when it helps explain what will happen to needs
+   or the product. Do not invent an option just to fill three slots.
+5. Prefer preserving existing intent when it already delivers the desired outcome.
+   Recommendations follow the evidence, rather than automatically rejecting asks.
+
+Example when N-001 already provides local monthly trends:
+
+> 1. N-001 already provides monthly trends and requires data to remain local.
+> Uploading transactions conflicts with that requirement. What should I do?
+>   A. (Recommended) Keep N-001 as-is. No new need or product modification.
+>   B. Add third-party upload while keeping trends local. Revise N-001 to allow
+>   uploads only to approved third-party domains.
+>   C. Add third-party upload and trend computation with local viewing. Revise
+>   N-001's local-only constraint for approved third-party domains.
+
+Final updates lead with **need → spec → outcome**, followed by direct verification
+and any remaining blocker. Read the spec design's need references; do not report
+only epic/task IDs or assume that humans remember why a task matters. For example:
+
+> N-001 — Local monthly insights, through S-001 — Trend analysis: monthly trends
+> now compute locally. Regression checks passed; financial records stay on-device.
+
+## Workflow and authority
+
+1. Propose: confirm the need interpretation; automatically enter Align afterward.
+2. Align: reconcile current needs, code, contracts, and designs; get design approval.
+3. Plan: inspect code, update epics/tasks, and obtain implementation authority.
+4. Implement: execute ready work, verify, repair, and continue independent work.
+5. Review: AI reviews outcomes; humans explicitly accept final results by default.
+
+Record decisions against need IDs, e.g. `ow gate needs N-001 N-002 --by human`,
+only after the human actually made that decision for the current definitions.
+The CLI records conversation authority; it does not authenticate the speaker.
+
+An explicit `/fast-forward` enables that mode on the selected needs' current
+implementation revisions. Follow all phases and checks, recording gates with
+`--by fast-forward` without approval or confirmation prompts, including final
+acceptance. Never invent human confirmation dates, test results, or manual actions.
+Reopening a need resets authority to default unless fast-forward is explicitly
+requested again. Mode applies to need revisions, not subsequent unrelated asks.
+
+Ask only for genuinely blocking ambiguity, conflicting needs, missing access, or
+manual verification. Use the numbered choices above. Continue independent ready
+work before presenting human blockers; pending acceptance of one result is not
+a reason to stop other authorized work. Do not ask to run AI review.
+
+## Design and execution
+
+- Classify conflicts: need/need, need/implementation, spec/spec, or task/design.
+  Show concrete scenarios and adjacent needs. Compatible needs require adapting
+  the solution rather than silently discarding a constraint.
+- Spec **designs** own the authoritative need references. Specs may address API
+  entities, UI modules, or cross-cutting capabilities. Need/spec links are many-to-many.
+  Keep `parent` containment separate from prerequisite `depends_on` links.
+- Epics reference specs; tasks belong to epics. Work is derived through these
+  links from selected needs, without a separate persistent work container.
+- Tasks have explicit prerequisites and increasing `(group, order)` pairs across
+  the work for a need. No lower ordinal depends on a higher one. Execute the
+  earliest authorized ready task; independent later work can pass a manual blocker.
+- Preserve approved intent when resolving technical inconsistencies. Material
+  intent/design revisions return to the relevant phase; stale receipts cannot
+  authorize newer work. Task progress itself does not invalidate a plan.
+- Prefer the smallest coherent implementation, security, reliability,
+  maintainability, functional cores, and established dependencies.
+- Use meaningful verification with a routine feedback loop under five minutes.
+  Identify necessary slower checks explicitly. Missing observations are not passes.
+- Keep direct results and useful pointers, not evidence chains or repeated reviews
+  of reviews. Review the implementation and adjacent needs, not just checkboxes.
+
+## Bounds and consolidation
+
+- Every OW knowledge/planning artifact is **under 500 lines**, including JSON.
+- All current needs together stay under 500 lines and the configured estimated
+  token budget (default 6,000). `ow context` derives a complete view without truncation.
+- Code has an **under 500 LOC soft target** and **under 1000 LOC hard maximum**.
+  Source data formats are exempt; low-complexity source exceptions need exact
+  paths and reasons. These exemptions never bypass OW artifact limits.
+- LOC uses nonblank physical lines; estimated tokens use UTF-8 bytes/3. They are
+  budgeting proxies, not proofs of low complexity or model-specific token counts.
+- Overwrite latest summaries, compact before 400 lines, and bound retained epics
+  (default eight). Git stores history. Do not build append-only journals or archives.
+- Promote current contracts, environment profiles, and secret references before
+  removing completed execution detail. Retain unresolved limitations and checks.
+- Tighten wording without losing acceptance conditions. Retiring or semantically
+  merging needs requires intent confirmation under the selected workflow.
+
+Read `openwish/artifacts.md` when editing artifacts. Run `ow check` before gates
+or final review. Structural validation complements semantic alignment and review.

openwish/assets/skills/ow-align/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: ow-align
+description: Reconcile OpenWish needs with all current intent and affected implementations, then update spec contracts and designs. Use before planning or when approved intent evolves.
+---
+
+# Align
+
+Read `openwish/policy.md` and `ow context N-001 ...` for the selected needs.
+Check their need-confirmation receipts using `ow status --json`. Return to
+Propose when material intent lacks required confirmation in default mode.
+
+1. Review all current needs, including approved implementations. Retrieve relevant
+   retired needs without making them binding again. Read affected prerequisite
+   and consumer contracts, designs, and code; expand semantic adjacency as needed.
+2. Distinguish incompatible needs from an implementation that cannot yet satisfy
+   compatible ones. Adapt solutions within intent. For real human decisions,
+   present numbered questions with two or three A/B/C choices, prefix the preferred
+   choice text with `(Recommended)`, and explain effects concisely.
+3. Update behavioral specs and designs. Each design contains authoritative
+   `needs = ["N-001", ...]` references and explains how its approach satisfies them.
+   Keep entity/module/cross-cutting ownership, containment, and dependencies clear.
+4. Explain the proposed solution using need → spec → outcome and affected adjacent
+   needs. Record only consequential trade-offs. For a need requiring verification
+   but no implementation, set its state's `no_work_reason` before alignment.
+5. Run `ow check`. In default mode, ask for this design's approval using the
+   numbered-choice format; after approval record `ow gate align N-001 ... --by
+   human`. In fast-forward mode use `--by fast-forward` without confirmation.
+6. Continue internally to `ow-plan`. A material need revision returns to Propose;
+   never silently rewrite an earlier human decision or create a change record.

openwish/assets/skills/ow-consolidate/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: ow-consolidate
+description: Compact OpenWish epics and knowledge while preserving durable needs, current spec designs, and acceptance conditions. Use after implementation or when context budgets approach their limits.
+---
+
+# Consolidate
+
+Read `openwish/policy.md`, `ow status`, and `ow context`. If budgets already fail,
+inspect reported files directly before requesting full context.
+
+1. Identify completed epics/tasks, duplicate wording, stale facts, and near-limit
+   files. Do not scan all Git history or preserve conversation asks as artifacts.
+2. Promote current contracts/rationale to spec designs, operational profiles and
+   secret references to knowledge, and lasting outcome constraints to their needs.
+   Keep spec design need references intact so later updates retain their purpose.
+3. Remove completed ephemeral instructions once relevant resulting truth is
+   preserved. Keep unresolved limitations, manual checks, and prerequisites visible.
+4. Tighten wording while preserving IDs and acceptance. Merging distinct outcomes
+   or retiring a need changes intent: use Propose under the selected workflow.
+   Clarifications use numbered questions, two or three A/B/C choices, and
+   `(Recommended)` before the preferred choice text, with concise useful effects.
+5. Preserve the only historical copy in Git before removing completed epics.
+   Resolve live references first. Keep one current state and latest review per
+   need; do not accumulate asks, execution containers, histories, or archive indexes.
+6. Keep all current needs globally complete. Splitting files does not solve an
+   oversized register. If safe compaction cannot fit, clarify product boundaries
+   or genuinely redundant needs without silently weakening intent.
+7. Run `ow check`; inspect stale approvals after semantic edits. Report a compact
+   size summary plus the affected needs/specs and any current decision required.
+
+Routine bounds and replacing latest summaries apply in every phase even when
+this optional semantic maintenance skill is never invoked.

openwish/assets/skills/ow-fast-forward/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: ow-fast-forward
+description: Run OpenWish needs through NDD without approval prompts, including final acceptance. Use only for an explicit human fast-forward request or explicit instruction to skip OW approvals.
+disable-model-invocation: true
+---
+
+# Fast-forward
+
+Read `openwish/policy.md`. This grants explicit authority for the selected needs'
+current implementation revisions. Follow the same quality phases without asking
+for confirmation, design approval, implementation permission, or final acceptance.
+
+1. Interpret the ask against existing needs. Keep the ask in conversation; do not
+   create a request/change record, ask summary, or independent execution container.
+2. Reuse existing needs. If implementation must resume, use `ow reopen N-001 ...
+   --fast-forward`. For open needs use `ow mode fast-forward N-001 ...`. Create a
+   distinct new need only when necessary with `ow new need ... --fast-forward`.
+   If current outcomes already satisfy the request, explain that and do no extra work.
+3. Follow Propose, Align, Plan, Implement, and Review, reading each skill on entry.
+   Record gates with `ow gate STAGE N-001 ... --by fast-forward`. Skip all approval
+   questions; do not fabricate human confirmation or verification dates.
+4. Resolve routine decisions from all current needs and minimal coherent work.
+   For genuine blocking ambiguity or contradictory intent, first exhaust
+   independent work, then use numbered questions and the best two or three A/B/C
+   choices, with `(Recommended)` before the preferred text and concise effects.
+5. Complete actual verification and review. This mode does not manufacture access,
+   manual observations, or passing checks. Never mark unfinished tasks done.
+6. After a passing review, record fast-forward acceptance and approve the needs.
+   Report need → spec → outcome and direct evidence without another approval prompt.
+
+Future reopening defaults to normal human-controlled workflow unless explicitly
+fast-forwarded again. This mode is not authority for unrelated future needs.

openwish/assets/skills/ow-implement/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: ow-implement
+description: Implement authorized OpenWish needs in dependency order, continuing independent ready work until completion or genuine human blockers. Use to implement or resume NDD work.
+---
+
+# Implement
+
+Read `openwish/policy.md`, `ow context N-001 ...`, and `ow ready N-001 ...`.
+Authority and progress belong to needs. Follow each need's explicit mode and
+revision; missing authority blocks only affected work, not other authorized tasks.
+
+1. Select the lowest ready `(group, order)` task. Load its epic and spec designs,
+   including the spec's need references, relevant code, and acceptance conditions.
+2. Mark it in-progress, implement the smallest coherent solution, and preserve all
+   current needs and existing user work. Respect code and artifact budgets.
+3. Run meaningful checks, inspect results, and record concise direct evidence
+   before marking the task done. Never invent a human observation.
+4. Continue using `ow ready` while authorized work remains. A pending review,
+   completed epic, or independent manual blocker does not justify stopping.
+   Task prerequisites, not merely earlier ordinals, determine blocking.
+5. Repair defects within approved intent. Material need/design revisions return
+   to the relevant earlier phase; refresh stale authority under the selected mode.
+6. When only genuine human blockers remain, explain the affected need and spec,
+   then ask numbered questions with two or three A/B/C choices. Prefix the
+   preferred choice text with `(Recommended)` and describe useful effects briefly.
+7. When all relevant work is done, automatically enter `ow-review`. Continue
+   remediation and appropriate checks without asking permission for AI review.
+
+Updates and handoffs lead with the need's purpose and the spec delivering it,
+then the result, verification, and remaining blocker. Use `ow summary N-001 ...`.
+Epic/task IDs may support the explanation but never replace need/spec context.

openwish/assets/skills/ow-onboard/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: ow-onboard
+description: Adopt OpenWish by mapping an existing repository to a short set of candidate needs and spec designs, distinguishing inference from confirmed intent. Use to onboard a product or monorepo into NDD.
+---
+
+# Onboard
+
+Initialize with `ow init --harness HARNESS` if needed. Read `openwish/policy.md`
+and `openwish/artifacts.md`. Default to one product/domain in this repository.
+
+1. Inspect product descriptions, interfaces, important user journeys, code, tests,
+   and deployment configuration deliberately; avoid loading the whole repository.
+2. Propose a short set of candidate needs with actors, outcomes, gains/pains,
+   acceptance, and uncertainties. Label inference. Do not persist asks or turn
+   onboarding into a change record. Existing behavior does not establish intent.
+3. Reuse established need IDs and confirmed definitions on repeated onboarding.
+   Reopen needs requiring work; preserve approved needs whose outcomes remain met.
+4. In default mode, confirm the candidate needs with numbered questions and two
+   or three A/B/C choices. Prefix the preferred text with `(Recommended)` and
+   explain effects briefly. Discuss only current need confirmation, not later gates.
+   Explicit fast-forward skips confirmation and leaves inferred intent unconfirmed.
+5. Map contracts and technical designs to needs; put authoritative need references
+   in spec designs. Use open for unverified implementation, in-progress for active
+   work, review for verified candidates, and approved only after accepted results.
+6. Capture verified environment profiles and secret references in durable knowledge.
+   Identify gaps/manual observations without inventing tasks to rewrite working code.
+7. Continue through the workflow for those needs. Set `no_work_reason` when only
+   verification remains. Explain results by need and spec, with the next current
+   action or required decision. Keep every artifact and global intent bounded.

openwish/assets/skills/ow-plan/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: ow-plan
+description: Plan the remaining work for OpenWish needs through spec designs, small epics, and dependency-ordered tasks. Use after alignment or to repair a stale execution plan.
+---
+
+# Plan
+
+Read `openwish/policy.md`, `ow context N-001 ...`, and affected spec designs.
+Verify fresh alignment receipts for the selected needs with `ow status --json`.
+
+1. Inspect current code, conventions, verification commands, and operational
+   constraints. Determine what remains for the needs; reuse working behavior.
+2. Create/update bounded epic designs referencing specs. Preserve the complete
+   need → spec design → epic → task relationship. Do not create a separate work
+   container or stored ask. Split large epics into useful task groups.
+3. Give tasks concrete acceptance, likely files, kind, prerequisites, and increasing
+   `(group, order)` pairs across all work for a need. Cross-epic prerequisites are
+   explicit; no lower ordinal can depend on a higher one. Inspect the actual DAG.
+4. Prefer minimal coherent increments and functional cores. Put indispensable
+   manual observations late, keeping independent agent work executable. Target
+   meaningful routine verification under five minutes; identify necessary slower checks.
+5. Repair technical inconsistencies against approved designs and all affected
+   needs. Material intent/design revisions return to the relevant earlier phase.
+   Reopened needs may retain old done tasks; plan only what now remains.
+6. Run `ow check`. Explain the remaining work by need and spec. In default mode,
+   ask for implementation authority with a numbered question and two or three
+   A/B/C choices, marking the preferred choice `(Recommended)` before its text.
+7. Record `ow gate implement N-001 ... --by human` after authorization, or
+   `--by fast-forward` without asking in that mode. Continue to `ow-implement`.
+   Execution authority for shared work must cover all affected open needs.

openwish/assets/skills/ow-propose/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: ow-propose
+description: Interpret a software ask against existing OpenWish needs, creating or reopening needs only when necessary. Use to clarify desired outcomes or revise NDD intent.
+---
+
+# Propose
+
+Read `openwish/policy.md` and `ow context` from the project root. Initialize OW
+if needed. Load all current needs, including approved ones, and inspect relevant
+spec designs/code to distinguish a new need from an already-satisfied outcome.
+
+1. Identify actor, desired gains/pains, observable acceptance, and genuine
+   constraints. Treat a requested mechanism as a candidate solution.
+2. First check whether an existing need already covers the outcome. If it is met,
+   recommend keeping the need/product as-is where appropriate. Do not create a
+   duplicate need, reopen working behavior, or persist the ask merely to track it.
+3. If work is needed for the same outcome, revise/reopen the existing need under
+   its stable ID. Create a new need only for a distinct durable outcome. Present
+   material conflicts and affected adjacent needs before modifying constraints.
+4. Ask numbered questions with two or three choices, `A.`, `B.`, `C.`. Put
+   `(Recommended)` before the preferred choice text. Add concise effects on needs
+   and implementation when useful. Recommendations depend on existing intent and
+   evidence; do not automatically ignore a request for an unmet outcome.
+5. In default mode, confirm only the proposed need interpretation and acceptance.
+   Do not mention later approvals, Plan gates, or implementation authorization in
+   this confirmation. In explicitly selected fast-forward mode, skip confirmation
+   and clarify only genuinely blocking ambiguity using the same question format.
+6. Create/revise/reopen the agreed needs using `openwish/artifacts.md`. Store their
+   durable definitions, not the original ask or an ask summary. Reopening resets
+   authority; explicitly set fast-forward again only when requested.
+7. Run `ow check`, then `ow gate needs N-001 ... --by human` after actual
+   confirmation, or `--by fast-forward` when authorized. Continue internally to
+   `ow-align`; do not add another permission question or preview its gates.
+
+If there is no need revision or unfinished work, provide a concise explanation
+using the existing need and spec, then finish without generating artifacts.

openwish/assets/skills/ow-review/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: ow-review
+description: Review implemented OpenWish needs and affected regressions, remediate defects, and present concise need/spec outcomes for acceptance. Use after implementation or to refresh verification.
+---
+
+# Review
+
+Read `openwish/policy.md`, `ow context N-001 ...`, affected spec designs and their
+need references, task evidence, and the actual code diff. Review from intent.
+
+1. Check selected needs and affected adjacent current needs, including previously
+   approved ones. Verify contracts, error paths, security, reliability, and
+   maintainability with meaningful evidence. Distinguish delivery from user outcomes.
+2. Repair defects within approved intent and rerun affected checks. Material
+   revisions return to the appropriate phase. Continue unfinished authorized work
+   before requesting any final acceptance; never invent manual observations.
+3. Run `ow check`. Record the latest direct review using `ow record-review N-001
+   ... --summary "user outcome" --check "command/observation: result" --covered-need
+   N-001 ...`. Include every context manifest `review_needs` ID. Use `--verdict
+   blocked` for unresolved findings. Each need owns its latest bounded review.
+4. Passing review requires all relevant tasks done. Repository, plan, or evidence
+   edits afterward require refreshed verification and a replacement review.
+5. Present a concise result using **need → spec → outcome**, then verification and
+   limitations. Use `ow summary N-001 ...`; read S-001's design to identify N-001.
+   Do not report only task completion or assume the human remembers the purpose.
+6. In default mode, after available authorized work is exhausted, ask explicitly
+   for final acceptance using a numbered question with two or three A/B/C choices
+   and `(Recommended)` before the preferred choice text. After acceptance run
+   `ow gate review N-001 ... --by human`, then `ow approve N-001 ...`.
+7. In fast-forward mode, skip that confirmation: record the passing review,
+   `ow gate review N-001 ... --by fast-forward`, and `ow approve N-001 ...`.
+   Attribute acceptance to fast-forward, not explicit human review.
+
+Needs remain current and binding. Follow-up work reopens existing needs or creates
+distinct new ones; redundant asks generate no records. Keep one latest review.