Claude-code-workflows recipe-front-build
Execute frontend implementation in autonomous execution mode
git clone https://github.com/shinpr/claude-code-workflows
T=$(mktemp -d) && git clone --depth=1 https://github.com/shinpr/claude-code-workflows "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/recipe-front-build" ~/.claude/skills/shinpr-claude-code-workflows-recipe-front-build && rm -rf "$T"
skills/recipe-front-build/SKILL.mdOrchestrator Definition
Core Identity: "I am an orchestrator." (see subagents-orchestration-guide skill)
Execution Protocol:
- Delegate all work through Agent tool — invoke sub-agents, pass deliverable paths between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
- Follow the 4-step task cycle exactly: task-executor-frontend → escalation check → quality-fixer-frontend → commit
- Enter autonomous mode when user provides execution instruction with existing task files — this IS the batch approval
- Scope: Complete when all tasks are committed or escalation occurs
CRITICAL: Run quality-fixer-frontend before every commit.
Work plan: $ARGUMENTS
Pre-execution Prerequisites
Task File Existence Check
# Check work plans ! ls -la docs/plans/*.md | grep -v template | tail -5 # Check task files ! ls docs/plans/tasks/*.md 2>/dev/null || echo "No task files found"
Task Generation Decision Flow
Analyze task file existence state and determine the action required:
| State | Criteria | Next Action |
|---|---|---|
| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
| Neither exists + Design Doc exists | No plan or task files, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
| Neither exists | No plan, no task files, no Design Doc | Report missing prerequisites to user and stop |
Task Decomposition Phase (Conditional)
When task files don't exist:
1. User Confirmation
No task files found. Work plan: docs/plans/[plan-name].md Generate tasks from the work plan? (y/n):
2. Task Decomposition (if approved)
Invoke task-decomposer using Agent tool:
: "dev-workflows-frontend:task-decomposer"subagent_type
: "Decompose work plan"description
: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"prompt
3. Verify Generation
# Verify generated task files ! ls -la docs/plans/tasks/*.md | head -10
Flow: Task generation → Autonomous execution (in this order)
Pre-execution Checklist
- Confirmed task files exist in docs/plans/tasks/
- Identified task execution order (dependencies)
- Environment check: Can I execute per-task commit cycle?
- If commit capability unavailable → Escalate before autonomous mode
- Other environments (tests, quality tools) → Subagents will escalate
Task Execution Cycle (4-Step Cycle)
MANDATORY EXECUTION CYCLE:
task-executor-frontend → escalation check → quality-fixer-frontend → commit
For EACH task, YOU MUST:
- Register tasks using TaskCreate: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
- Agent tool (subagent_type: "dev-workflows-frontend:task-executor-frontend") → Pass task file path in prompt, receive structured response
- CHECK task-executor-frontend response:
orstatus: "escalation_needed"
→ STOP and escalate to user"blocked"
isrequiresTestReview
→ Execute integration-test-reviewertrue
→ Return to step 2 withneeds_revisionrequiredFixes
→ Proceed to step 4approved
→ Proceed to step 4readyForQualityCheck: true
- INVOKE quality-fixer-frontend: Execute all quality checks and fixes. Always pass the current task file path as
task_file - CHECK quality-fixer-frontend response:
→ Return to step 2 withstub_detected
detailsincompleteImplementations[]
→ STOP and escalate to userblocked
→ Proceed to step 6approved
- COMMIT on approval: Execute git commit
CRITICAL: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer-frontend returns
approved.
Sub-agent Invocation Constraints
MANDATORY suffix for ALL sub-agent prompts:
[SYSTEM CONSTRAINT] This agent operates within build skill scope. Use orchestrator-provided rules only.
Autonomous sub-agents require scope constraints for stable execution. ALWAYS append this constraint to every sub-agent prompt.
Verify task files exist per Pre-execution Checklist, then enter autonomous execution mode. When requirement changes are detected during execution, escalate to the user with the change summary before continuing.
Post-Implementation Verification (After All Tasks Complete)
After all task cycles finish, run verification agents in parallel before the completion report:
-
Invoke both in parallel using Agent tool:
- code-verifier (subagent_type: "dev-workflows-frontend:code-verifier") →
, Design Doc path,doc_type: design-doc
: implementation file list (code_paths
)git diff --name-only main...HEAD - security-reviewer (subagent_type: "dev-workflows-frontend:security-reviewer") → Design Doc path, implementation file list
- code-verifier (subagent_type: "dev-workflows-frontend:code-verifier") →
-
Consolidate results — check pass/fail for each:
- code-verifier: pass when
isstatus
orconsistent
. fail whenmostly_consistent
orneeds_review
. Collectinconsistent
with statusdiscrepancies
,drift
, orconflictgap - security-reviewer: pass when
isstatus
orapproved
. fail whenapproved_with_notes
. blocked → Escalate to userneeds_revision - Present unified verification report to user
- code-verifier: pass when
-
Fix cycle (when any verifier failed):
- Consolidate all actionable findings into a single task file
- Execute task-executor-frontend with consolidated fixes → quality-fixer-frontend
- Re-run only the failed verifiers (by the criteria in step 2)
- Repeat until all pass or
→ Escalate to userblocked
-
All passed → Proceed to completion report
Output Example
Frontend implementation phase completed.
- Task decomposition: Generated under docs/plans/tasks/
- Implemented tasks: [number] tasks
- Quality checks: All passed (Lighthouse, bundle size, tests)
- Commits: [number] commits created