MCPInstall

culture

Models problems and trade-offs without writing code or specifications. Use when a workflow needs silent reasoning, or the user asks for "/culture", "no writes", "rubber-duck this", or "these bugs feel connected". Not for specs (/mold), code (/cook), or bug diagnosis and fixes (/pasteurize).

Installs
647
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/paulnsorensen/easy-cheese --skill culture
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads culture automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

/culture

Two modes; the invocation context, not a user flag, selects the mode:

  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.).
  2. 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", asked to think through a problem ("these bugs feel connected", "I want to understand before fixing"), 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), a bug diagnosis or fix (/pasteurize), review (/age), or external evidence gathering (/briesearch) — those targets get the internal-mode call instead, and the calling skill does the work.

Conversational navigation (prototype)

Inside a user-facing session, the user steers problem levels by ordinary conversation; this is navigation, not a separate entry path. Altitude navigation supplements the Flow below. Suggest a useful change of altitude when evidence indicates a pattern or a gap between behavior and goals. State the interpretation and stay within the agreed evidence scope. A suggestion does not authorize a broad audit or downstream transition. Read Problem altitudes when moving between levels, testing shared causes, or drawing relationships. Keep silent internal reasoning unchanged; it does not load the reference or start a user interview. Culture still owns the record ledger and session-end handoff. For behavioral evaluation, use the pressure scenarios.

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:

KindWhat qualifiesTarget with hallouminateFallback without it
Decisiona fork the user settled that had a real rejected alternativean ADR under adr/ in repo:<repo>:wiki, in the format and resolution of ../mold/references/adr.mddocs/adr/<slug>-NNN.md
Ideaa direction worth revisiting that nobody committed toideas/<slug>.md in the wikidocs/culture/<slug>.md § Ideas
Infoa fact, constraint, or gotcha learned mid-dialoguefold into the wiki page it extends (ground → read_markdown → add_markdown { overwrite: true }); a new page only when nothing fitsdocs/culture/<slug>.md § Info

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:

NeedPreferFallback
Visualizing diffs or examplesdeltaplain git diff
External sanity check/briesearchclearly mark as an assumption
Wiki grounding (evidence step, ≤1 ground in internal mode)mcp__hallouminate__list_corpora + mcp__hallouminate__ground on repo:<repo>:wiki — see ../cheese/references/optional-plugins.mdskip; note the absence once; cap at speculating when design rationale is central

Missing optional tools should not interrupt the conversation. In internal mode keep tool use light; it is a fast thinking pass. In user-facing mode tool use scales to the question — investigation through the explorer agent, or direct source-code backend calls when it is unavailable, is expected when the modeling needs grounding.

Output

See Flow step 5.

Handoff slug

Every user-facing session ends by writing a durable wheypoint, so the modeling is resumable. Invoke /wheypoint <focus> and let it own compaction, secret redaction, the state-mapped suggested-skills section, and the resumable slug. Culture does not maintain its own schema; the slug contract (status / next / mode / artifact and the ## Document body) is defined in skills/wheypoint/SKILL.md, which is the single source of truth.

Culture-relevant next: values: culture or hold to resume the modeling in a later session (defer convergence), mold (fuzzy idea, route to spec), cook (clear ask, route to implementation), or done when the user judges the thread genuinely closed. When the next step is blocked on a human decision, set status: gated: rather than a next: value.

Handoff

Pipeline: [culture] → mold → cook (⇄ press) → age → cure → plate

At session end, write the durable wheypoint first (invoke /wheypoint), then — when the conversation reveals real work — ask via the shared handoff gate in ../cheese/references/handoff-gate.md. Any structured confirm reaching this gate must satisfy the freshness rule in ../cheese/references/ask-user-question.md — only a fork already discussed conversationally this session may reach a structured question here. Lead each option with the verb (what the user wants to do next); the skill command is the backing detail. Before asking, render a compact context packet so the downstream skill can dispatch without losing the discussion:

handoff_context:
  source_skill: /culture
  summary: <one factual sentence>
  open_questions: [<only blockers, if any>]
  artifact: .cheese/notes/<slug>.md  # the session wheypoint, always written
  records: [<wiki page or fallback path per written ledger entry>]

Default options (pick at most three of these plus a stop):

  • Shape this into a written spec (recommended when the idea is still fuzzy) — /mold with the context packet, or /mold .cheese/notes/<slug>.md when a notes slug exists.
  • Implement it directly (recommended when the ask is clear and unambiguous) — /cook with the context packet as the accepted contract.
  • Implement and auto-review — /cook --auto with the context packet, runs Cook's Press loop, then chains through /age → /cure autonomously, fixing every medium-or-above finding plus cheap (contained-fix) lows across up to two cure passes. Stops at the final cure pass; opening or updating the PR stays a manual step. Pre-select this when the conversation reached an unambiguous contract; offer the non-auto /cook as an alternative when the user wants per-step approval.
  • Research more first (when the conversation hit a factual gap external docs could close) — /briesearch.
  • Pause / resume later — dispatch none; the session wheypoint already captured the state, so resume any time with /cheese --continue <slug>.

After a non-stop selection, run the selected downstream skill immediately with the context packet. /age is never the next step from culture — review needs a diff to look at.

Rules

  • Writes only knowledge — the ## Record ledger entries and the end-of-session wheypoint — never code, specs, commits, or PRs; see ## Invariant.
  • Ask the user the decisions that shape the work — one consequential fork at a time when they're exploring — rather than settling them yourself. Decide the rest and log it.
  • Agree when agreement is warranted; do not manufacture counterpoints to seem balanced.
  • When external evidence raises an alternative ("X uses Y or Z"), name it as a trade-off in the dialogue and a candidate option — never silently recommend "add both" or "expose a knob". Consequential design choices need explicit user adjudication, not agent inference from a citation; below the leverage line, pick one and log the alternative.
  • Apply the shared voice kernel (lives at ../age/references/voice.md): lead with the answer, flag confidence as certain | speculating | don't know, steelman, track contradictions across turns.

FAQ

What does the culture skill do?

Models problems and trade-offs without writing code or specifications. Use when a workflow needs silent reasoning, or the user asks for "/culture", "no writes", "rubber-duck this", or "these bugs feel connected". Not for specs (/mold), code (/cook), or bug diagnosis and fixes (/pasteurize).

How do I install culture?

Run npx skills add https://github.com/paulnsorensen/easy-cheese --skill culture in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/culture/ (personal) or .claude/skills/culture/ (project).

Which AI agents can use culture?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is culture safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains culture?

It is published by paulnsorensen in paulnsorensen/easy-cheese. It has 647 recorded installs.

More from paulnsorensen/easy-cheese

View all →

cook

paulnsorensen/easy-cheese

Implement an approved spec or focused task through stale-safe source edits. Use this skill when the user says "implement this", "cook this spec", or "fix this bug". Use it for /cook .cheese/specs/ .md. Also use it when the user says "go" with clear acceptance criteria. Run it alone for an unambiguous task. Use --prototype when the user says "prototype this", "go prototype it", or "spike this out" and wants to refine the result round by round. A spec helps but is not required. Do not use it for fuzzy planning (/mold). Do not use it for no-write discussion (/culture) or review-only work (/age).

mold

paulnsorensen/easy-cheese

Turn a high-leverage design decision into a validated spec through grounded dialogue. Use it when a leverage trigger fires (auth, irreversible effects, concurrency, contracts, destructive ops, a new slice, a cross-slice dependency, an invariant gap) or when the user asks for a spec or design. Typical phrases include "let's design X", "shape this into a spec", "what should the API for Z look like", and "/mold". A feature ask with zero fired triggers is a /cook mini-spec, not a mold; route it through /cheese. Do NOT use it for free-form discussion without artifact intent (/culture), direct implementation (/cook), or research-only questions (/briesearch). Ceremony scales to the ask through references/tiers.md, so a small clear change gets a validated mini-spec without a write-approval turn.

cure

paulnsorensen/easy-cheese

Apply selected fixes from an /age report, findings list, or CI failure. Run the project gates and hand a clean result to /plate. Use when the user wants selected findings resolved. Do not use for review, test authoring, or direct publication.

DevOps & Cloud649 installs

age

paulnsorensen/easy-cheese

Review a diff, PR, branch, or path across thirteen dimensions. Emit a severity-grouped findings report. Use when the user wants a code review. Trigger on "review this", "/age", "is this safe to merge", or "find bugs". Also trigger on "spot security issues", "check for slop", "review my PR", or "what's wrong with this code". Review every requested dimension. Review all thirteen dimensions by default. Do not apply fixes. Route them to /cure. Do not harden tests; route that work to /press.

cheese

paulnsorensen/easy-cheese

Route an idea, path, pull request, issue, failure, question, or bare /cheese to the correct workflow skill. Use this skill for /cheese, routing requests, help requests, or opening messages without a named workflow skill.

ultracook

paulnsorensen/easy-cheese

Retired — /ultracook no longer exists as a standalone skill. Any /ultracook invocation resolves to /cook, which now owns the single implementation pathway (including the fan-out mechanics this skill used to run). Use /cook instead.

647 installs

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.