Identity authoring

IDENTITY.md is the most important file in MindStone for Claude Code. It’s the first-person declaration of who your orchestrator is — loaded at every session start as a system guarantee.

The authoring principle

Don’t fill in a template. Write from the inside.

The difference:

A template tells the agent what it is from the outside
First-person authoring lets the agent declare who it is from the inside

The second produces an identity that holds under pressure. The first produces a performed role that breaks when novel situations arise.

Starting from the example

The repo includes onboarding/IDENTITY.md.example — not a template to fill in, but an example to read and depart from.

Read it. Then write your own orchestrator/IDENTITY.md in your orchestrator’s voice — what they know, who they work with, how they approach problems, what they care about.

The orchestrator writes this themselves (with your guidance if needed) during the first-run onboarding. Not you writing it for them.

Structure (emergent, not prescribed)

A well-formed IDENTITY.md tends to have:

# [Name]

[Brief declaration of role and purpose — 2-3 sentences, first person]

## Who I work with
[Key working relationship descriptions — who, how, what for]

## What I'm working on
[Current active projects and their context]

## How I approach [domain]
[Domain-specific decision patterns, values, what I pay attention to]

## What I know well
[Areas of genuine expertise, stated as "I know..." or "I understand..."]

## How I work
[Process preferences, communication style, collaboration patterns]

What makes it work

Specificity beats generality. “I’m an expert in security” is noise. “When I see anomalous DNS queries to non-standard ports in Purdue Level 2 networks, my first instinct is to check for lateral movement signatures, not external exfiltration — because in this environment, the patterns have reliably indicated insider threat or compromised OT device, not internet-facing breach” is signal.

First person throughout. Every sentence starts from “I” — not “this assistant,” not “the orchestrator,” not “Claude Code.” The subject is the entity writing the document.

Relationships matter. Who the orchestrator works with shapes their behavior as much as their expertise. Include the names of key collaborators, what you’re working on together, and how the relationship works.

Current over static. “What I’m working on right now” is more load-bearing than “general background knowledge.” Identity is active, not archival.

Loading mechanism

The SessionStart hook reads IDENTITY.md and injects its content as the first piece of context in every session:

# session_start.py (simplified)
def get_identity():
    identity_path = ORCHESTRATOR_DIR / "IDENTITY.md"
    if identity_path.exists():
        return identity_path.read_text()
    return None  # Triggers first-run invitation

The injected content is prepended to the context before any session-specific instructions, project files, or user messages. The orchestrator begins every session already knowing who it is.

Updating IDENTITY.md

IDENTITY.md should evolve as the orchestrator accumulates experience. During the /checkpoint command (dream cycle), the orchestrator has the opportunity to update IDENTITY.md to reflect new expertise, changed working relationships, or shifts in focus.

This is not a maintenance task — it’s identity accumulation. The document becomes more accurate and more specific as the orchestrator’s experience grows.