shinpr/codex-workflows · Archived

recipe-front-plan

Create frontend work plan from design document with test skeleton generation.

First seen Jul 22, 2026

Installation

$ npx skills add shinpr/codex-workflows --skill recipe-front-plan

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from shinpr/codex-workflows · top by installs.

npx skills add shinpr/codex-workflows

Browse all from shinpr/codex-workflows

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 26
License LICENSE
Default branch main
Open issues 1
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,092 B
  • docs SUMMARY.md 102 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Context: Dedicated to the frontend planning phase.

Required Skills [LOAD BEFORE EXECUTION]

  1. [LOAD IF NOT ACTIVE] documentation-criteria -- Work Plan scope and template
  2. [LOAD IF NOT ACTIVE] implementation-approach -- implementation ordering and verification strategy
  3. [LOAD IF NOT ACTIVE] subagents-orchestration-guide -- agent coordination and workflow flow
  4. [LOAD IF NOT ACTIVE] llm-friendly-context -- planning handoffs and artifact contract

Spawn rule: every spawnagent call uses forkturns="none" so the subagent receives only the task message and explicitly provided context.

Orchestrator Definition

Core Identity: Coordinate the frontend planning workflow and complete lightweight routing, file selection, approval recording, and status updates directly.

Execution Plan: Reuse the active execution plan. When the workflow has multiple dependent actions and no plan exists, create one that tracks them through final verification.

Execution Method:

  • Test skeleton generation -> performed by acceptance-test-generator
  • Work plan creation -> performed by work-planner
  • Work plan review -> performed by document-reviewer

The orchestrator invokes these specialists and directly handles deterministic coordination and status changes.

Scope Boundaries

Included in this skill:

  • Design document selection
  • Test skeleton generation with acceptance-test-generator
  • Work plan creation with work-planner
  • Work plan review with document-reviewer
  • Plan approval obtainment

Responsibility Boundary: This skill completes with work plan approval.

Create frontend work plan with the following process:

Execution Process

Step 1: Design Document Selection

Check for existence of design documents in docs/design/.

  • Present options if multiple exist (can be specified with $ARGUMENTS)

[STOP -- BLOCKING] If no design documents exist, notify user and halt. CANNOT proceed without a design document.

Step 2: Test Skeleton Generation

Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [path]. [UI Spec at [ui-spec path] if exists.]" Verify generated artifact paths and pass them to Step 3; an empty selection is valid.

Step 3: Work Plan Creation

Spawn work-planner agent: "Create an implementation-focused work plan from Design Doc at [path]. Include generated test skeleton artifact paths from Step 2 when present. Plan only repository implementation outcomes required by the Design Doc and UI Spec." Verify the returned Work Plan path and use it as the Step 4 review target.

Step 4: Work Plan Review

Spawn document-reviewer agent: "Review the frontend work plan. doc_type: WorkPlan. target: [work-planner completed path]. Verify Design Doc and UI Spec implementation coverage, absence of added operational scope, dependency order, executable verification, optional Verification Focus, and Review Scope."

Branch on verdict.decision:

  • approved -> proceed to Step 5 with the plan-level status pending
  • needs_revision -> apply Review Resolution with work-planner, then review the updated plan
  • rejected -> apply Orchestrator Escalation Resolution using the cited governing sources

Step 5: Plan Approval

[STOP -- BLOCKING] Present the implementation task set and any material choice, then obtain approval for the plan content. CANNOT proceed until user explicitly approves the work plan.

After explicit approval, record the plan-level status as approved.

ENFORCEMENT: Plan content MUST be approved before declaring completion. Unapproved plans are invalid.

Completion Criteria

  • Design document selected
  • Test skeletons generated
  • Work plan created
  • Work plan reviewed via document-reviewer
  • User approved plan content

Output Example

Frontend planning phase completed.

  • Work plan: docs/plans/[plan-name].md
  • Status: Approved

Please provide separate instructions for implementation.