shelf-issuelisted

Use when the user defers a bug or in-flight investigation — "shelve this", "park it as a known issue", "come back to this later" — to capture it as a resumable known-issue doc in the current project so it can be picked back up later without losing context. Also use when the user wants to preview, browse, or review existing known-issue docs — "show me the known issues", "preview the known issues", "spin up the known-issues dashboard" — to build an interactive HTML summary (sortable table with severity/status/category, click-through detail) served on a local server. Also use when the user wants to retrofit or bulk-edit many known-issue docs at once — "migrate all the known-issue docs to the new template", "rename this field across every known-issue doc".
punkaze/skills · ★ 1 · AI & Automation · score 72

Install: claude install-skill punkaze/skills

# Shelf an Issue Capture an in-flight bug or investigation as a known-issue doc so it can be picked back up later without losing context. Also builds an interactive local HTML dashboard for browsing existing known-issue docs. Three independent workflows — pick the one matching the request: - **Workflow A** — capture a *new* issue (the original, default behavior). - **Workflow B** — *preview* existing issues as an interactive dashboard. - **Workflow C** — retrofit or bulk-edit many existing docs at once (a template migration, a field rename across the whole corpus, etc.). ## Workflow A — Shelve a new issue An optional kebab-case slug may be given (e.g. `socket-no-inbound-events`, `http-init-sync-missing-oa`). It may instead arrive as prose, or be empty. ### Workflow 1. **Settle the slug.** If given a clean kebab-case slug, use it. If it's prose or empty, derive a short kebab-case slug from the issue and show it for confirmation. Then show the proposed filename `docs/known-issues/YYYY-MM-DD-<slug>.md` (today's date) — adjust the directory if this project already has a different known-issues convention, or (in a monorepo) use the `docs/known-issues/` nearest the affected package's root, falling back to the repo root if that's unclear. If the file already exists, ask whether to overwrite, append, or pick a new slug. 2. **Gather context.** Pull from the current conversation, not from a fresh investigation: - What was the user trying to do?