magnus919_agent-skills/neckbeard/templates/delivery-packet.md

Delivery Packet

Fill one packet per change-request run. Each section mirrors a field group from ../references/delivery-packet.md. Replace every _[fill: ...]_ marker with your value. The packet is a coordination handoff — record pointers, summaries, and verdicts, not specialist content.

(a) Change-request provenance

• Change-request URL or number: [fill: URL or tracker number, e.g. https://github.com/org/repo/issues/42 or JIRA-123]
• Source type: [fill: issue / ticket / email / verbal]
• Repository: [fill: repo path or URL, e.g. https://github.com/org/repo]
• Base ref: [fill: branch or ref the change is based on, e.g. main]
• Issue/comment snapshot: [fill: request text, comments, and linked work captured at intake — paste inline or link to a snapshot file]
• Tracking system: [fill: system identified per ../references/tracker-discovery.md, e.g. Linear (requester-confirmed) / GitHub Issues (detected: issue URL in request)]
• Head SHA at intake: [fill: git rev-parse HEAD at intake, e.g. a1b2c3d]

(b) Granted authority + workflow mode/path

• Authority class: [fill: Explore / Modify / Publish / Deploy / Merge — if unclear, write "explore (assumed)" and flag that confirmation is needed]
• Workflow mode: [fill: GitHub reference mode / enterprise mode]
• Selected path: [fill: lightweight / full / refactor / high-risk]

(c) Resumable phase/gate state + current head SHA

• Current phase: [fill: phase name, e.g. phase-7-independent-review]
• Current gate: [fill: gate name, e.g. gate-4-independent-review]
• Last passed gate verdict head SHA: [fill: exact SHA at which the last gate passed, e.g. 9f2c1ab]
• Current lifecycle state: [fill: intake / planning / implementation / in-review / ready / merged / closed / blocked / released]

Example (populated after a context boundary):

Current phase:                     phase-7-independent-review
Current gate:                      gate-4-independent-review
Last passed gate verdict head SHA: 9f2c1ab
Current lifecycle state:           in-review

A resuming agent reads: phases 1–6 and gates 1, 3, 2 are recorded as passed in section (h) and are not re-executed. Resume at phase 7, completing gate 4 then gate 5. Compare the recorded SHA 9f2c1ab to the actual head; if they differ, run the changed-head procedure in ../references/delivery-packet.md before continuing.

(d) Problem / baseline evidence / scope / non-goals / affected surfaces

• User-visible problem: [fill: one or two sentences — what is wrong or missing from the user's point of view]
• Baseline (pre-change) evidence: [fill: reproduction output, current-state observations — label boundary: component / integration / end-to-end / production; label stage: baseline]
• In-scope work: [fill: what this change will do]
• Non-goals: [fill: what this change will explicitly NOT do]
• Affected surfaces: [fill: paths, contracts, boundaries touched]

(e) Routing: selected skills + explicitly skipped skills with reasons

• Selected skills: [fill: skill name + per-stage lead when several compose, e.g. "backend-engineering (lead: implementation), api-design-and-evolution (lead: contract design)"]
• Skipped phases with reasons:
  • [fill: e.g. "phase 3 (architecture delta): lightweight path, single-function bug fix, no architecture impact"]
• Skipped skills with reasons:
  • [fill: e.g. "frontend-engineering: change touches backend API only"]
• No-specialist fallback: [fill: "no specialist selected — no applicability signal triggered" when no routing row triggers; otherwise "N/A"]

(f) Design: architecture delta / decisions / risks / compatibility / migration / rollback

• Architecture delta: [fill: path to ARCHITECTURE-DELTA.md, or "no delta — "]
• Decisions: [fill: key design decisions and their rationale]
• Rejected alternatives: [fill: approaches considered and why each was not chosen]
• Risks: [fill: what could go wrong; blast radius; what depends on this area]
• Compatibility: [fill: backward/forward compatibility analysis]
• Migration strategy: [fill: migration steps, or "none required"]
• Rollback plan: [fill: how to revert if this change fails]

(g) Plan: spec / acceptance criteria / test strategy / task plan / verification report paths

• SPEC.md path: [fill: e.g. SPEC.md]
• Acceptance criteria mapping: [fill: AC identifiers mapped to change-contract acceptance criteria; identify which criterion traces to the requester's stated outcome (contract Problem section, restated in phase 2) — required for the gate-3 verdict]
• Test strategy: [fill: test levels (unit / integration / end-to-end), regression coverage strategy]
• TASK-PLAN.md path: [fill: e.g. TASK-PLAN.md]
• QA verification plan path: [fill: e.g. VERIFICATION-PLAN.md]
• Verification report paths: [fill: e.g. VERIFICATION.md, test output logs]

(h) Gates: verdicts / assumptions / rejected alternatives / unresolved boundaries / evidence pointers

Gate	Verdict	Head SHA	Evidence	Conditions / blocker
gate-1 (architecture/design delta)	[fill: pass / conditional / blocked]	[fill: e.g. a1b2c3d]	[fill: path to evidence artifact]	[fill: unresolved conditions or blocker reason, or "none"]
gate-2 (QA test & verification plan)	[fill: pass / conditional / blocked]	[fill: SHA]	[fill: path]	[fill: or "none"]
gate-3 (spec + task-plan completeness)	[fill: pass / conditional / blocked]	[fill: SHA]	[fill: path]	[fill: or "none"]
gate-4 (independent review)	[fill: pass / conditional / blocked]	[fill: SHA]	[fill: path]	[fill: or "none"]
gate-5 (boundary verification)	[fill: pass / conditional / blocked]	[fill: SHA]	[fill: path]	[fill: or "none"]

Verdict semantics: pass = phase may exit, next phase may start. conditional = phase may exit only with recorded conditions tracked and closed before the next gate. blocked = phase may not exit, run stops and escalates per ../references/risk-authority-gates.md, packet transitions to blocked.

Example (populated gate verdict):

gate-1 (architecture/design delta) | pass | a1b2c3d | ARCHITECTURE-DELTA.md | none

• Assumptions: [fill: unverified assumptions stated explicitly]
• Rejected alternatives: [fill: design or approach alternatives rejected during gate reviews]
• Unresolved boundaries: [fill: boundaries not yet verified, or "none"]
• Evidence pointers: [fill: repo-relative paths to evidence artifacts, updated throughout the run]

(i) Lifecycle: PR / CI / review / final verified head SHA / release status

• PR (or review-submission) number: [fill: e.g. #42 or enterprise review ID]
• CI status: [fill: passing / failing / pending / not-applicable]
• Review status: [fill: approved / changes-requested / pending / not-applicable]
• Final verified head SHA: [fill: exact SHA at which all verdicts were re-confirmed, e.g. 7b40de2]
• Release status: [fill: not-released / release-ready / released / not-applicable]
• Terminal lifecycle state: [fill: merged / closed / blocked / released]
• Terminal state evidence: [fill: merge commit SHA, closure reason, or blocker reference]
• Rollback/follow-up triggers: [fill: conditions that would cause re-entry after closeout — e.g., a post-release regression requiring rollback or an operational discovery; write "none identified" if there are none. Recorded in the terminal record; any follow-up starts a new change request via phase 1 intake, never by re-opening this packet.]
• Lessons captured: [fill: reusable lesson(s) captured per Stage 6 "Deliver and learn" with their durable destination — skill, memory, or project docs — e.g., "multi-byte input handling lesson → project docs runbook"; or write "no reusable lesson identified". Recorded in the terminal record; silent omission is prohibited.]

Example (populated lifecycle):

PR (or review-submission) number: #42
CI status:                        passing
Review status:                    approved
Final verified head SHA:          7b40de2
Release status:                   release-ready
Terminal lifecycle state:         merged
Terminal state evidence:          merge commit 8c31ef4
Rollback/follow-up triggers:      post-release smoke check failure in the
                                  export path; operational discovery of
                                  multi-byte handling in adjacent endpoints
Lessons captured:                 multi-byte input boundary lesson →
                                  project docs runbook (export section)

Blocked-state record

• Failing gate identifier: [fill: e.g. gate-4-independent-review]
• Phase at which it occurred: [fill: e.g. phase-7-independent-review]
• Blocking evidence: [fill: what was observed that failed the gate]
• Escalation outcome: [fill: decision or authority needed to proceed, per ../references/risk-authority-gates.md]

Shared field reference

The following field categories share identical names and semantics with change-contract.md and evidence-ledger.md:

• Change-request provenance — change-request URL or number; source type (issue / ticket / email / verbal); repository; base ref.
• Skip reason — a concrete reason why an expected action was skipped or deemed unnecessary; silent omission is prohibited.
• Gate verdict — gate identifier; verdict (pass / conditional / blocked); supporting evidence; head SHA at which the verdict was reached.
• PR / CI status — PR (or review-submission) number; CI status.
• Release status — release disposition: not-released / release-ready / released / not-applicable.