compact
compact
Keep tasks/context.md short and scannable by consolidating older entries into readable summaries.
Guardrails
- Do not change product scope or implementation code.
- Do not move or rename PRDs here; completed PRDs are archived during
commitfinalise. - Do not create separate context archive files.
- Ask for explicit confirmation before applying consolidation edits.
- Always propose retention/consolidation counts first; let the user choose the final numbers.
- When asking for user decisions, provide numbered short-reply options (e.g.
1,2,3).
Workflow
- Preflight:
- Ensure
tasks/exists. - Inspect
tasks/context.md. - Count entries to compact in
tasks/context.md:Key decisions,Completed,Notes / gotchas.
- Ensure
- Propose consolidation options and ask for a decision:
- Suggest how many entries to keep in full detail vs consolidate into summary.
- Provide recommended defaults, then allow user override (more or fewer).
- Compact
tasks/context.mdin place:- Preserve
ProjectandCurrent statesections. - Keep the user-selected number of most recent detailed entries (entries are newest-first, so keep from the top).
- Before consolidating, extract still-relevant risks, open questions, or gotchas from older entries (bottom of each section).
- Move them into
Notes / gotchasorCurrent state: Blockersso they are not lost. - Replace older entries with a concise historical summary block appended at the bottom of each section.
- Preserve
- Report results:
- Show retained vs consolidated counts.
- Call out any sections intentionally left untouched.
Suggested Defaults
Use these as initial recommendations, then ask the user to confirm or adjust:
tasks/context.md:- Keep the latest 10 entries in detail across historical sections.
- Consolidate older entries into summary.
References
references/compact-templates.md: threshold-choice prompt and historical-summary examples.
Output
- Update only
tasks/context.md. - Return:
- proposed numbers and user-selected numbers
- retained vs consolidated counts
- concise summary of what changed
- End with a short status block:
- Files changed: list of created/updated files
- Key decisions: any assumptions or choices made (if any)
- Next step: recommended next skill or action
More from kelvinz/cobb
commit
Create atomic user-approved commits with `feat`/`fix`/`chore` titles. Include inline PRD checklist and context updates per atomic commit. Finalise branch merge/cleanup when requested. Triggers: commit changes, split commits, finalise branch, commit message.
27review
Review the current branch changes for correctness, security, tests, and scope, then return a clear go/no-go decision. Triggers: review, readiness check, pre-commit review, pre-finalise review.
26implement
Implement an existing PRD (`Type: feat`/`fix`/`chore`), update tests/checks, and mark completed PRD checklist items. Triggers: implement prd, build feature from prd, execute prd checklist.
26design
Router-first workflow for high-craft design execution across four modes: ui, ux, motion, and imagery. Use when designing or refining interfaces, structuring and auditing UX/usability/accessibility, implementing or specifying interaction motion, or producing static visual artifacts (.png/.pdf) with a matching philosophy note. Triggers: design ui, improve ux flow, run design audit, add transitions, reduce motion issues, create visual imagery, craft poster composition.
20memory
Maintain durable project memory in `tasks/memory.md` (state, decisions, milestones, gotchas), inline during other workflows or standalone for cleanup/backfill. Triggers: update memory.md, decision log, record project context.
17prd
Create, update, or list PRDs for features, fixes, and chores. Handles project setup (first PRD) and ongoing PRD management. Each PRD is a self-contained spec with status, priority, and acceptance criteria. Triggers: prd, new feature, write prd, plan feature, create spec, list prds, update prd, add feature.
15