Engagement Setup

Initialize a cogni-consult engagement: frame the desired outcome with the consultant, scaffold the action-fields-WBS directory structure, bind the one cogni-knowledge base the whole engagement compounds research into, and register the engagement for cross-session discovery. This is the entry point — without it, no later skill has a project to write to.

Setup deliberately stays light: it captures the outcome and the research spine, nothing more. The SMART key question, the five scoping dimensions, and the 3-6 action fields are consult-scope's job; the two default advisor personas (consulting-partner, project-manager) now ship at scaffold so personas/ is never empty, while engagement-specific scope-seeded stakeholder personas still come from consult-personas; deliverables emerge inside action fields. If an engagement already exists for this client/topic, do not create a duplicate — dispatch Skill("cogni-consult:consult-resume") to re-enter it.

Workflow

1. Gather Engagement Context

Collect these fields, extracting whatever the user already provided and asking only for what is missing:

• Engagement name: Descriptive name (e.g., "ACME DACH Cloud Expansion")
• Client: Company or organization name
• Desired outcome: One sentence describing what success looks like
• Market: One of dach, de, fr, it, pl, nl, es, us, uk, eu — collected explicitly, never derived from language (the mapping is ambiguous, e.g. de could mean dach or de)
• Language: ISO 639-1 deliverable/output language for the engagement's artifacts (default en). This is the deliverable axis only — the user-facing conversation follows the separately-resolved interaction language (see $CLAUDE_PLUGIN_ROOT/references/interaction-language.md), so do not set this field to match how the user happens to be writing.

Derive the engagement slug from the name in kebab-case — short and recognizable.