← the whole session plugin/skills/task-get-one-important/SKILL.md

Surface the single most critical proposable task from the current conversation — derives the gap between the person's intent and reality, fills out a complete proposal record (see /proposal-schema), and presents it to the person in plain conversation. Use when the person asks "what's the one thing that matters right now", at the start of a triage pass over a session, or before filing a proposal with /propose.

Task: Get One Important

What This Skill Does

Scans the current conversation for the single most salient, critical, recency-weighted, proposable task — a gap between what the person wants and what reality delivers — and presents it as a fully-formed proposal with the record filled in IF one exists, or says the conversation is clear if it does not. Shows full observability of each step.

A proposable task is a gap that could be addressed through a fix. Not a wish, not a vague improvement — a specific delta between intent and actuality.

This picks and works up ONE gap; it does not file it. Hand the result to /propose (or /how-to-submit-and-track-proposals) to actually file it, and to /align to check it against the whole project rather than just this conversation's most recent frustration.

Execution Steps

Phase 1 — Notice the Gap

  1. What does the person want? — Derive their intended UX outcome from what they said, asked, or reacted to in this conversation. Use verbatim quotes where possible.
  2. What is reality? — What actually happens today in the code, product, or system.
  3. Name the gap — One sentence: "{intended outcome} but instead {actual outcome}."
  4. Scope the problem — Ask: is this gap a symptom of something broader? What is the correct scope of the problem that creates this gap? Not the narrowest fix, not the broadest rewrite — the scope that eliminates the root cause without overreach.
  5. Evaluate the solution — What would close this gap? Is it code, config, process, or communication? What's the simplest change that fully resolves it?
  6. Derive the UX intent — Frame as: "When {user conditions}, they should {experience X}, so that {outcome Y}."

Phase 2 — Fill the Record

Fill out a complete proposal record — every field, no nulls, no "TBD", no placeholders. If you genuinely cannot determine a field, write "unknown — requires: {what you'd need to find out}".

Use /proposal-schema's frontmatter shape as the base (id, type: proposal, title, status: needs-review, score, priority, domain, tags, touches_users, created), and add these fields specific to this skill's job — a generic proposal record, not tied to any one project's database:

{
  "intentStatement": "When {conditions} the person should {experience} so that {outcome}",
  "verbatimUserQuote": "Exact quote from the person in this conversation proving intent existed",
  "extractionConfidence": "low | medium | high",
  "generatedBy": "{the actual model that produced this, e.g. claude-sonnet-5 — never hardcode a fixed value}",

  "humanImpact": {
    "affectedUsers": "Who specifically is affected and what journey triggers it",
    "currentExperience": "What they see/experience today (1 sentence)",
    "fixedExperience": "What they'd see/experience after the fix (1 sentence)",
    "changesByUserType": "What changes for each user type"
  },

  "currentStateVerification": {
    "verifiedAt": "ISO timestamp or 'not yet verified'",
    "verifiedStillBroken": true,
    "verificationMethod": "How you confirmed the gap still exists (code read, test, curl, browser)",
    "verificationNote": "What you observed"
  },

  "nextStep": "The specific, actionable next step to close this gap",
  "blockers": "What's blocking it, or 'none'",
  "complexity": "1-100, effort not importance",

  "evidence": {
    "screenshots": [],
    "verificationNote": "What you observed that proves the gap"
  },

  "before": "What exists today (code, behavior, or state)",
  "after": "Exact replacement or new behavior",
  "evidenceOfAlignment": "Quotes or signals from the person confirming this is wanted",
  "evidenceOfFix": "Measurable outcome after applying the fix",

  "relatedIntentIds": ["IDs from your own intent-tracking scheme, if you keep one — omit if you don't"],
  "relatedLogIds": ["IDs from your own logging/error-tracking system, if applicable — omit if you don't have one"]
}

Keep this record as a filed artifact (pass it to /propose or wherever you keep proposals) — it is not what the person reads directly. See Phase 3 for what they see.

Phase 3 — Present in Human Terms

The person reads plain conversation, not the record above. Speak the way you'd tell a colleague:

Here's the one thing I think matters most right now: {plain-language statement of the gap, using their own words where you can}. {One or two sentences on why this is the highest-signal one, and what closing it would look like for them.} {If verified: what you checked and how. If not: say so plainly.}

Then offer the next step — filing it with /propose, checking it against the whole project with /align, or digging deeper — as a natural question, not a menu of labelled fields.

Weighting Criteria

When multiple gaps exist in a conversation, pick the one that scores highest across:

Signal Weight
Recency — surfaced late in conversation (recent frustration > old mention) 30%
Criticality — blocks the person or degrades their core experience 30%
Proposability — can be stated as a concrete before/after with a clear fix 25%
Salience — the person reacted emotionally or repeated themselves about it 15%

/align deliberately pulls the opposite direction from this skill's recency weighting — it checks the chosen gap against the whole project, not just the most recent frustration. Run it after this skill, not instead of it, when the stakes warrant a wider check.

Rules

  • One task only. If you surface two, you picked wrong. Commit to the highest-signal one.
  • Verbatim quotes are mandatory. If the person didn't say anything quotable about this gap, your confidence should be low.
  • Verify before claiming. If you say verifiedStillBroken: true, you must have read code, run a command, or observed behavior. If you haven't verified, say so in verificationMethod.
  • Never propose what's already fixed. Check if the gap was resolved during this conversation before surfacing it.
  • Complexity is effort, not importance. A 95-priority item can be complexity 5 (easy fix, huge impact).
  • The person reads conversation, not JSON. Phase 2's record is a filed artifact for /propose and future agents; Phase 3's plain-language statement is what the person actually sees.