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

Project status update

Manage Conversint project ledgers for customer delivery work after a deal is won and for internal operating work under conversint-admin. Use /project-manager whenever Patrick or Daniel asks to capture project next steps, update project task status, summarize active todos by project or person, update internal todos from a Drive Watch run, migrate Active Projects tasks, check blockers/reviews, preserve traceability from inbound requests to tasks/evidence, or draft a customer status summary from a ledger. Do not use for sales CRM work, personal /todos, or skill-build feedback handled by /skill-dev-feedback.

Works with the context you provideVersion 2.0.1Historical revision

# /project-manager - project task ledgers

Use this skill to maintain internal project ledgers for Conversint customer delivery and internal operating work. A project ledger tracks tasks, owners, blockers, optional due dates, review waits, request traceability, evidence, fixing commits, and history. It is not a CRM, not Patrick's personal `/todos`, not `/skill-dev-feedback`, and not the raw website feedback ledger owned by `/website-feedback`.

Read repo-root `./references/dependencies/conversint-current/references/request-traceability.md` before capture/status work that comes from customer/stakeholder requests, meeting notes, website feedback, regulated-content review, or repo commits.

Mode Selection

Pick the mode from the first positional argument, or infer it from the user's request:

| User intent | Mode | Then load | |---|---|---| | Create a new customer or admin ledger | `init` | `./references/ledger-format.md` | | Capture next steps from notes, a transcript, an email, Drive Watch output, or an agent-session summary | `capture` | `./references/capture.md` | | Change task state, owner, reviewer, blocker, evidence, or next action | `status` | `./references/status.md` | | Report one project's current work | `report` | `./references/report.md` | | Summarize active todos across projects, grouped by project and person | `summarize` | `./references/summarize.md` | | Draft customer-ready summary text | `customer-summary` | `./references/customer-summary.md` |

If a request could either write or report, ask once before writing. For clear write requests, apply the justified ledger updates and report what changed afterward; do not pause for a confirmation gate.

Project Resolution

Start with `./references/dependencies/conversint-current/references/active-projects.md` when the user mentions active projects, project cleanup, current delivery work, internal operating work, or a project name that may already be active. That file is the shared orientation index: it names current projects and points to their ledgers. It is not a task tracker.

Project IDs, ledger paths, and optional delivery-repo mappings live in `config/project-management.json`.

```bash scripts/python lib/project_manager.py list-projects ```

Use `admin` for internal Conversint work. Customer project ledgers may live flat in `customers/<Customer Name>/` as `<Project Name> - Project Ledger.md` or inside a mapped delivery repo. Website projects should normally use `ledger_repo: "delivery"` with `ledger_path: ".chiefos/Website Project Ledger.md"` plus `delivery_repo_path`, `feedback_ledger_path`, and `default_review_branch`, so project tasks and raw website feedback travel with the site repo. The admin ledger is `./references/dependencies/conversint-current/conversint-admin/active-projects/Internal-Project-Ledger.md`.

If a requested project is not configured and the source clearly identifies the project, initialize it with:

  • project ID
  • customer name, if customer-scoped
  • display project name
  • ledger path
  • ID prefix

If the customer, project name, ledger path, or ID prefix is unclear, ask before creating the config entry.

Data Model

The allowed statuses are:

  • `To do`
  • `In progress`
  • `In review by: <name>`
  • `Blocked`
  • `Done`

Tasks are the only work unit. Handoffs, review asks, customer waits, and agent-session continuations are represented as tasks with enough context for the next person or session to act.

When work originates from an inbound request, preserve the request trail on the task:

  • `Source` names the channel or artifact, such as an email, meeting transcript, Drive Watch item, Vercel comment, Google Doc comment, or agent-session summary.
  • `Request metadata` stores compact reconstruction data: time, from, to, channel, source IDs, URL, document/comment/message/thread IDs, and related task/feedback IDs.
  • `Request verbatim` stores the original request wording when available. Keep it exact enough to compare the completed work back to the request; summarize only when the source is too long and link the full source in `Request metadata` or `Context`.
  • `Evidence` stores broad completion proof: path, URL, preview, test/check result, Drive doc, same-source reply, customer confirmation, or decision note.
  • `Fixed by` stores commit hash(es) when repo-tracked changes satisfy the task. Use it alongside `Evidence`; a commit hash alone is not enough for request-driven work.

`Due` is optional scheduling metadata. It accepts `YYYY-MM-DD`, `YYYY-MM-DD HH:MM`, or `YYYY-MM-DDTHH:MM`; the helper normalizes date+time values to `YYYY-MM-DD HH:MM America/Chicago`. Resolve natural language such as "Wednesday night" before calling the helper.

Use the helper for every ledger mutation:

```bash scripts/python lib/project_manager.py add --project <id> ... [--request-meta "..."] [--request-verbatim "..."] [--due "2026-06-24 20:00"] [--fixed-by abc1234] scripts/python lib/project_manager.py status --project <id> --ids PM-01 --to "In progress" [--request-meta "..."] [--request-verbatim "..."] [--due "2026-06-24"] [--clear-due] [--fixed-by abc1234] [--clear-fixed-by] scripts/python lib/project_manager.py report --project <id> scripts/python lib/project_manager.py summarize --project all ```

Never hand-edit the generated table or task detail blocks. The helper parses detail blocks as the source of truth and regenerates the table on every write.

Run helper mutations serially per project. Do not dispatch multiple `add`, `status`, or `render` commands against the same ledger in parallel; the helper takes a file lock and validates duplicate IDs, but the skill should still treat ledger writes as ordered state changes.

Core Rules

  • Keep ledgers internal by default. Customer-facing summaries are separate drafts created only on request.
  • Do not write to `/todos`; Patrick converts project tasks into personal todos or agent dispatch work separately.
  • Do not update CRM. CRM tracks sales lifecycle; this skill starts after Won.
  • Preserve traceability from inbound requests to tasks. When a task comes from a person, customer artifact, comment, email, transcript, or agent handoff, store the source metadata and original wording in the ledger instead of leaving it only in chat history.
  • Do not ingest `/skill-dev-feedback` items one by one. For customer skill builds, `/skill-dev-feedback` remains the item-level review ledger. `/project-manager` may track a single project-level wrapper task that references the feedback ledger and summarizes the open IDs.
  • Do not ingest website feedback comments one by one. `/website-feedback` owns raw website feedback capture across Vercel, Google Docs, Gmail/email, pasted notes, and repo files. `/project-manager` tracks grouped delivery work from those comments, with evidence pointing to the target repo's feedback ledger and `dev` preview URL, and `Fixed by` pointing to implementation commit(s).
  • For mapped website projects, use the configured `delivery_repo_path` and `feedback_ledger_path` when reporting evidence or routing a user toward raw feedback. Do not assume every website ledger lives in ChiefOS.
  • Do not update structural `references/org/*.md`. Drive Watch and the org drift-check process own those files.
  • Do not create a special handoff state. If work changes hands, create or update a task.
  • Agent-produced customer-visible work should usually move to `In review by: Patrick` or `In review by: Daniel`, not directly to `Done`.
  • `Done` requires evidence: path, URL, decision note, customer confirmation, test result, source reply, or similar. When repo-tracked changes satisfy the task, also set `Fixed by` with the commit hash(es). For request-driven work, evidence should connect the completed change back to the stored request metadata and original wording, not just name the artifact.
  • Approval-gated work requires both ordinary evidence and approval evidence before `Done`. Use approval gates only when they are explicitly requested or clearly required by the source/request; never mark a task `Approval required` silently.
  • When a capture or status update creates or changes a task with a clear due date/time, create or refresh its Google Calendar reminder after the ledger write. When `Due` is cleared, remove its prior reminder. Use `/calendar`'s `project_task_reminder.py`, not Patrick's personal `/todos` or a runtime automation tool. Date-only reminders default to 09:00 America/Chicago on the due date; date+time reminders use the exact due time. The helper includes the creator plus recognized internal owner/reviewer automatically; it excludes customer, vendor, and other external addresses.

High-Risk Approval Watchdog

Use this watchdog for customer-visible work where a client approval trail matters: regulated-content claims, pricing, testimonials, lead forms, publication/deployment approvals, customer commitments, and consequential AI systems. Read `./references/approval-watchdog.md` before evaluating trigger cues.

The watchdog is not a blanket rule for regulated customers or all AI work. When a hard trigger appears without an explicit approval request, report a sourced `RECOMMEND APPROVAL GATE`; do not mutate `Approval required`. Set that field only when the user/source explicitly requires approval before release, then record exact-final approval evidence before `Done`.

Standard Write Flow

1. Resolve the project and read the existing ledger. 2. Interpret the user's notes against existing task detail blocks. 3. Decide the write batch: - new tasks - already tracked tasks to skip - possible duplicates or ambiguities that require a question before writing - status updates 4. If the batch has no unresolved ambiguity, run the helper commands for the chosen changes. 5. Commit the changed ledger once with the helper's `commit` command. 6. Surface a compact report: what was added, updated, skipped as already tracked, and the ledger path + GitHub URL from the commit output.

Helpful Commands

```bash # list configured project scopes scripts/python lib/project_manager.py list-projects

# one-project report scripts/python lib/project_manager.py report --project admin

# cross-project summary scripts/python lib/project_manager.py summarize --project all

# commit after a write batch scripts/python lib/project_manager.py commit \ --project admin \ --message "project-manager: update active projects" ```

Next

Load the reference file for the selected mode and follow it.