Task Status Update

Task Status Update

Record finished or moved work on a task so the reader can scan it in ten seconds. A good update answers five questions and nothing more: what got done, what's left, what's blocked, what was decided, and what decision is now needed. Everything else belongs in a linked doc.

The failure mode this skill exists to prevent is the "slop grenade" — a 500-word essay dumped into a comment box with headers, self-corrections, and buried decisions, written as if the reader were another agent parsing a transcript. The reader is a human with forty tabs open. Write for them.

This skill is target-agnostic. The writing is the same everywhere; only the posting mechanics differ. Identify the target (Jira, Notion, GitHub, Linear, or a plain post), draft the update the same way, and post it using the right tool. Target-specific detail lives in references/targets.md.

The core contrast

Two updates on the same work. Both are "accurate." Only one is usable.

Usable (the whole update):

Blocked by INC0489468

Not usable: a ~600-word comment with five ## headers, a file table, two callouts, a corrected cost estimate, and the actual decision ("narrow the scope and close") sitting in paragraph nine. The information is real. The reader will not read it, and cannot answer "is this done?" from a glance.

Aim for the first. When the work genuinely needs more than a few lines, use a template (see references/templates.md) — never a freeform essay — and move the depth into a linked doc.

Workflow

1. Identify the task and its target

Work out which task and where it lives.

• If the user named a key or link (CAI-569, a Notion URL, owner/repo#17), use it.
• If not, infer from session/project context — a branch name like ekb-cai-569-..., a key in commit messages, a PR title, an open Notion task, or the work you just finished.
• If still unclear, search the likely target (see references/targets.md for the per-target query) and show the top few candidates.

Always confirm the task before writing anything to it. Show its id/summary and current status, and ask if that's the right one. Posting to the wrong task is expensive to undo.

Fetch the task first so the update builds on the thread instead of repeating it — read its current status, description/acceptance criteria, and the last update. See references/targets.md for the fetch tool per target.

2. Gather the facts and the links

Pull the substance from what you actually did this session — the diff, the commands, the outcome. Don't invent progress. Then collect links that let the update stay short by pointing outward instead of explaining inward:

• PR — link it; don't paraphrase the diff. Include the merge SHA on a close-out.
• Slack — if a thread drove a decision, link its permalink.
• ServiceNow / other tracker — confirm the referenced number, then link it.
• Notion — search for an existing spec, ADR, proposal, or objectives doc; link it if found.

See references/targets.md for exact link formats and the private-source check.

3. Decide what goes in the update vs a doc

This is the judgment that keeps tasks clean. An update carries the state, not the reasoning. If you're about to write more than a few lines of analysis, a decision record, a diagram, or a spec, that content wants a doc — the update links to it.

• Existing doc → link it.
• No doc, but the detail is substantial (an ADR, a design write-up, a full investigation) → offer to draft it in Notion and link it, keeping the update to the summary. Don't create the doc silently; propose it. If the user declines, keep the essential decision in one or two lines and drop the rest.
• Detail is minor → one line is fine.

4. Surface any decision that now needs to be made

This is the step most status updates skip, and it is often the most valuable part. Work frequently uncovers a fork the user — not you — must resolve: a scope call, a cost/latency tradeoff, a "which of these two libraries", a "do we ship now or wait for the fix". Naming that fork is the point of the update, because a decision sitting unstated is a silent blocker.

When you find one, state it as a decision needed, and follow three rules:

1. Name the decision as a question the reader can answer. "Do we keep the v1 DB read-only for a month, or decommission now?" — not "there are some considerations around the DB."
2. List the real options and their factual tradeoffs, briefly and neutrally. Give the reader what they need to choose: the cost, the risk, the effort, what each option blocks or unblocks. Facts, not adjectives.
3. Do not recommend one. The choice belongs to the user. State the options and ask which to take. Do not write "I recommend", "we should", "the best option is", or lead the reader with loaded phrasing. If a fact genuinely forces the answer (an option is impossible, or violates a hard constraint), say that as a fact — that is reporting a constraint, not making the call.

Use the Decision needed template in references/templates.md. Keep it to the question, the options with one-line tradeoffs, and — if it blocks progress — a note that work is paused until it's answered.

Why no recommendation: these decisions turn on context you may not have — budget, politics, risk appetite, roadmap. A confident recommendation built on a guess is worse than a clean question, because it invites the reader to rubber-stamp it. Surface the fork sharply and let the owner decide.

Distinguish this from a decision that was already made (step 5's "Decision" template), which you record — one line naming the decision and its consequence, reasoning in the linked doc.

5. Draft the update from a template

Pick the template that matches the update (full definitions and examples in references/templates.md):

• One-line — a single fact: a blocker, a hand-off, a state change. Most updates are this.
• Progress — work advanced but isn't done. Done / Next / (Blocker) / Links.
• Blocker — you're stuck. What's blocked, on what, what would unblock it.
• Decision made — a choice was made others need to know. Decision / Why (1 line) / Link.
• Decision needed — a choice the user must make. Question / Options + tradeoffs / (blocks?).
• Close-out — the work is done. What was delivered, evidence/PR, follow-ups split out.

Fill only the sections that have content. An empty heading is noise — delete it. Keep the whole thing to what fits on a screen without scrolling.

6. Run the writing pass

Before showing the draft, read references/writing-rules.md and clean the text against it. The two habits that matter most:

• No AI-isms. No "Certainly", no significance inflation, no "it's worth noting", no synonym cycling, no em-dash-joined clauses standing in for a period, no headers-for-headers' sake. Plain nouns and verbs.
• No slop grenade. If a sharp engineer wouldn't type this much into the box, cut it. Lead with the one sentence that carries the update.

7. Confirm state changes, then post

Never change status or assignee silently. Propose them, then post on the user's OK. See references/targets.md for the per-target posting, transition, and assignee tools, and for the rule that you can only use transitions the target actually offers (you can't invent a status).

Use full preferred names for people (e.g. "Eric Bellefontaine", "Eric Arnst"). After posting, give the user the task URL and a one-line confirmation of what changed. Don't re-paste the whole update back.

Guardrails

• Confirm before every write. Task identity, update body, status, assignee — all shown before anything posts. Being asked twice is cheaper than being wrong once.
• Don't fabricate. Only report work that actually happened this session or that the user states. If unsure whether a check passed, say what you observed, not what you assume.
• Decisions are the user's. Surface open decisions; never resolve one on the user's behalf, and never bury a recommendation inside a "neutral" options list. Ask.
• One update, not a running correction. If a prior update is now wrong, post one short correction stating the corrected fact, not a re-litigation of how you got there.
• Never paste secrets (tokens, keys, passwords, connection strings with credentials) into an update. Reference the secret store instead.
• Sources. When the update draws on Slack, Notion, or ServiceNow content, cite those sources to the user in your chat response (not necessarily in the posted update).

Targets and connectors

Supported targets and their exact tools are in references/targets.md: Jira (Atlassian Rovo), Notion tasks, GitHub / Linear issues, and plain posts (Slack, standup, email). If the target's connector isn't available, say so and either fall back to a plain post the user can paste, or stop — don't pretend to have posted.