theam/claude-dev-kit/follow-ups

Follow-ups

Close the loop: when a story finishes, the loose ends it surfaced should be tracked, not just described in the PR body. This skill turns them into real work items in the configured tracker, linked back to the source story — created only after approval. It's the tracking counterpart to the "Out of scope / follow-ups" section create-pr already writes.

Preconditions

• .claude/dev-kit.json exists with a tracker block (otherwise run dev-kit-setup first).
• The adapter's backend is authenticated (MCP connector authorized, or gh/az logged in) — otherwise tell the user how to authenticate and stop.
• The source story key (the item just delivered) is known, for linking. If unknown, ask once.

1. Gather the loose ends — only real ones

Collect follow-ups from the story just finished, from where they were already surfaced:

• the "Out of scope / follow-ups" list in the create-pr PR body,
• deferred review findings from fix-pr / pr-review (the "defer to a tracked issue" bucket),
• deliberate TODOs / known gaps the implementation left.

Never invent follow-ups. If there are none, say so and stop — don't pad a backlog to look thorough.

2. Propose — WAIT FOR APPROVAL

For each loose end, propose a work item:

• Type: default Task; use a User Story when it's a user-facing increment (ask if unsure).
• Title + a one-line description + why (the context from the story that produced it).
• Link to the source story (and its epic/parent when there is one) for traceability.
• A sizing hint or label when the team uses them (discover, don't assume).

Present the full list and wait for explicit approval; the user may edit or drop items. Create nothing until approved.

3. Create — via the tracker's write adapter

Create each approved item and link it to the source story. Verify writes by read-back where the CLI can silently no-op.

Jira (type: "jira") — Atlassian MCP

createJiraIssue for each item (project, type, summary, description, labels); link to the source with createIssueLink ("Relates to", or a sub-task under the story when appropriate).

Linear (type: "linear") — Linear MCP

Create the issue under the team; relate it to the source (relation or sub-issue); set labels/estimate.

GitHub Issues (type: "github") — gh

gh issue create --repo <owner/name> --title <t> --body-file - --label <type>, referencing the source in the body (Follow-up of #<n> / a task-list link). Verify by read-back (gh issue view --json labels) and apply labels via REST on a miss (classic-Projects orgs can silently no-op).

Azure DevOps (type: "azure") — az boards / MCP

az boards work-item create --type "Task|User Story" ...; link to the source with az boards work-item relation add (Related / Parent).

4. Report

List each created item with its key/URL, and record them where the story lives — add a "Follow-ups tracked: `<keys>`" line to the PR and/or the tracker comment so the trail is visible. On partial failure, report exactly what was created and what wasn't.

Guardrails

• Never create anything before approval.
• Only genuine loose ends from the work — no fabricated backlog.
• Always link to the source story for traceability.
• Watch for secrets/PII in the source material; don't copy them into tickets.