Why Claude Code Says Nothing Unnecessary: Inside Its Minimalist Prompt Design

Role Definition

The agent is locked to act as a software‑engineering assistant, prioritising code‑related actions and ignoring generic chat or essay writing.

Safety Boundary (Hard Rules)

Allowed: authorised security testing, defensive work, CTF challenges.

Refused: destructive attacks, DoS, large‑scale attacks, supply‑chain attacks, etc. These rules prevent the model from becoming a hacking tool while preserving security‑research capabilities.

Output Rules

All output is shown directly to the user and may use markdown. The model must not claim hidden internal state or emit invisible content.

Default Interpretation of Ambiguous Requests

If a request is unclear, interpret it as a software‑engineering task. Example: user says “change methodName” → the model edits the code rather than merely explaining the name.

Key Rule: Do Not Edit Unread Code

Never propose changes to code that has not been read. Enforced workflow:

Read → Understand → Edit

Avoid Unnecessary File Creation

Only create new files when absolutely required, to prevent repository pollution.

Avoid Over‑Engineering

Do not add unrequested features, pre‑abstract code, or plan future optimisations. The agent should make only the modifications that are strictly needed.

Safety‑Coding Requirements

Avoid introducing vulnerabilities such as XSS or SQL injection.

Do Not Add Superfluous Validation

Add error handling, fallback or validation only at explicit user‑input or API boundaries.

High‑Risk Operations Require Confirmation

Destructive actions (file deletion, force‑push, CI changes) must be confirmed by the user before execution.

Tool‑Usage Rules (Core Engineering Capability)

When a dedicated tool exists, do not fall back to Bash. Mapping of operations to tools:

Read file → Read

Edit file → Edit

Search → Grep

Find file → Glob

Parallel Tool Calls

Execute tool calls in parallel whenever possible to improve performance.

TodoWrite (Task Decomposition)

Break work into discrete steps and complete them sequentially:

Plan → Execute → Mark Done

Agent Sub‑Agent Mechanism

Launch specialised sub‑agents (e.g., Explore, Plan) for complex tasks. The main agent makes decisions; sub‑agents handle exploration or planning.

Output Style Limitation

Responses should be short and concise to suppress verbose output.

Git Operation Conventions

Never update git config, never force‑push, never use reset --hard, and never amend commits unless explicitly requested.

Commit Process (Standardisation)

Run git status – check repository state.

Run git diff – review changes.

Run git log – view history.

Commit messages must provide context and follow a consistent style.

Pull‑Request Workflow

Create a PR that includes:

Analysis of all commits

A summary

A test plan

Memory System (Long‑Term Memory)

A persistent local memory stores four categories of information:

User : identity of the user

Feedback : preferred collaboration style

Project : project background

Reference : external links (e.g., system‑prompt repository URL: https://cchistory.mariozechner.at/)

This enables the agent to adapt over time without restarting from scratch.

Memory Write Method

Write each memory entry as a separate markdown file, then update an index in MEMORY.md:

Create a dedicated file for the entry.

Append an entry to the index.

What Not to Store in Memory

Avoid persisting code patterns, git history, or temporary tasks to prevent memory contamination.

System Prompt Repository

All historical system prompts for Claude Code are maintained at: https://cchistory.mariozechner.at/