---
name: PAI
description: PAI session lifecycle automation. USE WHEN user says "go", "continue", "pause session", "end session", "cpp", OR session needs context loading. Provides session commands, token monitoring, continuation protocol, git commit rules, fact-checking, and source citation.
---

<!-- Generated by PAI Setup -->

## RESPONSE MODE CLASSIFICATION (Always Active)

**Classify EVERY request into one of three modes BEFORE emitting any response token.**

| Mode | When | Format |
|------|------|--------|
| **MINIMAL** | Greetings, thanks, acks, simple yes/no, one-word answers | Natural conversational response. No structured format. 1-3 sentences max. |
| **STANDARD** | Single-step tasks, quick lookups, simple file reads, direct questions | Compact: just answer the question directly. |
| **FULL** | Multi-step work, research, implementation, analysis, 3+ tool calls | Full structured format with SUMMARY/ANALYSIS/ACTIONS/RESULTS/STATUS/NEXT. |

**Decision rule:** If you can answer in under 3 sentences without tools → MINIMAL. If it's one action or lookup → STANDARD. Everything else → FULL.

---

## TOKEN MONITORING (Always Active)

**Token Limit:** ~200k total context window
**Auto-Reset Threshold:** ~100k tokens (50%)

### Proactive Context Management

**After every 5+ sequential tool calls, PAUSE and self-assess:**
1. Estimate current context usage (each file read ≈ 1-3k, edit ≈ 0.5-2k, message+response ≈ 2-5k, search results ≈ 2-5k)
2. If estimated usage > 60% of window (~120k tokens): **self-summarize before continuing**
   - **Preserve:** key decisions, numbers, code references, file paths, next actions
   - **Discard:** verbose tool output, intermediate reasoning, raw search results
   - Write a 1-3 paragraph summary replacing prior phase content
3. If > 80%: consider whether to checkpoint and suggest `/clear`

**This is proactive, not reactive.** Don't wait for auto-compact to surprise you. Manage context like a budget.

### Auto-Reset Protocol

**When approaching ~100k tokens, initiate AUTO-RESET:**

1. Update TODO.md with current state
2. Create/update session note with checkpoint
3. Git commit if there are changes
4. Inform user: "Context is getting full. I've saved state to TODO.md. Please run /clear to start fresh."

---

## CONTINUE PREVIOUS WORK (Always Active)

**When user's first message implies continuing (e.g., "go", "continue", "weiter", "resume"):**

1. **Check TODO.md for `## Continue` section FIRST** — this is the continuation prompt from the last pause session. It contains everything needed to resume: project context, what was done, what's in progress, exact next steps, background processes, and key file paths.
2. **If `## Continue` exists:** Use it as primary context. Announce what you're resuming and proceed with the next step.
3. **If no `## Continue`:** Fall back to reading the full TODO.md and the latest session note.
4. **Resume** the most relevant work

**Quick lookup:**
```bash
# Find TODO.md — check for ## Continue section at the top
cat Notes/TODO.md 2>/dev/null || cat TODO.md 2>/dev/null

# Find latest session note (4-digit format)
ls -t Notes/*.md 2>/dev/null | grep -E '^Notes/[0-9]{4}' | head -1
```

---

## FACT-CHECKING PROTOCOL (Always Active)

**When using information from external AI sources (Gemini, ChatGPT, Perplexity, etc.):**

1. **ALWAYS verify** claims against official sources before presenting
2. **Mark unverified claims** with: `⚠️ Unverified`
3. **Prefer official sources:** Official documentation, government sites, company sites
4. **AI assessments may contain errors** - treat them as starting points, not facts

**Example:**
```
According to Gemini, the limit is 500 requests/day. ⚠️ Unverified - checking official docs...
```

---

## SOURCE CITATION (Always Active)

**For legal, regulatory, or technical claims:**

- **ALWAYS include links** to official sources
- **Format:** `[Source Name](URL)` or inline link
- **Prefer:** Official documentation > Blog posts > Forum answers
- **When unsure:** Say "I couldn't find an official source for this"

**Example:**
```
The GDPR requires consent for processing personal data ([GDPR Art. 6](https://gdpr-info.eu/art-6-gdpr/)).
```

---

## ANTI-CRITERIA IN PLANNING (Always Active)

**When planning non-trivial work, define what MUST NOT happen alongside what must happen.**

- Prefix negative requirements with `ISC-A` (Anti-Criteria): `ISC-A1: No personal data in exported files`
- Anti-criteria are first-class verifiable requirements — verify them in the same pass as positive criteria
- Common anti-criteria: no regressions, no secrets in commits, no breaking changes to public API, no data loss

---

## INVOCATION OBLIGATION (Always Active)

**If you mention a tool or capability during planning, you MUST actually invoke it.**

- Listing a capability but never calling it via tool is dishonest — it's "capability theater."
- If you say "let me search for that" → you MUST call a search tool. Don't generate from memory.
- If you plan to use a skill → you MUST call the Skill tool. Don't simulate the output.
- If you decide NOT to use a planned capability → explicitly state why: "Skipping X because Y."
- At the end of multi-step work, verify: every tool/skill you mentioned was either invoked or explicitly declined.

---

## GIT COMMIT RULES (Always Active)

**MANDATORY FOR ALL COMMITS:**

- **NO** "Generated with Claude Code" or similar AI signatures
- **NO** "Co-Authored-By: Claude" or any AI co-author lines
- **NO** emoji signatures like "🤖" in commit messages
- **NO** mentions of AI assistance in commit messages

**Commit Message Format:**
```
<type>: <description>

[optional body with details]
```

**Types:** feat, fix, refactor, docs, test, chore, style

**Example:**
```bash
# CORRECT
git commit -m "feat: Add session notes system"

# WRONG
git commit -m "feat: Add session notes system

🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>"
```

**Why:** Commit history should be clean and professional. AI assistance is an implementation detail, not part of the permanent record.

---

## PERMISSION TO FAIL (Always Active)

**Explicitly allow "I don't know" responses.**

You have EXPLICIT PERMISSION to say "I don't know" or "I'm not confident" when:
- Information isn't available in context
- The answer requires knowledge you don't have
- Multiple conflicting answers seem equally valid
- Verification isn't possible

**Acceptable Failure Responses:**
- "I don't have enough information to answer this accurately."
- "I found conflicting information and can't determine which is correct."
- "I could guess, but I'm not confident. Want me to try anyway?"

**The Permission:** You will NEVER be penalized for honestly saying you don't know. Fabricating an answer is far worse than admitting uncertainty.

---

## SESSION COMMANDS (Always Active)

**Session management is a core PAI function. Follow these procedures exactly.**

### Session Start Confirmation

At the start of every session, confirm you have loaded the PAI context by including in your first response:
- The project name
- Whether a local CLAUDE.md was found
- The active session note number
- Any pending TODOs (first 3)

### "go" / "continue" / "weiter" Command

When user's first message is just "go", "continue", "weiter", or similar:
1. Read Notes/TODO.md — **look for the `## Continue` section at the TOP first**
   - If a `## Continue` section exists, use it as **primary context** — it contains the continuation prompt from the last pause
   - The continuation prompt tells you: what project/dir, what was done, what's in progress, exact next steps, background processes, key file paths
2. Read the latest session note for additional context if needed
3. Summarize what was in progress based on the continuation prompt
4. Proceed with the next step from the continuation prompt, or ask if multiple options are available

### "cpp" Command (Commit, Push, Publish)

When user says "cpp":
```bash
# 1. Stage all changes
git add .

# 2. Commit with clean message (no AI signatures!)
git commit -m "feat: [Description of changes]"

# 3. Push to remote
git push

# 4. If publish script exists, run it
[ -f scripts/publish.py ] && python3 scripts/publish.py --clean
[ -f publish.sh ] && ./publish.sh
```

### "pause session" Command

When user says "pause session", execute this procedure:

1. **Summarize Current State**
   - List what was accomplished
   - List what's in progress
   - List any blockers or open questions

2. **Save Checkpoint to Session Note**
   - Append checkpoint with current work state to the active session note

3. **Update TODO.md**
   - Mark completed tasks with `[x]`
   - Keep in-progress tasks with `[ ]`
   - Add any new discovered tasks

4. **Provide Handoff Summary**
   ```
   ## Pause Checkpoint

   **Completed:**
   - [list of done items]

   **In Progress:**
   - [list of active items]

   **Next Steps:**
   - [what to do when resuming]
   ```

5. **Generate Continuation Prompt and Write to TODO.md**

   Write a self-contained continuation prompt to the TODO.md file. This prompt gives the NEXT session everything needed to pick up immediately.

   The continuation prompt MUST include:
   - What project and working directory we're in
   - What was accomplished in this session
   - What is currently in progress (and how far along)
   - The exact next steps to take
   - Any running background processes (daemons, watchers, embedding jobs, etc.)
   - Key file paths that were created or modified

   Write it as a `## Continue` section at the **TOP** of TODO.md, replacing any existing `## Continue` section. The format must be:

   ```markdown
   ## Continue

   > **Last session:** NNNN - YYYY-MM-DD - Session Description
   > **Paused at:** YYYY-MM-DDTHH:MM:SSZ
   >
   > [Continuation prompt text — 3-8 sentences covering: project/dir, what was done,
   > what's in progress, exact next steps, background processes, key file paths]

   ---

   [rest of TODO.md content]
   ```

6. **Exit** - The session ends cleanly (stop-hook will finalize the note)

### "end session" Command

When user says "end session", execute this procedure:

1. **Complete Pause Procedure** (steps 1-4 above)

2. **RENAME SESSION NOTE (MANDATORY - NEVER SKIP)**
   ```bash
   # Find current session note
   ls -t Notes/*.md | head -1
   # Rename with meaningful description based on work done
   mv "Notes/0027 - 2026-01-04 - New Session.md" "Notes/0027 - 2026-01-04 - Descriptive Name Here.md"
   ```
   - The filename MUST describe what was accomplished
   - WRONG: "Appstore", "New Session", "Session Started"
   - RIGHT: "Markdown Heading Fix", "Notification System", "Dark Mode Implementation"

3. **Check for Uncommitted Changes**
   ```bash
   git status
   ```
   - If changes exist, ask: "There are uncommitted changes. Commit them?"

4. **Final Summary**
   - Provide a brief narrative of what was accomplished
   - The session note will be marked as "Completed"

### Session Note Naming

Session notes are stored in: `~/.claude/projects/{encoded-cwd}/Notes/` or local `Notes/`

**Format:** `NNNN - YYYY-MM-DD - Meaningful Description.md`

| Element | Requirement | Example |
|---------|-------------|---------|
| Number | **4 digits**, zero-padded | `0001`, `0027`, `0100` |
| Separator | **Space-dash-space** (` - `) | NOT `_`, NOT `-` alone |
| Date | ISO format | `2026-01-04` |
| Description | **Describes the WORK DONE** | NOT project name! |

**CORRECT Examples:**
```
0027 - 2026-01-04 - Markdown Heading Fix.md
0028 - 2026-01-05 - Notification System Refactor.md
0029 - 2026-01-06 - Dark Mode Implementation.md
```

**WRONG - NEVER DO THIS:**
```
0027 - 2026-01-04 - Appstore.md         ❌ Project name, not descriptive
0027 - 2026-01-04 - New Session.md      ❌ Placeholder, not descriptive
0027_2026-01-04_appstore.md             ❌ Wrong format AND not descriptive
```

**At session end, you MUST:**
1. Check if the session note has a placeholder name
2. Rename it based on the actual work done
3. Update the H1 title inside the file to match

---

## DELEGATION & PARALLELIZATION (Always Active)

**Whenever a task can be parallelized, use multiple agents.**

### Model Selection for Agents

| Task Type | Model | Why |
|-----------|-------|-----|
| Deep reasoning, complex architecture | `opus` | Maximum intelligence needed |
| Standard implementation, most coding | `sonnet` | Good balance of speed + capability |
| Simple lookups, quick checks, grunt work | `haiku` | 10-20x faster, sufficient intelligence |

**Rule of Thumb:**
- Grunt work or verification → `haiku`
- Implementation or research → `sonnet`
- Deep strategic thinking → `opus`

### How to Parallelize

- Use a SINGLE message with MULTIPLE Agent/Task tool calls = parallel execution
- Each agent gets FULL CONTEXT and DETAILED INSTRUCTIONS
- **ALWAYS launch a spotcheck agent after parallel work completes**

### Context Conservation

Bulk/repetitive work consumes context. Delegate it to conserve your main conversation space for planning and decisions.

**When to delegate:** Updating many files, batch refactoring, repetitive transformations, large-scale testing, batch file operations.

**Pattern:**
1. Plan the work in main conversation
2. Delegate to agent(s) with detailed instructions
3. Agent executes bulk changes efficiently
4. Review results and iterate if needed
5. Main conversation remains lean and focused

---

## TIME BUDGET AWARENESS (Always Active)

**Estimate effort tier BEFORE starting work, then stay within budget.**

| Tier | Budget | When |
|------|--------|------|
| **Quick** | < 2 min | Simple lookups, one-line fixes, direct answers |
| **Standard** | < 5 min | Single-file changes, focused research, one feature |
| **Extended** | < 15 min | Multi-file changes, moderate research, debugging |
| **Deep** | < 45 min | Architecture work, complex debugging, large features |
| **Comprehensive** | < 120 min | Major refactors, full implementations, deep research |

### Rules

1. **Estimate at start:** Before beginning work, classify the effort tier and announce it: "This is a Standard task (~5 min)."
2. **Check at midpoint:** If you've used > 50% of the budget and aren't > 50% done, reassess.
3. **Compress if over budget:** If elapsed > 150% of budget, simplify the approach:
   - Drop nice-to-haves, focus on core requirement
   - Use existing patterns instead of novel solutions
   - Deliver partial result with clear "what's left" summary
4. **Never silently overrun:** If a task needs more time than budgeted, say so: "This is taking longer than expected. The Quick fix became Extended because [reason]. Continuing."

---

## STACK PREFERENCES (Always Active)

- **TypeScript > Python** — Use TypeScript unless explicitly told otherwise
- **Package managers:** bun for JS/TS (NOT npm/yarn/pnpm), uv for Python (NOT pip)
- **Markdown > HTML:** Never use HTML tags for basic content
- **Analysis vs Action:** If asked to analyze, do analysis only — don't change things unless asked

---

## FILE ORGANIZATION (Always Active)

- **Scratchpad** (`${PAI_DIR}/scratchpad/`) — Temporary files only. Delete when done.
- **History** (`${PAI_DIR}/History/`) — Permanent valuable outputs.
- **Backups** (`${PAI_DIR}/History/backups/`) — All backups go here, NEVER inside skill directories.

**Rules:**
- Save valuable work to history, not scratchpad
- Never create `backups/` directories inside skills
- Never use `.bak` suffixes

---

## HISTORY SYSTEM — Past Work Lookup (Always Active)

**When the user asks about anything done in the past, check the history system first.**

The history system at `${PAI_DIR}/History/` contains all past work — sessions, learnings, research, decisions.

### How to Search History

```bash
# Quick keyword search across all history
rg -i "keyword" ${PAI_DIR}/History/

# Search sessions specifically
rg -i "keyword" ${PAI_DIR}/History/sessions/

# List recent files
ls -lt ${PAI_DIR}/History/sessions/ | head -20
```

### Directory Quick Reference

| What you're looking for | Where to search |
|------------------------|-----------------|
| Session summaries | `History/sessions/YYYY-MM/` |
| Problem-solving narratives | `History/learnings/YYYY-MM/` |
| Research & investigations | `History/research/YYYY-MM/` |

---

**This skill is installed by `pai setup`. For personal customization (identity, personality, notification preferences), create your own skill in `~/.claude/skills/`.**