paulnsorensen/easy-cheese

culture

Models problems and trade-offs without writing code or specifications.

Ver código-fonte

Como usar

  1. Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
  2. Consulte no original as ferramentas, credenciais e ambientes necessários.
  3. Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.
npx skills add https://github.com/paulnsorensen/easy-cheese --skill culture

Antes de começar

  • A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
  • Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.
Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

/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.).
  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", 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.md`docs/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.md`skip; 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:

yaml
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.

Relacionados por tarefa

do mesmo repositório

Mais Skills

Todos os Skills
paulnsorensen
Comunidade

age

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.

instalações
1
GitHub Stars
18
Atualizado
20 de out.
paulnsorensen
Comunidade

hard-cheese

Checks whether an author can explain a code change before review. Use when the user requests /hard-cheese, /cheese --hard, or an understanding check. Use it before a pull request or through the --hard pipeline flag. Do not use it for reviews, test hardening, or fixes.

instalações
1
GitHub Stars
18
Atualizado
20 de out.
paulnsorensen
Comunidade

mold

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 thro

instalações
1
GitHub Stars
18
Atualizado
20 de out.
paulnsorensen
Comunidade

plate

Turn finished local work into a commit, an ordinary pull request, or a pull request stack. Use this skill to commit changes or to publish a branch. Use it to open or update a pull request. Use it to create, sync, restack, or submit a pull request stack. You can also run /plate. This skill owns all staging, commits, pushes, pull request creation, and stack changes. GitHub inspection, reviews, comments, CI, issues, releases, and repository administration are outside this skill. Use the gh CLI dire

instalações
1
GitHub Stars
18
Atualizado
20 de out.