# Design conversations and capture

```
Type: knowledge
```

Design work has two phases: a lightweight conversation that helps Cameron
understand and choose, followed by repository capture only after a direction is
adopted. The split keeps exploration clear and prevents questions from turning
prematurely into project law.

## Phase 1: conversation

Use `.agents/skills/design-companion/SKILL.md` for riffs, comparisons,
terminology questions, confusion, and requests for an opinion.

1. **Answer first.** Give the direct answer before history, caveats, or system
   taxonomy.
2. **Make it concrete.** Explain one model and one turn-of-play example.
3. **Take a position.** Recommend a direction and name its most important
   tradeoff. Do not merely restate Cameron's idea.
4. **Repair confusion by simplifying.** If the explanation created confusion,
   withdraw unsupported abstractions and rebuild from familiar nouns. Do not
   invent a new resource or mode to explain the previous one.
5. **Stay conversational.** Questions and unresolved riffs do not create a
   worktree, issue, spec, devlog, commit, or implementation task.

Aim for 80-180 words by default. Prefer short paragraphs, one worked example,
and no more than one new abstraction per answer. Distinguish current runtime,
decided design, and proposals only when the distinction helps answer the
question.

## The capture gate

Move to capture only when Cameron explicitly adopts the direction or requests
an artifact. Examples include "I like that," "yes, use that," "lock it in,"
"capture this," "write/spec this," and an implementation request.

"What about...?", "I'm confused," and "okay, but..." are still conversation.
They do not affirm every detail in the preceding explanation. If adoption is
ambiguous and capture would materially change project law, stay in conversation
or ask one short question.

## Phase 2: capture

Use `.agents/skills/design-session/SKILL.md` after the gate is crossed.

1. **Sort what was actually adopted.** Use DECIDED, OPEN, and DEFERRED. Do not
   turn agent inference into a decision. An intentionally requested option
   packet may use PROPOSED, but ordinary brainstorming remains in chat until it
   is accepted.
2. **Record current design once.** Amend the owning `Type: law` page for
   durable intent and/or `Type: spec` page for exact behavior. Do not copy the
   same rule across pages. A spec's `Design:` field uses checked
   `wiki/path.md#heading-anchor` references to the binding clauses it realizes.
3. **Append history.** Add an entry to the current daily volume under
   `wiki/log/decisions/`, including
   important rejected alternatives so future agents do not re-propose them.
   The log explains the change; it does not make the rule current.
4. **Externalize only intentional open calls.** A genuine taste call Cameron
   leaves for later may become a Tangled issue following the binding format in
   [tick.md](tick.md), labeled `decision-required`. Do not file narrative dumps
   or questions that are still being discussed live.
5. **Close the capture phase.** Add the appropriate dated devlog and significant
   ledger entry, run proportionate checks, make defense-bearing commits when
   required, and land the work. Update knowledge pages made stale by the
   decision.

Capture work is repository work: create a task worktree before the first
write. Patch tools do not all honor a shell working directory, so verify their
path base and check that the shared primary checkout remains unchanged. When a
capture follows or overlaps a corpus migration, rebase semantically: inspect
concurrent commits file by file and move their current decisions into the new
single owner instead of restoring an obsolete authority surface.

## House style for captured design

- Vivid and precise beats formal. Use second person when it clarifies the
  player's experience.
- Attach the design reason to every mechanic, not just the rule.
- Put numbers in law only when the threshold defines the feel; otherwise use
  `[TUNE]` in specs and runtime actuals in
  `wiki/mechanics/sim-mechanics.md`.
- Keep game strings ASCII-only.

## Concurrency etiquette

Cameron runs multiple agents. Pull before working, push promptly, and stage
only the intended files. Reconcile concurrent append-only source logs by
preserving both; regenerate `DEVLOG.md` and `specs.md` projections after their
sources are combined. Never revert another session's work to make a capture
easier.