Phase 4 skill for clarified Jira task plans. Use after the task plan has been clarified and the user has explicitly approved Jira writes. This skill reads only its bundled files, dispatches the `subtask-creator` subagent with `JIRA_URL`, and returns a concise phase summary after Jira subtasks are created or reconciled and `docs/<TICKET_KEY>-tasks.md` is updated with the Phase 4 output contract.
Create or reconcile Jira subtasks for a clarified task plan at
docs/<TICKET_KEY>-tasks.md. This skill coordinates Phase 4 by dispatching one
specialist subagent, keeping only its structured summary, and reporting the
outcome the parent workflow needs for progress tracking.
The orchestrator does four things directly: read its bundled files, derive
identifiers from JIRA_URL, dispatch subtask-creator, and relay the
subagent's summary. Plan parsing, Jira operations, and plan-file edits all stay
inside subtask-creator after dispatch.
| Input | Required | Example |
|---|---|---|
JIRA_URL | Yes | https://workspace.atlassian.net/browse/PROJ-123 |
Derive these values from the URL when you need to describe the ticket:
.atlassian.netPROJ-123Prefer passing the full JIRA_URL downstream rather than only TICKET_KEY.
The URL carries the workspace context needed for Jira reads and writes.
1. Read the subtask-creator definition
2. Dispatch it with JIRA_URL
3. Interpret its structured result
4. Report only the concise phase summary to the caller
Read a subagent definition only when you are about to dispatch it.
| Subagent | Path | Purpose |
|---|---|---|
subtask-creator | ./subagents/subtask-creator.md | Reconcile the clarified plan with Jira and return a structured Phase 4 summary |
This skill is intentionally narrow. The parent workflow is responsible for Phase 4 gating and progress tracking; this skill assumes the Phase 3 approval step has already happened before Jira writes begin.
Inside Phase 4, keep only the routing verdicts plus the caller-facing rollup. For Jira, that means the parent / artifact identifiers, creation totals, warnings or failures, and the linkage rollup the caller needs for progress tracking. Jira stays on the single native subtask path, so no write-model or capability metadata is expected in the summary.
Relay only the structured fields the subagent returns. Raw Jira payloads, full
API responses, raw file contents, and intermediate parse details stay inside
subtask-creator unless the user explicitly asks for them.
Primary artifact:
docs/<TICKET_KEY>-tasks.md
For the complete standalone input contract, output contract, and summary-field
definitions, read ./references/phase-4-io-contracts.md.
That bundled reference file is the only normative Phase 4 contract source for
this skill. SKILL.md covers dispatch, routing, and reporting only. The
subagent defines how to achieve the contract but does not replace it.
subtask-creatorRead ./subagents/subtask-creator.md, then dispatch it with:
JIRA_URLThe subagent owns plan parsing, Jira-capable tool discovery, parent lookup, idempotent reuse of existing subtask links, sequential creation of missing subtasks, plan-file updates, and post-write validation.
Handle the returned summary this way:
SUBTASKS: PASS with Validation: PASS: report success and proceed.SUBTASKS: WARN with Validation: PASS: report partial success or degraded
input clearly. Phase 4 may still be usable if the plan file now satisfies the
local Phase 4 output contract, but make failed tasks visible so the user can
retry before executing them.SUBTASKS: BLOCKED: stop and relay the artifact or data-shape problem. This
usually means the plan is missing, malformed, or contains unsafe existing
Jira links that need manual correction.SUBTASKS: FAIL: stop and relay the fatal Jira or validation failure.SUBTASKS: ERROR: stop and relay the unexpected failure.Validation: FAIL: treat the phase as incomplete even
if some Jira writes succeeded, because the local plan contract is not
trustworthy yet.Validation: NOT_RUN: treat the phase as incomplete;
no trustworthy local post-write artifact was produced for downstream use.Using only the subagent's structured summary, tell the caller:
SKILL.md.TICKET_KEY,
updated plan-file path, creation totals, warnings or failures, and the
reminder that no implementation has started.Dispatch subtask-creator as a subagent. If the environment cannot invoke
subagents, report the skill as blocked rather than reproducing the subagent
inline.
Read ./subagents/subtask-creator.md
Dispatch subtask-creator with JIRA_URL
Subagent returns the contract-defined summary from
./references/phase-4-io-contracts.md, for example:
SUBTASKS: PASS Validation: PASS Parent: PROJ-123 TICKET_KEY: PROJ-123 Plan file: docs/PROJ-123-tasks.md ...
Route on that summary, then relay only the caller-facing rollup. Do not add GitHub-style write-path metadata to the Jira report.
</example>Use the subagent's structured verdict as the only routing input:
| Summary state | Orchestrator action |
|---|---|
SUBTASKS: PASS with Validation: PASS | Report success and proceed |
SUBTASKS: WARN with Validation: PASS | Report usable output with warnings and make failed or skipped linkage visible |
SUBTASKS: BLOCKED | Stop and surface the plan-shape or unsafe-linkage issue |
SUBTASKS: FAIL | Stop and surface the fatal Jira or validation failure |
SUBTASKS: ERROR or Validation: FAIL | Stop and surface the unexpected failure or local contract failure |
Treat Validation: NOT_RUN as incomplete Phase 4 output even when the
top-level status is already BLOCKED, FAIL, or ERROR.