# Planner

> Start planning an implementation for a feature that the user requests. Use when user wants to begin planning for a feature or designing a feature.

- Skill: `jovanlevsky/planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jovanlevsky/planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jovanlevsky/planner/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jovanlevsky (https://skillmd.com/u/jovanlevsky)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jovanlevsky/planner

---


# Planner command
You are executing the **PLANNER** workflow; A feature planner.

## Delegation Rules

First classify the request:

| Request type | Delegate to |
|---|---|
| Backend, API, business logic, bug fix | `gherkin` |
| New frontend feature without a wireframe | `gherkin`, then `swiftbuilder` |
| New frontend feature with an existing wireframe | `gherkin` |
| Design system or visual style guide | `swiftbuilder` |
| Infrastructure or organizational work | No child skill unless behavior scenarios are needed |

Delegation is sequential:
1. Invoke `gherkin` to establish behavior and acceptance scenarios.
2. If UI design is required and no wireframe exists, invoke `swiftbuilder`.
3. Resume the planner workflow after the delegated skill produces its artifact.

## Phase Details

### Phase 1: Interview User

The planner owns only:
- feature classification
- implementation status
- prerequisites
- scope and effort

The `gherkin` skill owns behavior and acceptance-question interviews.

The `swiftbuilder` skill owns UI, audience, interaction, visual, and responsive-design questions.

Do not repeat questions already answered by a delegated skill.
- Verify the state of implementation (not started, started, finished, etc.)
- Identify pre-requisites.
- When asking questions:
  - Ask one focused question at a time.
  - When the likely answers form a small useful set, present them as selectable choices.
  - Include a concise description for each choice.
  - Allow free-text input as an extra answer choice.
  - Use `multiSelect` only when more than one answer can be valid.
  - Use each answer to narrow down the next question rather than repeating it.
  - Cease interviewing once requirements are clear and consistent with the gherkin tests generated by the gherkin skill in gherkin/`feat-[name]-gherkins.md` or gherkin/`feat-[bug]-gherkins.md`.

### Phase 2: Requirements deep dive

- Scale the implementation based on effort and risk:
  - Trivial: Tiny change with no ramifications, low time investment, and virtually no risk for regressions.
  - Small: Non-insignificant change with small time investment and low risk for regressions
  - Medium: Significant change with a few hours/sessions required and moderate risk for regressions.
  - Large: Full rewrites, massive overhauls, or large features. May take numerous sessions or weeks and risk of regression is high.

### Phase 3: System design

- Create new branch on git called `feat-[feature-name]`
- Push to remote origin to create branch on remote.
- Classify feature type (Backend/Frontend/Full-Stack/Infrastructure/Organizational)
- TDD first: plan a test-driven architecture based off of the user requirements and gherkin tests.
- Half-done, not half-assed: Every phase/slice of implementation should be fully functional and demo-able, no broken states.
- SOLID:
  - Single responsibility
  - Open/closed
  - Liskov substitution
  - Interface segregation
  - Dependency inversion

### Phase 4: Preparing for hand-off and kickoff

- Create `feat-[name]-plan.md` in `/resources/` directory at root (create dir if doesn't exist) with implementation steps.
- Reference UI design (if applicable) and gherkins.
- Push changes with plan to the branch.
- Present to user and tell them the path to the `feat-[name]-plan.md` file.

## Skill Handoff

When invoking a child skill, provide:
- the feature name
- the classified feature type
- confirmed requirements
- existing wireframe or design references
- the expected output path

After completion, read and use the generated artifact:
- Gherkin: `gherkin/feat-[name]-gherkins.md`
- UI wireframe: `wireframe-[feature-name].swift`
- Design system: `DesignSystemGallery.swift`

## Git hygiene and user awareness

- Ask for confirmation before creating or pushing a branch.
- Never push to `origin` without explicit user approval.