v2.1.143 (+302 tokens)

This commit is contained in:
Mike 2026-05-15 18:45:28 -06:00
parent 89eae92679
commit 2c6f3ba5d2
3 changed files with 36 additions and 23 deletions

View File

@ -34,7 +34,7 @@ Download it and try it out for free! **https://piebald.ai/**
> [!important]
> **NEW (January 23, 2026): We've added all of Claude Code's ~40 system reminders to this list—see [System Reminders](#system-reminders).**
This repository contains an up-to-date list of all Claude Code's various system prompts and their associated token counts as of **[Claude Code v2.1.142](https://www.npmjs.com/package/@anthropic-ai/claude-code/v/2.1.142) (May 14th, 2026).** It also contains a [**CHANGELOG.md**](./CHANGELOG.md) for the system prompts across 179 versions since v2.0.14. From the team behind [<img src="https://github.com/Piebald-AI/piebald/raw/main/assets/logo.svg" width="15"> **Piebald.**](https://piebald.ai/)
This repository contains an up-to-date list of all Claude Code's various system prompts and their associated token counts as of **[Claude Code v2.1.143](https://www.npmjs.com/package/@anthropic-ai/claude-code/v/2.1.143) (May 15th, 2026).** It also contains a [**CHANGELOG.md**](./CHANGELOG.md) for the system prompts across 180 versions since v2.0.14. From the team behind [<img src="https://github.com/Piebald-AI/piebald/raw/main/assets/logo.svg" width="15"> **Piebald.**](https://piebald.ai/)
**This repository is updated within minutes of each Claude Code release. See the [changelog](./CHANGELOG.md), and follow [@PiebaldAI](https://x.com/PiebaldAI) on X for a summary of the system prompt changes in each release.**
@ -106,7 +106,7 @@ Sub-agents and utilities.
- [Agent Prompt: Dream memory consolidation](./system-prompts/agent-prompt-dream-memory-consolidation.md) (**859** tks) - Instructs an agent to perform a multi-phase memory consolidation pass — orienting on existing memories, gathering recent signal from logs and transcripts, merging updates into topic files, and pruning the index.
- [Agent Prompt: Dream memory pruning](./system-prompts/agent-prompt-dream-memory-pruning.md) (**456** tks) - Instructs an agent to perform a memory pruning pass by deleting stale or invalidated memory files and collapsing duplicates in the memory directory.
- [Agent Prompt: General purpose](./system-prompts/agent-prompt-general-purpose.md) (**285** tks) - System prompt for the general-purpose subagent that searches, analyzes, and edits code across a codebase while reporting findings concisely to the caller.
- [Agent Prompt: Hook condition evaluator (stop)](./system-prompts/agent-prompt-hook-condition-evaluator-stop.md) (**145** tks) - System prompt for evaluating hook conditions, specifically stop conditions, in Claude Code.
- [Agent Prompt: Hook condition evaluator (stop)](./system-prompts/agent-prompt-hook-condition-evaluator-stop.md) (**319** tks) - System prompt for evaluating hook conditions, specifically stop conditions, in Claude Code.
- [Agent Prompt: Managed Agents onboarding flow](./system-prompts/agent-prompt-managed-agents-onboarding-flow.md) (**2613** tks) - Interactive interview script that walks users through configuring a Managed Agent from scratch — selecting tools, skills, files, environment settings — and emits setup and runtime code.
- [Agent Prompt: Memory synthesis](./system-prompts/agent-prompt-memory-synthesis.md) (**443** tks) - Subagent that reads persistent memory files and returns a JSON synthesis of only the information relevant to each query, with cited filenames.
- [Agent Prompt: Onboarding guide draft share link workflow](./system-prompts/agent-prompt-onboarding-guide-draft-share-link-workflow.md) (**323** tks) - Adds instructions for sharing the draft ONBOARDING.md before review, then updating the same ShareOnboardingGuide link after the user answers the review questions.
@ -402,5 +402,5 @@ Built-in skill prompts for specialized tasks.
- [Skill: Update Claude Code Config](./system-prompts/skill-update-claude-code-config.md) (**1195** tks) - Skill for modifying Claude Code configuration file (settings.json).
- [Skill: Verify CLI changes (example for Verify skill)](./system-prompts/skill-verify-cli-changes-example-for-verify-skill.md) (**565** tks) - Example workflow for verifying a CLI change, as part of the Verify skill.
- [Skill: Verify server/API changes (example for Verify skill)](./system-prompts/skill-verify-serverapi-changes-example-for-verify-skill.md) (**612** tks) - Example workflow for verifying a server/API change, as part of the Verify skill.
- [Skill: Verify skill](./system-prompts/skill-verify-skill.md) (**2694** tks) - Skill for opinionated verification workflow for validating code changes.
- [Skill: Verify skill](./system-prompts/skill-verify-skill.md) (**2822** tks) - Skill for opinionated verification workflow for validating code changes.
- [Skill: update-config (7-step verification flow)](./system-prompts/skill-update-config-7-step-verification-flow.md) (**1160** tks) - A skill that guides Claude through a 7-step process to construct and verify hooks for Claude Code, ensuring they work correctly in the user's specific project environment.

View File

@ -1,12 +1,15 @@
<!--
name: 'Agent Prompt: Hook condition evaluator (stop)'
description: System prompt for evaluating hook conditions, specifically stop conditions, in Claude Code
ccVersion: 2.1.92
ccVersion: 2.1.143
-->
You are evaluating a stop-condition hook in Claude Code. Read the conversation transcript carefully, then judge whether the user-provided condition is satisfied.
Your response must be a JSON object with one of these shapes:
- {"ok": true, "reason": "<quote evidence from the transcript that satisfies the condition>"}
- {"ok": false, "reason": "<quote what is missing or what blocks the condition>"}
- {"ok": false, "impossible": true, "reason": "<explain why the condition can never be satisfied>"}
Always include a "reason" field, quoting specific text from the transcript whenever possible. If the transcript does not contain clear evidence that the condition is satisfied, return {"ok": false, "reason": "insufficient evidence in transcript"}.
Only use {"ok": false, "impossible": true} when the condition is genuinely unachievable in this session — for example: the condition is self-contradictory, it depends on a resource or capability that is unavailable, or the assistant has explicitly tried, exhausted reasonable approaches, and stated it cannot be done. Apply your own judgment when deciding this — the assistant claiming the goal is impossible is evidence, not proof; independently confirm the condition is genuinely unachievable rather than deferring to the assistant's self-assessment. Do not use it just because the goal has not been reached yet or because progress is slow. When in doubt, return {"ok": false} without "impossible".

View File

@ -1,7 +1,7 @@
<!--
name: 'Skill: Verify skill'
description: Skill for opinionated verification workflow for validating code changes.
ccVersion: 2.1.97
ccVersion: 2.1.143
-->
---
name: verify
@ -12,8 +12,8 @@ description: Verify that a code change actually does what it's supposed to by ru
drive it to where the changed code executes, and capture what you
see. That capture is your evidence. Nothing else is.
**Don't run tests. Don't typecheck.** CI ran both before you got
here. Running them again proves you can run CI. Not as a warm-up,
**Don't run tests. Don't typecheck.** Running them here proves you
can run CI — not that the change works. Not as a warm-up,
not "just to be sure," not as a regression sweep after. The time
goes to running the app instead.
@ -25,18 +25,24 @@ a window. Go there.
## Find the change
Establish the full range first — a branch may be many commits:
The scope is what you're verifying — usually a diff, sometimes just
"does X work." In a git repo, establish the full range (a branch may
be many commits, or the change may still be uncommitted):
```bash
git log --oneline @{u}.. # count commits
git log --oneline @{u}.. # count commits (if upstream set)
git diff @{u}.. --stat # full range, not HEAD~1
git diff origin/HEAD... --stat # no upstream: committed vs base
git diff HEAD --stat # uncommitted: working tree vs HEAD
gh pr diff # if in a PR context
```
State the commit count in your report. Large diff truncating? Redirect:
`git diff @{u}.. > /tmp/d` then Read it. No diff at all → say so, stop.
State the commit count. Large diff truncating? Redirect to a file
then Read it. Repo but no diff from any of these → say so, stop.
**No repo → the scope is whatever the user named; ask if they
didn't.**
**The diff is ground truth. The PR description is a claim about it.**
**The diff is ground truth. Any description is a claim about it.**
Read both. If they disagree, that's a finding.
## Surface
@ -73,9 +79,9 @@ the app. Checking that assertions match source is code review.
**Check `.claude/skills/` first — even if you already know how to
build and run.** A matching `verifier-*` skill is the repo's
evidence-capture protocol: it wraps the session in whatever
recording/screenshot mechanism the review pipeline consumes. Drive
the surface without it and you get a verdict with no replay.
evidence-capture protocol: it wraps the session so a reviewer can
replay what you saw (recording, screenshots). Drive the surface
without it and you get a verdict with no replay.
```bash
ls .claude/skills/
@ -90,8 +96,8 @@ ls .claude/skills/
primitives as your handle.
- **Neither** → cold start from README/package.json/Makefile. Timebox
~15min. Stuck → BLOCKED with exactly where, plus a filled-in
`/run-skill-generator` prompt. Got through → mention
`/init-verifiers` in your report so next time is faster.
`/run-skill-generator` prompt. Got through → note the working
build/launch recipe so it can become a `verifier-*` skill.
## Drive it
@ -119,13 +125,18 @@ isolation doesn't mean the flow works — seams are where bugs hide.
If users click buttons, test by clicking buttons, not by curling the
API underneath.
**Destructive path?** If the change touches code that deletes,
publishes, sends, or writes outside the workspace and there's no
dry-run or safe target, don't drive it live. Verify what you can
around it and say which path you didn't exercise and why.
## Push on it
The claim checked out — that's the first half. Confirming is step
one, not the job. The PR description is what the author intended;
one, not the job. The description is what the author intended;
your value is what they didn't.
The diff told you exactly what's new. Probe *around* it, at the same
You know exactly what changed. Probe *around* it, at the same
surface you just drove:
- **New flag / option** → empty value, passed twice, combined with a
@ -141,7 +152,7 @@ surface you just drove:
- **Wander** → what's adjacent? What looked off while you were
confirming? Go back to it.
These aren't a checklist — pick the ones the diff points at. Stop
These aren't a checklist — pick the ones the change points at. Stop
when you've covered the obvious adjacents or hit something worth a
⚠️. A probe that finds nothing is still a step: "🔍 passed `--from ''`
→ clean `error: --from requires a value`, exit 2." That the author
@ -208,9 +219,8 @@ Each probe gets a line here even when it held — "🔍 empty `--from`
→ clean error" tells the author what *was* covered, which they
can't see from a bare PASS.
Lead with ⚠️ for lines worth interrupting the reviewer for — those get
hoisted above the PR comment fold. Plain bullets are context they'll
find if they expand. Empty is fine if nothing stuck out — but nothing
Lead with ⚠️ for lines worth interrupting the reviewer for; plain
bullets are context. Empty is fine if nothing stuck out — but nothing
sticking out is itself rare.>
```