// View, add, generate, or act on follow-up items for the current project.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | followups |
| description | View, add, generate, or act on follow-up items for the current project. |
Use when the user mentions "follow-ups" / "followups", asks to generate or surface new follow-ups from the session, or wants to view or act on existing items.
~/.claude/followups/<project>.md — one file per project, where <project> is the local repo folder name:
basename "$(dirname "$(realpath "$(git rev-parse --git-common-dir)")")"
## <branch-name> — YYYY-MM-DD-HH-MM
- **Title** — One sentence description.
Append-only. Never edit or delete existing sections.
Pick the mode based on how the skill is invoked.
Read the file and display or summarize its contents. If it doesn't exist, say so.
Append a new dated section with the current branch and timestamp. Read the file first and skip items whose title or core idea already appears — no duplicates.
Present the list of existing items and help the user prioritize or start on whichever they choose.
Move completed items to a ## Resolved section at the bottom — never delete.
Use this mode when invoked from /wrap-up or when the user explicitly asks to generate or surface follow-ups from the session.
When called from /wrap-up: the intent is to define new items from session context — things that came up, were noticed, or were left unfinished. Don't just record what happened; look for what the user should do next that isn't already tracked.
Orient yourself:
git log --oneline -20 to see recent commitsDecide where items will be filed — GitHub issues or this followups file.
GitHub issues are only available when the remote is owned by McBrideMusings (case-insensitive).
Pass 1 — default remote:
cd <project_dir> && gh repo view --json owner --jq '.owner.login'
If this returns McBrideMusings, use GitHub issues. Done.
Pass 2 — all remotes (only if Pass 1 didn't match):
git remote -v
For each remote URL containing github.com, extract OWNER/REPO and check:
gh repo view OWNER/REPO --json owner --jq '.owner.login'
If any resolves to McBrideMusings, use that repo. Prefer a remote named mine if multiple match.
Result:
Zero items is a valid result. Don't pad. Most sessions produce 0–2 items. More than 3 should make you suspicious.
Surface things the user wouldn't catch from glancing at the diff — that's the entire value here.
Every item must clear all of:
Group under these headings. Omit empty ones. Order by impact within each.
[friction] and are listed first within FeaturesLead with the single most valuable item as a headline. If nothing is worth flagging:
Nothing worth flagging this session.
That is a complete, valid output.
1. **Title** — One sentence: what to do and why it matters.
Saw this because: <specific observation, file:line if possible>.
Friction items:
1. [friction] **Title** — Description.
Saw this because: <the friction moment>.
Number items with a single sequence across all sections.
Never propose closing, reversing, or superseding an existing issue. If session work obsoleted a GitHub issue, surface it as an inline note before the suggestions list:
FYI: issue #N ("") appears obsoleted by this session's work — /wrap-up Phase 2 will catch it, or close it manually.
Same applies to stale items in this followups file — flag them inline, don't write new "remove old item" entries.
If suggestions exist, ask once:
If no suggestions exist, just report "Nothing worth flagging this session" and stop.
Filing:
gh issue list --repo OWNER/REPO --state all --limit 50 first; skip items whose core idea already appears. File via gh issue create --repo OWNER/REPO. Include the provenance line in the body.- **Title** — description. (Saw this because: ...)If the user says "none", write nothing. Do not split items across destinations. Do not infer intent from silence.
Multiple repos: Present a separate list per repo and ask independently for each.