Aile: Writing Plans (aile-writing-plans)

Overview

This is the team's proprietary plan generation skill, used to convert Phase 1 inputs (PM requirements + UI mockups) into standardized Phase 2 deliverables:

Main plan entry:
```
docs/plans/{Story-Key}/plan.md
```
Optional design file:
```
docs/plans/{Story-Key}/design.pen
```

Write a comprehensive implementation plan assuming the engineer has zero background in our codebase and poor taste. Document everything they need to know: which files, code, tests each task touches, any documentation they may need to check, and how to test it. Break the entire plan into small tasks for them. DRY. YAGNI. Time-boxed. Frequent commits.

Assume they are a skilled developer but know almost nothing about our toolset or problem domain. Assume they have little understanding of good test design.

When to Use

Use in the following scenarios:

You have obtained the requirement description of the Jira Story and (at minimum) UI mockups/interaction specifications
You need to generate executable implementation plans with task granularity of 2-5 minutes
You need to refine Acceptance Criteria (AC) from a business perspective to a technically testable one and write them back to the Story (e.g., when Jira MCP is enabled)

Core Output Contract (Must Comply)

The plan file must be located at:
```
docs/plans/{Story-Key}/plan.md
```
The file must include:
- Status management (overall progress, task status overview, execution records)
- Requirement understanding and risks
- UI design (if there are UI changes,
```
design.pen
```
  must be included, or explicitly state "No UI design for this Story")
- Task breakdown (each task takes 2-5 minutes)
- Test cases and acceptance criteria (testable, unambiguous)
- AI execution guidelines (clear execution sequence, constraints, manual gate nodes)
Each task must be described in TDD manner: RED → Verification failed → GREEN → Verification passed → REFACTOR → Re-verify
When Jira MCP is enabled: After task breakdown, a Jira Sub-task must be created for each implementation task and written back to the Jira-related section in
```
plan.md
```
Status management must be traceable: Each task must have
```
Status
```
,
```
Assignee
```
,
```
Start Time
```
,
```
Completion Time
```
,
```
Block Reason
```
, with the initial status uniformly set to
```
To Do
```

Bite-sized Task Granularity

Each step is an action (2-5 minutes):

Step: "Write a failing test"
Step: "Run it to ensure it fails"
Step: "Implement the minimal code to make the test pass"
Step: "Run the tests and ensure they pass"
Step: "Commit"

Jira Sub-task Contract (When MCP is Enabled)

Use

jira_create_issue

to create Sub-tasks, with the following mandatory fields:

```
summary
```
: One-to-one correspondence with the task name (for easy tracking)
```
description
```
: Task objective, scope, acceptance key points
```
parent
```
: Parent Story Key (e.g.,
```
ABC-123
```
)
```
labels
```
: At least include the Story-Key and phase label (e.g.,
```
stage2-planning
```
)
```
assignee
```
: Optional; leave blank if unknown and mark "To be assigned" in
```
plan.md
```

If execution fails, it must degrade to "Local output only + manual entry", and must not claim that Jira synchronization is completed.

Execution Process

Declaration at Start: "I am using the aile-writing-plans skill to generate team plans."

Step 0: Read Context

Read
```
docs/README.md
```
and related module documents (e.g., if the scope involves
```
docs/modules/*
```
)
Read (if existing)
```
docs/specs/PRD.md
```
,
```
docs/specs/SAD.md
```
Read (if existing) previous plan deliverables for this Story (
```
docs/plans/{Story-Key}/
```
)

Step 1: Confirm Story-Key and Scope Boundaries

Clarify the Story-Key (e.g.,
```
ABC-123
```
) to be used as the directory name
Clarify "What to do / What not to do" (YAGNI: Remove unnecessary requirements from the plan)

Step 2: Task Breakdown and Sorting

Task granularity: 2-5 minutes per task
Output: Each task clearly specifies file paths, tests, verification commands, expected output
DRY: Reuse existing patterns, do not add unnecessary abstractions

Step 3: Write Plan File

Write the content to

docs/plans/{Story-Key}/plan.md

and ensure its structure complies with the team template (refer to

docs-templates/stage2-plan-template.md

Initialize the status management module:
- Fill in "Overall Progress"
- Establish "Task Status Overview" (all tasks default to
```
To Do
```
  )
- Establish "Execution Records" and write the first record

Step 6: Create Jira Sub-task (Optional)

Preconditions: Jira MCP is available, and the parent Story Key has been confirmed
Call
```
jira_create_issue
```
for each task in the task list to create Sub-tasks
Fill in the following fields during creation:
```
summary
```
,
```
description
```
,
```
parent
```
,
```
labels
```
,
```
assignee
```
(optional)
Write the creation results back to
```
plan.md
```
:
- Success: Record the Sub-task Key (e.g.,
```
ABC-234
```
  )
- Failure: Record "Not created (Reason: xxx, manual entry required)"

Step 6: Write Status Back to Jira MCP (Optional)

When the Jira status changes, call
```
jira_update_issue
```
to update the status field of the corresponding Story to "developing"

Step 7: Handover to Execution Phase

Recommended subsequent execution skills:
```
aile-tdd
```
or
```
aile-subagent-dev
```

aile-writing-plans

NPX Install

Tags

SKILL.md Content (Chinese)