--- name: dev-inbox description: Triage and route anything that comes up during a session — bugs, ideas, improvements, small fixes — to the right place. Use when the user or you notice something that may not belong to the current task. argument-hint: "Describe the problem, idea, or improvement" license: MIT allowed-tools: - Bash - Read - Write - Grep - Glob metadata: version: 1.0.0 category: workflow triggers: - "记一下" - "记下来" - "以后再说" - "这个先不管" - "open an issue" - "log this" - "track this" - "dev inbox" - "inbox" - "/dev-inbox" --- # Dev Inbox Triage anything that comes up during a session — bugs, features, improvements, fleeting ideas — and route it to the right place so it is never lost and always discoverable by future sessions. This skill works in any context: software development, writing, design, or any task. --- ## When to Activate - **Proactive**: You notice the user said something unrelated to the current task (a bug, idea, improvement, or tangent). Intervene immediately with a suggestion. - **Reactive**: The user explicitly says "记一下", "log this", "open an issue", "以后再说", "track this", or invokes `dev-inbox`. --- ## Decision Tree ``` User says something │ ├─ Is it part of the current task? │ (Current task = current conversation + open files + git diff) │ ├─ YES → Do it directly. Stop here. │ └─ NO ↓ │ ├─ Does it block the current task? │ ├─ YES → Handle it first, then return to current task. │ └─ NO ↓ │ ├─ Priority? │ ├─ HIGH — would cause data loss, money loss, security issue, or blocks others │ ├─ NORMAL — clearly needs doing, but not urgent │ └─ LOW — nice-to-have, fleeting thought, cosmetic │ └─ Record it + ensure future discoverability ``` --- ## Classification Assign one type and one priority: | Type | Meaning | Example | |------|---------|---------| | `fix` | Something existing is broken or wrong | Bug, incorrect content, wrong behavior | | `add` | Something new is needed | Feature, new section, new capability | | `improve` | Works but could be better | Better wording, cleaner UI, performance | | `idea` | Fleeting thought, maybe later | "What if we also..." | Priority: `high` / `normal` / `low` --- ## Interaction Pattern When you identify something that doesn't belong to the current task, respond with a **concrete suggestion** — not an open question: > This doesn't seem related to the current task. I suggest recording it as: > > **Type**: fix | **Priority**: normal > **Title**: Receipt is not generated after order submission > > Confirm? The user responds with one word (yes/no/adjust). Then execute. --- ## Where to Record Detect the environment and pick the best destination. The goal is **future discoverability** — the record must surface in a future session without the user remembering it exists. ### Priority order: 1. **GitHub remote + `gh` CLI available** - Check: `git remote get-url origin 2>/dev/null && command -v gh` - Action: `gh issue create` with title, label, and body - Why discoverable: Agent can `gh issue list --state open --label ` - Merge logic: Search open issues with same label + similar title keywords. If found → append checklist item. If unsure → ask user. 2. **Agent memory system available** (Windsurf memories, Claude memory, etc.) - Action: Write to memory with `[TODO]` prefix and type/priority metadata - Why discoverable: Automatically loaded on next session start 3. **Project directory exists** - Action: Append to `TODO.md` in project root (create if absent) - Format: Grouped by type, each item has priority tag - Why discoverable: Agent should read `TODO.md` at session start 4. **None of the above** - Action: Output formatted content for the user to place manually - Format: Ready to paste anywhere ### After recording, confirm: ``` Recorded: [type] [title] Location: [where it was saved] Discovery: [how a future session will find it] ``` --- ## Record Templates Adapt detail level to priority — lower priority = lighter format. ### fix (high/normal) ```markdown ## Problem [What is broken / wrong] ## Expected [What should happen] ## Context [Where/when discovered, related task if any] ``` ### fix (low) ```markdown - [One-line description of what's wrong] ``` ### add ```markdown ## What [What to add] ## Why [Why it matters] ``` ### improve ```markdown - [What it is now] → [What it should be] ``` ### idea ```markdown - [One sentence] ``` --- ## Merge Logic Before creating a new record, check if a related one already exists: - **GitHub Issues**: `gh issue list --state open --label ` — scan titles for keyword overlap - **TODO.md**: Scan same type section for similar items - **Memory**: Check for `[TODO]` entries with similar content If a match is found → append as a sub-item or checklist entry. If uncertain → ask: "This looks related to [existing item]. Add to it, or create separate?" --- ## GitHub Issue Labels When using GitHub Issues, apply these labels (create if they don't exist): ```bash gh label create "fix" --color "d73a4a" --description "Something is broken" 2>/dev/null gh label create "add" --color "0075ca" --description "New feature or content" 2>/dev/null gh label create "improve" --color "a2eeef" --description "Enhancement to existing" 2>/dev/null gh label create "idea" --color "e4e669" --description "Exploration, maybe later" 2>/dev/null gh label create "high" --color "b60205" --description "High priority" 2>/dev/null gh label create "low" --color "c5def5" --description "Low priority" 2>/dev/null ``` --- ## No-`gh` Fallback If `gh` is not installed but a GitHub remote exists, output: ``` I can't create the issue automatically (gh CLI not found). Here's the issue ready to paste: Title: [title] Labels: [type], [priority] Body: --- [formatted body] --- Create it at: [repo URL]/issues/new ``` --- ## Anti-patterns - Do not interrupt the user's flow with long explanations. Keep triage to 2–3 lines. - Do not ask open-ended questions like "What do you want to do with this?" — propose a concrete action. - Do not create records that can't be found later. Always state the discovery path. - Do not duplicate: always check for existing related records first. - Do not use this skill for things that ARE part of the current task — just do them. - Do not generate a file and leave it disconnected. The record must be in a system the agent will check. --- ## Relationship to Other Skills - **`session-handoff`** / **`close-loop`**: At session end, mention count of items recorded this session (e.g., "Recorded 3 items to dev-inbox this session"). No need to re-save — items are already persisted. - **`handoff-receiver`**: When resuming, check for pending inbox items as part of context loading.