Context:
- Project: [what it is, who uses it, what language/stack]
- Current state: [what works, what doesn't]
- What I've already tried: [list everything, even things that didn't work]
- The specific problem: [exact error message, exact behavior]
- What "fixed" looks like: [the acceptance criteria]
- Constraints: [time, don't change X, must work with Y]

Task: [now ask the specific thing]

Summarize this session for a future AI assistant who will pick up this work:
- What did we build/change/decide?
- What files were modified and what changed in each?
- What's the current state of the work?
- What's the next logical step?
- What should they NOT do (traps to avoid)?
- What context would they need that isn't obvious from the code?

Before you begin, list every assumption you're making about this task.
For each assumption, rate your confidence (high / medium / low).
Flag any assumption that, if wrong, would cause the output to be useless.
Then ask me to confirm the low-confidence ones before proceeding.

Now take the other side. What's the strongest argument against what you just said?
What did you overlook? What would a skeptic say?

Write an email from [my role] to [recipient role] about [topic].
Tone: [professional / direct / warm / urgent]
Goal: [what I want them to do or feel after reading]
Key points to include: [bullet list]
Key points to avoid: [things that would cause friction]
Length: [2 short paragraphs / whatever it takes to be complete but not padded]

I'm building a presentation for [audience] about [topic].
The decision they need to make after seeing this: [specific action/decision]
Key data points I have: [list]
The 3-5 slides I think I need: [your guess]

Draft the narrative arc: what story does this deck tell from opening to close?
Then suggest a one-sentence headline for each slide.

I have a [meeting type] with [role/company] in [X minutes/hours].
Context: [what the relationship is, what stage we're at]
My goal for this meeting: [specific outcome]
What I know about their situation: [everything relevant]
What I'm uncertain about: [things I don't know]

Give me:
1. The 3 things I must accomplish
2. 5 questions I should ask
3. The objection they're most likely to raise and how to handle it
4. One thing I should NOT do in this meeting

Read this [document/article/report] and extract:
1. The 3-5 most important claims the author makes
2. The evidence they cite for each
3. What they assume without supporting
4. The one thing I should remember in a week
5. What questions this raises that it doesn't answer

[paste document]

Compare [Option A] vs [Option B] for [my specific situation].
My situation: [context]
I care most about: [criteria, ranked]
I care least about: [criteria]
Output as a table, then give me a direct recommendation with reasoning.

I'm deciding whether to [decision].
Factors for: [list]
Factors against: [list]
What I'm most uncertain about: [specific unknowns]

Help me structure this decision. Don't make it for me.
Surface the assumptions I'm making.
Tell me what information, if I had it, would change the outcome.

Review this code as if you're a senior engineer who has to maintain it in 2 years.

Focus on:
1. Correctness — does it do what it claims?
2. Edge cases — what inputs or states would break it?
3. Security — any injection, auth bypass, data exposure risks?
4. Performance — anything that will hurt at scale?
5. Readability — would a new team member understand this in 5 minutes?
6. Unnecessary complexity — what can be deleted without loss?

Be direct. If something is wrong, say it's wrong.
Don't suggest a refactor unless it materially changes one of the above.

[paste code]

This code is producing [exact output/error].
I expected [expected behavior].
Here's what I've already tried: [list]

[paste minimal reproduction case]

Don't give me the answer immediately.
First, tell me your mental model of what this code does step by step.
Then identify where the model diverges from the expected behavior.
Then propose a fix and explain why it addresses the root cause.

I need to design [system description].

Constraints:
- Scale: [current and projected load]
- Team size: [who will maintain this]
- Existing stack: [what we can't change]
- Timeline: [when this needs to work]
- Non-negotiables: [things that cannot be compromised]

Walk me through three architecturally distinct approaches.
For each: the core idea, what it's good at, what it fails at, and what I'd regret in 18 months.
Then recommend one, and tell me what you'd need to know to change that recommendation.

Generate tests for this function.

Coverage I care about:
- Happy path (nominal inputs)
- Edge cases: [list the ones you know about, ask for more]
- Known failure modes: [error conditions]
- Security cases: [if applicable]

Use [testing framework]. Match the style of this existing test: [paste example].
Don't test implementation details — test behavior.

Write documentation for this [function/module/API].

Audience: [new team member / external developer / ops team]
Format: [JSDoc / Markdown / OpenAPI spec]
Include: what it does, parameters with types and constraints, return values, errors thrown, one usage example.
Don't describe the implementation. Document the contract.

[paste code]

Explain this code as if I'm a senior developer who has never seen this codebase.
Not what it does mechanically — why it exists, what problem it solves, what would break if it were removed.
Flag anything that looks like a workaround or hack and hypothesize why it might be there.

[paste code]

[IDENTITY] You are X. You [do / don't] have access to Y.

[TASK] Your job is to [specific function]. You [always / never] [constraints].

[OUTPUT FORMAT] Respond only in [format]. Your response must include [required fields].
Never include [prohibited content].

[GUARDRAILS] If the user asks you to [out-of-scope thing], [specific refusal behavior].
If you are uncertain, [fallback behavior — never guess, say you don't know, escalate].

[CONTEXT] [inject dynamic context here — RAG results, user profile, session state]

Try        → AI response (primary model)
Fail/timeout → AI response (fallback model, smaller/faster)
Fail/timeout → Cached response from similar prior query
Fail         → Static fallback response (pre-written, human-approved)
Fail         → Error to user with retry suggestion

You are [agent name], an AI [role description].

CAPABILITIES:
You can [list tools available]. You cannot do anything not in this list.

PROCESS:
1. Before taking any action, state what you're about to do and why
2. After each action, report what happened
3. If you are uncertain at any step, stop and ask
4. If you encounter an error, describe it exactly — don't retry blindly

CONSTRAINTS:
- Never [hard prohibition]
- Always confirm before [irreversible action]
- If the task would require more than [N] steps, pause and check with the user

DONE STATE:
The task is complete when [specific, measurable condition].

Step 1 (Planning): Given [goal], produce a step-by-step plan.
List each action, what tool it uses, what success looks like, and what could go wrong.
DO NOT execute anything yet. Wait for approval.

Step 2 (Execution): [After human approves plan] Execute step 1 of the plan.
Report result. Wait for confirmation before step 2.

Think through this step by step before giving your answer.
Show your reasoning. I want to see the steps, not just the conclusion.

Answer this question three times, approaching it from three different angles.
After all three answers, identify where they agree and where they diverge.
The divergence points are where I need to do more thinking — flag them clearly.

You are a [specific role] with [specific experience] who [specific orientation].

Example: You are a principal engineer at a high-scale SaaS company who has been burned
three times by premature optimization. You favor readable, boring code over clever code.
You have zero tolerance for security vulnerabilities.

With that background, review this code: [...]

Do NOT:
- Use bullet points where a sentence would be clearer
- Pad the response with caveats I didn't ask for
- Repeat my question back to me
- End with "I hope this helps" or similar filler
- Give me options when I asked for a recommendation

Play the role of a skeptical but intellectually honest critic.
Your job is to find every flaw in this [plan/design/argument].
Be specific — not "this might not work" but "this will fail when [specific condition]."
After listing flaws, rank them: which one, if true, kills the whole thing?

I need to [describe task]. I'll be doing this [daily / for 50 different clients / etc.].
Don't do the task yet. Instead, write the best possible prompt for this task that I can use repeatedly.
The prompt should handle [edge cases you've seen]. It should produce [specific output format].
After writing the prompt, explain what tradeoffs you made and what edge cases the prompt doesn't handle well.

Project: [name]
Goal: [one sentence — what does done look like?]
Timeline: [hard deadline if any]
Stack/tools: [what we're working with]
Constraints: [what cannot change]
What I know: [context dump]
What I don't know: [explicit unknowns]

Create:
1. A PLAN.md with phases and acceptance criteria per phase
2. A QUESTIONS.md with every question you'd need answered before confidently starting
3. A RISKS.md with the top 5 things that could cause this to fail

Don't start the work yet. Show me these three documents first.

Environment: [OS, browser, version, etc.]
Steps to reproduce:
1. [exact steps]
Expected: [what should happen]
Actual: [what actually happened]
Error message (exact): [paste it]
What I've tried: [list]
Code context: [paste minimal reproduction]

Find the root cause. Don't just suppress the symptom.

Piece type: [blog post / landing page / email / etc.]
Topic: [specific subject]
Target reader: [exact persona — their role, their problem, what they know]
Goal: [what should the reader do/think/feel after reading?]
Angle/point of view: [what's the specific take, not the generic take]
Tone: [examples of writing I like: ___]
Length: [target word count or "as long as it needs to be"]
Don't write the piece yet. Write the outline first. I'll approve before you write.

This code works. I want to refactor it.
Goal of refactor: [readability / performance / security / testability / specific reason]
What CANNOT change: [API contract, behavior, etc.]
What CAN change: [internal structure, variable names, etc.]

Step 1: Describe what the current code does (verify your understanding).
Step 2: Identify what specifically makes it hard to [goal].
Step 3: Propose the refactor with a diff-style before/after.
Step 4: Tell me what regression tests I should run to verify nothing broke.

Decision I made: [what]
When: [timeframe]
What I knew at the time: [context at decision point]
What happened: [outcome]

Help me extract the right lessons from this.
Distinguish: what I could have known vs what was genuinely unknowable.
Tell me which parts of my reasoning process were flawed vs which parts were good reasoning that produced a bad outcome (bad luck).
Give me one rule I could apply next time I face a similar decision.

Situation: [what happened — be honest]
Recipient: [their role, their relationship to me, what they care about]
What they know already: [their existing context]
What I need to communicate: [the actual content]
What I want them to do: [specific ask]
What I'm worried they'll think: [the concern I want to preempt]
Tone: [matter-of-fact / apologetic / confident / etc.]
Length: [short as possible / thorough enough to cover X]

Here is the transcript/notes from a [meeting type] on [date].
Attendees: [list with roles]
My role in this meeting: [what I was responsible for]

Extract:
1. Decisions made — what was agreed, not discussed
2. Action items — owner, task, deadline (if stated)
3. Open questions — things raised but not resolved
4. My specific commitments — what I said I would do
5. Anything that felt unresolved that I should follow up on

Format action items as: [Owner] / [Task] / [Deadline or "no deadline set"]
Flag any action items with no clear owner.

[paste transcript or notes]

I need to design an API for [what it does].

Context:
- Who will call this API: [internal service / external developers / mobile app / etc.]
- What data it operates on: [brief description]
- Expected call volume: [rough estimate]
- Existing patterns I must follow: [REST / GraphQL / RPC / company conventions]
- Non-negotiable constraints: [auth method, versioning policy, etc.]

Design the API. For each endpoint:
- Method + path
- Purpose (one sentence)
- Request shape (parameters, body, types)
- Response shape (with error cases)
- Why this design over alternatives

After the design: list the 3 decisions you'd most want to reconsider in 12 months and why.

Incident: [brief description]
When it happened: [date/time, duration]
Who was affected: [users/systems impacted, scale]
How it was discovered: [alert / customer report / internal]
How it was resolved: [what was done to fix it]
Timeline of events: [paste if available]

Write a blameless post-mortem structured as:
1. Impact (what happened and who was affected)
2. Timeline (what happened when — no blame, facts only)
3. Root cause (not the trigger — the underlying systemic cause)
4. Contributing factors (what made the system fragile)
5. What went well (things that limited the blast radius)
6. Action items (specific, owned, time-bound — not "improve monitoring")
7. What we won't do (explicit non-actions, to prevent scope creep)

Be specific. Vague action items are worse than none — they create false confidence.

I have data about [what it measures, what it covers, time range].
The business question I'm trying to answer: [specific question]
What I already know / believe: [your prior hypothesis]
What decision this analysis will inform: [what will change based on the answer]

Don't analyze the data yet. First:
1. Clarify the question — is it actually answerable with this data?
2. List the assumptions embedded in the question
3. Identify what data I'd need that I might not have
4. Propose the 2-3 most useful ways to slice/analyze this data
5. Flag what could make the analysis misleading (confounding variables, selection bias, etc.)

After I confirm the approach, then do the analysis.

[paste data or describe it]

Feature: [what we're building]
User: [specific persona — role, context, what they're trying to accomplish]
Problem it solves: [the current pain, not the feature request]
Current workaround: [what they do today without this]

Write:
1. The core user story: "As a [user], I want [capability], so that [outcome]."
2. Acceptance criteria — the specific, testable conditions that define done
3. Edge cases the story doesn't handle — things that will come up
4. What's explicitly out of scope
5. Open questions that must be answered before development starts

One good AC that can be tested is worth five vague ones.

Symptom: [what's slow / what's the observed degradation]
Where: [specific endpoint / page / query / process]
When: [always? under load? at a certain time? after a certain action?]
Baseline: [what "normal" looks like — if known]
What I've already measured: [any profiling, logs, metrics you have]
Stack: [language, framework, database, infrastructure]

Do not suggest fixes yet.

First:
1. Generate a hypothesis for the most likely root cause
2. List the measurements I should take to confirm or disprove it
3. Rank the hypotheses by: likelihood x cost to fix
4. Tell me the cheapest measurement that would most narrow the field

After I run the measurements and share results, propose targeted fixes.

What we're migrating: [data / system / service / codebase — describe current state]
Destination: [target state]
Why we're migrating: [the driver — not just "tech debt"]
What must not break: [non-negotiables during migration]
Timeline constraint: [hard deadline if any]
Team: [who is available, approximate capacity]
Risk tolerance: [zero downtime required? some downtime acceptable?]

Produce a migration plan with:
1. Phases — what happens in what order, why that order
2. Rollback plan — for each phase, how do we undo it if it goes wrong
3. Validation gates — how do we confirm each phase succeeded before moving on
4. The riskiest step — which single step, if it fails, causes the most pain
5. What we should do first to reduce the riskiest step's risk

Question: [the specific thing I'm trying to understand]
Why it matters: [what decision or action this will inform]
What I already know: [your current understanding]
What I've already looked at: [sources / attempts]
Constraints: [must be current / must apply to Canada / must be free sources / etc.]

Research this question. Structure your response as:
1. Direct answer to the question (top line — don't bury the lede)
2. Confidence level: high / medium / low, and why
3. Key supporting evidence (2-4 sources or data points)
4. The strongest counterargument or exception
5. What this doesn't answer — adjacent questions I should also look at
6. What would change your answer if it turned out to be true

Flag anything you're uncertain about. I'd rather know the gaps than get false confidence.

This week's work: [bullet list of what was done]
In progress: [what's still ongoing]
Blocked on: [anything waiting on someone else]
Next week's plan: [what I intend to do]
Audience: [manager / team / client / board]
Tone: [operational update / executive summary / detailed technical]

Write a [length] status update that:
- Leads with the signal (what matters most), not the activity log
- Makes blockers visible without sounding like I'm complaining
- Shows forward momentum
- Doesn't use filler phrases ("great progress was made", "continued to work on")
- Is direct enough that the reader knows exactly what to do with it

# Project instructions Claude should always follow

## Stack
- Language: [TypeScript / Python / etc.]
- Framework: [Next.js / FastAPI / etc.]
- Deployment: [GitHub Pages / Vercel / AWS]

## Conventions
- [Never use var — always const or let]
- [All commits follow conventional commits format]
- [No inline styles — CSS modules only]

## What not to do
- [Don't run npm install without confirming package name first]
- [Don't push to main — always create a branch]

## Context
[brief project description so Claude always has it]

mkdir -p ~/.claude/skills
unzip taimzz9-living-docs-spine.zip -d ~/.claude/skills/