issue-delivery-kickoff

name	issue-delivery-kickoff
description	Triage an issue, detect done-state and overlap, then hand it off to a fresh-worktree implementation agent.
compatibility	opencode
metadata	{"audience":"maintainers","repo":"perkcord"}

Issue Delivery Kickoff Skill

Purpose: turn a loosely selected GitHub issue into a safe execution handoff.

When To Use

• A specific issue has already been selected for implementation and needs triage before execution.
• The user wants a dependency chain or conflict check for a known target issue.
• The user wants a kickoff prompt for a new agent to complete a ticket.
• For full-queue prioritization or path selection, start with .opencode/skills/agent-workstream-planning/SKILL.md.

Relationship To Other Skills

• Use this skill after portfolio-level triage has already narrowed the path.
• For queue-wide prioritization and conflict mapping, start with .opencode/skills/agent-workstream-planning/SKILL.md.

Guardrails

• Always check whether the issue is already effectively done before planning new work.
• Explicitly distinguish already done from partially done and narrow the remaining scope before kickoff.
• Always inspect open PRs, recent issue comments, and nearby code before recommending execution.
• Default to a fresh git worktree + branch for any new implementation agent.
• Treat overlapping auth, billing, provider, and session work as conflict-prone unless proven otherwise.

Discovery Checklist

1. Read AGENTS.md and AGENTS.local.md when present.
2. Read the target issue and closely related issues.
3. Check for open PRs, recent owner comments, and signs of active work.
4. Search the repo for existing implementation evidence.
5. If the issue looks already done, stop and report the evidence instead of spinning up execution work.

What To Gather

• Issue goal and acceptance criteria
• Hard blockers or implied prerequisites
• Natural follow-ons
• Work that should not happen in parallel
• Whether the issue is likely already implemented and should be verified/closed instead

Done-State Check

Before handing off implementation, look for:

• schema/route/UI support already present
• tests covering the requested behavior
• copy or admin controls exposing the feature already
• issue notes, inbox notes, or repo comments indicating the issue can likely be closed

If these line up, prefer a "verify + close" recommendation over a new coding branch.

If the issue is only partially complete:

• identify the missing slice explicitly
• narrow the kickoff to just that remaining slice
• do not restate the original issue as if none of the work has landed

Topology / Target Check

For deployment, infra, or automation issues, also verify:

• whether the issue assumptions are stale
• whether the white-label/client lane must be handled separately from the shared/internal lane
• whether open topology work should shape the remaining implementation scope

Worktree Handoff Rule

Any issue-completion agent should start in a fresh worktree, not the main worktree.

Suggested pattern:

git worktree add "../perkcord-issue-<number>" -b "feat/issue-<number>-<slug>" main

Then the implementation agent should work from that new path and leave the main worktree clean.

Kickoff Prompt Template

Use a prompt that includes:

• the selected issue number and title
• the user's chosen product direction or constraints
• explicit instruction to check whether the work is already done and stop if so
• explicit instruction to narrow the scope if the issue is only partially done
• explicit instruction to use a fresh worktree + branch before coding
• related issues to coordinate with or avoid overlapping
• likely files/modules already identified during discovery
• expected first output: design note or implementation plan before broad code changes

For deployment/automation issues, also include:

• explicit instruction to verify the correct deployment target(s)
• explicit instruction to account for the white-label/client case when relevant

Continuation Prompt Pattern

If an agent is already working a related issue and the user wants to inform, not redirect, that agent:

• write a continuation prompt instead of a new kickoff
• say explicitly that this is not a scope change or stop-work request
• explain the likely next issue or follow-on lane
• ask the agent to leave behind artifacts that make the next lane easier without expanding into it now

Recommended Output Shape

• brief recommendation on whether to execute, verify, or close
• dependency chain
• parallel-safe vs conflict-prone issue list
• kickoff prompt for the next agent

Verification

• Ensure the kickoff prompt names the worktree rule explicitly.
• Ensure the kickoff prompt includes an "already done? verify first" step.
• Ensure partial-done issues are narrowed before handoff.
• If you change shared kickoff guardrails, update .opencode/skills/agent-workstream-planning/SKILL.md in the same pass.
• If you improved the workflow, add a short note to docs/agentic/agentic-improvement-log.md.