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

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. Preserve a request trail: source identity, original wording, decision made, and implementation or approval evidence. When wording or ownership is ambiguous, record the ambiguity and request clarification rather than assigning work by inference. 3. Apply only clear updates through the host's designated interface. Keep mutations serial for a given ledger. 4. **Apply the approval watchdog.** For customer-visible or client-operated production work, record whether it includes regulated or pricing claims, testimonials/results, a lead or sensitive-intake form, publication or deployment, a customer commitment, or consequential AI (sensitive data, material decisions, external action, or a material production change). Treat ordinary layout, generic educational copy, internal drafting, and other low-risk work as non-triggers unless a source says otherwise. If a hard trigger or an explicit user/source request applies, record the specific source and either the required approval or a recommendation for an approval gate. Do not set approval required unless the user or source requires it. Keep implementation evidence separate from acceptance; record the named reviewer and exact evidence needed before moving from `In review` to `Done`. 5. Return a compact status: added, updated, blocked, skipped as duplicate, and anything that needs a decision.

Mode-specific outputs

- `report`: current tasks, owners, evidence, blockers, review waits, and the next decision—without silently changing the ledger. - `summarize`: cross-project progress and dependencies, with each fact linked to its owning ledger rather than creating a parallel task system. - `stakeholder-summary`: a draft drawn only from verified ledger facts; it remains unsent until separately approved.

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.