Run a full AI consulting engagement.
/consulting [client-name] [--phase discovery|assess|propose|design|deliver|track] [-- brief]
Each phase delegates to a specialist skill — the phase will fail if its skill isn’t installed:
| Phase | Delegated skill |
|---|---|
discovery |
/client-discovery |
assess |
/opportunity-map |
propose |
/pitch-generator, /roi-calculator |
design |
/solution-architect |
deliver |
/deliverable-builder |
track |
/engagement-tracker |
Run /skills to confirm all six are installed before starting a full engagement — a missing sub-skill surfaces as a phase failure, not a clear “skill not found” message.
/consulting acme-corp -- AI readiness assessment for a mid-market logistics firm
What you’ll see: a new client workspace at consulting-toolkit/clients/acme-corp/ with engagement.json and a profile.md stub, then the discovery phase kicks off via /client-discovery.
/consulting acme-corp # resumes if engagement.json exists, else initializes at discovery
/consulting acme-corp --phase propose # jump straight to the proposal phase
/consulting acme-corp -- brief context here # new engagement with a free-text brief
/consulting # no client name — dashboard of all active engagements
Note: /consulting <client-name> with no --phase flag doesn’t always “resume” — it resumes only if consulting-toolkit/clients/<client-name>/engagement.json already exists. On a brand-new client name it initializes a fresh engagement at the discovery phase instead.
| Flag | Values | Default | What it does |
|---|---|---|---|
[client-name] |
— | (omit for dashboard) | Client identifier used for directory naming and file lookups |
--phase |
discovery assess propose design deliver track |
resume from saved state | Jump to a specific engagement phase |
-- <brief> |
free text | none | Engagement context or specific request |
consulting-toolkit/clients/<client-name>/engagement.json if it exists and resumes from the current phase; otherwise creates the client directory, engagement.json (phase statuses, decisions, risks, value tracking), and a profile.md stub.discovery → /client-discovery — interviews, tech assessment, stakeholder mappingassess → /opportunity-map — maturity scoring, priority matrixpropose → /pitch-generator + /roi-calculator — proposal and ROI modelsdesign → /solution-architect — architecture, build-vs-buy, sprint plandeliver → /deliverable-builder — final deliverables package, handoff docstrack → /engagement-tracker — status reports, value trackingengagement.json, and generates a phase transition summary. User-confirmation checkpoint: it always confirms with you before advancing to the next phase — it never auto-advances.engagement.json.After each phase it prints a context-hygiene tip: start a fresh session per phase (/clear, then /consulting <client> --phase <next>) — engagement state lives in engagement.json, so nothing is lost.
Cost and time: a full 6-phase engagement runs ~200-300 units of model spend and spawns 7+ sub-skill invocations sequentially (one or more per phase), each of which may spawn its own agents. Expect this to be a multi-session effort — budget a session per phase rather than expecting one pass to finish everything.
consulting-toolkit/clients/<client-name>/engagement.json — engagement state: phases, deliverables, decisions, risks, value captured (written by /consulting itself)consulting-toolkit/clients/<client-name>/profile.md — client profile (filled in across phases, written by /consulting itself)clients/<client-name>/ — note this is a different root than the consulting-toolkit/clients/ path above, since each delegated skill (/client-discovery, /opportunity-map, /pitch-generator, /solution-architect, /deliverable-builder, /engagement-tracker) manages its own output location. Always pass the exact same <client-name> to every phase skill, or later phases won’t find earlier phases’ files.| Problem | Fix |
|---|---|
| Engagement resumes at the wrong phase | The saved current_phase in engagement.json drives routing — pass --phase <name> to override |
| Phase skill reports missing discovery/assessment data | Phases build on each other — run the earlier phase first (e.g. /consulting <client> --phase discovery) |
| Analysis feels muddied after several phases in one session | Start a fresh session per phase: /clear, then /consulting <client> --phase <next> — state reloads from engagement.json |
| Two clients’ context bleeding together | Always /clear between clients — client context must never cross engagements |