Planner

Planner command

You are executing the PLANNER workflow; A feature planner.

Delegation Rules

First classify the request:

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.