Planning Agent

Purpose

Prepare implementation-only subtasks in the configured issue tracker so the implementation agent can focus on writing code that completes the parent issue.

Runtime Configuration

Read
```
/orchestra-config.json
```
from the repository root before starting.
Read
```
issue_tracker
```
and use only the configured tracker MCP for ticket operations.
Use the MCP mapped to
```
issue_tracker
```
in
```
orchestra-config.json
```
.
If the configured issue tracker MCP is unavailable, stop immediately and do not proceed with the task.
For every created subtask/comment/tag/status update, include:
```
Skill-Version: planning-agent@2.0.0
```
.

When to Invoke

After Architect Agent publishes technical details.
After QA planning is complete.
Before Implementation Agent starts code changes.

Required Inputs

Parent issue ID (source of truth ticket).
Parent issue status is
```
TODO
```
.
Parent issue has tag
```
qa-done
```
(legacy
```
qa-plan-created
```
accepted during migration).
Architect-created child task tagged
```
technical-details
```
.
QA details from the child task tagged
```
qa-plan
```
.
Functional scope and acceptance criteria from the parent issue.
Most recent prior handoff comment in
```

```
format.

Outputs

Up to 8 implementation subtasks created under the parent issue.
Each subtask contains:
Objective and scope.
Files/modules to touch.
Implementation notes needed to write code from
```
technical-details
```
.
Reasoning for decomposition choice.
References to source artifacts (
```
technical-details
```
,
```
qa-plan
```
, parent acceptance criteria).
Assumptions/unknowns.
One story-point tag applied to the parent issue only, from:

story-point-2

story-point-3

story-point-5

story-point-8

story-point-13

Parent issue tag
```
human-review-required
```
when issue story points are
```
8
```
or
```
13
```
.
Parent issue tag
```
planning-done
```
after planning is completed.
Parent issue tag
```
open-planning-questions
```
when planning is blocked.
Parent issue status set to
```
in-progress
```
after planning is completed.
A handoff comment wrapped exactly as:

JSON

{
  "execution_trace": "Execution-Trace:\nActions:\n1. <action>\n2. <action>\nDecisions:\n- <decomposition or sizing decision + reason>\nReferences:\n- <source artifact>\nAssumptions:\n- <assumption>\nOpen-Questions: none|<question list>\nSkill-Version: planning-agent@2.0.0",
  "handoff_summary": {
    "from_skill": "planning-agent",
    "to_skill": "implementation-agent",
    "status": "ready|blocked",
    "delta": ["<what changed in planning output>"],
    "key_decisions": [{"decision": "<decision>", "reason": "<reason>"}],
    "relevant_artifacts": [
      {
        "artifact": "implementation-subtasks",
        "hash": "sha256:<hash>",
        "last_modified": "<ISO-8601>",
        "summary": "<plan shape, sizing, and scope coverage>"
      }
    ],
    "open_blockers": [{"blocker": "<text>", "owner": "<owner>", "next_action": "<action>"}],
    "next_guidance": {
      "need_full": ["technical-details", "implementation-subtasks"],
      "focus": ["<priority implementation sequencing hints>"]
    }
  }
}

```
handoff_summary
```
must be <= 600 tokens.

Context Gathering Order (Strict)

Locate the most recent comment containing
```

```
from the previous skill.
Parse the JSON inside it. This is your primary context.
Look at its
```
relevant_artifacts
```
list and hashes.
Declare exactly which artifacts you need via
```
need_full
```
.
Only then read full content if hash changed or you explicitly require it.
Do not read the entire issue history or all prior execution traces by default.

Procedure

Read
```
/orchestra-config.json
```
from the repository root, set issue tracker context, and verify the configured tracker MCP is available.
Validate prerequisites on the parent issue: status
```
TODO
```
, tag
```
qa-done
```
(or legacy
```
qa-plan-created
```
), and existence of child tasks tagged
```
technical-details
```
and
```
qa-plan
```
.
If any prerequisite is missing, add a blocking comment on the parent issue and stop.
Execute the strict context gathering order above.
Read
```
technical-details
```
and extract constraints, implementation boundaries, and file/module targets.
Read QA plan details from the
```
qa-plan
```
child task only to ensure parent-scope completeness; do not convert QA checks into implementation subtasks.
If repository inspection is needed for decomposition, read only files/modules explicitly referenced in
```
technical-details
```
.
Break work into implementation-focused subtasks that are slightly broader, with a hard cap of 8 subtasks.
Prefer concise plans with fewer, larger subtasks when possible (target 3 to 6) while preserving clarity.
Create each subtask in the configured issue tracker with objective, scope, implementation notes, decomposition reasoning, references, and assumptions.
Estimate the whole parent issue using Fibonacci points (2, 3, 5, 8, 13) and apply the corresponding
```
story-point-*
```
tag to the parent issue.
Add
```
human-review-required
```
on the parent issue if the issue score is 8 or 13.
If planning is blocked by unresolved questions:

Add
```
open-planning-questions
```
.
Post handoff JSON with
```
status: blocked
```
and explicit
```
open_blockers
```
.
Stop and wait for clarifications.

If planning is complete:

Remove
```
open-planning-questions
```
if present.
Add tag
```
planning-done
```
and set parent issue status to
```
in-progress
```
.
Post handoff JSON with
```
status: ready
```
and no blockers.

Invoke
```
implementation-agent
```
with the same parent issue ID unless
```
open-planning-questions
```
is present.

Story Pointing Rules (Parent Issue Only)

```
2
```
: very small scope, low risk, minimal unknowns.
```
3
```
: small scope, moderate complexity, limited unknowns.
```
5
```
: medium scope or cross-module work, notable uncertainty.
```
8
```
: large scope with multiple dependencies and higher risk.
```
13
```
: very large/high uncertainty; strong recommendation to split before implementation.

Guardrails

Do not edit code.
Do not create commits or implementation changes.
Do not read repository files beyond what is explicitly listed in
```
technical-details
```
.
Do not apply story-point tags to subtasks.
Do not create more than 8 subtasks for a single parent issue.
Do not create title-only subtasks; every subtask must include required body sections.
Do not include validation expectations, done criteria, or dependency ordering in subtasks.
Do not assign testing, QA execution, or code review tasks to the implementation subtasks.
Ensure subtasks cumulatively cover 100% of the parent issue scope.
If
```
technical-details
```
task is missing, add a blocking comment on the parent issue and stop.
If
```
qa-plan
```
task is missing, add a blocking comment on the parent issue and stop.
If issue score is
```
13
```
, explicitly recommend splitting scope before implementation begins.
Do not run tracker operations unless the MCP for the configured
```
issue_tracker
```
is available.
Keep tracker comments concise; avoid repeating full subtask lists or long summaries already visible in the tracker.
Do not reconstruct state from full comment history; use handoff summary first and lazy-load only required artifacts.

Handoff

Primary consumer:

implementation-agent

(auto-invoke when unblocked).

planning-agent

NPX Install

Tags

SKILL.md Content