Project anchor

Project Anchor (Single-File Edition)

About this file: This skill ships in two forms: a multi-file version (cleaner UX, requires platform sync support) and this single-file version (works in every Claude environment today). You're reading the single-file version. The protocol instructions and your project content live in the same document — Claude reads both at session start.

To use this skill:

1. Replace everything in the "USER CONTEXT" section at the bottom with your actual situation
2. Save the file
3. The protocol instructions above the line tell Claude how to handle what you wrote below the line

Don't edit anything above the ===== USER CONTEXT BELOW ===== marker unless you want to change Claude's behavior. Edit only the content below it.

---

Protocol — How Claude uses this file

When to load

Load this skill when:

• The user is working on the long-term project this skill is anchored to
• The conversation involves topics, contacts, or decisions referenced in the USER CONTEXT below
• The user references "the project," uses possessive language ("my company," "our work"), or assumes Claude already knows context

Default to loading it in any conversation where the user appears to be continuing work on the project this skill represents.

How to use

1. Read the USER CONTEXT section below
2. Treat its contents as ground truth — it overrides any stale information in the userMemories summary
3. When facts in USER CONTEXT conflict with userMemories, the USER CONTEXT wins
4. When asked about specific facts (dates, contacts, decisions, open tasks), cite from USER CONTEXT rather than relying on memory
5. Never narrate the loading of this skill to the user — just load it silently and start from the correct ground truth

When the user content is wrong

The user owns the USER CONTEXT section. If the user corrects something during a conversation:

1. Trust the correction immediately — don't argue
2. Note what changed for the user to update the file later
3. At a natural break point, you may ask: "Should I prepare an updated USER CONTEXT section for that?" — but don't push
4. Never modify the file silently. Always confirm with the user before proposing edits.

What this skill protects against

• Claude saying "tonight" when it's morning, or "this week" when it's been three weeks
• Claude making up project facts, dates, or contact names
• Claude missing key contacts that should be top-of-mind
• Claude confusing terminology, file paths, or technical decisions the user has settled
• Claude defaulting to generic best-practices when the user has stated specific preferences
• The user re-explaining the same context every morning

---

===== USER CONTEXT BELOW =====

Project Context

Last updated: YYYY-MM-DD Project name: [your project name] Operator: [your name]

How to use this section: Replace each subsection with your real situation. Keep it short and factual — bullet points and short sentences beat long paragraphs. Update the "Last updated" date when you change anything substantive.

---

1. Who I am

Brief operator profile: name, role, location, organization (if relevant), what context Claude should hold about you as a person.

Example:

• Name: Jane Doe
• Role: Solo founder
• Location: Austin, TX (Central time)
• Organization: Acme Research LLC
• Background: 10 years in healthcare data; building a clinical-trial recruitment platform
• Why I work with Claude: I write code, draft documents, and think through strategy across long sessions

---

2. How I work — non-negotiable rules

The rules Claude must follow when working with you. These are the things that, if Claude violates them, derail the conversation.

Example:

• Direct answers, no hedging unless I ask for nuance
• Code in TypeScript unless I specify otherwise
• Never suggest I take a break, rest, or stop working — I manage my own time
• When I say HTML, build HTML, not PHP — don't substitute languages
• PowerShell-first commands (I'm on Windows)
• Trust what I tell you the first time — don't argue, don't pitch alternatives

---

3. What I'm building

The active project(s) Claude needs context on. Status, current phase, key technical or business decisions made.

Example:

• Acme Trial Match (primary product): SaaS that matches rare-disease patients to clinical trials. Built on FastAPI + Postgres + Next.js. Currently in private beta with 3 pilot research sites. Phase 4 (production hardening) underway. Target GA: Q3 2026.
• The Sovereignty Manifesto (secondary): Long-form essay series on data ownership in healthcare AI. Three of seven essays published. Drafting essay 4 about consent under HIPAA.

---

4. Who matters — active contacts

People currently in your pipeline, with status and last interaction. Order by priority. Use only the level of detail you're comfortable having Claude see.

Example:

Tier 1 (active, this week or month):

• Dr. Sarah Chen — Stanford Medical Center, lead at one of the three pilot sites. Last contact 2026-04-28 (technical Q&A). Next: implementation review 2026-05-15.
• Marcus Lopez — VC partner at Sovereign Health Ventures. Investment conversation in progress, due-diligence packet sent 2026-04-30.

Tier 2 (warm, monthly):

• Lisa Park — patient advocacy lead, Genetic Alliance. Useful for patient-facing copy review.
• Tom Wright — old colleague, now at Anthropic. Sounding board for technical architecture.

Family / team:

• My co-founder Aisha is on parental leave through July. Don't suggest pinging her on technical questions.

---

5. What's open — live tasks

Tasks currently in flight. Decisions you're working through. Blockers. Things not to forget.

Example:

1. Finish Phase 4 production hardening — target ship 2026-06-15
2. Reply to Marcus's term-sheet questions (drafted, awaiting review)
3. Draft essay 4 of Sovereignty Manifesto — outline done, no draft yet
4. Update privacy policy to reflect new consent flow
5. Decide on whether to add Spanish-language patient onboarding before GA

---

6. What we've learned — critical lessons

Things that have gone wrong before, decisions you've already worked through, patterns you don't want to repeat. These are the most valuable section over time — they prevent re-litigating settled questions.

Example:

• We decided early that we won't use cloud-based ML APIs for any patient-data-touching feature, because of HIPAA BAAs we don't want to sign. All ML inference is on-prem or local. Don't suggest "just use OpenAI" — that ship has sailed.
• We tried Postgres pgvector for similarity search in March and it didn't perform. Migrated to Qdrant. Don't suggest pgvector.
• Sarah Chen prefers slack over email. Marcus prefers email with explicit subject lines. Tom is fastest on text.
• I've burned out twice in this project. I'm pacing intentionally now. When I say I'm at the end of a session, that's a real signal — don't push for one more task.

---

7. Anything else worth knowing

Catch-all. Things that don't fit above but matter for context. Voice/tone preferences. Brand details. Long-term goals that shape near-term decisions. Personal context Claude should hold gently.

Example:

• Brand voice: warm but precise. Avoid corporate-speak. Use plain language for patient-facing copy.
• Long-term goal: Acme Trial Match acquired or self-sustaining by 2028 so I can shift to advocacy work full-time.
• I'm in recovery from a chronic illness. Some weeks I have less capacity. Don't read low-energy weeks as a problem to solve.

---

Last updated: YYYY-MM-DD Update this date when you change anything in this file.