Surface Incomplete Work — For the Person, Not the Database (INCOMPLETE2)

Before your output, print ## INCOMPLETE_TASKS on its own line.

What this is: the person reads what's unfinished, in language they don't have to translate, and decides. That's the whole thing.

The core principle: the transcript JSONL on disk is the source of truth. Not agent memory, not a compacted summary, not what the agent thinks happened. The actual file.

What changed from /incomplete, and why

This is a deliberate variant of a simpler /incomplete skill, kept as its own thing for two reasons an earlier session settled on (kept here as the reasoning, generalized from one real case, since the reasoning transfers even where the specific product doesn't):

• Sonnet, never the cheapest/fastest model tier. A cheap model flattens exactly the nuance that makes this output worth reading — it's reading the person's intent out of their own words, and a model optimized for cheap data-cleaning tends to paraphrase and lose the specific thing they actually said. Use your strongest available reasoning model for the analysis pass, not whatever's fastest.
• No database write. At all. A no-persistence design is a deliberate choice: if a skill that surfaces unfinished work also has somewhere to file it automatically, an agent will tend to file it there and move on, instead of putting it in front of the human. This skill has nowhere to put anything except the person's screen. If the person wants something persisted after seeing it, that's a separate, deliberate act with their hands on it — not something this skill does on their behalf.
• Voice-matched formatting is the deliverable. Each item should come to the person in language calibrated to how they actually talk and think, not a raw field dump that makes them do the translation work themselves — translation is the work being delegated to the agent in the first place. If you have a skill installed for writing in the person's own voice (this plugin ships one as /how-to-talk-like-the-founder, which despite its name is a general communication-style protocol — read its own file for what it actually asks for), and any code-reference or plain-language-translation skills (/on-talking-about-code, /speak-human), use them here. If none of those are installed, the fallback is the same principle stated directly: plain conversational sentences, no labelled-field dumps, ground every item in what the person actually experiences, never invent confidence you don't have.

Step 1 — Extract the transcript (programmatic, no AI)

Run this. Do not reason about what it would return.

If you have the incomplete-tasks-get-from-session skill installed (this plugin ships it):

bash ~/.claude/skills/incomplete-tasks-get-from-session/run_extract.sh

It reads the session's JSONL and returns session_uuid, user_messages_verbatim (in order), tasks_created, tasks_completed, incomplete_tasks, and tool_summary.

If that skill isn't installed, do the equivalent by hand: find the current session's transcript file (Claude Code writes it under ~/.claude/projects/<project-slug>/<session-uuid>.jsonl), and pull out, in order, every message where the role is the human's — that is your user_messages_verbatim. Pull the TaskList state (if the session used one) the same way, or via whatever task-tracking tool the session used.

If the output is large, parse the fields you need with python3 rather than dumping the blob.

Note: incomplete_tasks reflects the TaskList only. A session with zero tasks created has an empty array and still has unfinished work — it lives in the person's messages. The verbatim messages are the real source; the task array is a convenience.

Step 2 — Dispatch your strongest reasoning model with the transcript pre-loaded

Dispatch with your best available reasoning model (not the cheapest/fastest tier), run_in_background: true. Paste the extracted user_messages_verbatim and incomplete_tasks INTO the prompt — the subagent reads no files and hits no APIs.

You are reading the verbatim transcript of a session between a person and an agent.

INPUT (provided below by the caller — do not fetch anything yourself):
- The person's messages, verbatim, in order
- Tasks created during the session, if any

Your job: identify what the person asked for that is NOT yet done.

Rules:
- Use ONLY their actual words. Never rephrase a request into a cleaner form — the rephrasing IS the loss.
- Quote the exact sentence where they asked for each thing.
- Something they asked for with no corresponding task is still incomplete work — surface it.
- A thing they asked for, that got done, is NOT incomplete. Check the evidence before listing it.
- If you are unsure whether something landed, say so in `evidence` rather than guessing either way.

Return a JSON array, nothing else:
[
  {
    "personQuote": "the exact sentence where they asked for this",
    "intentTitle": "one sentence that triggers instant recall for them — what they said, tied to why it mattered",
    "intent": "the precise, context-bound outcome they want: who experiences it, what they see, what changes from today. No generalizing, no abstracting.",
    "evidence": "files edited, commands run, writes made that relate — or 'no evidence found'",
    "status": "not_started | in_progress | blocked",
    "priority": 60,
    "whats_missing": "the specific gap between their intent and where things actually are",
    "risks": "what could go wrong if this gets built wrong, in terms of what a person would experience — or null",
    "riskAbatement": "for each risk, the specific thing that prevents it — or null"
  }
]

Step 3 — Print each item to the person, in language they don't have to translate

If installed, load /how-to-talk-like-the-founder, /on-talking-about-code, and /speak-human before writing this section — they hold the detailed rules for how to say this. Do not skip them because the fields look ready to paste — they are not.

For each item, the person needs to see, without asking a follow-up question:

• Their own words, verbatim and quoted. Never your cleaned-up version of what they meant.
• What you understand the intent to be — the UX outcome, who experiences it, what changes.
• Where it actually stands, grounded in evidence you can point at. If nothing was done, say nothing was done.
• What's missing — the specific gap, not a restatement of the title.
• What could go wrong if it gets built wrong, in terms of what a person would experience, and what prevents that. Skip when there's no real risk rather than manufacturing one.

Any code reference should be fused with the literal conditions and the user journey that makes it true, or left out (that's what /on-talking-about-code covers if you have it; otherwise apply the same test yourself).

End with the decision in front of the person: which of these they want picked up, and in what order. They decide. Nothing is filed, queued, or written anywhere by this skill.

Rules

• The JSONL on disk is the source of truth. Not memory, not summaries.
• Use your strongest reasoning model, never the cheapest/fastest tier, for the analysis pass.
• Never summarize the person's words. personQuote is a direct quote. If you can't quote it, you don't have it.
• Never write to a database. This skill's output goes to the person's screen and stops there — not into a session-compaction store, a task database, or anywhere else, no matter what other persistence tools you have configured. If you want to persist something after the person picks it, that's a separate, explicit act (see /alignment-harness:harness-setup's records command if you want a local file to write it to) — never automatic from this skill.
• Never claim something is done without evidence you can name. "I believe it landed" is not evidence.
• Say what you don't know. An item you can't determine the state of gets said as exactly that.