Draft a Linear project update by comparing current issues with the previous report. Explain progress, added scope, schedule risks, and one needed decision, then publish the update to the project after the user approves it.
Draft a Linear project status update from what actually moved — progress, risks, and the one decision that needs making. Use when someone asks for a project update, a status post, where a project stands, whether it will land on time, or what to tell stakeholders.
Run score Not tested
See how to installRead a project’s Linear issues and previous status update, then draft a report based on what changed since that update. Review completed issues, added work, and changes to target dates. Use the remaining scope and time to assess whether the project is on track, at risk, or off track. Describe risks as specific events and consequences, and identify one decision or action needed from stakeholders.
Use this skill to explain a project’s progress and delivery outlook to people who will not review each issue. It can also summarize work added during the project or request a decision with a named owner and deadline. The update puts changes into a short report instead of relying on a completion percentage alone.
A connection to Linear’s MCP tools is required. The full draft is shown first. It is posted to the project only after you approve it; if you ask only for a draft, it is not posted. This skill compares against the previous update, so it produces a change-focused report rather than a standalone summary.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
A status update is read by people who will not open a single issue. It has to survive being the only thing they read: is this landing, what changed, and what do you need from them.
Percent-complete is the number people reach for and the one that lies. A project can sit at 70% for a month while the last three issues get harder. What tells the story is what moved since the previous update: issues completed, issues added, and target dates that shifted.
Fetch the project's issues plus its previous status update. Without the previous one you are writing a summary, not an update, and the reader cannot tell what is new.
Pick one and commit to it. Hedging every sentence is how a project stays green until the week it ships late.
| Call | What justifies it |
|---|---|
| On track | Remaining scope fits the remaining time at the current rate |
| At risk | A dependency, an unknown, or a rate that has to improve to land |
| Off track | The date will move, or scope has to be cut — say which |
If you cannot tell, the answer is at risk, and the reason is that nobody can tell.
"Backend integration is risky" gives the reader nothing. "The export endpoint is not built, we cannot finish import until it is, and the owner is on the payments migration until the 14th" tells them what to move. A risk is a specific event with a specific consequence and usually a specific person who can prevent it.
Include scope that was added mid-project. Silently absorbed scope is why the date moves, and it is invisible unless the update names it.
Most updates end with nothing to do, so nothing is done. If a decision, a person, or a descope would help, state it as the last line with a name and a date attached. One ask is better than three, because three get triaged and one gets answered.
Print the draft in full and stop. This skill drafts; publishing is the user's call. A status update is read by stakeholders and enters the project's permanent history, and a wrong trajectory or a risk named for the wrong person is not something a follow-up correction undoes — so an unreviewed post is worse than a late one.
Once they approve it, write it on the project so it lives next to the work rather than in a chat message that is gone by the next morning. Keep it to a few short paragraphs: trajectory, what moved, risks, the ask. If they asked only for a draft, stop after printing it.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.