token-burner

Token Burner

Automatically execute valuable project improvement tasks before the token expires, without wasting any quota.

Overview

Automatically scan the project, discover tasks such as code review, test generation, documentation improvement, dependency auditing, refactoring, etc., sort them by priority, and then execute them autonomously. Use a worktree to isolate each task, and automatically verify after execution to ensure every change is safe.

When to Use

• User wants to use tokens productively before they expire
• User wants to run an autonomous code improvement session
• User says "burn tokens" / "token burner" / "use up tokens"
• User wants to auto-discover and fix issues across a project
• User inputs /token-burner
• User wants automated code review across the project
• User wants to find and fix code smells automatically
• User wants to improve test coverage without manual effort
• User wants to do a full project health check and cleanup

When NOT to Use:

• User wants to work on a specific, well-defined task (use normal workflow)
• User wants to chat or brainstorm (no token waste concern)
• User's project has no code to improve
• User wants to run automated tests only (use test runner directly)
• User wants to generate documentation only (use doc generation tools)
• User wants to refactor specific files (do it manually for better control)

Core Pattern

Step 1: Project scan

Detect the project type and structure, and discover executable tasks:

# 检测项目类型
test -f package.json && echo "Node.js"
test -f go.mod && echo "Go"
test -f requirements.txt && echo "Python"
test -f Cargo.toml && echo "Rust"

# 检测 git 状态
git log --oneline -5          # 最近变更
git diff --stat HEAD~3        # 变更范围
git status --porcelain        # 未提交变更

Task discovery engine:(see templates/task-discovery.md）

Task type	Discovery method	Priority
🔒 Dependency security	If dependency-audit skill is available, delegate; otherwise run the audit tool directly	P0 - Execute immediately
🐛 Code defects	Analyze git diff logic issues in	P0 - Execute immediately
🧪 Test coverage	Find source files without tests, check coverage	P1 - High priority
📝 Missing documentation	Check README, function comments, API docs	P2 - Medium priority
♻️ Code refactoring	Duplicate code, complex functions, code smell	P2 - Medium priority
🧹 Git cleanup	Stale branches, conflict markers, large files	P3 - Low priority

Generate a task list, each task includes:type、file、description、impact（high/medium/low）、risk（high/medium/low）。

Step 2: Priority sorting

Sort by score = impact_score × (1 - risk_score) :

Factor	high	medium	low
impact	3	2	1
risk	0.8	0.4	0.1

Safety policy:

• P0 tasks (security vulnerabilities, defects) → execute immediately
• P1 tasks (tests) → can be executed, but each task is isolated in a worktree
• P2 tasks (documentation, refactoring) → can be executed
• P3 tasks (cleanup) → only execute when there are remaining tokens

Prerequisite dependency check:

Before execution, first check whether the required tools are available; when missing, skip the corresponding task type instead of failing silently:

# 检查工具可用性
command -v jq >/dev/null 2>&1 || echo "⚠️ jq 未安装，安全审计任务将跳过"
command -v npm >/dev/null 2>&1 || echo "⚠️ npm 未安装，Node.js 审计将跳过"
command -v go >/dev/null 2>&1 || echo "⚠️ go 未安装，Go 审计将跳过"
command -v pip-audit >/dev/null 2>&1 || echo "⚠️ pip-audit 未安装，Python 审计将跳过"

Filtering rules:

• Skip node_modules/、vendor/、.git/ and other directories
• Skip tasks already covered by other skills (such as those already configured by git-hooks-setup)
• Skip large tasks with more than 500 lines of changes (split into subtasks)

Step 3: Autonomous execution

Use the Agent tool to execute tasks one by one, with each task in an independent worktree:

对每个 task in 队列:
  retries = 0
  max_retries = 3
  while retries < max_retries:
    1. Agent(task.prompt, {
         subagent_type: "general-purpose",
         isolation: "worktree",
         description: "token-burner:" + task.type
       })
    2. 在 worktree 中跑测试验证
    3. 如果测试通过 → 合并到主分支，break
    4. 如果测试失败 → retries++
       - 如果 retries < max_retries → 回滚 worktree，重试
       - 如果 retries >= max_retries → 记录失败原因，跳过此任务
    5. 更新任务状态

Execution strategy for each task type:

Task type	Execution method	Verification method
🔒 Dependency security	Run the audit tool, generate fix commands	Re-audit to confirm
🐛 Code defects	Analyze the diff, locate the problem, fix it	Run related tests
🧪 Test coverage	Generate unit tests for source files	Run the new tests to confirm they pass
📝 Missing documentation	Generate README/comments/API docs	Check documentation format
♻️ Code refactoring	Extract functions, eliminate duplication, simplify logic	Run the full test suite
🧹 Git cleanup	Clean up unused files, format	Confirm with git status

Execution limits:

• Each task retries at most 3 times
• Skip a single task if it times out after 5 minutes
• Total number of tasks defaults to at most 20 (can be adjusted via --max-tasks )

Step 4: Record and report

After each task completes, record to memory (task type, file, status, description); execution structure see templates/execution-report.md。

Step 5: Wrap up

Generate the final report templates/execution-report.md, including:

• Execution statistics (success rate, duration, estimated token consumption)
• Detailed results for each task
• Reasons for tasks not executed
• Suggestions for the next run

Quick Reference

Note: Parameters below are natural language hints parsed by the AI. Without parameters, the AI will ask interactively.

/token-burner                          # Scan and execute all tasks
/token-burner 只跑测试和文档            # Only test and doc tasks
/token-burner 最多跑 10 个任务          # Limit to 10 tasks
/token-burner 只扫描不执行              # Scan only, don't execute
/token-burner 扫描 /path/to/repo       # Target specific project

Hint	Description	Default
Only run type	Task type filter (security/bug/test/docs/refactor/clean)	All
Run at most N tasks	Maximum tasks to execute	20
Scan only, do not execute	Scan only, don't execute	false
Scan path	Target project path	Current directory

Common Mistakes

Error	Correct approach	Reason
Merge without running tests	Must verify after each task is executed	Avoid introducing new bugs
Execute too many tasks at once	Keep within 20	Avoid giving up halfway when tokens run out
Skip worktree isolation	Always use isolation: "worktree"	Avoid interference between tasks
Do not record execution results	Write to the memory file	The next run needs to know what has been done
Do not verify production code	Must run tests after changes	Ensure existing functionality is not broken
Do not check tool availability	Verify whether the tool exists before execution	Tasks with missing tools should be skipped rather than reported as errors
Do not limit the number of tasks on large projects	Set --max-tasks limit	Avoid task interruption after tokens are exhausted
Skip risk assessment	Sort by impact × (1 - risk)	High-risk tasks should be handled with caution
Do not distinguish directories such as node_modules	Skip vendor/node_modules/.git	Scanning third-party code wastes tokens
Do not check diffs during refactoring	Limit single-task changes to < 500 lines	Overly large changes are hard to verify for safety