Fusion Issue Task Planning

User Story Task Planning

Experimental caveat

This skill is experimental and not yet stable. Behavior, structure, and outputs may change between versions.

When to use

Use this skill when you need an actionable task plan for a User Story issue before implementation.

Typical triggers:

• "plan tasks for #123"
• "break this story into steps"
• "create task issue drafts from this user story"

When not to use

Do not use this skill for direct code implementation, PR review, or GitHub mutations without explicit confirmation.

Required inputs

• Target issue reference (owner/repo#number or URL)
• Desired planning depth (minimal, standard, detailed)
• Run mode (draft-only, draft+publish-ready, or publish-now)

If missing inputs block planning, ask up to 3 focused follow-up questions from assets/follow-up-questions.md.

Defaults

• Planning depth: standard
• Run mode: draft-only
• Publish behavior: explicit same-turn confirmation required before any mutation

Tool format

• Tool names follow <mcp_server>::<tool> (example: mcp_github::sub_issue_write).

Instructions

Execute in order and state assumptions explicitly.

1. Probe preferred skills and classify drafting mode

• orchestrated: both fusion-issue-authoring and fusion-issue-author-task available; full workflow with explicit publish gates handled by the orchestrator.
• direct-subordinate: only fusion-issue-author-task available; operate in draft-only mode using its templates and safeguards, do not perform any GitHub mutations, and surface drafts plus clear instructions for how an orchestrator or user should publish them.
• inline: neither available; stay in draft-only mode, generate task drafts with a minimal built-in structure (Title, Problem, Scope, Acceptance criteria mapping, Verification, Dependencies), and avoid direct references to another skill's assets/ files.
• Prefer fusion-issue-author-task whenever it is available; do not bypass it with direct cross-skill file references.
• Never stop due to missing preferred skills; degrade gracefully.

2. Research the user story

• Gather title, body, acceptance criteria, scenarios, ancestor chain, existing sub-issues, and related links.
• If issue type is ambiguous, confirm whether to proceed as User Story.

3. Clarify only when needed

• Ask at most 3 questions per batch.
• Continue with explicit assumptions when safe defaults exist.

4. Extract planning anchors

• Outcomes
• Constraints and non-goals
• Verification points

5. Build dependency-ordered tasks

• For each task include objective, scope boundary, deliverable, verification method, and mapped AC references.
• Prefer independently verifiable slices.

6. Run devil's-advocate review before drafting

• Inspect the proposed task set for architecture-ambiguity signals:
• Unresolved design or architecture decisions mentioned in the story, comments, or ancestor issues
• Backend and frontend tasks that share an implicit API, data model, or ownership contract not yet agreed
• A discovery, research, or alignment task alongside concrete implementation tasks with no explicit blocking relationship
• Dependency statements that are vague or circular ("after backend is done", "when design is ready")
• Component, API, or data-model ownership that is unclear or contested
• If two or more signals are present:
• orchestrated mode: route through fusion-issue-authoring → agents/devils-advocate.agent.md in interrogator mode automatically — no user trigger required.
• direct-subordinate or inline mode: run an inline DA checklist using the same five signals above; surface findings as a structured ⚠ Ambiguity checklist and require the user to resolve or explicitly accept each before draft generation.
• If zero or one signal is present, run in moderate mode: surface up to 3 concerns and continue after the user acknowledges.
• Publish gate (all modes): do not publish tasks until either the devil's advocate confirms the split is sound or the user explicitly accepts the listed risks.
• Draft-only exception: in draft-only mode, draft generation may proceed even with unresolved ambiguities, but emit an ⚠ Ambiguity warning block at the top of the plan preview listing each unresolved item. Publication remains blocked until risks are accepted.

7. Generate task issue drafts

• orchestrated: route through fusion-issue-authoring with issue type Task
• direct-subordinate: invoke fusion-issue-author-task in draft-only mode and output explicit publish instructions that delegate final mutation to fusion-issue-authoring
• inline: write .tmp/TASK-<nn>-<slug>.md drafts using the minimal built-in structure from step 1
• Keep drafts local until explicit publish approval.

8. Generate plan preview

• Write .tmp/USER-STORY-TASK-PLAN-<context>.md from assets/task-plan-template.md.
• Include summary, traceability, ordered tasks, draft paths, publish plan, assumptions, risks.

9. Publish only after explicit confirmation

• Require explicit confirmation in the same turn.
• Stop if unresolved assumptions remain.
• Delegate publish execution to fusion-issue-authoring and prefer sub-agent invocation for task issue creation/update/linking.
• Pass required context to fusion-issue-authoring: owner, repo, parent story reference, ordered task drafts, labels/assignee intent, and dependency ordering.
• Require fusion-issue-authoring to keep MCP-first behavior and apply GraphQL fallback only when MCP write coverage is unavailable.
• The orchestrator's session-cache rules apply to all delegated calls: labels, assignee candidates, and issue types are fetched once per session and reused across all task issues in the batch.
• Budget awareness: a task-planning publish of N tasks costs ~N issue-write mutations + optional sub-issue link mutations. If N > 5, warn the user about rate-limit risk and offer to publish in batches.
• Do not call MCP write tools directly from this skill in publish mode.
• Hard fail publish mode if delegated execution returns unresolved item-level failures.

10. Repair mode for already-created tasks

• If tasks were created but are missing Issue Type or parent linkage, delegate repair to fusion-issue-authoring and prefer sub-agent invocation.
• Provide per-issue repair intent (set type=Task, add missing parent links, preserve order) and require verification results from the delegated run.
• Repair mode must be idempotent: skip already-correct issues and fix only missing metadata.
• Run post-flight verification after repairs and return actionable failures.

Common failures and resolution

• fusion-issue-authoring is unavailable in the runtime
• Stay in draft-only mode and return publish-ready artifacts plus explicit handoff instructions.
• Delegated publish returns partial failures
• Return per-issue failed status with exact reason and stop further mutations until user confirmation.
• Task issues are created but not linked to the parent story
• Trigger delegated repair through fusion-issue-authoring and require post-flight verification output.
• Task exists but Issue Type is missing or incorrect
• Trigger delegated repair through fusion-issue-authoring with type=Task intent and verify results.
• Post-flight verification reports partial failures
• Return per-issue failed status with exact reason, stop publish flow, and keep unresolved items for explicit user decision.

Expected output

Return in this heading order: 1. Experimental caveat 2. Story summary 3. Acceptance-criteria traceability 4. Ordered tasks 5. Draft file paths 6. Publish plan 7. Assumptions, risks, and open questions

Always include: Status: Awaiting user approval until publish is confirmed and completed.

For publish-now or repair mode, include a per-issue post-flight report with:

• issue exists
• issue type equals requested type
• parent equals expected story number
• status (ok, fixed, or failed)

Assets

• assets/follow-up-questions.md
• assets/task-plan-template.md

Safety & constraints

• This skill is mutation-capable. Repository-local workflow instructions take precedence over inline guidance when they conflict.
• Never mutate GitHub state without explicit confirmation.
• Never infer acceptance criteria without flagging assumptions.
• Always preserve AC traceability in the task plan.
• Keep drafts in .tmp/ before any publish action.
• In publish/repair mode, treat missing Issue Type or missing parent linkage as a failure until post-flight checks pass.
• Delegate mutation/repair execution to fusion-issue-authoring (prefer sub-agent) and do not call MCP write tools directly from this skill.

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}

Assumptions

• Assumption: {explicit assumption}

Blockers (if any)

• Blocker: {what is blocked}
• Why: {reason}
• Next action: {required user input or system step}

Risks and open questions

• Risk: {risk}
• Question: {question}

Status

Status: Awaiting user approval

Changelog

0.1.6 - 2026-05-04

patch

• #156 `3ed5296` - Add explicit devil's-advocate review step before task draft generation

Inserts a new step 6 that inspects the proposed task set for architecture-ambiguity signals before any drafts are generated. When two or more signals are present (unresolved design decisions, implicit backend/frontend contracts, vague sequencing, contested ownership), the workflow automatically routes to interrogator mode without requiring a user trigger. In draft-only mode with unresolved ambiguities, an ⚠ Ambiguity warning block is emitted at the top of the plan preview.

resolves equinor/fusion-skills#132

0.1.5 - 2026-03-24

patch

• #126 `1470bc8` - Add repository-policy handoff section for governance alignment

• Add explicit "Repository-policy handoff" section that defers issue type, changeset, and PR rules to repo-local instructions

Resolves equinor/fusion-core-tasks#581

0.1.4 - 2026-03-17

patch

• #85 `c8ba3df` - Make all GitHub-API-consuming skills more conservative with token usage.

• fusion-issue-authoring: concrete session-cache flow for labels and assignee candidates; per-session budget table
• fusion-issue-solving: expanded low-token strategy with session-cache references and budget awareness
• fusion-github-review-resolution: token budget guidance for thread-heavy reviews; cache PR metadata once
• fusion-issue-task-planning: session-cache delegation rules and batch-size warning for large task plans
• fusion-dependency-review: explicit data-reuse rules across parallel advisor fan-out
• fusion-discover-skills: tighter GraphQL budget and call-count cap for discovery sessions

resolves equinor/fusion-core-tasks#797

0.1.3 - 2026-03-05

patch

• #55 `2d346c8` - Add required ownership metadata (metadata.owner, metadata.status) to all skills. Owner is set to @equinor/fusion-core (repository default) and status is set according to skill lifecycle (active for production skills, experimental for early-stage skills). Sponsor metadata was considered but is not required for MVP.

resolves equinor/fusion-core-tasks#474

0.1.2 - 2026-03-03

patch

• #42 `947c0ab` - Shift publish/repair execution in fusion-issue-task-planning to delegated handling through fusion-issue-authoring (prefer sub-agent invocation), while keeping this skill focused on planning and draft generation.

Clarifies that MCP-first mutation and GraphQL fallback behavior are enforced by the delegated authoring workflow.

Removes local fusion-issue-task-planning/assets/graphql/ fallback files and points fallback usage to fusion-issue-authoring/assets/graphql/.

refs equinor/fusion-skills#40 resolves equinor/fusion-core-tasks#446

0.1.1 - 2026-03-03

patch

• #40 `cd68535` - Refine the experimental fusion-issue-task-planning workflow to be MCP-first for issue publishing and repair, clarify parent-linking as a separate sub-issue operation, and add reusable GraphQL fallback query/mutation files under skills/.experimental/fusion-issue-task-planning/assets/graphql/.

resolves equinor/fusion-skills#39

0.1.0 - 2026-03-02

minor

• #37 `54d03bc` - Add experimental fusion-issue-task-planning skill with user-story task planning workflow, explicit publish gates, provenance metadata, and reusable planning assets.

References equinor/fusion-core-tasks#430.