task-planning

Name: task-planning
Author: getpaperclipai

5stars1forks

How to install task-planning?

getpaperclipai/paperclip/task-planning

$npx -y skills add getpaperclipai/paperclip --skill task-planning

Installs into the current project.

Summary

Turn a Paperclip issue or request into a structured implementation plan with child task graph, blockers, owners, and acceptance criteria, then save it as the issue plan document.

Files · 1

View on GitHub

SKILL.md

1	# Task Planning
2
3	Produce implementation plans that the Paperclip executor can actually run: explicit child issues, real blockers, named owners, and a defined acceptance bar. Avoid plans that read well but cannot be split into work.
4
5	## When to use
6
7	- An issue asks you to "plan", "scope", "break down", "design the rollout", "propose the work", or similar.
8	- A user wants a written plan before approving implementation.
9	- A manager needs to delegate non-trivial work and the shape of the work is not obvious yet.
10	- You inherited an issue too large to deliver in one heartbeat and need to split it.
11
12	## When not to use
13
14	- The issue is a single small change you can ship in the same heartbeat. Just ship it.
15	- The issue is forensic ("why did this break"). Use a diagnosis skill first; plan only after the root cause is named.
16	- A current `plan` document already exists and the change is minor. Update that document; do not start fresh.
17
18	## Outputs
19
20	1. An updated issue document with key `plan` (markdown).
21	2. A short comment on the issue that links to the plan document and names the next action.
22	3. Where the plan requires approval, an issue-thread interaction of kind `request_confirmation` bound to the latest plan revision.
23
24	Do not create implementation subtasks until the plan is accepted.
25
26	## Plan structure
27
28	Required sections, in order:
29
30	1. Goal — one paragraph. What changes for the user, the operator, or the system once this work lands.
31	2. Context reviewed — bullet list of documents, files, and prior issues you read. Lets reviewers spot missing inputs.
32	3. Constraints and non-goals — what must hold (compatibility, security, performance) and what this plan deliberately will not do.
33	4. Approach — the chosen path, with a short rationale. If you considered alternatives, name them and why you rejected them.
34	5. Work breakdown — ordered list of child issues. Each child has:
35	- Title in imperative form.
36	- Owner specialty (Engineer, QA, Designer, Security, DevRel, Manager, etc.).
37	- Scope and deliverables.
38	- Acceptance criteria.
39	- Blocks/blocked-by relationships expressed by phase letter or child title.
40	6. Acceptance — the bar for the parent issue. How the user knows the whole thing is done.
41	7. Risks and mitigations — short list. Skip if there are none.
42	8. Deferrals — what is intentionally pushed to follow-up issues, with why.
43
44	## Rules of thumb for splitting
45
46	- One child issue, one specialty. If two specialties have to coordinate inside the same issue, split it.
47	- One child issue, one acceptance verdict. If a reviewer would say "this is half done", split it.
48	- A child must be checkout-able by the owner from its title and description alone. Reviewers should not have to re-read the parent plan to understand a child.
49	- Order children by real blocker chains, not by author preference. Parallel children should explicitly say `blockers: none`.
50	- Avoid `polish` or `cleanup` child issues without acceptance criteria — they never close.
51
52	## Filing the plan
53
54	Use the Paperclip API to write the plan document, then comment:
55
56	- `PUT /api/issues/{issueId}/documents/plan` with the markdown body. If `plan` already exists, include the latest `baseRevisionId`.
57	- `POST /api/issues/{issueId}/comments` with a short summary that links the plan: `/<prefix>/issues/<issue-id>#document-plan`.
58	- If approval is required: `POST /api/issues/{issueId}/interactions` with `kind: request_confirmation`, `targetRevisionId` set to the new plan revision, `continuationPolicy: wake_assignee`, and `idempotencyKey: "confirmation:{issueId}:plan:{revisionId}"`.
59	- Set the issue to `in_review` after creating the confirmation. Stay assigned so the acceptance wakes the planner.
60
61	When the plan is accepted, see the companion skill for converting accepted plans into Paperclip executable tasks. Key requirements covered there: produce a compact task matrix (task, owner, initial status, blockers); encode every hard dependency as `blockedByIssueIds` — parent/child nesting alone does not block execution; and verify the created issue graph before closing the source planning issue.
62
63	## Anti-patterns
64
65	- Plan disguised as a description edit. Use the `plan` document.
66	- "Phases A–Z" with no work breakdown inside the phases.
67	- Children with descriptions that say "see parent" — they fail at delegation time.
68	- Acceptance written as "code review approval". Reviewers need a behavior bar, not a process bar.
69	- Plans that bury blocker chains in prose. Use explicit blocked-by lines.

People who liked this also viewed

6 picks

Type

task-planning

5stars1forks

View on GitHub

How to install task-planning?

getpaperclipai/paperclip/task-planning

$npx -y skills add getpaperclipai/paperclip --skill task-planning

Installs into the current project.

Summary

Turn a Paperclip issue or request into a structured implementation plan with child task graph, blockers, owners, and acceptance criteria, then save it as the issue plan document.

Files · 1

View on GitHub

SKILL.md

1	# Task Planning
2
3	Produce implementation plans that the Paperclip executor can actually run: explicit child issues, real blockers, named owners, and a defined acceptance bar. Avoid plans that read well but cannot be split into work.
4
5	## When to use
6
7	- An issue asks you to "plan", "scope", "break down", "design the rollout", "propose the work", or similar.
8	- A user wants a written plan before approving implementation.
9	- A manager needs to delegate non-trivial work and the shape of the work is not obvious yet.
10	- You inherited an issue too large to deliver in one heartbeat and need to split it.
11
12	## When not to use
13
14	- The issue is a single small change you can ship in the same heartbeat. Just ship it.
15	- The issue is forensic ("why did this break"). Use a diagnosis skill first; plan only after the root cause is named.
16	- A current `plan` document already exists and the change is minor. Update that document; do not start fresh.
17
18	## Outputs
19
20	1. An updated issue document with key `plan` (markdown).
21	2. A short comment on the issue that links to the plan document and names the next action.
22	3. Where the plan requires approval, an issue-thread interaction of kind `request_confirmation` bound to the latest plan revision.
23
24	Do not create implementation subtasks until the plan is accepted.
25
26	## Plan structure
27
28	Required sections, in order:
29
30	1. Goal — one paragraph. What changes for the user, the operator, or the system once this work lands.
31	2. Context reviewed — bullet list of documents, files, and prior issues you read. Lets reviewers spot missing inputs.
32	3. Constraints and non-goals — what must hold (compatibility, security, performance) and what this plan deliberately will not do.
33	4. Approach — the chosen path, with a short rationale. If you considered alternatives, name them and why you rejected them.
34	5. Work breakdown — ordered list of child issues. Each child has:
35	- Title in imperative form.
36	- Owner specialty (Engineer, QA, Designer, Security, DevRel, Manager, etc.).
37	- Scope and deliverables.
38	- Acceptance criteria.
39	- Blocks/blocked-by relationships expressed by phase letter or child title.
40	6. Acceptance — the bar for the parent issue. How the user knows the whole thing is done.
41	7. Risks and mitigations — short list. Skip if there are none.
42	8. Deferrals — what is intentionally pushed to follow-up issues, with why.
43
44	## Rules of thumb for splitting
45
46	- One child issue, one specialty. If two specialties have to coordinate inside the same issue, split it.
47	- One child issue, one acceptance verdict. If a reviewer would say "this is half done", split it.
48	- A child must be checkout-able by the owner from its title and description alone. Reviewers should not have to re-read the parent plan to understand a child.
49	- Order children by real blocker chains, not by author preference. Parallel children should explicitly say `blockers: none`.
50	- Avoid `polish` or `cleanup` child issues without acceptance criteria — they never close.
51
52	## Filing the plan
53
54	Use the Paperclip API to write the plan document, then comment:
55
56	- `PUT /api/issues/{issueId}/documents/plan` with the markdown body. If `plan` already exists, include the latest `baseRevisionId`.
57	- `POST /api/issues/{issueId}/comments` with a short summary that links the plan: `/<prefix>/issues/<issue-id>#document-plan`.
58	- If approval is required: `POST /api/issues/{issueId}/interactions` with `kind: request_confirmation`, `targetRevisionId` set to the new plan revision, `continuationPolicy: wake_assignee`, and `idempotencyKey: "confirmation:{issueId}:plan:{revisionId}"`.
59	- Set the issue to `in_review` after creating the confirmation. Stay assigned so the acceptance wakes the planner.
60
61	When the plan is accepted, see the companion skill for converting accepted plans into Paperclip executable tasks. Key requirements covered there: produce a compact task matrix (task, owner, initial status, blockers); encode every hard dependency as `blockedByIssueIds` — parent/child nesting alone does not block execution; and verify the created issue graph before closing the source planning issue.
62
63	## Anti-patterns
64
65	- Plan disguised as a description edit. Use the `plan` document.
66	- "Phases A–Z" with no work breakdown inside the phases.
67	- Children with descriptions that say "see parent" — they fail at delegation time.
68	- Acceptance written as "code review approval". Reviewers need a behavior bar, not a process bar.
69	- Plans that bury blocker chains in prose. Use explicit blocked-by lines.

People who liked this also viewed

6 picks

Type