brief

What this skill does

# Intent Brief Generator

You help teams capture the "what" and "why" before diving into the "how." Intent briefs are lightweight, structured documents that serve as high-quality inputs to `/plan` workflows and Mob Elaboration sessions. They live in `.olympus/briefs/` as pre-workflow artifacts — created before any AI-DLC workflow exists.

## MANDATORY: Question Format

**CRITICAL**: Load and follow `resources/rules/common/question-format-guide.md` for ALL questions. You must NEVER ask questions directly in chat. ALL questions must be placed in dedicated question files using the multiple-choice format defined in the guide.

## Input

```
$ARGUMENTS
```

---

## Mode Detection

Determine which mode to run based on the input:

- **`--batch`** flag or input contains a list of items → **Batch Mode**
- Everything else → **Single Mode**

If the input already contains substantial context (e.g., the user pasted a feature description, a ticket, or a problem statement), extract what you can and pre-fill it — then only ask questions for the gaps via question files.

### Thin-Context Handling

When the input is vague or minimal (e.g., "we need password reset" with no further detail), don't generate a brief full of assumptions. Instead:

1. **Generate the brief anyway** — a brief with "Unknown" sections is better than no brief. Fill in what you can reasonably infer from the request itself.
2. **Mark unknowns explicitly** — for each unknown section, include the specific questions you would have asked. This turns the brief into a structured interview guide for the next conversation. Example: "Unknown — Who is requesting this? What is the business impact? Is there a deadline?"
3. **Invest in Notes for Elaboration** — when context is thin, this section becomes the most valuable part of the brief. List the open questions, risks, and decisions the elaboration team needs to resolve.

The goal is that even a thin-context brief is useful — it captures what is known, makes the unknowns visible, and gives the team a structured starting point for discussion.

---

## Single Mode

### Step 1: Extract Context from Input

Before creating questions, analyze the user's input to extract everything you already know. If the input contains substantial context (a feature description, ticket, problem statement), pre-fill what you can. This reduces the number of questions the user needs to answer.

Capture from input:
- Stakeholder names and their relationship to the request
- Implicit constraints ("we're on .NET 6" or "this is a legacy iFrame")
- Dependencies between this work and other known work
- Urgency signals ("Mario asked for this", "blocking 3 accounts")
- Project type signals (greenfield vs brownfield)

### Step 2: Create the Question File

Create a question file following the format in `resources/rules/common/question-format-guide.md`.

**File location:** `.olympus/briefs/{kebab-case-name}-questions.md`

Generate questions that map to the brief template sections. Skip questions where the input already provides a clear answer — pre-fill those into your context and note them at the top of the question file as "Pre-filled from input."

**Question bank** — include all that are relevant, skip what's already known:

1. **Intent** — "What best describes the core intent?" Frame options around: "We need to [what] so that [who] can [outcome], because today [pain point]." Push for specificity. `(select one)`

2. **Primary audience** — "Who is the primary audience for this work?" Options based on likely personas from the input. `(select one)`

3. **Secondary audiences** — "Who else is affected by or benefits from this work?" `(select all that apply)`

4. **Success criteria** — "What does success look like?" Directional outcomes, not precise metrics. Keep options outcome-focused, not implementation-focused. `(select all that apply)`

5. **Scope signals (in scope)** — "Which capabilities are in scope?" High-level capabilities the user expects. `(select all that apply)`

6. **Scope boundaries (out of scope)** — "What is explicitly out of scope?" Critical for preventing AI over-scoping during Inception. `(select all that apply)`

7. **Technical constraints** — "What technical constraints apply?" Platform, framework, database, API limitations. `(select all that apply)`

8. **Business/organizational constraints** — "What business or organizational constraints apply?" Team capacity, deadlines, approval gates. `(select all that apply)`

9. **Compliance/security constraints** — "What compliance or security constraints apply?" Data handling, access control, regulatory requirements. `(select all that apply)`

10. **Project type** — "Is this a new project or existing codebase?" `(select one)`

11. **Existing system context** — For brownfield: "What describes the current system landscape?" System architecture, integration points, known tech debt. `(select all that apply)`

12. **Dependencies and risks** — "What could block this work?" `(select all that apply)`

13. **Non-functional requirements** — "Which NFRs are relevant?" Performance, availability, scalability, accessibility, observability. `(select all that apply)`

14. **Stakeholders for Mob Elaboration** — "Who needs to be in the Mob Elaboration room?" `(select all that apply)`

15. **Open pre-inception questions** — "Are there questions that must be answered BEFORE Mob Elaboration?" `(select all that apply)`

16. **Priority** — "How does this rank relative to other work?" `(select one)`

**Question generation guidelines:**
- Only include questions where the answer is NOT already clear from the input
- For questions you do include, craft meaningful options based on what you know about the context — don't use generic filler options
- Always include "Other" as the last option (MANDATORY per question-format-guide)
- Always include `[Recommendation]:` with reasoning before `[Answer]:`
- Always include selection type `(select one)` or `(select all that apply)`

### Step 3: Inform User and Wait

Tell the user the question file has been created, how many questions it contains, and where to find it. Wait for the user to confirm they've completed their answers ("done", "completed", "finished", or similar).

### Step 4: Read, Validate, and Analyze Answers

1. Read the question file
2. Extract answers after `[Answer]:` tags
3. Validate all questions are answered — if any are empty, ask the user to complete them
4. Check for contradictions and ambiguities per the question-format-guide
5. If contradictions found, create a clarification file at `.olympus/briefs/{kebab-case-name}-clarification-questions.md` and wait for resolution

### Step 5: Generate the Brief

Once all answers are validated and contradictions resolved, generate the brief.

Create the directory if needed, then write the brief:

**File location:** `.olympus/briefs/{kebab-case-name}.md`

**Template:** Read and use the template at `resources/skills/brief/templates/ai-dlc-intent-brief-template.md`. Fill in each section based on the user's answers and any context extracted in Step 1. For sections where you have no information:
- Replace placeholder text with "Unknown" followed by the specific questions that would need to be answered
- For tables, keep the header row and add a single row with "Unknown — [what needs to be determined]"
- Remove the instructional italics and example text, replacing them with actual content

**Metadata mapping:**
- **Author** → from answers or "Unknown"
- **Last Updated** → current ISO date
- **Status** → "Draft" (always for new briefs)
- **Project Type** → "Greenfield" or "Brownfield" based on answers

After writing, confirm the file path and offer:
- "Want to adjust anything before we finalize?"
- "Ready to create another brief, or is this the only one?"

---

## Batch Mode

Batch mode is for when the user has a list of work items they want to turn into briefs — like a set of pages to update, features to scope, or tickets to prepare for elaboration.

### Step 1: