# Project Status

Draft a Linear project status update from what actually moved, progress, risks, and...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill project-status -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill project-status -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill project-status -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill project-status -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Draft a project status update

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.**

## 1. Read the movement, not the snapshot

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.

## 2. Judge the trajectory honestly

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.

## 3. Name risks as things that could happen

"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.

## 4. Ask for what you need

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.

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/linear/skills/project-status/SKILL.md