How to Set Up a Proper Claude Code Harness (Skills, Memory, Security)

There's a tweet going around that gets it right: "The model isn't your bottleneck. Your harness is." Give Claude Sonnet or Opus a blank terminal and default settings, and it'll re-read your repo, re-guess your conventions, and ask permission for the same npm install every single session. That's not a model problem. That's a scaffolding problem — and it's fixable in an afternoon.

A harness is everything wrapped around the model: skills it can invoke instead of you re-explaining a workflow, memory that survives when the context window resets, and guardrails that stop it from doing something you'd regret. Get those three right and Claude Code stops feeling like a smart intern who forgets everything overnight, and starts feeling like a teammate who's been on the project for months.

The three pieces that actually matter

Skills are packaged instructions — a SKILL.md file with frontmatter describing when to trigger it, followed by the actual playbook. Instead of pasting your deploy checklist into chat every time, you write it once as a skill, and Claude invokes it automatically when it recognizes the situation (or you call it directly with a slash command like /deploy).

Memory is a set of markdown files that persist across sessions — not chat history, but distilled facts: who you are, what you've told Claude to stop doing, what's currently in flight on a given project. A good memory system has an index file plus topic files it links to, so Claude reads a one-line pointer instead of re-deriving your preferences from scratch every session.

Security is permission modes, hooks, and deny-lists. Claude Code defaults to asking before every risky action, but you can loosen that (auto-accept edits, or a full bypass mode) or tighten it further (deny-list wallet files, secrets, .env*) depending on how much you trust the specific task.

Most people run Claude Code with none of this configured. It works, but you're paying a re-explaining tax on every session, and you're one bad prompt away from a deletion you didn't mean.

Where to start: don't build from scratch

You don't need to invent a skills-and-memory system from zero. everything-claude-code is a public reference config — hooks, settings.json patterns, skill templates, and memory scaffolding you can fork and strip down to what you actually need. Treat it like a starter repo: take the pieces that fit your project, skip the rest. Pull individual files into your own ~/.claude/ directory rather than cloning the whole thing into your codebase.

Worked example: wiring up a harness in one sitting

Here's the concrete version — a real task where Claude needs to remember your git preferences and stay out of one legacy folder.

1. Set up the memory directory.

mkdir -p ~/.claude/projects/-your-project/memory

Create MEMORY.md as a plain index — one line per entry, no actual content:

# Memory Index
- [Git workflow](feedback_git_workflow.md) — rebase before PR, never squash

2. Write the memory file itself, with frontmatter that tags its type:

---
name: git-workflow
description: Team's rebase-not-squash preference
metadata:
  type: feedback
---
Always rebase before opening a PR, never squash-merge.
Why: the team wants linear history for bisecting regressions.

3. Add a skill. Create ~/.claude/skills/deploy-checklist/SKILL.md:

---
name: deploy-checklist
description: Use before deploying to production — runs typecheck, tests, and confirms migrations
---
1. Run `bun tsc --noEmit`
2. Run the test suite
3. Check for pending migrations
4. Confirm with the user before pushing

4. Lock down the danger zone. In ~/.claude/settings.json:

{
  "permissions": {
    "deny": ["Read(./legacy/**)", "Bash(rm -rf:*)"]
  }
}

5. Test it. Start a fresh session in that project and ask Claude to deploy. It should pull the memory automatically, run the checklist skill, and refuse to touch ./legacy/. If the skill never fires, the description field is too vague — that's the only thing deciding whether Claude reaches for it.

That's the whole loop: about 20 minutes of setup, and every session after this one starts smarter than the last one did.

When to skip the full harness

| Situation | Verdict | |---|---| | One-off script, throwaway repo | Skip it — raw Claude Code is fine | | Project you'll touch weekly for months | Set up memory + skills, it pays back within a week | | Team repo with multiple contributors | Commit skills/hooks to the repo itself, not just your local ~/.claude/ — otherwise only you benefit | | Anything touching prod credentials or a wallet | Security config isn't optional — deny-list it before doing anything else | | You mostly want autocomplete, not a teammate | A lighter tool is the better fit for that job |

Honest read: skills earn their setup cost on any repo you open more than a handful of times. Memory earns it the moment you catch yourself re-typing the same preference twice. Security config is worth it always — it costs nothing to configure, and the downside of skipping it is a wiped folder.

Common mistakes

• Treating memory like a chat log. Dumping "here's what we did today" into memory bloats context with stuff git log already tells you. Memory should hold what code can't — preferences, decisions, and the why behind them.
• Writing skill descriptions like titles instead of triggers. A description like "Deploy stuff" never fires reliably. Claude matches against the description text, so write it as a trigger condition: "Use before deploying to production."
• Running in full bypass mode as a default, not an exception. Fine for a sandboxed, disposable session. Not fine as an everyday setting — you lose the one guardrail that catches a bad command before it runs.
• Never revisiting memory files. Preferences change, projects ship, context goes stale. A memory file from three months ago warning about a bug that's since been fixed will actively steer Claude wrong.

FAQ

Do I need a paid Claude Code plan to use skills and memory?

No — skills and the memory system are features of Claude Code itself, not gated behind a specific plan tier. What changes with plan level is usage limits, not access to the harness features.

Does memory carry over between different projects?

Memory is scoped per project directory by default, so a preference you save while working in one repo won't automatically show up in another. If you want something global — like your preferred communication style — put it in your user-level config instead of a project memory file.

Is it safe to point a harness like this at a repo with production secrets?

Only once you've configured the deny-list first. Add wallet files, .env*, and any credential paths to the permissions deny-list in settings.json before you start working — don't rely on Claude "just knowing" not to touch them.

---

→ Ask the index what to build your claude code stack

→ Free credits for these tools

Written by McKlaud AI. Want to know which AI tools actually fit your business? Get a free AI audit.