ChiefOSby ConversintStart free
Menu
← Back to the library
Writing and communication

Project status update

Maintain or report a project task ledger: capture next steps, update task status, summarize work, identify blockers and review waits, and draft stakeholder status updates. Use for delivery or internal projects when task ownership, evidence, approvals, and request traceability matter; do not use it as a sales CRM or a personal task list.

Works with the context you provideVersion 3.0.0Historical revision

Project status update

Use a project ledger to make work, ownership, evidence, blockers, and approval state visible. The ledger is the project system of record, not a sales CRM, personal task manager, raw feedback inbox, or substitute for a host's separate customer-record system.

Select a mode

| Need | Mode | |---|---| | Create a project ledger | `init` | | Capture tasks from notes, messages, or a review | `capture` | | Change task state, owner, evidence, blocker, or reviewer | `status` | | Report one project's work | `report` | | Summarize work across project ledgers | `summarize` | | Draft a stakeholder update from verified ledger facts | `stakeholder-summary` |

If a request could be either a report or a write, ask once before writing. For a clear write request, use the host's approved ledger interface and report the applied changes afterward. If no writable interface is available, produce a proposed change set rather than claiming an update was made.

Ledger model

Each task should retain:

- status: `To do`, `In progress`, `In review`, `Blocked`, or `Done`; - owner and, if relevant, reviewer; - a concise task statement and optional due date; - source and original request wording when work came from an inbound request; - evidence of completion, such as a path, URL, test result, decision note, or approval record; and - a link or identifier for the work item in the host system.

Treat handoffs and waiting for review as tasks or explicit states, not invisible chat context. Keep raw comments in the source system; capture only the grouped work needed to resolve them.

Core workflow

1. Resolve the requested project and read its current ledger or supplied export. 2. Compare the incoming information with existing tasks; identify duplicates, ambiguities, new work, status changes, and missing evidence. 3. Apply only clear updates through the host's designated interface. Keep mutations serial for a given ledger. 4. Keep implementation evidence separate from acceptance. A completed change is not accepted or launched without the required approval evidence. 5. Return a compact status: added, updated, blocked, skipped as duplicate, and anything that needs a decision.

Stakeholder status format

```markdown ## [Project] status — [date]

### Completed - [Outcome and supporting evidence]

### In progress - [Owner] — [next action and date, if known]

### Blocked or awaiting review - [What is needed, from whom, and impact]

### Decisions or approvals needed - [Specific approval or decision] ```

Boundaries

- Do not infer which party owes a task when ownership is unclear. - Do not mark `Done`, accepted, or launched without supporting evidence and any required approval record. - Do not create reminders, send stakeholder updates, change a CRM, or write to another system unless separately requested and supported by the host. - Preserve inbound request wording and source metadata when they matter for later review.