@thebackstoryis/engineering-with-ai 0.2.9

package/skills-src/ewai-project-discovery/references/discovery-contract.md

@@ -0,0 +1,34 @@
+# Discovery contract
+
+`ewai discover` requires an initialized project with `SPECS/pipeline.yaml`.
+
+## Outputs
+
+- `SPECS/1.Scope/context.md`
+- `SPECS/1.Scope/project-scope.md`
+- `SPECS/2.Purpose/intent-brief.md`
+- `SPECS/2.Purpose/explorations/project-discovery.md`
+- `SPECS/3.Evidence/success-criteria.md`
+- `SPECS/3.Evidence/risk/compliance-applicability.md`
+- `SPECS/4.Constraints/project-constraints.md`
+- `SPECS/5.Strategy/approach.md`
+- `SPECS/5.Strategy/architecture/stack.md`
+- `SPECS/5.Strategy/options/minimum-standards.md`
+
+The command also records resolved technology packs and discovery paths in `SPECS/pipeline.yaml`.
+
+For a new project with no repository evidence, the answers must record either selected pack identifiers, explicit custom technology, or an open stack decision. The owner should be interviewed about product and operating constraints before technology is recommended. Accepted stack practices belong in canonical constraints, patterns, or ADRs; the generated minimum-standards file remains a proposal until reviewed.
+
+## Automation
+
+Pass a YAML or JSON document using schema `ewai.discovery-answers/v1` with `--answers`. Required fields are:
+
+- `project.name`
+- `project.purpose`
+- `project.problem`
+- one or more `project.primaryUsers`
+- one or more `project.desiredOutcomes`
+
+Use `yes`, `no`, or `unknown` for tri-state assurance answers. Use `--force` only after reviewing the existing discovery artefacts; without it, the command refuses to overwrite them.
+
+Use `available` or `unavailable` for `validation.claude`, `validation.codex`, and `validation.antigravity`. Only explicitly available providers may satisfy external-validation stages.

package/skills-src/ewai-prototype-iteration/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: ewai-prototype-iteration
+description: Review an EWAI prototype plan and each produced rendered design with the most relevant available core, project, personal, and already installed premium personas; assess every finding; and govern bounded iteration before human prototype selection. Use during UI Design after a design system has been applied, when planning screens and journeys, after producing or revising a runnable prototype, or when explaining why a persona-guided design cycle should iterate or stop.
+---
+
+# EWAI Persona-Guided Prototype Iteration
+
+Create review evidence; do not grant design acceptance. Read [the review contract](references/review-contract.md) completely before recording a plan or design review.
+
+## Workflow
+
+1. Confirm that UI Design is in scope, the design-system application receipt is valid, and a fresh prototype plan is available.
+2. Prepare plan review with `ewai prototype-review plan-prepare DELIVERY --input FILE --project PROJECT --json` or `ewai_prototype_plan_prepare`. Use signals grounded in the intended actors, outcomes, journeys, screens, accessibility needs, domain and risk.
+3. Show every actively engaged persona's safe ID, name, tier, matched signals and engagement reason. Use the returned ensemble only. Core and project personas plus standard model capabilities form a complete baseline; personal and already installed premium personas are optional enrichment. Never fetch, sync, reveal or persist persona bodies.
+4. Ask each active persona to review the plan through its stated lens. Keep persona findings separate from assessment. Give each finding a stable concern code and cited plan evidence.
+5. Give every finding exactly one disposition: `incorporate`, `incorporate-with-modification`, `defer`, `reject`, or `escalate`, with a substantive rationale. Record with `plan-record` or `ewai_prototype_plan_record`.
+6. Apply incorporated feedback before producing the runnable prototype. If the plan changes materially, prepare it again; do not silently reuse the earlier persona ensemble.
+7. Capture source and rendered-viewport evidence for the produced design. Record interaction, assistive-technology, user-research, Manual QA and release as independent channels; missing evidence remains missing.
+8. Prepare a rendered-design cycle with `cycle-prepare` or `ewai_prototype_cycle_prepare`. Recompute relevant personas from the actual design and evidence. Do not inherit the plan ensemble merely because it was previously active.
+9. Ask the active design-stage personas to review the rendered result, then assess and record every finding with `cycle-record` or `ewai_prototype_cycle_record`.
+10. Follow the derived action: iterate, present the result for human selection, or route the unresolved decision to a named human. Default to two design cycles; configure only one to three. Never continue autonomous iteration beyond the limit.
+11. Link the reviewed plan and final cycle in `ewai.prototype-manifest/v3`. Human prototype selection, Manual QA, deployment and release remain separate.
+
+## Boundaries
+
+- Treat persona output as a hypothesis, not user research or owner evidence.
+- Never let a persona select the prototype, approve a deviation, accept Manual QA, or authorise release.
+- Never collapse source, rendering, interaction, assistive-technology, user-research, Manual QA or release into one evidence claim.
+- Never rewrite immutable review evidence. Prepare and record a successor linked by digest.
+- Never count more findings as better review. Select relevant perspectives and cite material evidence.

package/skills-src/ewai-prototype-iteration/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Persona-Guided Prototype Review"
+  short_description: "Review prototype plans and renders with personas"
+  default_prompt: "Use $ewai-prototype-iteration to review this prototype plan and rendered design with the most relevant available personas."

package/skills-src/ewai-prototype-iteration/references/review-contract.md

@@ -0,0 +1,49 @@
+# Persona-guided prototype review contract
+
+## Two independent review stages
+
+Plan review examines intended screens, journeys, outcomes, information architecture, constraints and decision ownership. Rendered-design review examines the produced prototype and the evidence actually captured for it. Persona relevance is recomputed for each stage.
+
+Store only safe persona metadata: ID, name, tier, category, matched signals and engagement reason. The host model with installed core and project personas is complete. Personal and premium personas may enrich the review only when already installed.
+
+## Finding and assessment separation
+
+A finding records:
+
+- active `personaId`;
+- stable `concernCode`;
+- `advisory`, `material`, or `critical` severity;
+- observation and recommendation;
+- bounded evidence references.
+
+Its stable ID derives from persona, concern code and sorted evidence references, not explanatory prose.
+
+Every finding receives exactly one assessment:
+
+- `incorporate`: apply the recommendation;
+- `incorporate-with-modification`: apply the recorded bounded modification;
+- `defer`: retain it visibly for a later owned decision;
+- `reject`: do not apply it, with rationale;
+- `escalate`: require a named human decision.
+
+An unassessed finding keeps the review incomplete. A material or critical deferral requires human decision. Incorporated feedback causes iteration unless the configured cycle limit has been reached, when it becomes `human-decision-required`.
+
+## Evidence channels
+
+Represent all channels independently:
+
+| Channel | Required for persona design review | Authority boundary |
+| --- | --- | --- |
+| `source` | yes | supports source observations only |
+| `rendered-viewport` | yes | supports visible rendered observations |
+| `interaction` | when performed | does not imply assistive-technology evidence |
+| `assistive-technology` | when performed | remains absent until actually exercised |
+| `user-research` | when performed | persona simulation never substitutes for it |
+| `manual-qa` | separate human gate | persona review cannot mark it available |
+| `release` | separate release authority | persona review cannot mark it available |
+
+## Immutable chain
+
+Plan reviews and cycles are content-addressed under `SPECS/6.Build/<delivery>/ui-design-assets/prototype-iterations/`. A later design cycle names the immediately preceding cycle digest. `ewai.prototype-manifest/v3` links the reviewed plan and final cycle to the selected HTML entry point.
+
+Historical manifest v1 and v2 records remain readable. Newly stamped v3 deliveries must not complete UI Design with only a design-system receipt and no reviewed prototype evidence.

package/skills-src/ewai-retro/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: ewai-retro
+description: Close an EWAI feature, delivery, incident, or iteration by examining the actual artefacts and feedback, facilitating a blameless retrospective, recording owned actions under SPECS/3.Evidence/retros, and refining the applicable project-local SPECS, patterns, constraints, personas, stack guidance, templates, validators, and pipeline assets. Use after manual QA and delivery, after material failure, or whenever the user asks what was learned and how the system should improve.
+---
+
+# EWAI Retrospective
+
+Turn delivery experience into durable improvement. Every completed capability gets a Retro, even when the conclusion is that no material change is needed.
+
+Resolve the workspace and SPECS root from `.ewai-pipeline/project.json`; all logical `SPECS/...` paths below are relative to that configured root.
+
+## Gather evidence
+
+1. Read the configured `pipeline.yaml`, feature intent or capsule, delivery tracker, gate records, test evidence, review findings, manual QA feedback, and relevant Git history.
+2. Review the previous Retro actions and record whether they were completed, deferred, or dropped with a reason.
+3. Separate observed facts from interpretation. Keep missing timing, review, or test evidence visible.
+
+## Facilitate learning
+
+Ask one question at a time:
+
+1. What should continue, and why did it work?
+2. What should stop, and what was the underlying cause?
+3. What should start, with an owner and review point?
+4. What surprised us or contradicted the SPECS?
+5. Which project or EWAI asset would have prevented the problem or amplified the success?
+
+Use a minimum viable Retro when time is constrained, but do not skip the learning and asset-routing steps.
+
+## Route accepted learning
+
+- Update scope, domain language, or personas under `SPECS/1.Scope/`.
+- Update intents, requirements, journeys, or explorations under `SPECS/2.Purpose/`.
+- Keep the Retro and its evidence under `SPECS/3.Evidence/retros/`.
+- Promote verified non-negotiables into `SPECS/4.Constraints/`.
+- Update architecture, stack, decisions, options, patterns, SOPs, runbooks, or capsules under `SPECS/5.Strategy/`.
+- Refine project-local skills, validators, templates, personas, or technology packs only when the project owns them.
+- In a customer project, record an upstream EWAI improvement proposal rather than editing a global EWAI installation.
+
+Do not promote one-off preference into a universal rule. Record first occurrences; extract a shared pattern when evidence shows reuse, with the established three-instance rule as the default threshold unless severity justifies earlier action.
+
+## Complete Retro
+
+Write `SPECS/3.Evidence/retros/<date>-<slug>.md` with facts, Continue/Stop/Start insights, root causes, asset changes, owned actions, previous-action review, and follow-up date. Link every applied asset change and every deferred proposal.
+
+Retro passes only when accepted low-risk documentation improvements are applied, larger changes have owned work items, and the delivery tracker records the Retro artefact. Do not mark a capability complete merely because the meeting ended.
+
+Read [asset routing](references/asset-routing.md) before applying learning beyond the Retro file.

package/skills-src/ewai-retro/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Retrospective"
+  short_description: "Turn delivery feedback into durable improvements"
+  default_prompt: "Use $ewai-retro to close this delivery, capture what we learned, and refine the relevant SPECS and EWAI assets."

package/skills-src/ewai-retro/references/asset-routing.md

@@ -0,0 +1,14 @@
+# Retrospective asset routing
+
+| Learning | Canonical destination |
+|---|---|
+| Project boundary, domain term, or user understanding | `SPECS/1.Scope/` |
+| Outcome, requirement, journey, or intent correction | `SPECS/2.Purpose/` |
+| Retro, gate, incident, iteration, or risk evidence | `SPECS/3.Evidence/` |
+| Verified rule that downstream work must inherit | `SPECS/4.Constraints/` |
+| Architecture, approach, stack, decision, pattern, SOP, or runbook | `SPECS/5.Strategy/` |
+| Capability delivery evidence | `SPECS/6.Build/<slug>/` |
+
+Keep a recommendation in Evidence or Strategy until an accountable owner accepts it as a binding Constraint.
+
+Project-local assets can be updated inside the project. Changes to EWAI's distributed core, commercial packs, or global installation require an upstream proposal and the normal EWAI review/release process.

package/skills-src/ewai-rollout/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: ewai-rollout
+description: Review a governed consultancy, organisation, or multi-project EWAI rollout using its bounded read-only snapshot, exact Organisation Blueprint comparisons, structural assurance evidence, standard host-model reasoning, and contextually engaged installed personas. Use when Codex needs to examine rollout cohorts, baseline adoption, Blueprint drift, missing, stale, unavailable, or invalid evidence, accountable review routes, or one selected project's rollout assurance without changing client projects.
+---
+
+# EWAI Rollout Review
+
+Resolve the host project and configured SPECS root before acting. Read [the rollout contract](references/rollout-contract.md) before interpreting a workspace or producing advice.
+
+Use the standard host LLM for the review. Installed project and core personas enrich the normal baseline. Installed personal and premium personas are optional specialist lenses, not prerequisites.
+
+## Retrieve the governed projection
+
+Validate the project-owned policy first:
+
+```bash
+ewai rollout validate --project . --json
+```
+
+Retrieve the whole rollout or select a concise concern so EWAI can engage relevant personas:
+
+```bash
+ewai rollout status --project . --json
+ewai rollout status --focus "Blueprint drift and security evidence" --project . --json
+ewai rollout assurance client-portal --project . --json
+```
+
+When the EWAI MCP server is available, use `ewai_rollout_status` with optional `focus` and `projectId`. These surfaces are read-only. Do not provide a project-root override, credentials, approval, risk acceptance, raw client evidence, or mutation instructions.
+
+Preserve `not-configured`, `invalid`, `ready`, and `attention` exactly. Preserve project adoption states `aligned`, `review-required`, `not-adopted`, `unavailable`, `stale`, and `invalid`. Missing or non-current evidence never means healthy.
+
+When the focus or selected project changes materially, retrieve a fresh projection so the active persona ensemble can swap relevant lenses in and out.
+
+## Disclose active personas
+
+Before analysis, list each active persona's name, tier, matched signals, and engagement reason. Use only returned safe metadata.
+
+- Apply project and core personas when selected by the current context.
+- Apply personal or premium personas only when already installed and selected as relevant.
+- Treat an absent premium library as nonblocking; the standard host model remains capable of the review.
+- Never initiate entitlement checks, persona synchronisation, content retrieval, or installation from this skill.
+- Never imitate, reconstruct, expose, or claim access to an unavailable persona body.
+
+Personas surface questions and alternatives. They do not supply stakeholder evidence, approve a baseline, judge assurance adequacy, or become accountable decision-makers.
+
+## Review in evidence order
+
+1. Report `declared-policy`: the rollout owner, cohort, required evidence, assigned project, review owner, and exact Blueprint baseline.
+2. Report `observed-project-evidence`: bounded child-owned Blueprint, delivery, standards, Manual QA, and security states with their stated limitations.
+3. Report `automated-check`: exact Blueprint comparisons and freshness outcomes. Do not infer semantic-version precedence or compatibility.
+4. Report `persona-hypothesis`: concerns, edge cases, or questions raised through a disclosed active persona lens.
+5. Reserve `human-decision` for an actual named human decision. A suggested route is not the decision itself.
+
+Use the returned review questions to find the baseline difference needing ownership, required evidence that is absent or unreliable, unsupported conclusions, and the named person who owns the next action.
+
+## Produce an actionable review
+
+Return:
+
+1. rollout, cohort, project, and snapshot status;
+2. active persona names, tiers, matched signals, and engagement reasons;
+3. declared baseline and required evidence;
+4. observed evidence, freshness, gaps, and limitations;
+5. separately labelled automated checks and persona hypotheses;
+6. the next route and named accountable owner; and
+7. both returned advisory and security notices.
+
+Keep absolute paths, repository roots, raw evidence documents, prompts, persona bodies, credentials, validator findings, risk dispositions, and unrestricted client content out of the response.
+
+## Authority boundary
+
+This skill is advisory and read-only. It cannot change rollout policy, update a Blueprint pin, write child SPECS, dispatch work, approve Build or Manual QA, accept residual risk, declare evidence adequate, certify security, change release readiness, deploy, or release.
+
+Stop if validation fails, child evidence escapes the configured Portfolio topology, required fields are absent, the user asks the review to mutate a client project, or a conclusion would require treating model or persona output as human evidence. Route the decision to the returned project, review, cohort, Portfolio, security, or release owner.

package/skills-src/ewai-rollout/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Rollout Review"
+  short_description: "Review governed rollout evidence safely"
+  default_prompt: "Use $ewai-rollout to review the current governed rollout, disclose active personas and route unresolved decisions to named humans."

package/skills-src/ewai-rollout/references/rollout-contract.md

@@ -0,0 +1,74 @@
+# Rollout review contract
+
+Read this reference before interpreting `ewai.rollout-workspace/v1`, troubleshooting a rollout, or producing an LLM-assisted consultancy or network review.
+
+## Canonical inputs
+
+- `.ewai-pipeline/project.json` locates the host project and configured SPECS root.
+- `SPECS/pipeline.yaml` owns configured repository names and safe workspace-relative roots.
+- `SPECS/1.Scope/portfolio.yaml` owns the portfolio, programme, project hierarchy, topology, ownership, and declared dependencies.
+- `SPECS/1.Scope/rollout.yaml` owns rollout baselines, cohorts, assignments, evidence expectations, freshness, and review ownership.
+- Each assigned project owns its Organisation Blueprint pin, standards, delivery, Manual QA, and security evidence.
+
+The rollout workspace is a disposable, bounded projection. It is not a second client registry and cannot write into a child project.
+
+## Workspace and adoption states
+
+| Status | Meaning | Safe response |
+| --- | --- | --- |
+| `not-configured` | No rollout policy exists. | Point to the implementation guide; do not create policy without authority. |
+| `invalid` | Policy, Portfolio, project topology, or evidence structure failed validation. | Report stable diagnostics and stop interpretation. |
+| `ready` | The policy is valid and all projected adoption and required evidence states are current. | Review the evidence; do not call this approval or certification. |
+| `attention` | At least one project adoption or required-evidence state needs review. | Preserve the reason and route it to the named owner. |
+
+Project adoption can be `aligned`, `review-required`, `not-adopted`, `unavailable`, `stale`, or `invalid`. Required evidence can be `present`, `missing`, `stale`, `not-configured`, or `unavailable`. Absence and uncertainty never imply alignment.
+
+## Safe public fields
+
+The projection may expose:
+
+- bounded rollout, Portfolio, cohort, baseline, and project IDs, names, owners, review dates, and required evidence classes;
+- exact expected and observed Blueprint ID, version, and optional digest;
+- structural adoption and evidence states, safe timestamps, limitations, and accountable routes;
+- latest delivery status, phase, Build-approval boolean, and Manual QA state;
+- security-validation configuration and structural run state without findings or dispositions;
+- active persona ID, name, tier, matched signals, and engagement reason;
+- installed-tier availability counts, review questions, evidence classes, and mandatory notices.
+
+It must not expose absolute roots, raw policy or persona bodies, source documents, prompts, credentials, validator output, findings, risk decisions, adapter code, or request-supplied authority.
+
+## Exact Blueprint comparison
+
+V1 compares the project-owned Blueprint pin with the cohort baseline by exact ID and version, plus digest when the baseline declares one. An exact match is `aligned`. Any difference is `review-required`.
+
+The checker does not infer semantic-version precedence, upgrade safety, compatibility, replacement, equivalence, or migration completeness. A named accountable human owns that decision.
+
+## Evidence taxonomy
+
+| Class | Meaning | Authority |
+| --- | --- | --- |
+| `declared-policy` | Baseline, cohort, assignment, ownership, or evidence expectation recorded by the host project. | A governed declaration, not proof of adoption. |
+| `observed-project-evidence` | Allowlisted structural evidence read from an assigned project. | Bounded observation with freshness and limitations. |
+| `automated-check` | Exact comparison or deterministic freshness result. | A repeatable check, not an adequacy judgement. |
+| `persona-hypothesis` | Concern or interpretation from a disclosed persona lens. | Advisory proposition requiring evidence or human resolution. |
+| `human-decision` | Decision actually recorded by a named accountable person. | The only decision class; limited to its recorded scope. |
+
+The selected-project assurance view is explicitly structural-only and returns no adequacy verdict.
+
+## Persona and LLM method
+
+`review.standardLlmAvailable` means the ordinary host model can perform the bounded review. Installed project and core personas improve context at baseline. Installed, relevant personal or premium personas may enrich a focused review.
+
+Retrieve the projection again when the focus changes so irrelevant personas leave the active ensemble and newly relevant ones can enter. Disclose the returned name, tier, matched signals, and engagement reason. Missing premium content is nonblocking. Never fetch, synchronise, imitate, or reconstruct unavailable premium content from this skill.
+
+Persona output remains `persona-hypothesis` unless supported by project evidence or resolved by a named human. It cannot become `human-decision` evidence by repetition or confidence.
+
+## Human and assurance boundary
+
+Always preserve both workspace notices:
+
+> Rollout and persona analysis is advisory. Organisation Blueprint adoption, evidence adequacy, accepted risk, Manual QA, deployment and release decisions remain with named accountable humans.
+
+> Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.
+
+Rollout analysis cannot change policy, write child SPECS, approve Build or Manual QA, accept risk, certify security, dispatch work, change readiness, deploy, or release.

package/skills-src/ewai-shape-intents/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: ewai-shape-intents
+description: Explore a broad product idea, capability, workflow, or feature request with a project owner and turn it into a reviewed, interconnected map of draft EWAI intents. Use when a user wants to add several related features, shape an initiative, decompose a large idea, discover an MVP or release slice, build a backlog from a function, or decide which intents should exist before refining them individually.
+---
+
+# EWAI Shape Intents
+
+Turn a human idea into an understandable product map before creating individual intents. Stay conversational, ask one useful question at a time, and never start planning, delivery, or implementation from this skill.
+
+Read [intent mapping contract](references/intent-mapping-contract.md) before proposing or creating the map.
+
+## Establish project truth
+
+1. Run `ewai checkin --project <path> --json`.
+2. Read the project purpose, users, existing intents, technology strategy, constraints, imported context, and relevant Archaeology findings under `SPECS/`.
+3. Search existing intents for overlapping outcomes. Prefer extending or relating existing work over creating duplicates.
+4. If the project has not completed discovery, pause intent shaping and use `$ewai-project-discovery` first.
+
+## Select the shaping perspective
+
+Query the installed persona index:
+
+```bash
+ewai persona index \
+  --project <path> \
+  --query "product definition prioritization requirements release shaping" \
+  --json
+```
+
+- Prefer the premium `product-owner` persona when the index confirms it is installed. Read its full persona privately and use its product-shaping method to drive the interview.
+- If premium access exists but the persona library is not installed or has an offered update, ask before running `ewai persona premium sync --project <path> --yes`.
+- If it is unavailable, say so briefly and continue using the project's purpose, users, evidence, and core personas. Never impersonate or reconstruct an unlicensed premium persona.
+- If the premium `product-owner` persona is installed and selected, record it as a shaping persona on the map. Otherwise record another available shaping persona or omit the field. Never create an unlicensed reference or false provenance. Attach a shaping persona to an individual intent only when its perspective is needed throughout that intent's lifecycle.
+
+## Explore the idea
+
+Begin with what is on the user's mind. Then ask one question at a time, adapting to what is already known. Establish:
+
+- the problem, desired outcome, and why it matters now;
+- the people affected and the jobs or journeys they need to complete;
+- the rules, decisions, hand-offs, integrations, data, and operational consequences;
+- the smallest valuable outcome and what is explicitly out of scope;
+- security, privacy, assurance, accessibility, support, and failure expectations;
+- evidence of success, assumptions, and unknowns that could change the shape.
+
+Do not interrogate the user for information already present in project evidence. Summarise your evolving understanding and invite correction.
+
+## Shape interconnected intents
+
+Split by independently valuable, testable outcomes—not by frontend, backend, database, or engineering task. Keep one intent when one coherent outcome is the honest shape.
+
+Use discovery spikes only when an unresolved choice blocks responsible intent definition. Mark relationships explicitly as `depends-on`, `enables`, `complements`, `conflicts-with`, `supersedes`, or `relates-to`.
+
+For each proposed intent, add a delivery-shape preview. Most intents created from this skill should be `single`; use `split` or `decision-required` only when the map still contains an umbrella item that needs further decomposition before delivery.
+
+Present:
+
+1. the overall idea and intended outcome;
+2. a compact table of proposed intents, users, value, and boundaries;
+3. a readable relationship map and suggested sequence;
+4. assumptions, open decisions, overlap with existing intents, and possible deferrals.
+
+Ask the user to merge, split, rename, resequence, defer, or reject items. Iterate until they explicitly approve the map.
+
+## Create only after approval
+
+Use the `ewai_create_intent_map` MCP tool with `confirmed: true`. If MCP is unavailable, write the approved request to JSON or YAML and run:
+
+```bash
+ewai intent map-create <request-file> \
+  --project <path> \
+  --yes \
+  --approved-by "<name>"
+```
+
+The operation must create the durable map plus every linked draft intent atomically. Do not create intents speculatively or one-by-one before approval.
+
+After creation, offer:
+
+- to refine one draft through `$ewai-intent`;
+- to review the map in the dashboard;
+- to leave the approved drafts in the backlog.
+
+Never begin the fourteen-stage delivery cycle from this skill.

package/skills-src/ewai-shape-intents/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Shape Intents"
+  short_description: "Turn a broad idea into connected intents"
+  default_prompt: "Use $ewai-shape-intents to explore this idea and turn it into a connected set of project intents."

package/skills-src/ewai-shape-intents/references/intent-mapping-contract.md

@@ -0,0 +1,109 @@
+# Intent mapping contract
+
+## Durable outputs
+
+An approved map creates:
+
+```text
+SPECS/2.Purpose/explorations/intent-maps/<map-slug>.md
+SPECS/2.Purpose/explorations/intent-maps/<map-slug>.json
+SPECS/2.Purpose/intents/<domain>/<intent-slug>.md
+SPECS/2.Purpose/intents/<domain>/<intent-slug>.json
+```
+
+The map captures the shaping conversation and approval. Each intent repeats its map identifier and direct relationships so it remains intelligible when read alone. SQLite is a rebuildable projection of those project-owned files.
+
+## Request schema
+
+Pass an `ewai.intent-map-request/v1` object:
+
+```yaml
+schema: ewai.intent-map-request/v1
+slug: safer-alerting
+title: Safer alerting
+idea: Improve the reliability and visibility of emergency alert delivery.
+desiredOutcome: Operators can trust that every intended recipient is accounted for.
+users:
+  - Alert operator
+evidence:
+  - SPECS/3.Evidence/archaeology/dispatch-findings.md
+boundaries:
+  - Preserve blind-relay privacy.
+nonGoals:
+  - Replace the messaging provider.
+assumptions: []
+openQuestions:
+  - Who owns failed-delivery escalation?
+shapingPersonas:
+  - ref: product-owner
+    role: facilitator
+    depth: 4
+intents:
+  - domain: alerts
+    slug: accountable-dispatch
+    title: Accountable dispatch
+    problem: Some intended recipients can disappear from dispatch without a durable outcome.
+    desiredOutcome: Every intended recipient has an observable delivery disposition.
+    users:
+      - Alert operator
+    journeys: []
+    acceptanceCriteria:
+      - Every targeted recipient produces a durable delivery or skip record.
+    constraints:
+      - Raw recipient contact details remain hidden from administrators.
+    evidence:
+      - SPECS/3.Evidence/archaeology/dispatch-findings.md
+    openDecisions: []
+    personas: []
+    relationships:
+      - type: enables
+        target: alerts/delivery-reconciliation
+        rationale: Reconciliation requires a complete dispatch ledger.
+    deliveryShape:
+      recommendation: single
+      reason: This is one independently valuable delivery outcome with a clear acceptance boundary.
+      suggested_children: []
+      blocking_questions: []
+      reviewed_decision: keep-as-one
+```
+
+## Relationship direction
+
+- `depends-on`: the source cannot responsibly deliver its outcome before the target.
+- `enables`: completing the source makes the target possible or materially safer.
+- `complements`: the intents are independently useful but stronger together.
+- `conflicts-with`: the intents express incompatible choices requiring resolution.
+- `supersedes`: the source replaces the target's intended outcome.
+- `relates-to`: a meaningful connection exists without a stronger semantic claim.
+
+Targets use exact `<domain>/<slug>` references. `depends-on` relationships among newly created intents must be acyclic.
+
+`depends-on` may also record `required_before: build|delivery` and `required_state: plan-complete|delivered`. When omitted, EWAI defaults to `required_before: delivery` and `required_state: delivered`, allowing related intents to be explored and planned in parallel without pretending their delivered outcomes are independent.
+
+## Slicing rules
+
+A good intent:
+
+- produces a user, business, operational, or assurance outcome that can be evaluated;
+- can pass through the complete EWAI lifecycle without pretending a technical layer is a product outcome;
+- has a defensible boundary and acceptance evidence;
+- names dependencies without hiding scope inside another intent.
+- includes a delivery-shape preview showing whether it should be delivered as-is, split first, or paused for a split decision.
+
+Do not force a large idea into many intents. Do not combine unrelated outcomes merely to reduce the count. Avoid tasks such as “build API,” “create database,” or “make frontend” unless the technical capability itself is the independently valuable outcome.
+
+If an intent remains large, record `deliveryShape.recommendation: split` with suggested child outcomes and dependencies, or `decision-required` with the owner questions that block a safe split. Do not send an oversized parent intent into delivery merely because it has a dependency map.
+
+## Completion gate
+
+The map is ready to create only when:
+
+- the user has reviewed and explicitly approved it;
+- every intent has a title, problem, desired outcome, and stable domain/slug;
+- relationships point to proposed or already existing intents;
+- every proposed intent has a delivery-shape preview;
+- overlaps and conflicts with existing intents are visible;
+- assumptions, exclusions, and materially blocking questions are recorded;
+- the proposed set is small enough to understand and complete enough to represent the user's idea.
+
+Creation is atomic. If any intent fails validation or collides with existing files, no part of the new map should remain.

package/skills-src/ewai-solution-readiness/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: ewai-solution-readiness
+description: Prepare and complete a governed, evidence-bound Solution Readiness Review for an EWAI delivery. Use when an owner asks whether a solution has proportionate evidence for internal, sensitive, client-facing, public-service, critical or regulated use; when release evidence must be composed across intent, impact, standards, tests, Manual QA, security, hosting, operations, documentation and specialist assurance; or when an earlier readiness report may have become stale.
+---
+
+# EWAI Solution Readiness
+
+Use the CLI/domain contract to prepare evidence. Facilitate a named human review. Never turn the result into certification or release permission.
+
+## Method
+
+1. List profiles with `ewai readiness profiles --project . --json`.
+2. Ask the accountable owner to choose `internal-only`, `internal-sensitive`, `client-facing`, `public-service`, or `critical-regulated`.
+3. Prepare current evidence with `ewai readiness prepare SLUG --profile PROFILE --project . --json`.
+4. Show every dimension, state, limitation and citation. Never collapse them into a score.
+   When an organisation policy baseline is enabled, include the current policy design gate as an evidence dimension with its exact baseline, fact and evaluation digests, matched controls, decisions and staleness. `not-configured` stays visible where policy is not required; never relabel it as satisfied.
+5. Show **Active personas** with safe ID, name, tier, matched concern and engagement reason.
+6. Review the generated `readiness-review.template.json` with a named human. Every required dimension needs an explicit disposition and reason. Conditions and residual risks need an owner and future review date.
+7. Record it with `ewai readiness review ASSESSMENT --input FILE --reviewed-by NAME --project . --json`.
+8. Explain the result and every contributing condition or blocker.
+9. Check currency with `ewai readiness status ASSESSMENT --project . --json`. When stale, prepare a new assessment; never overwrite history.
+
+## Evidence vocabulary
+
+- Prepared states: `satisfied`, `conditional`, `blocking`, `missing`, `stale`, `not-applicable`, `not-configured`.
+- Human dispositions: `accepted`, `conditional`, `blocked`, `insufficient-evidence`, `not-applicable`.
+- Advisory results: `ready-for-human-decision`, `conditional`, `blocked`, `insufficient-evidence`.
+
+Never accept `missing`, `stale`, `blocking` or `not-configured` required evidence as satisfied. `ready-for-human-decision` means the evidence is coherent enough for accountable human judgement; it does not mean approved or released.
+
+## Persona method
+
+- Use standard model reasoning plus installed core and project personas as the complete baseline.
+- Swap in relevant installed project, personal and premium personas as the profile and evidence gaps change.
+- Keep project, personal and core persona provenance visible alongside any optional premium enrichment.
+- Premium personas are optional enrichment. Never sync, download or imitate premium content during this skill.
+- Keep active personas visible at preparation and review.
+- Treat personas as advisory lenses. They do not supply stakeholder evidence, accept risk or approve release.
+
+## Stop conditions
+
+- Stop if the delivery slug or cited path escapes the configured project.
+- Stop if the preparation, repository revision or cited evidence is stale.
+- Stop if a required dimension lacks a decision or a condition lacks accountable ownership.
+- Stop if anyone asks the skill to rewrite source evidence, approve Manual QA, change a security disposition, deploy or release.
+- The skill does not approve Manual QA or release.
+- Preserve blockers and uncertainty. Do not manufacture evidence, a percentage score or a certificate.
+
+## Mandatory notices
+
+Repeat both notices on every presentation path:
+
+Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.
+
+Solution Readiness Review is advisory evidence, not certification, business acceptance, Manual QA approval, security approval, deployment permission or release authorisation. Accountable humans retain every approval and risk decision.

package/skills-src/ewai-solution-readiness/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Solution Readiness"
+  short_description: "Prepare and review release-readiness evidence"
+  default_prompt: "Use $ewai-solution-readiness to prepare a governed readiness review for this delivery."