Fusion Issue Task Planning
Turn a Fusion issue into a structured task plan with configurable depth, defaulting to draft-only until you explicitly confirm publish.
Overview
Fusion Issue Task Planning is an agent skill most often used in Build (also Ship launch prep) that drafts Fusion issue task plans with bounded Q&A and defers publish mutations to fusion-issue-authoring.
Install
npx skills add https://github.com/equinor/fusion-skills --skill fusion-issue-task-planningWhat is this skill?
- Asks at most three blocking questions per batch with blocker-first ordering
- Supports planning depth minimal, standard, or detailed with default standard
- Default run mode draft-only; publish requires explicit same-turn confirmation
- Delegates issue mutation and repair to fusion-issue-authoring (prefer sub-agent)
- Documents GraphQL fallback asset location under fusion-issue-authoring for parent/sub-issue ops
- At most 3 follow-up questions per batch
- 4 blocking question templates in the readme
Adoption & trust: 880 installs on skills.sh; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a Fusion issue but no ordered task list mapped to acceptance criteria, and you cannot risk unprompted issue updates.
Who is it for?
Teams using Fusion issue links who want agent-generated task maps with draft-first safety and sub-agent authoring for writes.
Skip if: GitHub-only trackers with no Fusion context, or builders who want the agent to edit issues without a separate authoring skill.
When should I use this skill?
You have or can obtain a Fusion issue reference and need a task plan at minimal, standard, or detailed depth before any publish mutation.
What do I get? / Deliverables
You get a depth-appropriate draft plan with flagged assumptions; after explicit confirmation, fusion-issue-authoring can apply publishes and GraphQL fallbacks.
- Draft task plan mapped to acceptance criteria and related links
- Documented assumptions when criteria are incomplete
- Explicit publish-ready package only after same-turn user confirmation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build/pm is the canonical shelf because the skill maps acceptance criteria to tasks on a tracked issue before implementation proceeds. PM subphase matches issue-backed planning, depth tiers (minimal, standard, detailed), and handoff to authoring rather than coding features directly.
Where it fits
Convert a vague feature issue into standard-depth tasks while preserving stated non-goals from the description.
Stay draft-only when acceptance criteria are incomplete and flag assumptions for human review on the same turn.
Produce a detailed task plan for a release issue without publishing until launch stakeholders confirm.
How it compares
Issue-planning workflow with hard publish gate—not a generic markdown TODO generator.
Common Questions / FAQ
Who is fusion-issue-task-planning for?
Maintainers planning Fusion-backed user stories or bugs who want structured tasks before any issue field is mutated.
When should I use fusion-issue-task-planning?
In Build/pm when breaking down owner/repo#issue work, or in Ship/launch when turning launch checklist issues into detailed tasks before execution.
Is fusion-issue-task-planning safe to install?
Planning defaults to draft-only, but paired authoring can mutate issues after you confirm—review the Security Audits panel on this page and keep publish confirmation explicit.
Workflow Chain
Then invoke: fusion issue authoring
SKILL.md
READMESKILL.md - Fusion Issue Task Planning
# Follow-up questions Use these only when required inputs are missing. Ask at most 3 questions per batch and prioritize blockers first. ## Blocking questions 1. Which issue should I plan for (`owner/repo#number` or URL)? 2. Should I proceed as a `User Story` if the issue type is missing or ambiguous? 3. What planning depth should I use: `minimal`, `standard`, or `detailed`? 4. Should I keep this `draft-only`, or prepare for publish after your explicit confirmation? ## Context enrichment questions 5. Which constraints or non-goals must be preserved when mapping tasks to acceptance criteria? 6. Are there specific ancestor issues or related links that must be included? ## Defaults - Planning depth: `standard` - Run mode: `draft-only` - Publish behavior: explicit same-turn confirmation required before mutation ## Questioning rules - Ask at most 3 questions per batch. - Do not ask questions that can be answered from issue data. - If blocked by missing issue reference, ask only question 1 first. - If acceptance criteria are incomplete, continue with explicit assumptions and flag for review. # Task planning assets `fusion-issue-task-planning` focuses on planning and draft generation. Issue mutation and repair execution is delegated to `fusion-issue-authoring` (prefer sub-agent invocation). GraphQL fallback assets are maintained in: - `skills/fusion-issue-authoring/assets/graphql/` Use that location for parent/sub-issue and issue-type fallback operations when MCP write tools are unavailable. # Task Plan Draft — User Story ## Experimental caveat EXPERIMENTAL: This workflow is not yet stable and may change. ## Skill availability - Drafting mode: {orchestrated | direct-subordinate | inline} - `fusion-issue-authoring`: {available | not installed} - `fusion-issue-author-task`: {available | not installed} ## Run mode - Mode: {draft-only | draft+publish-ready | publish-now} - Planning depth: {minimal | standard | detailed} ## Issue context - Issue: {owner/repo#number} - Title: {title} - Story: {as a / i want / so that} ## Ancestors and relevant links - Parent/ancestor chain: - {owner/repo#x} - {owner/repo#y} - Relevant links: - {issue/pr/doc url} - {issue/pr/doc url} ## Acceptance criteria anchors - {criterion 1} - {criterion 2} - {criterion 3} ## Acceptance-criteria traceability - AC-1 -> Task {n}, Task {m} - AC-2 -> Task {n} - AC-3 -> Task {n}, Task {m} ## Ordered implementation tasks - [ ] Task 1 — {objective} - Sequence: {01} - Acceptance criteria: {ac refs} - Scope boundary: {in/out} - Deliverable: {artifact} - Verification: {test/check} - [ ] Task 2 — {objective} - Sequence: {02} - Acceptance criteria: {ac refs} - Scope boundary: {in/out} - Deliverable: {artifact} - Verification: {test/check} ## Dependency notes - Task {n} depends on Task {m} because {reason} ## Generated task issue drafts - Draft: `.tmp/TASK-{2-digit-sequence}-{slug}.md` - Proposed title: {title} - Sequence: {n} - Depends on: {task refs} ## Publish plan (requires explicit confirmation) - Publish path: {orchestrated via fusion-issue-authoring (preferred sub-agent) | subordinate-draft via fusion-issue-author-task then publish via fusion-issue-authoring | draft-only handoff} - Delegated publisher: `fusion-issue-authoring` - Delegated inputs: - `owner`, `repo`, `parent story`, `ordered task drafts`, `labels/assignee intent`, `dependency ordering` - Delegated behavior contract: - MCP-first issue mutation and verification through `fusion-issue-authoring` - GraphQL fallback only when MCP write coverage is unavailable - Return per-issue post-flight verification (`exists`, `type`, `parent`, `status`) - This skill does not call MCP write tools directly for publish/repair. - Apply sub-issue ordering from planned sequence - Optional: parent summary comment with created issue links ## Post-flight report - `{owner}/{repo}#{n}` | exists: {yes/no} | type: {actual} | parent: {actual} | status: {ok/fixed/failed} #