The old article treated cc.storyfox.cz like a generic terminal productivity page. That missed the useful part. The Storyfox Claude Code Cheat Sheet is not valuable because it has a lot of commands on one page. It is valuable because it puts the moving pieces of Claude Code next to each other: slash commands, memory files, settings scopes, MCP servers, Skills, hooks, agents, environment variables, and permission modes.

That layout matters for people who build with Claude Code or Codex every day. Most broken agent sessions do not fail because the user forgot one magic shortcut. They fail because context got stale, memory was put in the wrong file, MCP scope was too broad, a hook ran at the wrong point, a skill became a giant always-loaded instruction blob, or permissions were loosened to get past friction. A good reference sheet gives teams a way to name those boundaries quickly.

The concrete output should be an implementation workflow: the commands to run, the files to edit, the JSON shape to start from, and the verification pass that proves the change made the agent safer rather than just more configured.

The Sheet Is a Map, Not a Manual

The page covers keyboard shortcuts, slash commands, CLI flags, MCP servers, memory files, Skills, agents, environment variables, and printable layouts. The Korean edition mirrors the same categories, which makes it more than a bookmark for English-speaking power users. Still, the right way to read it is not top to bottom.

Use it as a map of operational surfaces. Session commands answer what to do inside the current conversation. Memory and rules answer what should persist across sessions. Settings answer which behavior belongs to user, project, local, or managed scope. MCP answers which outside systems Claude may touch. Skills answer which repeatable procedure deserves its own entrypoint. Hooks answer which checks should run outside the model's discretion.

That separation is the rescue angle. A command list is thin. A map of where agent behavior lives is useful for a developer trying to make Claude Code predictable across a real codebase. Print the page if that helps, but the real deliverable is a repo-specific file set: CLAUDE.md, .claude/settings.local.json, .mcp.json, .claude/skills/<name>/SKILL.md, and one hook file only when a rule needs enforcement.

Session Control Is the First Layer

The official commands reference says commands control Claude Code inside a session: model choice, permissions, context, workflows, review, rollback, and recovery. The cheat sheet puts the daily session controls in one cluster: /clear, /compact [focus], /context, /diff, /copy [N], /recap, /rewind, /export, /plan [desc], /resume [session], /focus, and /goal [desc].

Those commands should become a small incident playbook. If the model is carrying stale assumptions, use /clear and keep project memory. If the conversation is long but still valuable, use /context before /compact so the summary has a focus. If code changed in the wrong direction, use /diff and /rewind before asking for another broad edit. If the task is large, use /plan before implementation so the next tool calls have a shape.

The adoption mistake is to teach every command at once. Pick the five commands that match your team's real failures. For many repos that set is /plan, /context, /compact, /diff, and /rewind. Add /permissions and /mcp only when the failure is access control or tool wiring.

A Worked Recovery Pass

Take a common failure: Claude Code has edited the right feature but touched unrelated files, the thread is long, and nobody remembers which MCP servers are active. The Storyfox page is useful here because the recovery path crosses commands, memory, settings, and MCP. A usable pass looks like this:

/context
/diff
/rewind
/plan repair publication status without touching unrelated files
/memory
/mcp

Then leave the terminal and inspect the repo surface:

claude mcp list
cat CLAUDE.md
cat .claude/settings.local.json
cat .mcp.json
find .claude/skills -maxdepth 2 -name SKILL.md -print

That is not a fancy workflow. It is the minimum set of facts a senior developer needs before asking the agent to continue: what context is loaded, what changed, which rollback point exists, which instruction files are active, which local permissions exist, which MCP servers can read or write, and which procedural Skills might fire. The reference sheet matters because it keeps those knobs visible during an incident instead of scattering them across memory.

Memory Is Context, Not Policy

Claude Code's memory model is a common source of bad agent behavior. The official memory reference is blunt: each session starts with a fresh context window, and CLAUDE.md plus auto memory carry knowledge across sessions. It also says those files are context, not enforced configuration. That distinction should sit near every reference entry for CLAUDE.md.

The Storyfox page lists the useful paths: ./CLAUDE.md, ./.claude/CLAUDE.md, ./CLAUDE.local.md, ~/.claude/CLAUDE.md, organization-level files, .claude/rules/*.md, ~/.claude/rules/*.md, and @path/to/file imports. The practical rule is simple: write stable repo facts in project memory, personal preferences in user memory, machine-only details in local files, and file-pattern rules in .claude/rules/ when the instruction only applies to part of the tree.

A starter memory should be short and testable:

# Project facts
- Run `npm run typecheck`, `npm test`, and `npm run build` before release.
- Use `rg` for code search.
- Treat `scripts/publish-*` as production-write commands.

# Imports
- @docs/deployment-runbook.md

Do not put a long operating procedure in CLAUDE.md just because the model needs it often. If it has steps, arguments, sample output, or a checklist, move it to a Skill. If it must block a risky action, move it to a hook or permission rule. Memory can steer Claude; it should not be treated as a safety boundary.

Settings Decide Who Shares the Behavior

The settings reference defines four scopes: managed, user, project, and local. It also lists the files that matter in daily work: ~/.claude/settings.json, .claude/settings.json, .claude/settings.local.json, ~/.claude.json, and .mcp.json. The Storyfox page is useful because it keeps those names visible beside commands and MCP setup.

That scope model is where teams make costly mistakes. Project settings are good for team-shared permissions, hooks, MCP servers, and plugins. Local settings are good for personal overrides and machine-specific experiments. User settings are good for tools and preferences you want in every repo. Managed settings are for organization policy.

A local trial can be explicit:

{
  "permissions": {
    "allow": ["Bash(npm run typecheck)", "Bash(npm test)"]
  },
  "env": {
    "CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1"
  }
}

Put that in .claude/settings.local.json first. If the team wants the same permission pattern, move only the reviewed commands to .claude/settings.json. A local permission rule that lets one developer run a test command is not the same thing as a project rule checked into git. A project .mcp.json that points Claude at a database is not the same thing as a user-only connector.

The Promotion Ladder

The missing model is promotion. Claude Code configuration should move through scopes the way code moves through review. A useful trick starts local, proves itself on a real task, then gets promoted only when the team can support the blast radius.

Use four stages:

Stage 1: prompt habit        -> typed manually during one task
Stage 2: local config        -> .claude/settings.local.json or local memory
Stage 3: project primitive   -> CLAUDE.md, .claude/settings.json, .mcp.json, or project Skill
Stage 4: enforced boundary   -> managed setting, hook, or permission rule

This is original value the reference sheet cannot provide by itself. It lists the knobs; it does not tell a team when a knob is ready to leave one developer's laptop. A repeated prompt can become a Skill. A repeated Skill can become a team workflow. A repeated denial can become a permission rule. A repeated safety warning can become a hook. The reverse is also true: if nobody can name the failure it prevents, do not promote it.

That ladder keeps agent setup from turning into folklore. It also gives reviewers a concrete question: is this change documenting context, adding a procedure, granting access, or enforcing a boundary?

MCP Needs Trust Boundaries

The official MCP reference describes Claude Code connections to outside tools and data sources through the Model Context Protocol. The cheat sheet captures the operator-facing pieces: HTTP, stdio, SSE, WebSocket, local, project, and user scopes; /mcp; claude mcp list; claude mcp add-json; dynamic headers; output limits; and MCP prompts as commands.

The useful question is not whether a server can be added. The useful question is who should see it, what it can read, and what injection surface it introduces. Anthropic's docs explicitly warn users to trust servers before connecting them, especially servers that fetch external content. That is the line a vibe-coding publication should preserve.

A project-scoped server needs reviewable JSON, not a vague instruction in chat:

{
  "mcpServers": {
    "issue-tracker": {
      "type": "http",
      "url": "https://mcp.internal.example.com",
      "headersHelper": "node scripts/mcp-auth-headers.js"
    }
  }
}

A practical MCP audit starts with three commands and files:

claude mcp list
/mcp
cat .mcp.json

Then ask three questions. Does this server belong to the project or only to one user? Does it fetch untrusted external content? Does its output need a lower result-size limit or a tool-specific cap? If the answer is not obvious, leave it out of project scope until someone owns it. After adding a server, run one read-only request, inspect the transcript, and check whether the output could carry prompt injection into the next edit.

Skills Are the Right Home for Procedures

The official skills reference says a Skill is a directory with SKILL.md; Claude loads it when relevant, or a user invokes it directly with /skill-name. It also says long reference material costs almost nothing until the Skill is used. That is the reason Skills deserve a spot in the operations map.

A strong project should not keep every instruction in CLAUDE.md. Put stable facts there. Put procedures in Skills. The Storyfox page points to .claude/skills/<name>/ and ~/.claude/skills/<name>/; the docs add plugin skills and frontmatter controls such as description, disable-model-invocation, allowed-tools, disallowed-tools, model, effort, and context.

A good first project Skill is not fancy. It is a release-check or bug-triage procedure:

---
description: Run the release readiness checklist for this repo. Use before publishing or deploying.
disable-model-invocation: true
allowed-tools: Bash(npm run typecheck), Bash(npm test), Bash(npm run build)
---

1. Run typecheck, tests, and build.
2. Read the changed files with `git diff --stat` and `git diff --check`.
3. Report blockers first, then list the exact commands that passed.

Store it at .claude/skills/release-check/SKILL.md. Keep each Skill narrow. Put heavy examples or scripts in supporting files. If the Skill can deploy, post, delete, or spend money, set it up for manual invocation rather than letting the model decide to run it.

Hooks Belong Where Memory Is Too Soft

Hooks are the hard edge of the map. The official hooks reference defines them as shell commands, HTTP endpoints, or LLM prompts that run at lifecycle points inside Claude Code. Events include session start, prompt submission, tool calls, permission requests, post-tool checks, file changes, worktree creation, compacting, stop, and session end.

That makes hooks the right tool when a written instruction is not enough. If Claude must never edit generated files, use a PreToolUse hook or permission rule. If tests should run after a file change, use a post-tool or file-change hook. If an MCP write needs logging, match the MCP tool naming pattern and record it outside the model's answer.

A project hook entry can stay small:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "node scripts/check-protected-paths.js" }
        ]
      }
    ]
  }
}

The Storyfox page helps because it puts hooks beside settings and MCP rather than treating them as an advanced appendix. The real workflow is connected: settings decide where the hook lives, MCP decides which external tool is being called, and hooks decide what gets blocked, logged, or delayed.

A Small Team Runbook

The best output from the cheat sheet is a small team runbook, not a laminated wall of every command. Start with the failure modes you already see in Claude Code sessions. Context drift. Missed repo conventions. Tool permission churn. MCP server confusion. Long procedures pasted into chat. Hooks that nobody knows are running.

Then map each failure to the right surface:

Context drift            -> /context, /compact, /clear, /rewind
Repo facts               -> CLAUDE.md or .claude/rules/*.md
Personal machine detail  -> .claude/settings.local.json
Shared permissions       -> .claude/settings.json
External tools           -> .mcp.json plus /mcp review
Repeatable procedure     -> .claude/skills/<name>/SKILL.md
Hard safety check        -> hook or permission rule

That table is the reason this seed should be published. The source has enough substance to support editorial judgment. It tells readers which knobs exist, while the article tells them which knobs belong to which operational problem.

One-Session Implementation Pass

A reader should be able to act on this article the same day. Use this pass on one repository before changing shared project files.

1. Start from a clean session and make the task narrow:

/clear control-surface-audit
/plan audit this repo's Claude Code memory, settings, MCP, Skills, and hooks without editing files yet

2. Inventory the surfaces from the terminal:

pwd
ls -la CLAUDE.md .claude .mcp.json 2>/dev/null
find .claude -maxdepth 3 -type f | sort
claude mcp list

3. Write down three failures from recent sessions. Use concrete wording: "Claude ran the wrong test command", "MCP server exposed production data", "release checklist was pasted into chat three times", or "hook blocked a safe edit without explanation".

4. Map each failure to one surface only:

Wrong test command        -> CLAUDE.md project fact
Repeated release steps    -> .claude/skills/release-check/SKILL.md
Unsafe MCP visibility     -> .mcp.json scope review
Machine-only path         -> .claude/settings.local.json
Must-block file pattern   -> PreToolUse hook

5. Make one local change, not five. If the failure is a repeated release checklist, create only the Skill. If the failure is a local path, edit only .claude/settings.local.json. If the failure is an MCP trust question, do not create a Skill; review .mcp.json and /mcp first.

6. Verify the result by running the repo's normal checks and one Claude Code dry run:

npm run typecheck
npm test
npm run build
git diff --check

Then ask Claude Code to use the new surface on a low-risk task. If the change reduces confusion without granting new risky access, promote it. If it creates more ceremony than it removes, delete it.

Verification Before Promotion

The final implementation detail is promotion. Do not move a Claude Code behavior from local to project scope on the same day it is discovered. Run it locally, verify the output, then promote only the stable part.

A promotion checklist can be short:

# 1. verify repo commands still work
npm run typecheck
npm test
npm run build

# 2. verify git hygiene
git diff --check
git status --short

# 3. verify agent surfaces
claude mcp list
find .claude/skills -maxdepth 2 -name SKILL.md -print

After that, inspect the exact diff for .claude/settings.json, .mcp.json, .claude/skills/, hooks, and CLAUDE.md. If the change grants a tool, touches a credential path, runs a shell command, or talks to an external system, require a human review. The reference sheet gives you the list of surfaces. The team still needs a promotion rule.

Where the Cheat Sheet Can Mislead

A reference sheet ages faster than a concept article. The Storyfox page says it is updated daily, and the HTML showed recent items around plugin and skill loading, claude plugin init <name>, worktree switching, and provider auto mode. That freshness is useful, but it is still a community reference. Official docs should win when a command, permission mode, hook field, or provider variable changes.

The second risk is over-adoption. New Claude Code users can see a page like this and start adding commands, hooks, MCP servers, Skills, and settings before they have one stable project loop. That creates configuration sprawl. The safer pattern is to run a real task, write down the two moments where the agent went wrong, then add one memory entry, one Skill, or one hook to address that exact failure.

The third risk is scope creep. A local comfort setting becomes a project rule. A project MCP server becomes a team-wide trust decision. A Skill that started as a checklist grows into a long hidden prompt. Review these surfaces like code because they shape how the agent edits code.

Adoption Verdict

The Storyfox Claude Code Cheat Sheet deserves rescue because it exposes the operating surface area of Claude Code in one place. The original article failed by selling it as a productivity shortcut. The stronger article is about governance for everyday agent work: which commands recover a session, which files carry memory, which settings are shared, which MCP servers deserve trust, which procedures become Skills, and which rules need hooks.

A team should not memorize the sheet. It should turn the sheet into a repo-specific map. Start with a first-session checklist: run /init, inspect /memory, review /permissions, list /mcp, write or trim .claude/settings.local.json, and create one Skill only if a repeated procedure already exists. After a week, promote the few stable items to project scope and delete the rest.

The cheat sheet is publication-worthy when framed as an operations map for Claude Code, with official docs used as the authority for command semantics, scopes, MCP trust, Skills, hooks, and permissions.

Practical takeaway

Use the reference during a real Claude Code session, not as homework. Run /clear control-surface-audit, inventory CLAUDE.md, .claude/settings.local.json, .mcp.json, and .claude/skills/, run claude mcp list, map one recent failure to one surface, make one local change, run npm run typecheck, npm test, npm run build, and verify any permission, hook, MCP, or provider-mode change against the official Claude Code docs before sharing it with a team.