feat: add guided Agenova feature delivery skill

README.md

@@ -25,6 +25,15 @@ Install one skill for a supported agent:
 npx skills add wunderforge/shared-agent-assets --skill <skill-name> --agent codex
 ```
 
+For example, install the guided Agenova delivery workflow:
+
+```sh
+npx skills add wunderforge/shared-agent-assets --skill agenova-feature-delivery --agent codex
+```
+
+Use `--agent claude-code` to install the same vendor-neutral workflow for
+Claude Code.
+
 The same repository can target Claude Code, Cursor, and other clients supported
 by the [`skills` CLI](https://github.com/vercel-labs/skills).
 
@@ -40,4 +49,3 @@ Every skill is scanned with
 fail-closed: only a `SAFE` recommendation is accepted.
 
 See [CONTRIBUTING.md](CONTRIBUTING.md) for the asset contracts and review flow.
-

skills/agenova-feature-delivery/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: agenova-feature-delivery
+description: Guide an Agenova ticket from an approved task packet through exploration, design, implementation, independent review, and evidence-backed verification while making AIDLC decisions visible.
+---
+
+# Agenova feature delivery
+
+Use this skill to implement a bounded Agenova ticket without replacing the
+project's existing source of truth.
+
+## Choose a mode
+
+- **Guided mode:** use for first-time contributors, process exercises, or when
+  the user wants to inspect how decisions affect implementation. Read
+  [the guided workflow](references/guided-workflow.md).
+- **Delivery mode:** use for routine work with an approved task packet. Follow
+  the same gates, but report only material decisions, risks, and evidence.
+
+At review time, read [the review rubric](references/review-rubric.md). In guided
+mode, use [the learning-log template](references/learning-log-template.md) to
+make the process inspectable without creating a second requirements document.
+
+## Source of truth
+
+Use this order when instructions conflict:
+
+1. The repository's routing and contribution instructions.
+2. Current product and architecture contracts.
+3. The linked GitHub ticket.
+4. Its approved task packet and design specification.
+5. Conversation guidance for the current run.
+
+Do not silently broaden the ticket, reopen an approved product decision, or
+turn the learning log into an authority. Record an approved implementation
+decision in the task packet before relying on it in code.
+
+## Delivery loop
+
+1. **Establish readiness.** Identify the ticket, active task packet, acceptance
+   criteria, dependencies, and required evidence. If the planning gate has not
+   passed, complete only the missing planning work and request review.
+2. **Explore selectively.** Inspect the smallest set of product contracts,
+   adjacent code, tests, fixtures, and prior decisions needed to test the task
+   packet's assumptions.
+3. **Resolve consequential uncertainty.** Surface only questions whose answers
+   change public behavior, architecture boundaries, security, data shape, or
+   acceptance evidence. Recommend the smallest compatible option.
+4. **Update the plan.** Put approved decisions and their implementation impact
+   into the task packet or design specification before changing code.
+5. **Implement narrowly.** Make the smallest coherent change that satisfies the
+   acceptance criteria. Preserve unrelated work and established contracts.
+6. **Review independently.** Apply the rubric's correctness, architecture, and
+   evidence lenses. When delegation is available and the user has authorized
+   it, these may be separate read-only review lanes; otherwise run them in
+   sequence.
+7. **Verify progressively.** Run focused checks while editing, then the
+   repository's full required quality gate. Fix failures or report the exact
+   blocker; never weaken a gate to make the change pass.
+8. **Close the evidence loop.** Map every acceptance criterion to observable
+   evidence and state what the gates proved. Do not claim that a passing gate
+   proves behavior it does not exercise.
+
+## Operating boundaries
+
+- Read only the repository material relevant to the active ticket.
+- Write only ticket-scoped planning, implementation, test, and evidence files.
+- Run only the repository's documented local build and validation commands.
+- Do not access credentials, private data, customer data, or secret-bearing
+  files.
+- Do not push branches, update GitHub, merge code, install dependencies, or use
+  external network services unless the user has authorized that action.
+- Stop for a human decision when alternatives materially change public
+  contracts, MVP scope, security posture, or irreversible external state.
+
+## Safe invocation example
+
+> Use `agenova-feature-delivery` in guided mode for the linked ticket. Inspect
+> the approved task packet, show me the design checkpoint before implementation,
+> then implement and explain what each quality gate proves.
+
+Expected outcome: a ticket-scoped change, updated authoritative planning when a
+decision changed, passing evidence, and a concise learning trail.

skills/agenova-feature-delivery/references/guided-workflow.md

@@ -0,0 +1,61 @@
+# Guided workflow
+
+Guided mode slows down only at decisions that teach or protect the design. It
+does not narrate routine file reads or mechanical edits.
+
+## 1. Readiness checkpoint
+
+Summarize in a few lines:
+
+- the user-visible outcome;
+- the acceptance evidence;
+- the current dependencies and blockers;
+- what is explicitly out of scope.
+
+If the ticket and task packet disagree, stop implementation and resolve the
+authoritative requirement first.
+
+## 2. Exploration checkpoint
+
+Report findings as evidence, not as a codebase tour:
+
+- which starting assumptions were confirmed;
+- which assumption was wrong or incomplete;
+- which existing contract, implementation, or test constrains the solution.
+
+Do not discuss choices that have no effect on the result.
+
+## 3. Design checkpoint
+
+For each consequential question, present:
+
+1. the decision to make;
+2. one recommended option and, only when useful, credible alternatives;
+3. the effect on public behavior, implementation, tests, and future adapters;
+4. the exact task-packet section that will change after approval.
+
+Wait for the user when the decision changes a public contract, MVP scope, or
+security boundary. Otherwise record the choice and continue.
+
+## 4. Implementation checkpoint
+
+Before editing code, restate the resulting implementation slice in one short
+paragraph. During implementation, surface a new question only if it invalidates
+the approved design or acceptance evidence.
+
+## 5. Review and gate checkpoint
+
+Run the independent review lenses, address actionable findings, and then run
+focused checks followed by the repository gate. Record:
+
+- what a review changed;
+- any issue intentionally deferred and why it is outside the ticket;
+- each command or CI gate and the behavior it actually validates;
+- any failure that prevented completion.
+
+## 6. Learning closeout
+
+Use the learning-log template to summarize the causal chain. Keep it concise
+enough to review during a team meeting. Store it beside the task packet only
+when the repository expects a durable artifact; otherwise include it in the
+handoff or pull-request discussion.

skills/agenova-feature-delivery/references/learning-log-template.md

@@ -0,0 +1,34 @@
+# Delivery learning log
+
+This is an educational trace, not a requirements source. Link back to the
+authoritative ticket and task packet instead of copying them.
+
+## Goal
+
+One sentence describing the ticket outcome.
+
+## Decision trail
+
+| Starting assumption or question | Evidence or discussion | Decision | Authoritative artifact changed | Implementation consequence |
+| --- | --- | --- | --- | --- |
+|  |  |  |  |  |
+
+Include only decisions that affected behavior, design, security, scope, or
+verification.
+
+## Review impact
+
+- Finding:
+- Change made:
+- Why it mattered:
+
+## Quality-gate evidence
+
+| Gate or check | What it proved | Result |
+| --- | --- | --- |
+|  |  |  |
+
+## Remaining boundary
+
+List any explicitly deferred work or unresolved risk. Do not describe deferred
+work as completed.

skills/agenova-feature-delivery/references/review-rubric.md

@@ -0,0 +1,29 @@
+# Review rubric
+
+Use three independent lenses. Findings must identify an observable failure,
+contract violation, or missing evidence; style preferences are not findings.
+
+## Correctness and negative cases
+
+- Does the change satisfy every acceptance criterion?
+- Are rejection paths and boundary values tested, not only the happy path?
+- Could defaults, state transitions, errors, or concurrency produce an invalid
+  result?
+
+## Product and architecture boundaries
+
+- Does the implementation preserve the approved governance contract?
+- Does backend- or vendor-specific behavior remain behind its adapter boundary?
+- Has the change introduced a second source of truth or expanded MVP scope?
+- Are security decisions deterministic where the contract requires them to be?
+
+## Evidence and maintainability
+
+- Does each claimed behavior have direct, repeatable evidence?
+- Do tests use the shared fixtures or contracts expected by the task packet?
+- Do repository gates cover the changed languages and generated artifacts?
+- Are names and documentation consistent with the public contract?
+
+Prioritize findings that could change behavior, break integration, weaken a
+boundary, or make completion unverifiable. Re-run the affected checks after a
+fix, then run the full repository gate.