[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RTWRNTK1MJSPVFMKW7RY6S":3,"skill-same:01M6RTWRNTK1MJSPVFMKW7RY6S":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":13,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M6RTWRNTK1MJSPVFMKW7RY6S","customs-trade-compliance",null,"Codified expertise for customs documentation, tariff classification, duty optimization, restricted party screening, and regulatory compliance across multiple jurisdictions. Informed by trade compliance specialists with 15+ years experience. Includes HS classification logic, Incoterms application, FTA utilization, and penalty mitigation. Use when handling customs clearance, tariff classification, trade compliance, import\u002Fexport documentation, or duty optimization.","sakamoto-family-smile\u002Fagent_monorepo","sakamoto-family-smile","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F132812403?v=4","01M6RTAT3H8PMWX5SJ65KP3VYF","01M6RTAV321WB5RAHCWTZMX5CV",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fcustoms-trade-compliance\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"compliance","customs trade compliance","trade","when","github","expertise","for","screening","customs documentation","with","hs","import","logic","across","export","use","classification","Optimization","code","documentation","2026-11-10 10:12:30",false,"---\nname: delivery\ndescription: \"Implement one ticket: reconcile its assumptions against the real codebase, get an implementation plan approved, write the code with @spec annotations, and keep the delivery record current from plan approval onward. The only skill that changes source code. Use when a ticket's dependencies are delivered and it is ready to build, such as 'implement TICKET-004' or 'deliver the next ticket'. Not for writing tickets (ticket-breakdown) or reviewing delivered code (code-review).\"\nargument-hint: \"[capability area] [TICKET-XXX] [in change-slug]\"\ndisable-model-invocation: true\nallowed-tools: Bash(python3 ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgener8v-state.py *)\n---\n\n# Delivery Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which ticket (capability area + TICKET-XXX) to deliver before doing anything else. The ticket belongs to a change: when exactly one change is active (status `ready` or `in_delivery` in `pipeline-state.yaml`), default to it; when several are active and the argument does not name one (`in \u003Cchange-slug>`), ask which. Never guess the target.\n\n## Purpose\n\nTake a single ticket from a ticket breakdown and implement it. This skill operates in three phases: first **reconciling** the ticket's stated assumptions against the actual codebase, then producing an **implementation plan** for user approval, then **executing** the plan by writing actual code. It is the only skill in the pipeline that writes to the real codebase — all other skills produce markdown artifacts in `.gener8v\u002F`. The delivery record captures what was reconciled, what was planned, what was built, what decisions were made, and where the implementation diverged from the plan.\n\nReconciliation comes first because a ticket — however well-specified — encodes *assumptions* about the codebase it will build on: that a table or column exists, that a script or command is available, that a referenced document is present at the pinned version, that a predecessor's output is where it claims to be. When those assumptions are wrong, the most expensive outcome is discovering it mid-build (or worse, building confidently on top of the wrong foundation). Verifying them against ground truth *before* planning turns a runtime failure into a cheap pre-flight finding.\n\n## When to Use\n\nUse this skill when:\n- A ticket file under `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Ccapability-area-slug>\u002F` is ready for implementation (no unresolved blockers in its Depends On field)\n- The user wants to implement a specific ticket\n- All predecessor tickets (from the Depends On field) have been delivered\n- The team is ready to move from planning artifacts to working code\n\n## Input\n\n**Source:** A single ticket from a ticket breakdown, plus all pipeline artifacts referenced in the ticket's Prior Art\n**Read from:**\n- Ticket: `.gener8v\u002Fchanges\u002F[change-slug]\u002Ftickets\u002F[capability-area-slug]\u002FTICKET-XXX.md` — one ticket, one file; there is no extraction step. Its `**Change:**`, `**Capability Area:**` and `**Specification:**` header lines confirm the target\n- Backlog: `.gener8v\u002Fchanges\u002F[change-slug]\u002Ftickets\u002F[capability-area-slug]\u002Fbacklog.md` — the dependency chain and suggested ordering this ticket sits in\n- Predecessor tickets (from the Depends On field): sibling `TICKET-XXX.md` files in the same directory\n- Change brief: `.gener8v\u002Fchanges\u002F[change-slug]\u002Fchange.md` — its Status (Draft or Approved) and Priority Cut\n- Prior Art as declared in the ticket (pipeline documents and predecessor ticket outputs)\n- Technical Design: `.gener8v\u002Ftechnical-design\u002F[capability-area-slug].md` or `.gener8v\u002Ftechnical-design\u002Fsystem-design.md` (if available)\n- Constraints: `.gener8v\u002Fconstraints\u002Fprd.md` and `.gener8v\u002Fconstraints\u002F[capability-area-slug].md` (whichever exist — PRD-level constraints apply to every ticket)\n- System Context: `.gener8v\u002Fcontext.md` (if available — its `## Repositories` table names each repository's directory and verify commands; its testing and build sections add detail)\n- Conventions: `.gener8v\u002FCONVENTIONS.md`\n- Predecessor delivery records: `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F*-delivery.md` (for dependent tickets), including their `## Post-Review Amendments`\n- Predecessor review reports: `.gener8v\u002Fchanges\u002F[change-slug]\u002Freviews\u002F*-{code,quality,security}-review.md` for every ticket in Depends On and for any predecessor whose Files Produced overlap this ticket's Output — findings deferred \"to the next ticket\" and accepted risks live there. Predecessors normally sit under the same change; a dependency on an earlier change's ticket is read from that change's directory\n- Existing codebase files referenced in Prior Art\n\n**Expects:** A ticket file opening with `# TICKET-XXX: title` and the three header lines, then Summary, Priority, Value, Requirements Covered, Prior Art, Acceptance Criteria, Output, Constraints, and Size fields. Predecessor tickets in the Depends On field should have delivery records.\n\n**If input is missing or malformed:**\n- If several changes are active and none is named, ask which one before reading anything\n- If no `tickets\u002F\u003Ccapability-area-slug>\u002FTICKET-XXX.md` exists for the target under the change, stop and recommend running the Ticket Breakdown skill first (`ticket-breakdown \u003Carea> for \u003Cchange-slug>`)\n- Legacy: if the area's tickets exist only as a per-area file `tickets\u002F\u003Ccapability-area-slug>.md` holding `### TICKET-NNN:` sections, recommend `python3 ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgener8v-state.py split-tickets` and deliver from the resulting ticket file — never from the legacy shape\n- If predecessor tickets have not been delivered, warn the user — the ticket's Prior Art may reference files that do not yet exist\n- If technical design or constraints are missing, proceed but note the gap — implementation decisions may lack architectural context\n\n## Output\n\n**Produces:** Two things:\n1. The actual code files declared in the ticket's Output section (written to the real codebase)\n2. A delivery record documenting what was planned, built, and decided\n\n**Write to:** `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F[capability-area-slug]-[ticket-id]-delivery.md`\n**Creates directory:** `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F` if it does not exist\n**Naming convention:** Combines the capability area slug with the lowercase ticket ID (e.g., `search-and-retrieval-ticket-001-delivery.md`)\n\nThe delivery record is the bridge between pipeline artifacts and the real codebase. Downstream skills (reviews, audits, orchestrate) read delivery records to locate implemented code.\n\nThe record is **written early and updated as the delivery progresses** — first after reconciliation (`Status: Reconciled`), again the moment the plan is approved (`Status: In Progress`, plan preserved verbatim, a `## Progress` checklist), and finally when the code is verified (`Status: Delivered`). Nothing the user approved lives only in the conversation; a compaction or a new session resumes from the record.\n\nDelivery also appends rows to the living specification's `## @spec Coverage` table (`.gener8v\u002Fspecifications\u002F[capability-area-slug].md`) for every requirement it annotated, with root-relative code locations — that section is promised by the Specification skill and this is the skill that keeps the promise.\n\n## Output Format\n\nWrite the delivery record in the shape of `assets\u002Fdelivery-record.md`. Read it before creating the record and follow it exactly, headings and status lines included: `gener8v-state.py` parses the `**Status:**`, `**Verification:**` and `**Reviews Deferred:**` lines and whether `## Post-Review Amendments` holds anything other than `None`, and the plugin's hooks look for `**Status:** In Progress`. A record that drifts from the shape is misread by both.\n\n---\n\n## Principles\n\n### Reconcile Against Ground Truth Before Planning\nA ticket's assumptions are claims to verify, not facts to trust. Before drafting the implementation plan, check every assumption the ticket depends on against the actual repository: do the schema objects it references (tables, columns, enums, constraints) exist in the schema\u002Fmigrations? Do the files, scripts, and commands it invokes exist? Is every document in Prior Art \u002F Required Reading present at the pinned version? Did predecessor tickets actually produce the outputs this ticket builds on? Resolve from the code what the code can answer — and note where the answer closes an open question the ticket left for the user (e.g., a \"Decision Point\" that the existing schema already settles). If a *blocking* assumption is false (a required table is missing, a referenced script does not exist, a pinned doc is absent), stop and report — set delivery status to **Blocked** with the reconciliation findings, and do not proceed to planning. The \"build-on-existing-schema\" premise is the most common silent failure; verify it explicitly.\n\n### Checkpoint the Record\nThe delivery record is not a report written at the end; it is the ticket's working memory. Reconciliation results go in as soon as they exist, the plan goes in the moment it is approved, progress is ticked as files land. If the context is compacted or the session ends mid-implementation, the next session opens the record and continues — it never has to reconstruct a plan the user already approved, and never re-asks for approval.\n\n### Verified, Not Inspected\nAn acceptance criterion is satisfied when an executed check proves it — a test, a type-check, a build, a query — and the Verification Run records the command and its exit code. Reading the code and finding it plausible is not verification. A criterion with no executed evidence is recorded as Unverified, not ticked. The same rule covers the NFRs a ticket carries: where the specification's verification method is executable (a benchmark, a load test, a lint) it runs in the Verification Run; where it is not, the NFR is Unverified with what would verify it.\n\n### Plan Before You Build\nNever start writing code without presenting the implementation plan to the user first. The plan describes which files will be created or modified, what each will contain, and how acceptance criteria will be met. User approval is the gate between planning and execution. This prevents wasted effort and ensures alignment before code is written. The approval is recorded, not just given: the record carries `**Plan approved by:** Engineer — \u003Cname>, YYYY-MM-DD`. One person may hold every role; the record still names the role, so a reader knows which hat approved the plan.\n\n### Prior Art Is Your Context Window\nRead everything the ticket's Prior Art section points to before planning. For first tickets in a chain, this means pipeline documents (specifications, constraints, technical design). For later tickets, this means the actual code files produced by predecessor tickets plus their delivery records. Do not guess what predecessor tickets produced — read the actual files.\n\n### Output Is Your Contract\nThe ticket's Output section declares what files this delivery produces. Downstream tickets reference those files in their Prior Art. Deliver exactly what was promised — same file paths, same exposed interfaces. If the implementation must diverge from the declared output, document the deviation and its impact on downstream tickets.\n\n### Acceptance Criteria Are Done\nA ticket is delivered when all acceptance criteria are satisfied. Not when the code compiles. Not when it looks right. Not when most criteria are met. Each criterion must be verifiable against the delivered code, and the delivery record must show how each was satisfied.\n\n### Decisions Are First-Class\nImplementation always surfaces decisions not anticipated by the ticket or technical design. A library choice, an error handling strategy, a data structure selection — these are implementation-time decisions that affect downstream work. Record every non-trivial decision with context and rationale using DEL-XXX IDs. These are the implementation-time equivalent of Architecture Decisions (AD-XXX).\n\n### Deviations Are Expected, Not Failures\nReal implementation often diverges from the plan. A dependency behaves differently than expected, an approach proves impractical, a better solution emerges during coding. The delivery record documents what changed and why. Deviations are information for downstream tickets and reviews, not defects.\n\n### Annotate for Traceability\nEvery function, class, method, or handler that implements a requirement gets an `@spec` annotation comment linking it to the requirement IDs it satisfies. Use the language's native comment syntax:\n\n```python\n# @spec SR-REQ-001, SR-REQ-002\ndef process_query(text):\n```\n\n```typescript\n\u002F\u002F @spec SR-REQ-001, SR-REQ-002\nfunction processQuery(text: string) {\n```\n\nPlace annotations on the line immediately above the declaration. One annotation per code location, listing all requirement IDs implemented there. A requirement may appear in multiple annotations if it is implemented across multiple locations. These annotations make traceability greppable (`grep -r \"@spec\" src\u002F`) and survive beyond the review phase — any developer can trace code back to requirements without consulting pipeline artifacts.\n\n### Predecessors' Reviews Are Prior Art Too\nA finding a review deferred \"to the next ticket\", and a risk it accepted on a file this ticket will edit, are part of this ticket's context. Read the predecessor reviews, list carried findings in the reconciliation table, and address or consciously carry each one.\n\n### Stay in Your Lane\nOnly implement what this ticket specifies. Do not refactor adjacent code, add unrequested features, or \"fix\" things you notice in predecessor output. If something needs attention, note it in the delivery record — it belongs in a separate ticket. Scope discipline prevents one ticket from silently changing the foundation that other tickets depend on.\n\n## Process\n\n1. **Locate the Ticket**: Resolve the change — the one named in the argument, else the single active change, else ask. Open `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Ccapability-area-slug>\u002FTICKET-XXX.md` — the whole ticket is that one file; there is nothing to extract. Confirm that its `**Change:**`, `**Capability Area:**` and `**Specification:**` header lines match the target. Read the sibling `backlog.md` for the dependency chain and suggested ordering. Read the change brief for its Status and Priority Cut; a delivery started from a `Draft` brief proceeds, and the record's `**Change:**` line says so (Audit raises a Warning, never a block).\n\n2. **Check Prerequisites**: Verify that all tickets listed in the Depends On field — sibling `TICKET-XXX.md` files in the same directory — have delivery records in `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fdelivery\u002F`. If any are missing, warn the user that Prior Art references may point to files that do not exist.\n\n3. **Read Prior Art**: Follow every item in the ticket's Prior Art section. Read pipeline documents (specifications, constraints, technical design). Read predecessor delivery records and the actual code files they produced. Read system context if available.\n\n4. **Read Technical Design**: If a technical design exists for this capability area, read it for architecture decisions (AD-XXX) that affect this ticket's implementation.\n\n5. **Reconcile Ticket Assumptions Against Ground Truth**: Before planning, verify every assumption the ticket depends on against the actual repository. Read the schema\u002Fmigrations to confirm referenced tables, columns, enums, and constraints exist; confirm that scripts and commands the ticket invokes are present; confirm every Prior Art \u002F Required Reading document exists at the pinned version; confirm predecessor tickets produced the outputs declared in their Output sections; list findings the predecessor reviews deferred to this ticket or risks they accepted on files this ticket touches. Build the Pre-Flight Reconciliation table. Where the code answers a question the ticket left open (e.g., a Decision Point the existing schema already settles), record it as resolved rather than escalating it. **Write the delivery record now** — Ticket Reference and Pre-Flight Reconciliation, `Status: Reconciled` on a Go verdict. **Gate:** if any *blocking* assumption is false, set status to **Blocked**, report to the user, and stop — do not proceed to planning. Only a **Go** verdict continues.\n\n6. **Draft Implementation Plan**: Produce a plan that covers:\n   - Every file to be created or modified (aligned with the ticket's Output section)\n   - What each file will contain (modules, functions, classes, configuration)\n   - How each acceptance criterion will be satisfied\n   - Any decisions or trade-offs identified during planning\n   - Any constraints from the ticket that shape the implementation\n   - The repository the code lands in, from `context.md`'s `## Repositories` table (`.` when there is one); a ticket that touches two repositories is two tickets unless the change is atomic, in which case the plan names both and the record will list both commits\n\n7. **Present Plan to User**: Show the implementation plan and wait for explicit approval. The user may:\n   - **Approve**: Proceed to implementation\n   - **Modify**: Adjust the plan based on user feedback, then re-present\n   - **Reject**: Do not proceed; discuss alternative approaches\n\n   On approval, **append the plan verbatim to the delivery record**, record `**Plan approved by:** Engineer — \u003Cname>, YYYY-MM-DD`, add the `## Progress` checklist (one line per planned file), and set `Status: In Progress`. From this point the record — not the conversation — is the authority for what is being built.\n\n8. **Implement, on the ticket's route**: Write the actual code files as described in the approved plan. Follow the technical design's architecture decisions. Respect constraints referenced in the ticket (PRD-level and area-level). Produce the files declared in the ticket's Output section — including the test files the ticket lists. Tick each file in `## Progress` as it lands.\n\n   Route the writing first (CONVENTIONS §13). The ticket's kind is `deliver-small` when its Size is Small, or Medium with no Known Hazards and no compliance constraint (CC-XXX); otherwise `deliver-large`. When the route names a model other than `inherit`, hand the writing to a `general-purpose` subagent on that model and effort: give it the approved plan verbatim, the record's path, the files and Prior Art it needs, and the instruction to write the planned files, tick `## Progress`, and stop without running the verification or finalizing the record. Steps 9–15 stay in the main session, which reads the files the subagent wrote before it annotates, verifies or commits anything. When the route is `inherit`, write the code in the main session as before. Record which model wrote the code in the record's `**Implemented by:**` line (`\u003Cmodel> · \u003Ceffort> — routed as \u003Ckind> from Tower` or `from the defaults`, or `the session's model`).\n\n9. **Add `@spec` Annotations**: For each function, class, method, or handler that implements a requirement from the ticket's Requirements Covered list, add an `@spec` annotation comment on the line immediately above the declaration. List all requirement IDs that the code location satisfies. If a requirement is implemented across multiple locations, annotate each one.\n\n10. **Run Verification**: Execute the named repository's checks — tests, type-check, lint, build — using the Verify commands from its row in `context.md`'s `## Repositories` table or the repository's own scripts (`package.json` scripts, `Makefile`, `pyproject.toml`, CI configuration). Run every NFR check the ticket carries that is executable (a benchmark against a latency target, a log-format test, an accessibility lint) using the method the specification names. Record every command with its exit code in `## Verification Run`. A failing check is fixed or the delivery is `Partial`; it is never omitted. Set `**Verification:**` accordingly.\n\n11. **Verify Acceptance Criteria**: Walk through each acceptance criterion from the ticket, including the verification method listed for each NFR it carries. Tick it only when an executed check from the Verification Run proves it, and cite that check. A criterion the code implements but no executed check covers is recorded as Unverified; a non-executable NFR is Unverified with what would verify it.\n\n12. **Record Decisions**: Document any implementation decisions made during coding as DEL-XXX entries with context, decision, rationale, and ticket impact.\n\n13. **Record Deviations**: Compare the delivered implementation against the approved plan. Document anything that changed and why. If the Output files differ from what the ticket declared, note the impact on downstream tickets.\n\n14. **Finalize the Delivery Record**: Fill Delivery Summary, Acceptance Criteria Verification, Decisions, Deviations and `@spec` Annotations; set `Status: Delivered` (or `Partial`). Then append one row per annotated requirement to the living specification's `## @spec Coverage` table (create the section if it is absent), with root-relative code locations, so the specification shows where each requirement lives in code.\n\n15. **Commit Together**: Commit in the repository named in the plan — the delivered code and the delivery record in the same commit (a branch per ticket is the recommended boundary; the record's file name is the natural commit subject). An atomic ticket spanning two repositories commits in each and the record lists both commits. Do not push or open a pull request unless the user asks. The three reviews are the pipeline's review of the change; a repository's own PR review, if any, sits on top of them.\n\n## Example\n\nA full delivery of `support-search\u002Fsearch-and-retrieval\u002FTICKET-001` (query input, SR-REQ-001..003): the ticket as read from its own file, the plan presented for approval with its repository and approval line, and the finished record — reconciliation, verification run, criteria verification, a DEL decision and `@spec` annotations.\n\nIt is at `skills\u002Fdelivery\u002Freferences\u002Fexample.md`.\nRead it before producing your first artifact of this kind.\n\n---\n\n## Troubleshooting\n\n- **Pre-Flight Reconciliation finds a blocking assumption false.** The ticket was written against a repository that does not exist yet — a missing table, script or pinned document. The record says `Blocked` with what must exist first; the fix is upstream, not in this delivery: deliver the predecessor that produces it, or amend the ticket through Ticket Breakdown (an Audit in reconciliation mode checks the amended ticket before the next attempt). Never build the missing prerequisite inside this ticket — that is the scope creep the gate exists to stop.\n- **Context was compacted, or the session ended, mid-delivery.** The plugin's SessionStart hook says so and points at the record. Re-read its Pre-Flight Reconciliation and approved Implementation Plan, continue from the first unticked line in `## Progress`, and do not re-plan or ask for approval again — the approval is already recorded.\n- **The turn is sent back because source changed after the record was last updated.** The plugin's Stop hook saw a delivery `In Progress` and source files newer than its record. Tick `## Progress`, add any DEL-XXX decision or deviation the change implies, then finish. If the change is not part of this delivery (a trivial fix alongside it), say so in the reply; the hook sends a turn back only once.\n- **Writing code raises \"no delivery is In Progress\".** The plugin's PreToolUse hook looks for the exact line `**Status:** In Progress` in a delivery record. Either the plan's approval was never recorded (the record still says `Reconciled` — do step 7 first) or the status line was reworded; restore it to the template's form.\n- **A verification check fails for a reason outside the ticket.** A pre-existing failing test or lint rule is still recorded in `## Verification Run` with its exit code, `**Verification:** failed`, and the delivery is `Partial` with the cause named. Fixing adjacent code is a separate ticket, not this one.\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Planning Skill**: Opens the change whose brief (`changes\u002F\u003Cchange-slug>\u002Fchange.md`) scopes the ticket — its Priority Cut and approval status\n- **Ticket Breakdown Skill**: Provides the ticket file that defines what to implement — summary, priority, value, requirements (REQ and NFR), Prior Art, acceptance criteria, output, constraints, and dependencies — and the area's `backlog.md` for ordering\n- **Technical Design Skill**: Provides architecture decisions (AD-XXX) that guide implementation choices\n- **Specification Skill**: Provides requirement detail referenced in Prior Art\n- **Constraints Skill**: Provides constraints referenced in the ticket\n- **Dependencies Skill**: Provides sequencing information consumed via ticket dependencies\n\n**Downstream:**\n- **Code Review Skill**: Reviews the delivered code against pipeline artifacts (acceptance criteria, requirements, constraints, architecture decisions)\n- **Quality Review Skill**: Reviews the delivered code for engineering quality\n- **Security Review Skill**: Reviews the delivered code for security vulnerabilities\n- **Delivery Skill** (subsequent runs): Later tickets reference this delivery's output in their Prior Art and read this ticket's reviews for carried findings\n- **Orchestrate \u002F hooks**: read `Status`, `Verification` and `Reviews Deferred` from the record; a ticket is `done` only when Delivered, verified, and approved-or-deferred by every review\n\n## Revisions\n\n- A delivery record is written progressively during the delivery (Reconciled → In Progress → Delivered) and is append-only afterwards: reviews add `## Post-Review Amendments` entries; nothing above that section is rewritten\n- If the ticket's requirements change after delivery, create a new ticket for the changes rather than modifying the delivery record\n- If a review identifies issues, the fixes are applied in that review's resolution phase and recorded under `## Post-Review Amendments` (with re-verification), or a follow-up ticket is created\n- Delivery records in `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fdelivery\u002F` are permanent artifacts for traceability\n\n## Notes\n\n- This skill is unique in the pipeline: it writes to the real codebase, not just `.gener8v\u002F`\n- The delivery record is the bridge between pipeline artifacts (all in `.gener8v\u002F`) and actual code files\n- One delivery per ticket — do not batch multiple tickets into a single delivery\n- If a ticket is sized Large, consider whether it should have been split during Ticket Breakdown rather than delivering a monolithic implementation\n- The `{ext}` placeholder in ticket Output sections should be resolved during implementation planning based on the system context and technology stack\n- When system context (`.gener8v\u002Fcontext.md`) is available, use it to inform language, framework, and convention choices; its `## Repositories` table is where the plan's repository and the Verification Run's commands come from — in a workspace of several repositories every path in the record stays root-relative (`api\u002Fsrc\u002Fsearch\u002Fquery.ts`)\n- Delivery status values: **Reconciled** (pre-flight Go, plan not yet approved), **In Progress** (plan approved, code being written), **Delivered** (all acceptance criteria verified), **Partial** (some criteria met, others blocked), **Blocked** (cannot proceed — including a failed Pre-Flight Reconciliation: a missing table\u002Fcolumn\u002Fscript or an absent pinned document means the ticket is blocked before planning, with the reconciliation findings naming what must exist first)\n- A project whose `tickets\u002F`, `delivery\u002F` and `reviews\u002F*-review.md` still sit at the top level of `.gener8v\u002F` is the legacy pseudo-change `initial`; read from there if that is where the ticket is, but never write a new record to the legacy location — Orchestrate recommends the one-time migration\n- With the plugin installed, a `PreToolUse` hook reminds the model when source is edited while no delivery record is `In Progress`, and the `SessionStart` hook points a resumed or compacted session at the in-flight record\n","# Delivery Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which ticket (capability area + TICKET-XXX) to deliver before doing anything else. The ticket belongs to a change: when exactly one change is active (status `ready` or `in_delivery` in `pipeline-state.yaml`), default to it; when several are active and the argument does not name one (`in \u003Cchange-slug>`), ask which. Never guess the target.\n\n## Purpose\n\nTake a single ticket from a ticket breakdown and implement it. This skill operates in three phases: first **reconciling** the ticket's stated assumptions against the actual codebase, then producing an **implementation plan** for user approval, then **executing** the plan by writing actual code. It is the only skill in the pipeline that writes to the real codebase — all other skills produce markdown artifacts in `.gener8v\u002F`. The delivery record captures what was reconciled, what was planned, what was built, what decisions were made, and where the implementation diverged from the plan.\n\nReconciliation comes first because a ticket — however well-specified — encodes *assumptions* about the codebase it will build on: that a table or column exists, that a script or command is available, that a referenced document is present at the pinned version, that a predecessor's output is where it claims to be. When those assumptions are wrong, the most expensive outcome is discovering it mid-build (or worse, building confidently on top of the wrong foundation). Verifying them against ground truth *before* planning turns a runtime failure into a cheap pre-flight finding.\n\n## When to Use\n\nUse this skill when:\n- A ticket file under `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Ccapability-area-slug>\u002F` is ready for implementation (no unresolved blockers in its Depends On field)\n- The user wants to implement a specific ticket\n- All predecessor tickets (from the Depends On field) have been delivered\n- The team is ready to move from planning artifacts to working code\n\n## Input\n\n**Source:** A single ticket from a ticket breakdown, plus all pipeline artifacts referenced in the ticket's Prior Art\n**Read from:**\n- Ticket: `.gener8v\u002Fchanges\u002F[change-slug]\u002Ftickets\u002F[capability-area-slug]\u002FTICKET-XXX.md` — one ticket, one file; there is no extraction step. Its `**Change:**`, `**Capability Area:**` and `**Specification:**` header lines confirm the target\n- Backlog: `.gener8v\u002Fchanges\u002F[change-slug]\u002Ftickets\u002F[capability-area-slug]\u002Fbacklog.md` — the dependency chain and suggested ordering this ticket sits in\n- Predecessor tickets (from the Depends On field): sibling `TICKET-XXX.md` files in the same directory\n- Change brief: `.gener8v\u002Fchanges\u002F[change-slug]\u002Fchange.md` — its Status (Draft or Approved) and Priority Cut\n- Prior Art as declared in the ticket (pipeline documents and predecessor ticket outputs)\n- Technical Design: `.gener8v\u002Ftechnical-design\u002F[capability-area-slug].md` or `.gener8v\u002Ftechnical-design\u002Fsystem-design.md` (if available)\n- Constraints: `.gener8v\u002Fconstraints\u002Fprd.md` and `.gener8v\u002Fconstraints\u002F[capability-area-slug].md` (whichever exist — PRD-level constraints apply to every ticket)\n- System Context: `.gener8v\u002Fcontext.md` (if available — its `## Repositories` table names each repository's directory and verify commands; its testing and build sections add detail)\n- Conventions: `.gener8v\u002FCONVENTIONS.md`\n- Predecessor delivery records: `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F*-delivery.md` (for dependent tickets), including their `## Post-Review Amendments`\n- Predecessor review reports: `.gener8v\u002Fchanges\u002F[change-slug]\u002Freviews\u002F*-{code,quality,security}-review.md` for every ticket in Depends On and for any predecessor whose Files Produced overlap this ticket's Output — findings deferred \"to the next ticket\" and accepted risks live there. Predecessors normally sit under the same change; a dependency on an earlier change's ticket is read from that change's directory\n- Existing codebase files referenced in Prior Art\n\n**Expects:** A ticket file opening with `# TICKET-XXX: title` and the three header lines, then Summary, Priority, Value, Requirements Covered, Prior Art, Acceptance Criteria, Output, Constraints, and Size fields. Predecessor tickets in the Depends On field should have delivery records.\n\n**If input is missing or malformed:**\n- If several changes are active and none is named, ask which one before reading anything\n- If no `tickets\u002F\u003Ccapability-area-slug>\u002FTICKET-XXX.md` exists for the target under the change, stop and recommend running the Ticket Breakdown skill first (`ticket-breakdown \u003Carea> for \u003Cchange-slug>`)\n- Legacy: if the area's tickets exist only as a per-area file `tickets\u002F\u003Ccapability-area-slug>.md` holding `### TICKET-NNN:` sections, recommend `python3 ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgener8v-state.py split-tickets` and deliver from the resulting ticket file — never from the legacy shape\n- If predecessor tickets have not been delivered, warn the user — the ticket's Prior Art may reference files that do not yet exist\n- If technical design or constraints are missing, proceed but note the gap — implementation decisions may lack architectural context\n\n## Output\n\n**Produces:** Two things:\n1. The actual code files declared in the ticket's Output section (written to the real codebase)\n2. A delivery record documenting what was planned, built, and decided\n\n**Write to:** `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F[capability-area-slug]-[ticket-id]-delivery.md`\n**Creates directory:** `.gener8v\u002Fchanges\u002F[change-slug]\u002Fdelivery\u002F` if it does not exist\n**Naming convention:** Combines the capability area slug with the lowercase ticket ID (e.g., `search-and-retrieval-ticket-001-delivery.md`)\n\nThe delivery record is the bridge between pipeline artifacts and the real codebase. Downstream skills (reviews, audits, orchestrate) read delivery records to locate implemented code.\n\nThe record is **written early and updated as the delivery progresses** — first after reconciliation (`Status: Reconciled`), again the moment the plan is approved (`Status: In Progress`, plan preserved verbatim, a `## Progress` checklist), and finally when the code is verified (`Status: Delivered`). Nothing the user approved lives only in the conversation; a compaction or a new session resumes from the record.\n\nDelivery also appends rows to the living specification's `## @spec Coverage` table (`.gener8v\u002Fspecifications\u002F[capability-area-slug].md`) for every requirement it annotated, with root-relative code locations — that section is promised by the Specification skill and this is the skill that keeps the promise.\n\n## Output Format\n\nWrite the delivery record in the shape of `assets\u002Fdelivery-record.md`. Read it before creating the record and follow it exactly, headings and status lines included: `gener8v-state.py` parses the `**Status:**`, `**Verification:**` and `**Reviews Deferred:**` lines and whether `## Post-Review Amendments` holds anything other than `None`, and the plugin's hooks look for `**Status:** In Progress`. A record that drifts from the shape is misread by both.\n\n---\n\n## Principles\n\n### Reconcile Against Ground Truth Before Planning\nA ticket's assumptions are claims to verify, not facts to trust. Before drafting the implementation plan, check every assumption the ticket depends on against the actual repository: do the schema objects it references (tables, columns, enums, constraints) exist in the schema\u002Fmigrations? Do the files, scripts, and commands it invokes exist? Is every document in Prior Art \u002F Required Reading present at the pinned version? Did predecessor tickets actually produce the outputs this ticket builds on? Resolve from the code what the code can answer — and note where the answer closes an open question the ticket left for the user (e.g., a \"Decision Point\" that the existing schema already settles). If a *blocking* assumption is false (a required table is missing, a referenced script does not exist, a pinned doc is absent), stop and report — set delivery status to **Blocked** with the reconciliation findings, and do not proceed to planning. The \"build-on-existing-schema\" premise is the most common silent failure; verify it explicitly.\n\n### Checkpoint the Record\nThe delivery record is not a report written at the end; it is the ticket's working memory. Reconciliation results go in as soon as they exist, the plan goes in the moment it is approved, progress is ticked as files land. If the context is compacted or the session ends mid-implementation, the next session opens the record and continues — it never has to reconstruct a plan the user already approved, and never re-asks for approval.\n\n### Verified, Not Inspected\nAn acceptance criterion is satisfied when an executed check proves it — a test, a type-check, a build, a query — and the Verification Run records the command and its exit code. Reading the code and finding it plausible is not verification. A criterion with no executed evidence is recorded as Unverified, not ticked. The same rule covers the NFRs a ticket carries: where the specification's verification method is executable (a benchmark, a load test, a lint) it runs in the Verification Run; where it is not, the NFR is Unverified with what would verify it.\n\n### Plan Before You Build\nNever start writing code without presenting the implementation plan to the user first. The plan describes which files will be created or modified, what each will contain, and how acceptance criteria will be met. User approval is the gate between planning and execution. This prevents wasted effort and ensures alignment before code is written. The approval is recorded, not just given: the record carries `**Plan approved by:** Engineer — \u003Cname>, YYYY-MM-DD`. One person may hold every role; the record still names the role, so a reader knows which hat approved the plan.\n\n### Prior Art Is Your Context Window\nRead everything the ticket's Prior Art section points to before planning. For first tickets in a chain, this means pipeline documents (specifications, constraints, technical design). For later tickets, this means the actual code files produced by predecessor tickets plus their delivery records. Do not guess what predecessor tickets produced — read the actual files.\n\n### Output Is Your Contract\nThe ticket's Output section declares what files this delivery produces. Downstream tickets reference those files in their Prior Art. Deliver exactly what was promised — same file paths, same exposed interfaces. If the implementation must diverge from the declared output, document the deviation and its impact on downstream tickets.\n\n### Acceptance Criteria Are Done\nA ticket is delivered when all acceptance criteria are satisfied. Not when the code compiles. Not when it looks right. Not when most criteria are met. Each criterion must be verifiable against the delivered code, and the delivery record must show how each was satisfied.\n\n### Decisions Are First-Class\nImplementation always surfaces decisions not anticipated by the ticket or technical design. A library choice, an error handling strategy, a data structure selection — these are implementation-time decisions that affect downstream work. Record every non-trivial decision with context and rationale using DEL-XXX IDs. These are the implementation-time equivalent of Architecture Decisions (AD-XXX).\n\n### Deviations Are Expected, Not Failures\nReal implementation often diverges from the plan. A dependency behaves differently than expected, an approach proves impractical, a better solution emerges during coding. The delivery record documents what changed and why. Deviations are information for downstream tickets and reviews, not defects.\n\n### Annotate for Traceability\nEvery function, class, method, or handler that implements a requirement gets an `@spec` annotation comment linking it to the requirement IDs it satisfies. Use the language's native comment syntax:\n\n```python\n# @spec SR-REQ-001, SR-REQ-002\ndef process_query(text):\n```\n\n```typescript\n\u002F\u002F @spec SR-REQ-001, SR-REQ-002\nfunction processQuery(text: string) {\n```\n\nPlace annotations on the line immediately above the declaration. One annotation per code location, listing all requirement IDs implemented there. A requirement may appear in multiple annotations if it is implemented across multiple locations. These annotations make traceability greppable (`grep -r \"@spec\" src\u002F`) and survive beyond the review phase — any developer can trace code back to requirements without consulting pipeline artifacts.\n\n### Predecessors' Reviews Are Prior Art Too\nA finding a review deferred \"to the next ticket\", and a risk it accepted on a file this ticket will edit, are part of this ticket's context. Read the predecessor reviews, list carried findings in the reconciliation table, and address or consciously carry each one.\n\n### Stay in Your Lane\nOnly implement what this ticket specifies. Do not refactor adjacent code, add unrequested features, or \"fix\" things you notice in predecessor output. If something needs attention, note it in the delivery record — it belongs in a separate ticket. Scope discipline prevents one ticket from silently changing the foundation that other tickets depend on.\n\n## Process\n\n1. **Locate the Ticket**: Resolve the change — the one named in the argument, else the single active change, else ask. Open `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Ccapability-area-slug>\u002FTICKET-XXX.md` — the whole ticket is that one file; there is nothing to extract. Confirm that its `**Change:**`, `**Capability Area:**` and `**Specification:**` header lines match the target. Read the sibling `backlog.md` for the dependency chain and suggested ordering. Read the change brief for its Status and Priority Cut; a delivery started from a `Draft` brief proceeds, and the record's `**Change:**` line says so (Audit raises a Warning, never a block).\n\n2. **Check Prerequisites**: Verify that all tickets listed in the Depends On field — sibling `TICKET-XXX.md` files in the same directory — have delivery records in `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fdelivery\u002F`. If any are missing, warn the user that Prior Art references may point to files that do not exist.\n\n3. **Read Prior Art**: Follow every item in the ticket's Prior Art section. Read pipeline documents (specifications, constraints, technical design). Read predecessor delivery records and the actual code files they produced. Read system context if available.\n\n4. **Read Technical Design**: If a technical design exists for this capability area, read it for architecture decisions (AD-XXX) that affect this ticket's implementation.\n\n5. **Reconcile Ticket Assumptions Against Ground Truth**: Before planning, verify every assumption the ticket depends on against the actual repository. Read the schema\u002Fmigrations to confirm referenced tables, columns, enums, and constraints exist; confirm that scripts and commands the ticket invokes are present; confirm every Prior Art \u002F Required Reading document exists at the pinned version; confirm predecessor tickets produced the outputs declared in their Output sections; list findings the predecessor reviews deferred to this ticket or risks they accepted on files this ticket touches. Build the Pre-Flight Reconciliation table. Where the code answers a question the ticket left open (e.g., a Decision Point the existing schema already settles), record it as resolved rather than escalating it. **Write the delivery record now** — Ticket Reference and Pre-Flight Reconciliation, `Status: Reconciled` on a Go verdict. **Gate:** if any *blocking* assumption is false, set status to **Blocked**, report to the user, and stop — do not proceed to planning. Only a **Go** verdict continues.\n\n6. **Draft Implementation Plan**: Produce a plan that covers:\n   - Every file to be created or modified (aligned with the ticket's Output section)\n   - What each file will contain (modules, functions, classes, configuration)\n   - How each acceptance criterion will be satisfied\n   - Any decisions or trade-offs identified during planning\n   - Any constraints from the ticket that shape the implementation\n   - The repository the code lands in, from `context.md`'s `## Repositories` table (`.` when there is one); a ticket that touches two repositories is two tickets unless the change is atomic, in which case the plan names both and the record will list both commits\n\n7. **Present Plan to User**: Show the implementation plan and wait for explicit approval. The user may:\n   - **Approve**: Proceed to implementation\n   - **Modify**: Adjust the plan based on user feedback, then re-present\n   - **Reject**: Do not proceed; discuss alternative approaches\n\n   On approval, **append the plan verbatim to the delivery record**, record `**Plan approved by:** Engineer — \u003Cname>, YYYY-MM-DD`, add the `## Progress` checklist (one line per planned file), and set `Status: In Progress`. From this point the record — not the conversation — is the authority for what is being built.\n\n8. **Implement, on the ticket's route**: Write the actual code files as described in the approved plan. Follow the technical design's architecture decisions. Respect constraints referenced in the ticket (PRD-level and area-level). Produce the files declared in the ticket's Output section — including the test files the ticket lists. Tick each file in `## Progress` as it lands.\n\n   Route the writing first (CONVENTIONS §13). The ticket's kind is `deliver-small` when its Size is Small, or Medium with no Known Hazards and no compliance constraint (CC-XXX); otherwise `deliver-large`. When the route names a model other than `inherit`, hand the writing to a `general-purpose` subagent on that model and effort: give it the approved plan verbatim, the record's path, the files and Prior Art it needs, and the instruction to write the planned files, tick `## Progress`, and stop without running the verification or finalizing the record. Steps 9–15 stay in the main session, which reads the files the subagent wrote before it annotates, verifies or commits anything. When the route is `inherit`, write the code in the main session as before. Record which model wrote the code in the record's `**Implemented by:**` line (`\u003Cmodel> · \u003Ceffort> — routed as \u003Ckind> from Tower` or `from the defaults`, or `the session's model`).\n\n9. **Add `@spec` Annotations**: For each function, class, method, or handler that implements a requirement from the ticket's Requirements Covered list, add an `@spec` annotation comment on the line immediately above the declaration. List all requirement IDs that the code location satisfies. If a requirement is implemented across multiple locations, annotate each one.\n\n10. **Run Verification**: Execute the named repository's checks — tests, type-check, lint, build — using the Verify commands from its row in `context.md`'s `## Repositories` table or the repository's own scripts (`package.json` scripts, `Makefile`, `pyproject.toml`, CI configuration). Run every NFR check the ticket carries that is executable (a benchmark against a latency target, a log-format test, an accessibility lint) using the method the specification names. Record every command with its exit code in `## Verification Run`. A failing check is fixed or the delivery is `Partial`; it is never omitted. Set `**Verification:**` accordingly.\n\n11. **Verify Acceptance Criteria**: Walk through each acceptance criterion from the ticket, including the verification method listed for each NFR it carries. Tick it only when an executed check from the Verification Run proves it, and cite that check. A criterion the code implements but no executed check covers is recorded as Unverified; a non-executable NFR is Unverified with what would verify it.\n\n12. **Record Decisions**: Document any implementation decisions made during coding as DEL-XXX entries with context, decision, rationale, and ticket impact.\n\n13. **Record Deviations**: Compare the delivered implementation against the approved plan. Document anything that changed and why. If the Output files differ from what the ticket declared, note the impact on downstream tickets.\n\n14. **Finalize the Delivery Record**: Fill Delivery Summary, Acceptance Criteria Verification, Decisions, Deviations and `@spec` Annotations; set `Status: Delivered` (or `Partial`). Then append one row per annotated requirement to the living specification's `## @spec Coverage` table (create the section if it is absent), with root-relative code locations, so the specification shows where each requirement lives in code.\n\n15. **Commit Together**: Commit in the repository named in the plan — the delivered code and the delivery record in the same commit (a branch per ticket is the recommended boundary; the record's file name is the natural commit subject). An atomic ticket spanning two repositories commits in each and the record lists both commits. Do not push or open a pull request unless the user asks. The three reviews are the pipeline's review of the change; a repository's own PR review, if any, sits on top of them.\n\n## Example\n\nA full delivery of `support-search\u002Fsearch-and-retrieval\u002FTICKET-001` (query input, SR-REQ-001..003): the ticket as read from its own file, the plan presented for approval with its repository and approval line, and the finished record — reconciliation, verification run, criteria verification, a DEL decision and `@spec` annotations.\n\nIt is at `skills\u002Fdelivery\u002Freferences\u002Fexample.md`.\nRead it before producing your first artifact of this kind.\n\n---\n\n## Troubleshooting\n\n- **Pre-Flight Reconciliation finds a blocking assumption false.** The ticket was written against a repository that does not exist yet — a missing table, script or pinned document. The record says `Blocked` with what must exist first; the fix is upstream, not in this delivery: deliver the predecessor that produces it, or amend the ticket through Ticket Breakdown (an Audit in reconciliation mode checks the amended ticket before the next attempt). Never build the missing prerequisite inside this ticket — that is the scope creep the gate exists to stop.\n- **Context was compacted, or the session ended, mid-delivery.** The plugin's SessionStart hook says so and points at the record. Re-read its Pre-Flight Reconciliation and approved Implementation Plan, continue from the first unticked line in `## Progress`, and do not re-plan or ask for approval again — the approval is already recorded.\n- **The turn is sent back because source changed after the record was last updated.** The plugin's Stop hook saw a delivery `In Progress` and source files newer than its record. Tick `## Progress`, add any DEL-XXX decision or deviation the change implies, then finish. If the change is not part of this delivery (a trivial fix alongside it), say so in the reply; the hook sends a turn back only once.\n- **Writing code raises \"no delivery is In Progress\".** The plugin's PreToolUse hook looks for the exact line `**Status:** In Progress` in a delivery record. Either the plan's approval was never recorded (the record still says `Reconciled` — do step 7 first) or the status line was reworded; restore it to the template's form.\n- **A verification check fails for a reason outside the ticket.** A pre-existing failing test or lint rule is still recorded in `## Verification Run` with its exit code, `**Verification:** failed`, and the delivery is `Partial` with the cause named. Fixing adjacent code is a separate ticket, not this one.\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Planning Skill**: Opens the change whose brief (`changes\u002F\u003Cchange-slug>\u002Fchange.md`) scopes the ticket — its Priority Cut and approval status\n- **Ticket Breakdown Skill**: Provides the ticket file that defines what to implement — summary, priority, value, requirements (REQ and NFR), Prior Art, acceptance criteria, output, constraints, and dependencies — and the area's `backlog.md` for ordering\n- **Technical Design Skill**: Provides architecture decisions (AD-XXX) that guide implementation choices\n- **Specification Skill**: Provides requirement detail referenced in Prior Art\n- **Constraints Skill**: Provides constraints referenced in the ticket\n- **Dependencies Skill**: Provides sequencing information consumed via ticket dependencies\n\n**Downstream:**\n- **Code Review Skill**: Reviews the delivered code against pipeline artifacts (acceptance criteria, requirements, constraints, architecture decisions)\n- **Quality Review Skill**: Reviews the delivered code for engineering quality\n- **Security Review Skill**: Reviews the delivered code for security vulnerabilities\n- **Delivery Skill** (subsequent runs): Later tickets reference this delivery's output in their Prior Art and read this ticket's reviews for carried findings\n- **Orchestrate \u002F hooks**: read `Status`, `Verification` and `Reviews Deferred` from the record; a ticket is `done` only when Delivered, verified, and approved-or-deferred by every review\n\n## Revisions\n\n- A delivery record is written progressively during the delivery (Reconciled → In Progress → Delivered) and is append-only afterwards: reviews add `## Post-Review Amendments` entries; nothing above that section is rewritten\n- If the ticket's requirements change after delivery, create a new ticket for the changes rather than modifying the delivery record\n- If a review identifies issues, the fixes are applied in that review's resolution phase and recorded under `## Post-Review Amendments` (with re-verification), or a follow-up ticket is created\n- Delivery records in `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fdelivery\u002F` are permanent artifacts for traceability\n\n## Notes\n\n- This skill is unique in the pipeline: it writes to the real codebase, not just `.gener8v\u002F`\n- The delivery record is the bridge between pipeline artifacts (all in `.gener8v\u002F`) and actual code files\n- One delivery per ticket — do not batch multiple tickets into a single delivery\n- If a ticket is sized Large, consider whether it should have been split during Ticket Breakdown rather than delivering a monolithic implementation\n- The `{ext}` placeholder in ticket Output sections should be resolved during implementation planning based on the system context and technology stack\n- When system context (`.gener8v\u002Fcontext.md`) is available, use it to inform language, framework, and convention choices; its `## Repositories` table is where the plan's repository and the Verification Run's commands come from — in a workspace of several repositories every path in the record stays root-relative (`api\u002Fsrc\u002Fsearch\u002Fquery.ts`)\n- Delivery status values: **Reconciled** (pre-flight Go, plan not yet approved), **In Progress** (plan approved, code being written), **Delivered** (all acceptance criteria verified), **Partial** (some criteria met, others blocked), **Blocked** (cannot proceed — including a failed Pre-Flight Reconciliation: a missing table\u002Fcolumn\u002Fscript or an absent pinned document means the ticket is blocked before planning, with the reconciliation findings naming what must exist first)\n- A project whose `tickets\u002F`, `delivery\u002F` and `reviews\u002F*-review.md` still sit at the top level of `.gener8v\u002F` is the legacy pseudo-change `initial`; read from there if that is where the ticket is, but never write a new record to the legacy location — Orchestrate recommends the one-time migration\n- With the plugin installed, a `PreToolUse` hook reminds the model when source is edited while no delivery record is `In Progress`, and the `SessionStart` hook points a resumed or compacted session at the in-flight record\n",{"name":48,"description":49,"allowed-tools":50,"argument-hint":51,"disable-model-invocation":52},"delivery","Implement one ticket: reconcile its assumptions against the real codebase, get an implementation plan approved, write the code with @spec annotations, and keep the delivery record current from plan approval onward. The only skill that changes source code. Use when a ticket's dependencies are delivered and it is ready to build, such as 'implement TICKET-004' or 'deliver the next ticket'. Not for writing tickets (ticket-breakdown) or reviewing delivered code (code-review).","Bash(python3 ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgener8v-state.py *)","[capability area] [TICKET-XXX] [in change-slug]",true,"main","26f591c601503d32ccba54a6ddbcba75a00910c0",".claude\u002Fskills\u002Fecc\u002Fcustoms-trade-compliance","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile","2026-11-08 20:29:14",{"source":8,"skillName":48,"commands":60,"prompt":70,"zipAvailable":52},[61,64,67],{"tool":62,"command":63},"npx","npx skills add sakamoto-family-smile\u002Fagent_monorepo --skill delivery",{"tool":65,"command":66},"bunx","bunx skills add sakamoto-family-smile\u002Fagent_monorepo --skill delivery",{"tool":68,"command":69},"pnpm","pnpm dlx skills add sakamoto-family-smile\u002Fagent_monorepo --skill delivery","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fcustoms-trade-compliance\u002FSKILL.md",[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"assets\u002Fdelivery-record.md","ASSET","资产文件",5903,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdelivery\u002Fassets\u002Fdelivery-record.md",{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fexample.md","REFERENCE","参考文档",8975,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdelivery\u002Freferences\u002Fexample.md",[85,119,127,144,167,193],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":99,"publishedAt":43},"01M6RW50THEFSKK42YNR8XFZA1","remotion-video-creation","Best practices for Remotion - Video creation in React. 29 domain-specific rules covering 3D, animations, audio, captions, charts, transitions, and more.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fremotion-video-creation\u002FSKILL.md",[91,96],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000016","图像与多媒体",[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,29],"Video","remotion video","remotion video creation","creation","Remotion","Charts","Captions","Audio","3D","Composition","Animation","best practices","more","animations","domain-specific","domain","three","Rules","Lottie",{"skillNo":120,"name":121,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":43},"01M6VCJ23NPECPSZJKGY691F75","hotcook-recipes","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fhotcook-agent\u002Fdata\u002Fskills\u002Fhotcook-recipes\u002FSKILL.md",[],[125,126],"hotcook recipes","recipes",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":139,"publishedAt":43},"01M6VCHHE00X5XHSDRD1KH1BW2","code-helper","Code review and assistance skill","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-2\u002Fskills\u002Fcode-helper\u002Fskill.md",[133,136],{"categoryNo":134,"categoryName":135,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":137,"categoryName":138,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师",[140,141,41,142,143],"code helper","helper","code review","review",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":156,"publishedAt":43},"01M6VCH3Q31A20H6SQ1H0J7JB2","research-assistant","Web research assistant skill using Brave Search MCP","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-1\u002Fskills\u002Fresearch-assistant\u002Fskill.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":154,"categoryName":155,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000023","Skill与智能体开发",[157,158,159,160,161,162,163,164,165,166],"research assistant","research","assistant","MCP","web","search","brave search","web research","brave","web research assistant",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":177,"publishedAt":43},"01M6VCGZZGPNVJSCZ1JTMNZAHY","x-api","X\u002FTwitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fx-api\u002FSKILL.md",[173,176],{"categoryNo":174,"categoryName":175,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":137,"categoryName":138,"taxonomyType":20,"taxonomyTypeDesc":21},[178,179,32,26,180,181,29,182,183,184,185,186,187,188,189,38,190,191,162,192],"x api","api","limits","rate","threads","reading","native","posting","platform","patterns","api integration","twitter","auth","analytics","OAuth",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":43},"01M6VCGVX6DGB1FKTA53QBBCQB","workspace-surface-audit","Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fworkspace-surface-audit\u002FSKILL.md",[199],{"categoryNo":154,"categoryName":155,"taxonomyType":94,"taxonomyTypeDesc":95},[201,202,203,204,160,205,206,41,207,208,209,210,38,211,212,213,214,184,215,26],"workspace surface audit","workspace","audit","hooks","workflows","connectors","capabilities","harness","repo","environment","up","harness setup","active","env","value"]