APM

>Agent Skill

@yellinzero/aico-frontend-plan

skilldevelopment

Create or enhance frontend tasks with detailed implementation steps. Supports TWO modes: MODE A: Enhance existing task (add detailed steps to task in file) MODE B: Create new standalone task file (can contain single or multiple tasks) IMPORTANT: This skill creates MICRO-LEVEL atomic steps, NOT macro architecture plans. For architecture planning or feature scoping, use EnterPlanMode instead. Use this skill when: - Running /frontend.plan command - User asks for "atomic steps", "step-by-step plan with verification" - Have a specific task and need implementation steps - User wants to create a standalone task file (not from story) - Need granular steps: Setup (create files) → Implementation (write code) → Test (verify) DO NOT use for: - Architecture planning (use EnterPlanMode) - General development planning - Feature scoping or estimation Output: - MODE A: Update specific task section in file with Implementation Steps - MODE B: Create new standalone-{name}.md file with one or multiple tasks

apm::install
$apm install @yellinzero/aico-frontend-plan
apm::skill.md
---
name: aico-frontend-plan
description: |
  Create or enhance frontend tasks with detailed implementation steps. Supports TWO modes:

  MODE A: Enhance existing task (add detailed steps to task in file)
  MODE B: Create new standalone task file (can contain single or multiple tasks)

  IMPORTANT: This skill creates MICRO-LEVEL atomic steps, NOT macro architecture plans.
  For architecture planning or feature scoping, use EnterPlanMode instead.

  Use this skill when:
  - Running /frontend.plan command
  - User asks for "atomic steps", "step-by-step plan with verification"
  - Have a specific task and need implementation steps
  - User wants to create a standalone task file (not from story)
  - Need granular steps: Setup (create files) → Implementation (write code) → Test (verify)

  DO NOT use for:
  - Architecture planning (use EnterPlanMode)
  - General development planning
  - Feature scoping or estimation

  Output:
  - MODE A: Update specific task section in file with Implementation Steps
  - MODE B: Create new standalone-{name}.md file with one or multiple tasks
---

# Plan

## ⚠️ CRITICAL RULES - READ FIRST

1. **DETECT MODE**: Determine if input is an existing task reference or a new requirement description
   - If input looks like `story-user-profile Task 1` or `standalone-fix-login Task 2`: **MODE A**
   - If input is a new requirement (e.g., "Fix login button hover"): **MODE B**

2. **MODE A - Enhance Existing Task**:
   - Read the task file from `docs/reference/frontend/tasks/`
   - User must specify task number (e.g., "Task 1", "Task 2")
   - Add or update the "Implementation Steps" section for that specific task
   - Keep all other sections intact
   - Save back to the same file

3. **MODE B - Create Standalone Task File**:
   - Analyze the requirement - is it simple (1 task) or complex (multiple tasks)?
   - If complex, break into multiple tasks (like task-breakdown does)
   - Use filename: `standalone-{requirement-name}.md` (kebab-case)
   - Save to `docs/reference/frontend/tasks/`
   - File format: same as story-based (multiple task sections)

4. **READ CONSTRAINTS FIRST**:
   - Must read `docs/reference/frontend/design-system.md` for design tokens
   - Must read `docs/reference/frontend/constraints.md` for tech stack
   - If task references a design, read from `docs/reference/frontend/designs/`

## Language Configuration

Before generating any content, check `aico.json` in project root for `language` field to determine the output language. If not set, default to English.

## MODE A: Enhance Existing Task

### Process

1. **Read task file**: Get file from `docs/reference/frontend/tasks/{filename}.md` (story-_ or standalone-_)
2. **Extract specific task**: Find the task section by number (e.g., "Task 1", "Task 2")
3. **Read related files** (if referenced): Load design from `docs/reference/frontend/designs/`
4. **Read design system**: Load `docs/reference/frontend/design-system.md` for design tokens
5. **Read constraints**: Load `docs/reference/frontend/constraints.md`
6. **Break into atomic steps**:
   - Start with file creation/setup
   - One section/feature per step
   - Include verification for each step
   - Do NOT include commit step (that happens during execution)
7. **Keep steps atomic**: One action per step
8. **Update task section**: Add/replace "Implementation Steps" in the specific task
9. **Present summary**: Show what was added

### Example

```bash
# Input: User runs /frontend.plan story-user-profile Task 2

# Output:
 Read file: docs/reference/frontend/tasks/story-user-profile.md
 Found Task 2: Implement Header Section
 Added 4 implementation steps

Steps added:
1. Create header component file
2. Implement header layout
3. Add responsive styles
4. Add unit tests

Task ready for implementation. Use /frontend.implement to execute.
```

## MODE B: Create Standalone Task File

### Process

1. **Analyze requirement**:
   - Is this a simple task (single responsibility) or complex (multiple steps)?
   - If complex, break down into multiple independent tasks

2. **Ask user for details** (optional):
   - Auto-generate task name from description
   - Ask for confirmation

3. **Read constraints**:
   - Read design system and technical constraints
   - If user mentions a component, check existing code

4. **Generate task file** (unified format):
   - File header with metadata
   - If simple: 1 task section with detailed steps
   - If complex: Multiple task sections (Task 1, Task 2, etc.)
   - Each task has: Description, Context, AC, Scope, Implementation Steps
   - Progress section at end

5. **Save task file**: Write to `docs/reference/frontend/tasks/standalone-{name}.md`

6. **Present summary**: Show created file and next steps

### Example - Simple Requirement

```bash
# Input: User runs /frontend.plan "Fix login button hover state"

# Output:
 Created standalone task: standalone-fix-login-button-hover.md

File contains:
- 1 task: Fix Button Hover
- 3 implementation steps
- Test verification included

Next: Use /frontend.implement standalone-fix-login-button-hover Task 1
```

### Example - Complex Requirement

```bash
# Input: User runs /frontend.plan "Add user profile page with avatar, bio, and settings"

# Output:
 Created standalone task: standalone-user-profile-page.md

File contains:
- Task 1: Setup Profile Page Component
- Task 2: Implement Avatar Section
- Task 3: Implement Bio Section
- Task 4: Implement Settings Section
- Task 5: Add Tests

Total: 5 tasks

Next: Use /frontend.implement standalone-user-profile-page Task 1
```

## Implementation Steps Format

Both modes use the same step format:

````markdown
## Implementation Steps

### Step 1: [Action]

**Files**:

- Create: `src/components/[Name].tsx`
- Modify: `src/pages/[Page].tsx:L10-L20`

**Action**:
[Exact code or action to take]

**Verify**:

```bash
[verification command]
```
````

Expected: [expected output]

---

### Step 2: [Next Action]

...

````

## Step Granularity

Each step = ONE atomic action:

| Good Steps | Bad Steps |
|------------|-----------|
| Create component file with imports | Create component with all logic |
| Add component skeleton (empty return) | Implement entire component |
| Implement single section | Implement all sections |
| Write one test case | Write all tests |

## Step Types

### Setup Step
```markdown
**Files**: Create: `src/components/ProfileCard.tsx`
**Action**: Create file with basic structure
**Verify**: `npx tsc --noEmit` → No errors
````

### Implementation Step

```markdown
**Files**: Modify: `src/components/ProfileCard.tsx:L8-L10`
**Action**: Implement header section with Avatar and name
**Verify**: `npm run dev` → Component renders correctly
```

### Test Step

```markdown
**Files**: Create: `src/components/__tests__/ProfileCard.test.tsx`
**Action**: Write unit test for profile name rendering
**Verify**: `npm test ProfileCard` → 1 test passed
```

## Standalone Task File Template

For MODE B, see [Task File Template](../task-breakdown/references/task-file-template.md) for complete structure.

Use the same format as story-based tasks, just with:

- Filename: `standalone-{requirement-name}.md`
- Header: `# Standalone Tasks: [Requirement Name]`
- No `> **Story**: ...` line

**Note**: For simple requirements, file may contain only 1 task. For complex requirements, break into multiple tasks.

## Key Rules

- ALWAYS include verification command for each step
- MUST keep steps to 2-5 minutes of work
- MUST save to docs/reference/frontend/tasks/ directory
- NEVER combine multiple actions into one step
- Do NOT include commit step in plan (commits happen during execution)
- MODE A: Preserve all existing content, only add/update steps
- MODE B: Generate complete, self-contained task file

## Common Mistakes

- ❌ Steps too large → ✅ One action per step
- ❌ Skip verification → ✅ Every step has verify command
- ❌ Vague actions → ✅ Include exact code
- ❌ Not saving to file → ✅ Always save task file
- ❌ Including commit in steps → ✅ Commits happen during execution, not planning
- ❌ MODE A: Overwriting existing content → ✅ Only update Implementation Steps section
- ❌ MODE B: Missing metadata → ✅ Include all template sections