Culture

/culture

Two modes:

1. Internal mode (default). Other workflow skills — and /cheese itself — invoke /culture silently as a thinking pass: restate the question, list assumptions, name candidate options, run a quick shape check, pick the next action. The dialogue does not surface to the user; only the resulting decision (carrying its record ledger) and any code edits the calling skill makes do. The most common callers are:

• /cheese step 1 — silent classification reasoning before announce.
• /cheese tier-2 escalation (see skills/cheese/SKILL.md § Escalation) — fills missing context when the cook-fast-path clarity check fails on the raw input; the synthesis lands in the mini-spec's ## Provenance section.
• Other workflow skills' own pre-dispatch reasoning passes (mold, cook taste-test, etc.).

1. User-facing mode. The user wants to think, not build: no production code, no spec, no PR. This is culture's sustained domain-modeling mode — investigate as deeply as the question needs, hold it open across turns and sessions rather than forcing convergence, record ideas, decisions, and info as they settle (## Record ledger), and end by writing a durable /wheypoint so the modeling resumes later. Reach this mode when the user said "no writes" / "rubber-duck this" / "just talk", or routed a thinking-and-modeling task here.

Do not use the user-facing mode when the user wants a written spec (/mold), implementation (/cook), review (/age), or external evidence gathering (/briesearch) — those targets get the internal-mode call instead, and the calling skill does the work.

Invariant

/culture writes no production code and no spec, and does not commit changes, open PRs, or mutate project state. What it does write is knowledge. In user-facing mode it records ideas, decisions, and info through the ## Record ledger, and ends every session by writing a durable handoff, delegated to /wheypoint (see ## Handoff slug); that wheypoint is written at session end only, never during the dialogue. The user declares the session over — the agent never declares convergence on the user's behalf; it may ask whether the thread feels settled, and otherwise carries it forward. In internal mode it writes nothing at all and hands its ledger back to the caller. If a user-facing conversation reveals that something should be built, route to /mold or /cook after the wheypoint is written. In internal mode, just return the decision and let the calling skill act.

Flow

Both modes share this reasoning loop; the per-step difference is internal-returns-a-decision vs user-facing-renders-the-dialogue.

1. Restate the question or tension in one sentence. If the question rests on a false premise or a loaded assumption, name it.
2. Identify assumptions, constraints, and decision criteria.
3. Explore trade-offs and likely blast radius. When the trade-off hinges on "what does this touch", run a read-only shape check on the candidate seam — semantic caller search plus dependency/blast-radius context from the selected backend — and label each option [low | medium | high blast radius]. Procedure mirrors ../mold/references/shape-check.md; culture stops at the verdict and never drafts signatures. Steelman the rejected option before settling on a recommendation.
4. Gather evidence to the depth the question needs. Start with a light wiki probe — is this already decided or already known? — per the detect-and-degrade contract in `../cheese/references/optional-plugins.md`: at most one ground call in internal mode, scaled up as useful in user-facing mode; when hallouminate is absent, skip, note the absence once, and cap confidence at speculating when design rationale is central. In internal mode keep the rest light — a quick shape check, no deep research — so the calling skill stays fast. In user-facing mode investigate as deeply as useful: dispatch the read-only explorer agent for code grounding and take back its digest, rather than dumping raw reads into the dialogue; when that agent is unavailable, call the selected source-code backends directly.
5. Decide the next move. In internal mode, return a single recommendation and stop. In user-facing mode you need not force convergence: render a compact summary, the Ideas / Decisions / Info ledger, and confidence-tagged open questions (certain | speculating | don't know), then either recommend a downstream skill or defer and carry the thread forward. Once the user calls the thread over, flush the ledger, then end the session by writing the wheypoint (## Handoff slug), whose next: records where the modeling landed.

Asking the user is the point: every consequential fork is theirs to decide, surfaced as a choice rather than settled for them. A fork is consequential per the leverage line in ../age/references/voice.md; everything below it is [AGENT-DECIDED] with a vetoable alternative. The depth you offer — full signatures, named edge cases, file:line evidence — informs each question; it never substitutes for asking it. In user-facing mode, raise forks conversationally in the dialogue; reserve structured question tools for the end-of-session handoff gate. Never bundle multiple consequential forks into one prompt.

Record ledger

Thinking is worth keeping. Each user-facing round prints an Ideas / Decisions / Info ledger beside the open questions, and every entry lands in the durable knowledge lane, never in code:

Resolve the target the way adr_target() does: shape-match the current repo's repo:<repo>:wiki corpus, never a literal name; when hallouminate is absent, write the tracked fallback and say so in one loud line. Write an entry the moment the user says record that, note that, or remember that; flush the rest once the user calls the thread over, before the wheypoint, which then links each record under its artifacts. Never record a passing thought the user did not settle or ask to keep — those stay in the wheypoint. Internal mode writes nothing: it returns the ledger inside its decision so the calling skill persists it (Mold's Curdle turns decisions into ADRs; a mini-spec cites them under ## Provenance).

Preferred tools and fallbacks

Call source-code search and read backends directly according to `code-intelligence-routing.md`. Blast-radius reads use semantic caller search plus a read-only dependency/shape check when the backend offers one.

Beyond source-code routing there are culture-specific tools: