# Task Status Update > Write short, human-readable status updates on a task and record them wherever the task lives — a Jira issue, a Notion task, a GitHub or Linear issue, or a plain status post (Slack, standup, email). Use whenever work is finished or has moved and belongs on a tracked task: when an agent or the user completes a unit of work, or the user says "update the task", "post an update", "log progress", "comment on CAI-123", "mark this in review / blocked / done", "close this out", "give me a standup update", or names a task by key or link. Trigger proactively after finishing a build, PR, fix, migration, or investigation that maps to a task, even if the user never says the tracker's name — offer to record it. A good update lets a busy reader answer in ten seconds: what got done, what's left, what's blocked, what was decided, and what decision is now needed. When the work surfaces a choice the user must make, state the decision and the factual options plainly and ask — do not recommend one. Keeps updates short and free of - Skill: `ebellefontaine/task-status-update` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add ebellefontaine/task-status-update` - Raw SKILL.md: https://api.skillmd.com/api/skills/ebellefontaine/task-status-update/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: ebellefontaine (https://skillmd.com/u/ebellefontaine) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ebellefontaine/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.