Assemble a System Prompt Like the Pros

PROJECT CONTEXT:
My agent's system prompt is a wall of text that grew by accretion. Analyses of production harnesses show system prompts are assembled programmatically from layered sections: identity, rules, tool guidance, environment, and dynamic state.

GOAL:
Rebuild my system prompt as a structured, programmatic assembly with static layers, dynamic sections, and rules the harness can actually enforce.

REQUIREMENTS:
- The prompt decomposed into named sections: identity, capabilities, hard rules, tool guidance, environment, dynamic state
- An assembler function that builds the prompt from sections at runtime
- Dynamic sections (cwd, git status, date, active plan) injected fresh per session or turn
- Hard rules written as testable statements paired with harness-side enforcement where possible
- A token budget per section with measurement

CONSTRAINTS:
- No section may duplicate another's job - one home per instruction
- Behavioral rules that can be enforced in code should also be enforced in code

DEFINITION OF DONE:
- The assembled prompt renders from sections with a visible per-section token report
- Dynamic state (cwd, date, plan) is correct at runtime, not baked in
- Each hard rule maps to either a test case or a harness enforcement point
- Removing any single section produces a measurable behavior change (sections earn their tokens)

COMMON FAILURES TO AVOID:
- One monolithic prompt where nobody knows which line does what
- Stale baked-in facts (dates, paths) contradicting reality at runtime
- Rules stated in the prompt but violated freely because nothing enforces them
- Prompt bloat: sections kept out of superstition rather than measured value