context-budget-planner
Estimates the implementation phase's token footprint from spec, test plan and affected files, and recommends compaction before context runs out. Use when a graduated or full lane change moves from planning to implementation.
- License 许可
- MIT
- 所属仓库
- Eliyce/paqad-ai
- 最近更新
- 2026-11-13
- Stars
- ★ 8
- Forks
- 0
01 前言 Front Matter
- name
- context-budget-planner
- metadata
- { "cacheable": "false", "model_tier": "fast", "paqad-meta": "skill.meta.yaml", "output_format": "markdown" }
- description
- Estimates the implementation phase's token footprint from spec, test plan and affected files, and recommends compaction before context runs out. Use when a graduated or full lane change moves from planning to implementation.
02 资源文件 7
- 参考文档agents/openai.yaml174 B
- 资产文件assets/output.template.md527 B
- 资产文件assets/weights.default.txt203 B
- 参考文档references/budget-heuristics.md2.2 KB
- 脚本scripts/estimate-tokens.sh2.0 KB
- 脚本scripts/lint-output.sh1019 B
- 参考文档skill.meta.yaml602 B
03 SKILL.md 正文
What It Does
Predicts the token footprint of the upcoming implementation phase before it starts. Reads spec size, test plan size, affected module docs, and known changed files; sums their token cost using the per-line weights in the heuristics reference; compares against the available budget; and recommends compaction when the estimate would push the session into the Amber or Red tier.
The point is to catch starvation before it happens, not after compaction has already evicted decisions mid-task.
Use This When
Once at the boundary between planning and implementation in the graduated and full lanes: after acceptance criteria and test plan exist, before the first source file is opened. Skip in the fast lane; the overhead is not justified for low-complexity work.
Inputs
- Read the active spec at
spec_pathfirst. - Read
test_plan_pathwhen supplied. - Read each module doc in
affected_module_doc_pathsonly enough to compute its line count. - Read
references/budget-heuristics.mdbefore applying any threshold so the per-line weights and tier boundaries stay consistent across runs.
Procedure
- Determine the project's model context window (from project profile) and committed tokens (default 200000 / 30000 if not declared).
- Pick per-line weights from
references/budget-heuristics.md(orassets/weights.default.txtif the project has none yet). - Pipe
<weight> <path>rows intoscripts/estimate-tokens.sh --available <N> --committed <N>: it line-counts, multiplies, sums, picks the tier, and emits the markdown block. - When the script reports Amber or Red, fill the compaction list using the priority order from
references/budget-heuristics.md. - Validate the final output with
scripts/lint-output.sh.
Output Contract
- Match
assets/output.template.md:## Context Budget, singleSummary:line,### Per-Artifact Estimatetable,### Recommended Compactions. - Green/Yellow →
Recommended Compactions: noneexactly. Amber/Red → ordered list with one-line reasons. - Output must pass
scripts/lint-output.sh(exit 0).
Escalate / Stop Conditions
- Ask when the project profile declares no model context window and the default would clearly overcommit.
- Warn when
Tier: redis reached even after applying every available compaction: implementation should be split into smaller stories rather than starting with no headroom. - Do not recommend evicting the active spec, the rules constitution, the project profile, or the active decision packet under any tier.
Resources
references/budget-heuristics.mdscripts/estimate-tokens.shscripts/lint-output.shassets/output.template.mdassets/weights.default.txtagents/openai.yaml
04 同仓库更多 Skills
sample-skill
Sample bundled skill fixture
processing-invoices
Turns a supplier invoice into one ledger line. Use when a supplier invoice arrives and needs booking.
processing-invoices
Turns a supplier invoice into one ledger line. Use when a supplier invoice arrives and needs booking.
understand-idea
Chat and Claude Code: Step 1 of the discover journey: clarifies the goal, who benefits, success and constraints into the idea block. Use when the journey directs it to step 1, not directly.
size-work
Chat and Claude Code: Suggest a size for a ticket from comparable finished work, as a labelled suggestion the team still owns. Use it when someone asks "how big is this?", "roughly how much work is ABC-12?", or wants a backlog item sized. It finds the team's sizing scale at first use, picks two to five of the closest finished tickets with links, and gives a size or range with the drivers behind it and a confidence of low, medium or high, lowered and explained when the area's documents are template text. Every result is labelled a suggested size, never a date or a commitment. It writes nothing into the size field unless the user says "set it", and it refuses to overwrite an existing size unless the user asks to replace it. Produces the sizing block of the record.
refine-ticket
Chat and Claude Code: Improve one or more existing tracker tickets without losing the author's intent. Use it when someone wants a ticket read, diagnosed and tidied up ("this ticket is vague", "fix up ABC-12", "split this, it's too big"). It reads each ticket in full and snapshots it with its last-updated time, says what is wrong with evidence, and proposes a field-by-field before and after change set limited to summary, description, labels, parent, links and new child tickets on a split. It writes nothing until an explicit "apply it" bound to that exact change set, re-checks the ticket for conflicting edits just before writing, never replaces rich descriptions with plain text, never deletes or closes a ticket, and reads each ticket back after applying. Produces the existing and changes blocks of the record.