From b8c8668c6735c5fdc680221b991f59a5e0a32dda Mon Sep 17 00:00:00 2001 From: dapeng Date: Fri, 11 Sep 2026 22:10:11 +1000 Subject: [PATCH] feat: add guided Agenova feature delivery skill --- README.md | 10 ++- skills/agenova-feature-delivery/SKILL.md | 82 +++++++++++++++++++ .../references/guided-workflow.md | 61 ++++++++++++++ .../references/learning-log-template.md | 34 ++++++++ .../references/review-rubric.md | 29 +++++++ 5 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 skills/agenova-feature-delivery/SKILL.md create mode 100644 skills/agenova-feature-delivery/references/guided-workflow.md create mode 100644 skills/agenova-feature-delivery/references/learning-log-template.md create mode 100644 skills/agenova-feature-delivery/references/review-rubric.md diff --git a/README.md b/README.md index 61c25e9..b46056d 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,15 @@ Install one skill for a supported agent: npx skills add wunderforge/shared-agent-assets --skill --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. - diff --git a/skills/agenova-feature-delivery/SKILL.md b/skills/agenova-feature-delivery/SKILL.md new file mode 100644 index 0000000..d0c0cf5 --- /dev/null +++ b/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. diff --git a/skills/agenova-feature-delivery/references/guided-workflow.md b/skills/agenova-feature-delivery/references/guided-workflow.md new file mode 100644 index 0000000..311c456 --- /dev/null +++ b/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. diff --git a/skills/agenova-feature-delivery/references/learning-log-template.md b/skills/agenova-feature-delivery/references/learning-log-template.md new file mode 100644 index 0000000..15c804a --- /dev/null +++ b/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. diff --git a/skills/agenova-feature-delivery/references/review-rubric.md b/skills/agenova-feature-delivery/references/review-rubric.md new file mode 100644 index 0000000..c3047b7 --- /dev/null +++ b/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.