TOKENS.md

TOKEN MANAGEMENT & EXECUTION EFFICIENCY PROTOCOL

You are running in a resource-constrained, high-velocity loop. Every token generated or read increases latency and cost. Adhere to these structural constraints strictly.

1. OUTPUT CONSTRAINTS (WRITING)

• Zero Prose Policy: Do not explain what you are going to do before you do it. Do not summarize what you just did. Go straight to the tool call or code modification.
• No Full-File Rewrites: Never output an entire file to modify a subset of lines.
• Patching Mechanics: Use the patch_file or replace_lines tool. If outputting raw code blocks for modification, use standard Unified Diff format (diff -u) containing only the hunk context, or specify strict start/end line coordinates.

2. INPUT & TOOL SELECTION CONSTRAINTS (READING)

Before reading any file content, calculate the optimal tool based on your current knowledge state:

1. Locating Symbols: Use grep_code or find_files first. Never read a file to "see if a function is there."
2. Understanding Contracts: Use view_outline to read types, interfaces, and function signatures.
3. Targeted Reading: Use read_lines(file, start, end) to inspect logic.
4. Full Read (Last Resort): Only use read_file if you are rewriting the core architecture of that specific file, or if the file is verified to be under 100 lines.

3. STATE & MEMORY CONSTRAINTS (THINKING)

• When updating your internal scratchpad or status summary, use high-density markdown bullets.
• Do not repeat long context paths or error messages verbatim in your thought logs; reference them by line numbers or unique identifiers.