# Goblin Task Breakdown > Convert vague, complex, overwhelming, or blocked work into an executable, dependency-ordered task graph with adjustable granularity. Use for task breakdowns, brain-dump compilation, next-action planning, stuck-state recovery, or machine-readable plans for Mentiad and Vulpes Velox. - Skill: `tess600/goblin-task-breakdown` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add tess600/goblin-task-breakdown` - Raw SKILL.md: https://api.skillmd.com/api/skills/tess600/goblin-task-breakdown/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: Tess600 (https://skillmd.com/u/tess600) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tess600/goblin-task-breakdown --- # Goblin Task Breakdown Turn a stated goal or brain dump into work a person can actually begin. Preserve the user's intended outcome, constraints, confirmed decisions, completed work, and task IDs. This skill is inspired by Goblin Tools' approachable task decomposition but is independent and unaffiliated. Its distinguishing contract is: compile without overcommitting, decompose without losing intent, render without overwhelming, and execute without exceeding authorization. ## Choose a mode - `task`: decompose one stated objective. - `brain_dump`: extract candidate actions, decisions, worries, ideas, and reference information before decomposition. Infer optional controls when clear: - `granularity`: 1–5; default 3. Accept `spiciness` as an alias. - `current_energy`: low, medium, or high. - `available_time_min`: approximate usable time. - `output_format`: human, json, or task_graph. - `consumer`: human, mentiad, vulpes_velox, or external. Ask at most one question, and only when its answer would materially change the first action. Otherwise state the smallest reasonable assumption and continue. ## Preserve canonical intent Identify the outcome, observable definition of done, starting state, constraints, confirmed decisions, and completed work. Do not invent deadlines, access, people, requirements, commitments, or authorization. When revising or resuming, preserve stable node IDs, completed nodes, and unrelated branches. Granularity changes presentation depth, not the goal. ## Compile brain dumps carefully Separate content into actionable work, decisions, waiting items, ideas for later, and non-actionable context. Do not convert every sentence into a commitment. Mark inferred work as `proposed`; require confirmation before adding it to the canonical graph. ## Build executable nodes Use one node type: `action`, `decision`, `wait`, `handoff`, or `checkpoint`. An action node is executable only when it: 1. Starts with a concrete verb and acts on one identifiable object. 2. Names the tool, file, place, or person when known. 3. Has an observable completion condition. 4. Fits one focused sitting at the selected granularity. 5. Contains no hidden decision, wait, unresolved dependency, or multiple actions joined by “and.” 6. Requires no additional planning before it can begin. Avoid vague verbs such as “handle,” “work on,” “figure out,” “prepare,” and “make progress.” Add setup or cleanup only when it removes real friction or protects project state. ## Granularity and friction - 1: phases - 2: coarse actions - 3: executable actions, commonly 2–15 minutes - 4: micro-actions - 5: immediate steps for overload or panic Track friction separately from granularity, duration, and energy. A short social or irreversible task can have high friction. When friction is high, expose fewer nodes, separate choices from actions, reduce context switching, and prefer a visible first result. ## Status and dependency rules Use `proposed`, `ready`, `blocked`, `waiting`, `in_progress`, `done`, or `skipped`. A node is `ready` only when all dependencies are complete and no access or decision blocker remains. The graph must be acyclic, and `first_action_id` must reference a ready leaf node. ## Execution safety Every machine-readable node records: - `execution`: manual, agent, or either - `side_effect`: none, read, write, external, or destructive - `requires_approval`: true or false Planning does not authorize execution. An agent may execute a node only when its status, dependencies, access, side effect, approval state, and active environment all permit it. Stop before communication, payment, publication, deletion, credential use, or another consequential action unless the user has authorized it. ## Produce the output For people, progressively disclose: 1. Goal 2. Done means 3. Do now — exactly one smallest useful action 4. Next — at most three dependency-ordered actions 5. Blocked or waiting 6. Later When overwhelmed, show exactly one 2–10 minute action and state what can safely wait. For `json` or `task_graph`, read and conform to [`references/task-graph-schema.json`](references/task-graph-schema.json). Return valid JSON without commentary or Markdown fences when machine-only output is requested. ## Graph operations - `expand `: add child nodes while retaining the node as parent. - `collapse `: hide descendants without deleting them. - `smaller ` / `bigger `: change only that branch's granularity. - `complete `: mark done and release eligible dependents. - `skip `: preserve but remove from the active route. - `resume`: return the next ready leaf. - `recompile`: reassess proposed work without overwriting confirmed state. Never regenerate unrelated branches. ## Consumer behavior - Mentiad renders and preserves the canonical graph. - Vulpes Velox receives only ready, authorized executable leaves. - External adapters may flatten presentation but must preserve canonical meaning and report information loss. Before returning, verify the observable definition of done, canonical intent, stable IDs, completed work, dependency order, immediate startability, valid machine output, and authorization boundaries.