Track consulting engagement progress and milestones.
/engagement-tracker <client-name> <--action status|update|milestone>
--type status-updateWhat is RAG? RAG (Red/Amber/Green status indicator) tracks engagement health across five dimensions: schedule, scope, resources, quality, and stakeholder. Each dimension rates as Red (blocked/at risk), Amber (issues in progress), or Green (on track). The overall engagement RAG is the worst status across all dimensions.
/engagement-tracker acme-corp
What you’ll see: an ASCII dashboard — per-phase progress bars and milestone checklists, overall progress, key metrics (days elapsed, on-track yes/no), a RAG summary across schedule/scope/resources/quality/stakeholder, blockers, and next actions — also written to tracking/status.md.
/engagement-tracker acme-corp # default action: status dashboard
/engagement-tracker acme-corp --action status # same, explicit
/engagement-tracker acme-corp --action update # add a dated progress log entry
/engagement-tracker acme-corp --action milestone # mark a milestone complete (e.g. "D3")
| Flag | Values | Default | What it does |
|---|---|---|---|
--action |
status update milestone |
status |
Dashboard, dated log entry, or milestone completion |
--date |
YYYY-MM-DD |
today | Backdate milestone completion to a past date (milestone action only) |
clients/<client-name>/engagement.json. On first run it creates the file with four tracked phases (Discovery & Assessment, Analysis & Strategy, Solution Design, Deliverable Creation), each with predefined milestones (locked phase structure; you cannot create custom phases or milestones, but you can edit milestone names in engagement.json directly if needed). User-confirmation checkpoint: when creating fresh, it prompts you for the start date and target end date.status — renders the full ASCII dashboard: progress bars per phase, milestone checklists with completion dates, overall progress, key metrics computed from the dates (time used %, on-track), the five-dimension RAG summary (overall RAG = worst dimension), blockers and risks, next actions, and recent updates. Written to tracking/status.md and shown in the terminal. Important: RAG ratings default to GREEN — you must update them with justifications during status updates to avoid all-green dashboards.update — user-confirmation checkpoint: prompts for the update details (or accepts them in the invocation), then appends a dated entry — activities completed, decisions, risks/issues, next steps — to tracking/updates.md, updates engagement.json (next actions, blockers, RAG ratings with justifications, phase progress), and regenerates the dashboard.milestone — displays the current milestone list with IDs, prompts you for the milestone ID to mark complete (or accepts it as a parameter), updates the milestone and recalculated phase progress in engagement.json, appends a completion entry to tracking/milestones.md, shows a confirmation box, and regenerates the dashboard. When all milestones in a phase complete, the phase automatically closes and advances to the next phase — you will see a notification confirming which phase is now active.Updates and milestone entries are always appended — previous entries are never overwritten.
All under clients/<client-name>/:
engagement.json — engagement state: phases, milestones, RAG, blockers, next actions, update logtracking/status.md — the ASCII dashboard (regenerated after every action)tracking/updates.md — append-only dated progress logtracking/milestones.md — append-only milestone completion records| Problem | Fix |
|---|---|
| Dashboard looks stale | Re-run --action status — the tracker also regenerates automatically when tracking/status.md is older than the latest update |
| Marked the wrong milestone | Milestone status lives in engagement.json — ask to set that milestone back to pending and the progress recalculates |
| Completed a milestone last week, not today | Use --date YYYY-MM-DD to backdate the completion |
| Everything shows GREEN by default | RAG ratings must be justified — challenge unexplained greens; the quality checklist requires justification, not defaults |