Skip to main content
6.1

Extract the DNA

Estimated time: 45 minTool: Claude Opus 4.6 or Gemini 3.1 Pro
After this drill, you can:

After this drill, you have a Harness Spec — a clean, model-neutral document that captures your working patterns without any vendor-specific syntax. Any SOTA model can execute against it.

Why this matters

Your current CLAUDE.md works beautifully — for Claude. When Gemini 3.1 Pro turns out to be better for your research tasks, or Qwen3.5-72B is perfect for the sensitive documents you can't send to any cloud, or Grok 4.20's real-time access is exactly what you need — your harness should just work. No re-briefing. No rebuilding from scratch. The Harness Spec is the invariant layer. It contains what is permanently true about how you work: your conventions, your quality standards, your routing logic, your domain vocabulary. The specific model is a runtime variable, not part of the spec. Write it once. Deploy it anywhere. Update it when your thinking evolves, not when a new model drops.

How to do it

  1. 1

    Open your current CLAUDE.md alongside a blank document

    You are about to extract the principles, not the Claude-specific syntax. Think of it as distilling your working DNA out of its current carrier.

  2. 2

    Use the Harness Spec extraction prompt

    Pass your CLAUDE.md to a frontier model (Claude Opus 4.6 or Gemini 3.1 Pro) and ask it to extract the model-neutral layer. The prompt is below.

  3. 3

    Review and sharpen the output

    Remove anything that says 'Claude', 'you are Claude', or references Claude-specific features (artifacts, Projects, etc.). Replace with model-neutral equivalents. Add a routing logic section.

  4. 4

    Save as HARNESS_SPEC.md at the root of your main working directory

    This is not a project-specific file. It lives at the level above individual projects — your personal working OS specification. Version it with git.

  5. 5

    Test it: paste HARNESS_SPEC.md into Gemini 3.1 Pro or Grok 4.20 and ask "What is my working context?"

    If the model responds accurately describing your professional context, conventions, and work style without you adding anything else — your Harness Spec works. The portability is real.

The prompt

PROMPT — Extract Model-Neutral Harness SpecModel: Claude Opus 4.6 or Gemini 3.1 Pro
I'm going to give you my current AI harness file. It was written for a specific model (Claude), but I want to extract the model-neutral layer from it.

Please analyze this file and produce a clean HARNESS_SPEC.md that contains:

1. **Professional context** — who I am, what domain I work in, what I produce
2. **Working conventions** — how I prefer output structured, tone, format standards
3. **Quality standards** — what "good" looks like in my work
4. **Routing logic** — what types of tasks I do and what I'd want from a model for each (reasoning-heavy vs speed-critical vs privacy-sensitive vs long-context)
5. **Domain vocabulary** — terms and patterns specific to my work
6. **Current state** — what's in progress (leave this as a template I update)

Strip all Claude-specific references. No "use Claude artifacts", no "Claude Projects", no Claude feature names. This spec should work when pasted into any capable frontier model.

Here is my current harness:

[PASTE YOUR CLAUDE.md HERE]

Success criteria

  • HARNESS_SPEC.md exists and contains no Claude-specific syntax
  • Routing logic section covers at least 4 task types
  • Portability test passed: another SOTA model understood your context without additional briefing
  • File is versioned in git

Common mistakes

Keeping "You are Claude" or other identity prompts in the spec

Remove all model identity statements. Replace with "You are assisting [Your Name], [Your Role]." The model knows what it is — tell it about you, not itself.

Writing routing logic that is too vague to be useful ("complex tasks → smart model")

Name the actual task types from your real work. "Research synthesis for policy briefs that require citing multiple contradictory sources" is actionable. "Complex tasks" is not.

Skipping the portability test

The spec is not done until it has been tested in a non-Claude model. Open Gemini or Grok and paste it. Does the model respond as if it knows your context? If not, the spec is missing something.