task-planning

Name: task-planning
Author: UnpaidAttention

84stars18forks

How to install task-planning?

unpaidattention/fable5-methodology/task-planning

$npx -y skills add UnpaidAttention/fable5-methodology --skill task-planning

Installs into the current project.

Summary

Parse a request and produce an ordered execution plan before any code is written. Trigger this at the START of any new task — when the user asks to build, implement, add, create, migrate, or refactor something; when a request spans multiple files or steps; when a request contains

Files · 1

View on GitHub

SKILL.md

1	# Task Planning
2
3	Turn a request into a verified understanding and an ordered, checkable plan — before touching
4	code.
5
6	## Step 1: Parse the request
7
8	Answer these four questions in writing (a todo note or a short message):
9
10	1. Deliverable: what artifact exists when you're done — a file, a passing test, a diff, a
11	prose answer? One sentence. If you can't write the sentence, the request is ambiguous —
12	go to Step 3.
13	2. Explicit constraints: scan for named technologies, paths, formats, prohibitions ("no new
14	dependencies"), and process instructions ("one file at a time", "ask before committing").
15	List them. Process instructions are requirements with the same weight as functional ones.
16	3. Implicit requirements by deliverable type:
17	- New endpoint → input validation, auth, error responses, ≥1 test.
18	- Bug fix → regression test that fails before the fix, passes after.
19	- Script → handles missing/malformed input, exits non-zero on failure.
20	- Refactor → behavior preserved, existing tests pass, no public API change unless stated.
21	4. Verification condition: what command or observation proves it works? Define it now —
22	it shapes the implementation. No plan is complete without it.
23
24	## Step 2: Detect hidden scope
25
26	- "Just / simply / quick" = the user's effort prediction, not permission to cut corners.
27	- Symptom described, not a change ("login is broken") → the deliverable is a diagnosis;
28	report findings, don't jump to the first plausible fix.
29	- Solution named, not a problem ("add a retry here") → implement it, but if inspection shows
30	it won't fix the underlying issue, say so in one line while delivering.
31	- Plurals and "etc." → enumerate the concrete list you believe is in scope and state it.
32
33	## Step 3: Ask vs. proceed
34
35	Ask (max 2–3 batched questions, each with your recommended default) only when ALL hold:
36	- The ambiguity changes WHAT you'd build, not just how; AND
37	- The wrong choice is expensive to reverse (schema, public API, deletion, external side
38	effects, >~30 min of work in one direction); AND
39	- The codebase/conversation cannot answer it. Never ask what a grep can answer.
40
41	Otherwise proceed and state the assumption in one line at delivery:
42	> "Assumed per-day grouping, not per-run — flip `GROUP_BY` if wrong."
43
44	## Step 4: Decide whether to plan formally
45
46	Dive in (no written plan) when ALL: 1–2 localized edits, whole change fits in your head,
47	verification is one command, revert is cheap.
48
49	Write a plan when ANY: 3+ files or a module boundary crossed; a schema/public-interface
50	decision embedded; migration-shaped repetition; user-specified ordering; or you're unsure what
51	step two is.
52
53	## Step 5: Build the plan
54
55	1. Steps in dependency order: types/schema → pure logic → I/O adapters → interfaces → glue.
56	2. Each step ends with its own check (compile / import / unit test / run).
57	3. Do the riskiest step first — the unfamiliar API, the unverified assumption. If it fails,
58	the plan changes while it's cheap.
59	4. A step describable only with "and" gets split.
60	5. 4+ steps → write the plan down (todo list or file). Head-only plans mutate silently.
61
62	## Step 6: Scope each candidate piece — build / defer / refuse
63
64	1. Stated or implicit requirement → build.
65	2. Needed for the stated thing to actually work (error path, the edge case the data will
66	certainly contain) → build.
67	3. Plausible future need ("might want multiple providers") → defer, with a one-line note:
68	"skipped X; add when Y".
69	4. Contradicts the request (framework where a script was asked) → refuse, one line, with
70	reason.
71
72	## Worked example
73
74	Request: "Write a script that syncs new rows from table A to table B nightly."
75
76	- Parse: deliverable = runnable script; verification = run twice against a seeded test DB, row
77	counts correct and no duplicates.
78	- Implicit: idempotency (cron re-runs), non-zero exit on failure, log counts.
79	- Build: sync + idempotency + exit codes + count logging.
80	- Defer: config file for table names (constants + note), parallelism, metrics.
81	- Refuse: generic pluggable-ETL framework — "60-line script; a framework isn't warranted until
82	a third table pair exists."
83	- Plan order: (1) query for new rows + test on seeded DB, (2) idempotent insert + re-run test,
84	(3) logging/exit codes, (4) end

People who liked this also viewed

6 picks

Type

task-planning

84stars18forks

View on GitHub

How to install task-planning?

unpaidattention/fable5-methodology/task-planning

$npx -y skills add UnpaidAttention/fable5-methodology --skill task-planning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Task Planning
2
3	Turn a request into a verified understanding and an ordered, checkable plan — before touching
4	code.
5
6	## Step 1: Parse the request
7
8	Answer these four questions in writing (a todo note or a short message):
9
10	1. Deliverable: what artifact exists when you're done — a file, a passing test, a diff, a
11	prose answer? One sentence. If you can't write the sentence, the request is ambiguous —
12	go to Step 3.
13	2. Explicit constraints: scan for named technologies, paths, formats, prohibitions ("no new
14	dependencies"), and process instructions ("one file at a time", "ask before committing").
15	List them. Process instructions are requirements with the same weight as functional ones.
16	3. Implicit requirements by deliverable type:
17	- New endpoint → input validation, auth, error responses, ≥1 test.
18	- Bug fix → regression test that fails before the fix, passes after.
19	- Script → handles missing/malformed input, exits non-zero on failure.
20	- Refactor → behavior preserved, existing tests pass, no public API change unless stated.
21	4. Verification condition: what command or observation proves it works? Define it now —
22	it shapes the implementation. No plan is complete without it.
23
24	## Step 2: Detect hidden scope
25
26	- "Just / simply / quick" = the user's effort prediction, not permission to cut corners.
27	- Symptom described, not a change ("login is broken") → the deliverable is a diagnosis;
28	report findings, don't jump to the first plausible fix.
29	- Solution named, not a problem ("add a retry here") → implement it, but if inspection shows
30	it won't fix the underlying issue, say so in one line while delivering.
31	- Plurals and "etc." → enumerate the concrete list you believe is in scope and state it.
32
33	## Step 3: Ask vs. proceed
34
35	Ask (max 2–3 batched questions, each with your recommended default) only when ALL hold:
36	- The ambiguity changes WHAT you'd build, not just how; AND
37	- The wrong choice is expensive to reverse (schema, public API, deletion, external side
38	effects, >~30 min of work in one direction); AND
39	- The codebase/conversation cannot answer it. Never ask what a grep can answer.
40
41	Otherwise proceed and state the assumption in one line at delivery:
42	> "Assumed per-day grouping, not per-run — flip `GROUP_BY` if wrong."
43
44	## Step 4: Decide whether to plan formally
45
46	Dive in (no written plan) when ALL: 1–2 localized edits, whole change fits in your head,
47	verification is one command, revert is cheap.
48
49	Write a plan when ANY: 3+ files or a module boundary crossed; a schema/public-interface
50	decision embedded; migration-shaped repetition; user-specified ordering; or you're unsure what
51	step two is.
52
53	## Step 5: Build the plan
54
55	1. Steps in dependency order: types/schema → pure logic → I/O adapters → interfaces → glue.
56	2. Each step ends with its own check (compile / import / unit test / run).
57	3. Do the riskiest step first — the unfamiliar API, the unverified assumption. If it fails,
58	the plan changes while it's cheap.
59	4. A step describable only with "and" gets split.
60	5. 4+ steps → write the plan down (todo list or file). Head-only plans mutate silently.
61
62	## Step 6: Scope each candidate piece — build / defer / refuse
63
64	1. Stated or implicit requirement → build.
65	2. Needed for the stated thing to actually work (error path, the edge case the data will
66	certainly contain) → build.
67	3. Plausible future need ("might want multiple providers") → defer, with a one-line note:
68	"skipped X; add when Y".
69	4. Contradicts the request (framework where a script was asked) → refuse, one line, with
70	reason.
71
72	## Worked example
73
74	Request: "Write a script that syncs new rows from table A to table B nightly."
75
76	- Parse: deliverable = runnable script; verification = run twice against a seeded test DB, row
77	counts correct and no duplicates.
78	- Implicit: idempotency (cron re-runs), non-zero exit on failure, log counts.
79	- Build: sync + idempotency + exit codes + count logging.
80	- Defer: config file for table names (constants + note), parallelism, metrics.
81	- Refuse: generic pluggable-ETL framework — "60-line script; a framework isn't warranted until
82	a third table pair exists."
83	- Plan order: (1) query for new rows + test on seeded DB, (2) idempotent insert + re-run test,
84	(3) logging/exit codes, (4) end

People who liked this also viewed

6 picks

Type