skills/task-brain-lite/SKILL.md
Use this skill when the user says "/task_brain", "break down this task", "plan this", "decompose this problem", or when a task has multiple moving parts, unclear dependencies, or high ambiguity.
npx skillsauth add kyuna0312/kyuna_token_saver Task Brain LiteInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Decompose → Prioritize → Execute → Remember → Reuse.
Before anything else, assess the task:
.remember/logs/task_brain.jsonl
n within ±2 of current subtask counttsol appears in the current task description[memory: HIT — N/3 signals] if N ≥ 2, else [memory: miss]Show user: [complexity: H] [deps: A→B, C→B] [memory: hit/miss]
If complexity is Medium or High, initialize the task state table after the next phase.
Break into semantic subtasks:
verb_noun (e.g., parse_schema, write_tests, deploy_service)Show decomposition tree, then emit the initial task state table:
| task | state |
|-------------------|---------------------------|
| parse_schema | ready |
| write_models | blocked(parse_schema) |
| implement_auth | blocked(write_models) |
| write_tests | blocked(implement_auth) |
This table is the live state. Reprint it (compactly) after every EXECUTE cycle.
For Medium complexity, produce a flat ordered list — no tree, no depth:
subtask_one — reason it comes first (e.g., "needed by all others")subtask_two — reasonsubtask_three — reasonRules:
Use [SEQUENCE] header here, not [SPLIT].
Score each task:
Ready tasks: score = 1.0 + (1 / complexity_weight)
complexity_weight: L=1, M=2, H=3
Blocked tasks: score = 0.5 if unmet_deps_count == 1
score = 0.0 if unmet_deps_count > 1
Done tasks: score = -1 (excluded from selection)
Pick the highest-scoring ready task. Ties: prefer lower complexity (easy wins first).
If no ready tasks remain, surface the blocked task with score 0.5:
Next: [task] (score: 0.50) | Waiting on: [blocker]Show: Next: [task_name] (score: X.XX)
Before executing, check for memory hit:
[memory] Adapting: {s} ({e}) → {sol}Execute one task only. Output only what's needed.
Done criteria — before moving on, state the verifiable artifact:
Done: [one-line artifact description]done, unlock its dependents to readyAfter execution, confirm with user before next task — unless they said "auto" or "run all".
After each completed task, append to .remember/logs/task_brain.jsonl:
{"s": "task_name", "e": "2026-04-20", "sol": "one-line summary of approach", "t": ["tag1", "tag2"], "cx": "M", "n": 3}
Fields:
s: task slug/namee: date completedsol: solution summary (what worked, key insight)t: tags for future retrieval (language, domain, pattern type)cx: complexity class (L/M/H) — used in Signal 1 of memory matchn: total subtask count in this session — used in Signal 1 of memory matchShow: [LOG] ✓ saved
REUSE executes during Phase 4. This section defines the matching algorithm for reference:
Match score = number of signals fired:
cx AND |current_n − stored_n| ≤ 2tsol appears in current task descriptionShow memory hit if score ≥ 2. Never reuse blindly — if context has shifted, note the delta.
Print phase headers only when the phase runs:
| Complexity | Phases shown |
|------------|-------------|
| Low | [ANALYZE], [EXECUTE], [LOG] |
| Medium | [ANALYZE], [SEQUENCE], [PRIORITY], [EXECUTE], [LOG] |
| High | [ANALYZE], [SPLIT], [PRIORITY], [EXECUTE], [LOG] |
[REUSE] as a header — reuse output appears inline within [EXECUTE]tools
This skill should be used when the user asks to "show recent changes", "show forge changelog", "show changelog for <project>", "what did I add this week", "what files did I touch today", "what packages keep recurring", "what drifts from the template", "review template suggestions", "show pending forge suggestions", "sync forge templates", "apply template suggestion", or "compute back-mapping suggestions". Provides read, drift-discovery, and template back-mapping workflows that wrap the `forge-db` MCP tools (`get_changelog`, `compute_suggestions`, `apply_suggestion`).
development
This skill should be used when the user says "build a wiki", "maintain a wiki", "ingest docs into wiki", "query my wiki", "set up llm wiki", "wiki-based knowledge base", "stop re-reading docs every session", "persistent knowledge base", or "compress my docs into wiki pages".
tools
This skill should be used when the user says "optimize settings.json", "tune settings for low tokens", "settings.json for performance", "disable auto memory", "configure for token savings", "minimal context window settings", or "settings taking too many tokens".
tools
This skill should be used when the user asks to "add token counter to status line", "show context usage in status bar", "visualize token usage", "set up token status line", "live token counter", "show context window percentage", or wants to see token burn in the terminal status bar.