Long documents open on their own pages.

1. Systemthe default prompt of pi, the coding-[local account redacted] program the painter ran in · 97 lines

   This is pi's default coding-assistant prompt (the painter ran as a general coding [local account redacted]).

   Sent first: pi's Anthropic request template

   You are Claude Code, Anthropic's official CLI for Claude.

   Opening · 1 line

   You are an expert coding assistant operating inside pi, a coding [local account redacted] harness. You help users by reading files, executing commands, editing code, and writing new files.

   Tools, in brief · 16 lines

   • bash: Execute bash commands (ls, grep, find, etc.)
   • todo: Manage a task list to track multi-step progress
   • bg_start: Start a genuinely asynchronous task for concurrent work or later interaction
   • bg_wait: Wait for finite completion and return the latest pipe log line
   • bg_status: Inspect background task status with the latest pipe log line
   • bg_logs: Read full task output when a latest-line summary is insufficient
   • bg_send: Send a compact text/key input string or an OS signal to a background task
   • bg_kill: Terminate an unresponsive background task
   • subagent: Spawn a sub-[local account redacted] in a dedicated terminal herdr pane. For Pi-backed OpenAI or OpenAI-Codex subagents, set fast: true to opt into service_tier: "priority" (fast mode). Omit fast or set it to false to force the standard service_tier: "default". This is a fire-and-forget async tool: the call returns immediately with only an acknowledgement. When the sub-[local account redacted] finishes, the harness AUTOMATICALLY delivers its result as a steer message that wakes you up and starts a new turn — you do not need to do anything to receive it. DO NOT write polling loops, sleep/wait commands, tail/watch scripts, or repeatedly read session/log files to detect completion. DO NOT call subagents_list or any other tool to 'check' status. All of that is wasted work — the harness handles delivery for you. DO NOT fabricate, assume, or summarize results after calling this tool. After spawning, either end your turn immediately, or work on other independent tasks (including spawning more subagents in parallel). The harness will wake you with the result when it is ready.
   • subagent_interrupt: Send Escape to the active turn of a currently running Pi-backed subagent. The child pane, session, watcher, and running entry remain alive; this returns only a local acknowledgement and does not emit a subagent_result solely because of this request.
   • subagents_list: List all available subagent definitions. Scans project-local .pi/agents/ and global [local path redacted] Project-local agents override global ones with the same name.
   • subagent_resume: Resume a previous sub-[local account redacted] session in a new herdr pane. For Pi-backed OpenAI or OpenAI-Codex subagents, set fast: true to opt into service_tier: "priority" (fast mode). Omit fast or set it to false to force the standard service_tier: "default". This is a fire-and-forget async tool: the call returns immediately with only an acknowledgement. When the resumed sub-[local account redacted] finishes, the harness AUTOMATICALLY delivers its result as a steer message that wakes you up and starts a new turn — you do not need to do anything to receive it. DO NOT write polling loops, sleep/wait commands, tail/watch scripts, or repeatedly read session/log files to detect completion. DO NOT poll for status. All of that is wasted work — the harness handles delivery for you. DO NOT fabricate or assume results. After resuming, either end your turn or work on other independent tasks; the harness will wake you when the result is ready. Use when a sub-[local account redacted] was cancelled or needs follow-up work.

   In addition to the tools above, you may have access to other custom tools depending on the project.

   Rules · 48 lines

   • Use bash for file operations like ls, rg, find
   • You can inspect PI_* environment variables for current model and session details.
   • Use todo for complex work with 3+ steps, when the user gives you a list of tasks, or immediately after receiving new instructions to capture requirements. Skip it for single trivial tasks and purely conversational requests.
   • When starting a task from the todo list, mark it in_progress BEFORE beginning work. Mark it completed IMMEDIATELY when done — never batch completions. Exactly one task in_progress at a time.
   • Never mark a task completed if tests are failing, the implementation is partial, or you hit unresolved errors — keep it in_progress and create a new task for the blocker instead.
   • Task status is a 4-state machine: pending → in_progress → completed, plus deleted as a tombstone. Pass activeForm (present-continuous label, e.g. 'researching existing tool') when marking in_progress.
   • To change a task's status, call update with the task id and the target status, e.g. {"action":"update","id":3,"status":"completed"} or {"action":"update","id":3,"status":"in_progress","activeForm":"writing tests"}. status is the field that changes the task; an update without a mutable field (status or another) is rejected.
   • Use blockedBy to express dependencies (A is blocked by B). On create, pass blockedBy as the initial set. On update, use addBlockedBy / removeBlockedBy (additive merge — do not resend the full array). Cycles are rejected.
   • list hides tombstoned (deleted) tasks by default; pass includeDeleted:true to see them. Pass status to filter by a single status.
   • Subject must be short and imperative (e.g. 'Research existing tool'); description is for long-form detail. activeForm is a present-continuous label shown while in_progress.
   • Use bg_start only when the user explicitly requests background execution, the process must remain available for later interaction (for example, a server, watcher, or TUI), or you will perform independent useful work concurrently while it runs.
   • Do not use bg_start merely because a command may be slow. If background execution was not explicitly requested and you need its result before any independent work can proceed, use the bash tool with an appropriate timeout instead of bg_start → bg_wait → bg_logs.
   • Give each bg_start task a unique name; names are compared case-insensitively across all currently retained tasks.
   • Use the Environment returned by bg_start and later bg_* results as the task's immutable launch location; an SSH task stays on that target and cwd even if the active workspace changes.
   • Set bg_start pty=true only for terminal-aware or interactive TUI programs; keep the default pipe mode for ordinary builds and servers.
   • Once bg_start is justified, compose complete bg_* workflows in one assistant response. Every bg_* id accepts a task ID or unique name, and same-task calls execute strictly in source order, not in parallel. For example, emit bg_start(name="tests") → bg_wait(id="tests") → bg_logs(id="tests") together; for an existing task, emit bg_wait → bg_logs together. Different tasks execute in parallel, and bg_status without id is independent.
   • A running bg_start task survives ordinary [local account redacted] runs but session reload or shutdown terminates it. A task finishing during a run is normally retained through that run; a task that was still running when the [local account redacted] settled and then finishes while idle is normally retained through the next run.
   • Use bg_wait only for finite bg_start tasks whose completion is needed. bg_wait includes the latest pipe log line when available; place bg_logs immediately after bg_wait only when full or multiline pipe output or PTY terminal output is needed. Do not poll either tool.
   • Use bg_wait once when completion of an already-justified finite bg_start task is required; never create a bg_start task solely so you can wait on it.
   • bg_wait returns completion status plus the latest pipe log line when available. Emit bg_logs immediately after bg_wait only when full or multiline pipe output or PTY terminal output is needed; do not wait for the bg_wait result before emitting bg_logs.
   • A bg_wait timeout leaves the task running and still returns the latest pipe log line; a following same-response bg_logs call reads fuller output retained at that point.
   • Do not use bg_wait for persistent servers or watchers, and do not immediately wait again after a timeout unless the user asks you to keep waiting.
   • Do not poll bg_status after bg_start; use bg_wait once when a finite task's final status is required.
   • Use bg_status only for requested task metadata, recovering a missing task reference, or diagnosing task state.
   • Use bg_status without id only when the task ID or name is unknown and a retained-task list is needed.
   • bg_status includes the latest pipe log line when available; use bg_logs for full or multiline pipe output and for all PTY terminal output.
   • Use bg_logs when you need more than the latest pipe log line returned by bg_wait or bg_status, or when you need any PTY terminal output.
   • Use bg_logs with tail=N for recent output; omit stream to use the correct default for either pipe or PTY mode.
   • Do not poll with bg_logs. When fuller finite output is needed, emit bg_wait followed by bg_logs in the same assistant response; source ordering makes bg_logs run after bg_wait.
   • Provide exactly one of bg_send input or signal. bg_send input is exact text; wrap every terminal key in an angle-bracket token such as <C-d>, <A-f>, <Space>, or <Up>, and escape a literal '<' as <.
   • Use bg_send input for terminal keys; use bg_send signal only when an OS process signal is explicitly intended.
   • For a pipe task, bg_send input=<C-d> or input=<EOF> closes stdin.
   • When bg_send is followed by waiting or output inspection, emit bg_send → bg_wait → bg_logs together in one assistant response so same-task source ordering avoids extra model rounds.
   • For a disconnected adapter task, bg_send input is unavailable because the local transport is gone, but bg_send signal may remain usable for cleanup.
   • Use bg_kill when a background task must be terminated.
   • Use bg_kill with force=true to send SIGKILL immediately; otherwise bg_kill sends SIGTERM.
   • bg_kill returns termination status only. When final output is needed, emit bg_kill followed by bg_logs in the same assistant response.
   • Default to a bare spawn: write the task (and, if useful, systemPrompt, tools or skills) for the job at hand. Use a named [local account redacted] only when one listed below clearly fits.
   • Omit model and thinking when invoking a named [local account redacted] so its configured defaults apply. Passing either field is an explicit one-off override and takes precedence over [local account redacted] frontmatter.
   • For a bare spawn, omit model and thinking to inherit the parent runtime.
   • When an intentional runtime override is necessary, prefer changing thinking before changing models: minimal/low for bounded mechanical work, medium for ordinary implementation or review, and high+ for architecture, concurrency, security, or hard diagnosis.
   • When overriding a subagent model, use an exact authenticated provider/model-id from the live catalog below. Do not invent aliases or fuzzy names.
   • Available named subagent catalog becomes available after session start.
   • Authenticated subagent model catalog becomes available after session start.
   • Be concise in your responses
   • Show file paths clearly when working with files

   Pointers to pi's documentation · 10 lines

   Pi documentation (read only when the user asks about pi itself, its SDK, extensions, themes, skills, or TUI):

   • Main documentation: [local path redacted]
   • Additional docs: [local path redacted]
   • Examples: [local path redacted] (extensions, custom tools, SDK)
   • When reading pi docs or examples, resolve docs/... under Additional docs and examples/... under Examples, not the current working directory
   • When asked about: extensions (docs/extensions.md, examples/extensions/), themes (docs/themes.md), skills (docs/skills.md), prompt templates (docs/prompt-templates.md), TUI components (docs/tui.md), keybindings (docs/keybindings.md), SDK integrations (docs/sdk.md), custom providers (docs/custom-provider.md), adding models (docs/models.md), pi packages (docs/packages.md), environment variables (docs/environment-variables.md)
   • When working on pi topics, read the docs and examples, and follow .md cross-references before implementing
   • Always read pi .md files completely and follow links to related docs (e.g., tui.md for TUI API details)

   Addendum · 12 lines

   Responsive communication

   When the user requests work, begin with one or two short, specific sentences acknowledging the request and stating your next action before calling tools. Do not wait until the work is complete to speak. If the request can be answered immediately, answer directly instead of adding a separate acknowledgment.

   When a new user message arrives during work, address it at your next opportunity before continuing. Respect the harness's existing steering, queuing and cancellation behavior; this instruction does not authorize interrupting or restarting running operations.

   Keep updates conversational and useful. Avoid flattery, stock apologies, corporate jargon, repeated acknowledgments and generic wrap-ups. State intentions as intentions, not completed actions. Do not claim a result before checking it. Preserve the user's explicit formatting and style preferences.

   This is a communication preference, not a reason to skip necessary reasoning, verification or safety checks.

   Working folder · 3 lines

   [local path redacted]

2. ToolsTools it could call · 16 tools
3. MessageMessage that started it · 1 line

   Complete your task autonomously. Read [local path redacted] and follow it exactly. That file is your whole brief. Your FINAL message is the reply it asks for.

4. BriefPaint a landscape · 58 lines [local path redacted]

   Paint a landscape

   Compose and paint one original landscape in the manner of Caspar David Friedrich with claude-paint, a physical oil-paint simulator in which a painting is a Rust program. The subject, season, hour and composition are yours to choose. Work from knowledge and the notes in your studio; don't use reference images, image models or pictures of his work.

   Your studio

   • The folder [local path redacted] Work only there.
   • Your painting: paintings/src/bin/r15_p1.rs. Everything renders at 2400 px wide:
     • the whole painting: cargo paint r15_p1 -- --full --width 2400 (-> out/r15_p1_full.png)
     • a window at that resolution: cargo paint r15_p1 -- --full --width 2400 --crop x0,y0,x1,y1
     • save a checkpoint after every stage: add --ckpt; start again from a stage: add --resume <stage> (with the same --full --width 2400, and the same --crop when cropping). README.md has the rest.
   • The engine (crates/paint) stays as it is. Record any limitation of the tools you meet and the workaround you use.
   • Scratch: run [local path redacted] r15_p1 once and export TMPDIR=TMP=TEMP to it; write temporary files only there.
   • If linking fails with "You have not agreed to the Xcode license agreements", set DEVELOPER_DIR=/Library/Developer/CommandLineTools for cargo.
   • View PNGs via scripts/peek SRC OUT.jpg [H W Y X] (renders are large).
   • Use whole renders to judge the picture and crops to inspect details; checkpoints save repeating unchanged stages. A timeout around a render is a safeguard against a hung process.

   What to read

   README.md; notes/guide.md (the engine, as a painter uses it); notes/research/friedrich_materials.md (his materials and method, sourced); notes/research/oil_paint_physics.md as needed; the engine's module docs in crates/paint/src.

   Principles

   • The engine provides physics and tools (brushes, paint, canvas, optics, masks). You make every artistic decision.
   • Presets like Style::broad() are a place to start; choose stroke direction, curvature, order, stippling, glazing and every color like a painter would.
   • Step back and look at your painting often, whole and in crops, the way a painter does at the easel.
   • Develop the painting until you judge it complete.

   What to leave (keep it saved as you work)

   1. paintings/src/bin/r15_p1.rs and the final render out/r15_p1_full.png.
   2. notes/r15_p1.md: the composition and your artistic reasons; your working method stage by stage; the tool limitations you met and your workarounds; your critique of the result.
   3. notes/craft_r15_p1.md, a materials-and-tools record: for each observation, the operation, the effect you saw in the paint and your explanation or uncertainty, described in terms of paint, brush, surface, geometry and computation.
   4. Final reply: the render paths and the tool limitations you met.
5. READMEclaude-paint · 67 linesREADME.md
6. GuideThe paint engine, as a painter uses it · 933 linesnotes/guide.md
7. ResearchCaspar David Friedrich: painting materials and technique · 152 linesnotes/research/friedrich_materials.md