intake

name	intake
description	Use when starting requirements gathering for a new companion. Draws out requirements through guided reverse prompting conversation. Discovers persona and capability fit through dialogue.
disable-model-invocation	true
argument-hint	[persona] [client/companion]

/intake — New Companion Reverse Prompting

Draw out companion requirements through guided conversation. Discovers which persona and capabilities fit through conversation.

Usage:

• /intake — Use current companion, discover persona through conversation
• /intake [client/companion] — Override for specific companion
• /intake [persona] — Start with a known persona for current companion
• /intake [persona] [client/companion] — Both persona and companion

Personas accelerate intake with persona-specific questions. Available personas are in companion-kits/public-kits/personas/ and companion-kits/private-kits/[org]-companion-kit/personas/.

---

Step 1: Determine the Companion

1. If $ARGUMENTS contains a companion path, use that

2. Otherwise, read tracking/current-companion.md for the current companion

3. If no companion is set and no argument given, ask the user to set one first:

   No companion set. Use /companion to set or create one first:
     /companion new [client/companion]
   

4. Verify the companion directory exists at companions/[client]/[companion]/

Determine the organization from the client portion of the path (e.g., consortium.team from consortium.team/my-companion).

Build the accessible kits list by reading tracking/permissions.yaml:

• Always include: companion-kits/public-kits/
• Always include: companion-kits/private-kits/[client]-companion-kit/ (derived from companion path)
• Also include each kit in always_accessible_private_kits from permissions.yaml (e.g., companion-kits/private-kits/[kit-name]/)

This list determines where to search for personas, capabilities, and library materials throughout intake.

---

Step 2: Check Existing Context

Read any existing context files in companions/[client]/[companion]/context/:

• requirements.md
• constraints.md
• decisions.md

If context already exists, acknowledge it:

I see some context has already been captured for [companion]:
- [summary of what exists]

We can continue from here, or start fresh. What would you prefer?

---

Step 2b: Load Persona (if specified)

If $ARGUMENTS contains a persona name, search for it:

1. Search for the persona across all accessible kit directories (from Step 1):

   • companion-kits/public-kits/personas/[persona]/PERSONA.md
   • companion-kits/private-kits/[kit]/personas/[persona]/PERSONA.md for each kit in the accessible kits list

2. Read the persona's files:

   • PERSONA.md — Identity, voice, key concepts
   • intake-guide.md — Persona-specific questions
   • typical-capabilities.md — Which capabilities this persona typically uses
   • reference-projects.md — What worked before (if exists)

3. Note the persona in context/decisions.md:

   | Persona: [persona] | Loaded from companion-kits/{public-kits,private-kits}/[org]-companion-kit/personas/[persona] | [date] |
   

4. Use the persona's intake questions in addition to the core questions below. Persona questions help reach known-good configurations faster.

If no persona was specified, proceed to Step 3 — the conversation will discover which persona fits (see Step 4b).

Important: Personas are accelerators, not constraints. They get you to a good starting point. The methodology ("start wrong, iterate to right") handles adaptation through usage.

---

Step 3: Begin Reverse Prompting

Your role: Draw out what the user knows. Don't assume or generate requirements — extract them.

Core principle: Ask ONE question at a time. Let the answer inform the next question.

Start with:

Let's capture what this companion is about. I'll ask questions one at a time.

What problem does [companion] solve? Or put another way — why does this companion need to exist?

---

Step 4: The Question Sequence

Work through these areas, but adapt based on answers. Don't mechanically go through a checklist — let the conversation flow naturally while ensuring coverage.

If a persona is loaded: Weave the persona-specific questions from intake-guide.md into the flow below. Persona questions often provide better specificity for their domain.

1. Purpose (start here)

• What problem does this solve?
• Why does it matter? What happens if it doesn't get built?
• What's the "one thing" this companion must do well?

2. Users

• Who will use this?
• What do they need that they don't have today?
• What's their current workaround?
• Are there different types of users with different needs?

3. Success Criteria

• How will you know it's working?
• What does "done" look like?
• What would make this a failure even if it "works"?

4. Constraints

• Technical constraints (language, platform, integrations)?
• Time constraints?
• Resource constraints?
• Organizational constraints (approvals, dependencies)?

5. Context

• Related systems or prior art?
• Existing patterns to follow or avoid?
• Domain knowledge needed?

6. The Quality

• What makes this companion distinct from similar ones?
• What's the "feel" you're going for?
• If you had to explain this to someone in one sentence, what would you say?

---

Step 4b: Suggest Persona Match (if no persona was specified)

After covering the core questions (especially Purpose, Users, and The Quality), suggest which persona fits best.

Scan available personas:

1. Read all PERSONA.md files from all accessible kit directories (from Step 1):

   • companion-kits/public-kits/personas/*/PERSONA.md
   • companion-kits/private-kits/[kit]/personas/*/PERSONA.md for each kit in the accessible kits list

2. Compare the captured requirements against each persona's "When to Use" criteria.

3. Present the best match(es):

   Based on what you've described, this sounds like a **[persona name]** companion:
   [1-2 sentence summary of why this persona fits]
   
   This persona typically includes these capabilities:
   - [capability 1] — [brief description]
   - [capability 2] — [brief description]
   
   Does this feel right, or is this something different?
   

4. If the user confirms, load the persona's intake-guide.md and typical-capabilities.md, then ask the persona-specific questions that weren't already covered.

5. If the user says it's different, continue with generic intake and note that this may be a new persona pattern.

---

Step 4c: Suggest Capabilities

After the persona is identified (or if no persona fits):

1. Read the persona's typical-capabilities.md for recommended capabilities.

2. Scan available capabilities across all accessible kit directories (from Step 1):

   • companion-kits/public-kits/capabilities/*/CAPABILITY.md
   • companion-kits/private-kits/[kit]/capabilities/*/CAPABILITY.md for each kit in the accessible kits list

3. Suggest capabilities based on conversation:

   For this companion, I'd recommend these capabilities:
   
   **Core (always included):**
   - Reverse Prompting — [why it fits]
   - Context Ecosystem — [why it fits]
   
   **Recommended based on what you've described:**
   - [Capability] — [why it fits, based on specific things the user said]
   
   **Available but probably not needed yet:**
   - [Capability] — [what it does, why it's not urgent]
   
   Which of these resonate? Anything you'd add or remove?
   

4. Record selected capabilities in context/decisions.md.

---

Step 4d: Suggest Library Materials

Scan libraries across all accessible kits (from Step 1) that have a library/ directory:

1. Scan library entries:

   • Read metadata.yaml files in companion-kits/private-kits/[kit]/library/**/metadata.yaml for each kit in the accessible kits list

2. Match by subject tags and persona relevance:

   • Compare library entry subjects and related_personas against the companion being created

3. Suggest relevant materials:

   Your organization's library has materials that could be useful for this companion:
   
   - [Book Title] by [Author] — [how it's relevant to this companion]
   - [Book Title] by [Author] — [how it's relevant]
   
   Want to pull any of these into this companion's reference?
   

4. Record library selections in context/decisions.md.

Note: Library materials are contextualized for each companion during the build phase, not during intake. The selection here determines which materials to contextualize.

---

Step 5: Push for Specificity

When answers are vague, push deeper:

Vague	Push for
"Users need it to be fast"	"What's fast? Sub-second? What operations?"
"It should be easy to use"	"Easy for whom? What's hard about current options?"
"Various stakeholders"	"Name one. What do they specifically need?"
"Standard security"	"What data is sensitive? What's the threat model?"

Good answers are concrete. "A developer who needs to..." beats "users." "Under 200ms response time" beats "fast."

---

Step 6: Capture as You Go

After each major area is covered, write to the appropriate context file:

context/requirements.md — What the companion must do

# Requirements

## Purpose
[Why this exists, the problem it solves]

## Users
[Who uses it, what they need]

## Success Criteria
[How we know it's working]

## Core Functionality
[The must-haves]

context/constraints.md — Boundaries and limitations

# Constraints

## Technical
[Platform, language, integration requirements]

## Timeline
[Deadlines, phases]

## Resources
[Team, budget, dependencies]

## Organizational
[Approvals, policies, external dependencies]

context/decisions.md — Choices made during intake

# Decisions

Decisions made during companion intake.

| Decision | Rationale | Date |
|----------|-----------|------|
| Persona: [name] | [why this persona fits] | [date] |
| Capabilities: [list] | [why these were selected] | [date] |
| Library materials: [list] | [why these are relevant] | [date] |
| [other decisions] | [why] | [when] |

---

Step 7: Summarize and Confirm

After covering the key areas:

1. Summarize what was captured (brief bullet points)

2. Identify gaps — what's still unclear or missing?

3. Confirm with the user:

   Here's what I've captured:
   
   **Purpose:** [one sentence]
   **Users:** [who]
   **Success looks like:** [criteria]
   **Key constraints:** [list]
   **What makes it distinct:** [the quality]
   
   **Companion composition:**
   - Persona: [name or "custom"]
   - Capabilities: [list]
   - Library materials: [list or "none"]
   
   Gaps remaining:
   - [what's still unclear]
   
   Does this capture it accurately? Anything to add or correct?
   

4. Write final versions of context files after confirmation

---

Step 8: Suggest Next Steps

Context captured for [companion].

Next steps:
  /process   — Feed in any existing documents or transcripts
  /gaps      — See full assessment of what's captured vs. needed
  /checkpoint — Save session state before ending

---

Principles

• One question at a time — Don't overwhelm
• Listen more than talk — Your job is to extract, not generate
• Push for concrete — Vague requirements become vague companions
• It's okay to not know — "Not sure yet" is valuable information
• Capture decisions — Why something was decided matters as much as what
• The quality matters — What makes this distinct is often the key insight
• Discover, don't prescribe — Let the conversation reveal which persona and capabilities fit