Menu
Execute from codebase-scoped analysis to frontend design document creation including UI Spec.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Anti-pattern detection, root-cause discipline, quality check workflow, and implementation completeness assurance. Use when: fixing bugs, reviewing code quality, refactoring, making technical decisions, or performing quality assurance.
Language-agnostic coding standards for maintainability, readability, and quality. Use when: implementing features, refactoring code, reviewing code quality, or writing functions.
Documentation creation criteria for PRD, ADR, Design Doc, UI Spec, and Work Plan with templates. Use when: creating or reviewing technical documents, determining which documents are required, or following document templates.
Implementation strategy selection framework with meta-cognitive approach. Use when: planning implementation strategy, selecting between vertical/horizontal slicing, or defining verification criteria for tasks.
Integration and E2E test design principles, value-based selection, test skeleton specification, and review criteria. Use when: designing integration tests, E2E tests, generating test skeletons, or reviewing test quality.
Guides subagent coordination through implementation workflows. Use when: orchestrating multiple agents, managing workflow phases, determining autonomous execution mode, or coordinating recipe execution.
| name | recipe-front-design |
| description | Execute from codebase-scoped analysis to frontend design document creation including UI Spec. |
Context: Dedicated to the frontend design phase.
documentation-criteria -- document quality standardsimplementation-approach -- implementation methodologyexternal-resource-context -- external resource hearing and lookupllm-friendly-context -- clear prompts, handoffs, and generated artifactsSpawn rule: every spawn_agent call uses fork_turns="none" so the subagent receives only the task message and explicitly provided context.
Core Identity: "I am not a worker. I am an orchestrator."
Execution Method:
Orchestrator spawns agents and passes structured data between them.
Included in this skill:
Responsibility Boundary: This skill completes with frontend design document (UI Spec/ADR/Design Doc) approval. Work planning and beyond are outside scope.
Requirements: $ARGUMENTS
Build a lightweight seed for codebase-analyzer. This is a file-location pass only, with no deep reading and no design decisions.
rg -l --glob '!**/{node_modules,dist,build,coverage,.git}/**' --glob '!**/*.{lock,min.js,map}' '<keyword>'. If rg is unavailable, use grep -RIl with the same exclusions where possible.source, test, docs, and generated_or_vendor. Exclude generated_or_vendor from the seed.affectedFiles, and keep a one-line seedRationale for each file.affectedFiles. If the user confirms no related code exists, confirm whether to proceed with a new-surface design before invoking codebase-analyzer.Construct requirement_analysis with:
affectedFiles: the Step 1 seedaffectedLayers: ["frontend"] plus shared when shared files are includedscale: provisional scale from file count (small 1-2, medium 3-5, large 6+)purpose: the user requirementsconfidence: confirmed when target files are explicit or the ranked seed is focused; otherwise provisionaladrRequired: true when the request changes component architecture, state ownership, routing architecture, data flow, external dependencies, or shared cross-boundary contracts; otherwise falseadrReason: the specific matched ADR condition, or nullprdRequired: true when scale is large and no existing PRD covers the scope; otherwise falsescopeDependencies: questions whose answers can change the target files, scale, UI surface, or document typequestions: user-facing questions needed before designdocumentTypeRationale: why ADR, Design Doc, or both are needed from the provisional seedseedRationale: one-line reason for each file in affectedFilestechnicalConsiderations: include any obvious user-stated constraints, risks, and dependencies; use empty lists only when none are statedSpawn codebase-analyzer agent: "Analyze the existing codebase to provide evidence for frontend Design Doc creation. Focus on existing implementations, state paths, API integrations, and constraints the design should respect. requirement_analysis: [Step 1 requirement_analysis]. requirements: [original user requirements]. layer: frontend. target_paths: [Step 1 affectedFiles]. focus_areas: component hierarchy, state management, UI interactions, data fetching."
After codebase-analyzer returns, present the frontend design scope to the user before UI or design work:
analysisScope.filesAnalyzed and directly relevant components, routes, or modulesanalysisScope.categoriesDetected, focusAreas, and pathsdocumentTypeRationale, adrRequired, and adrReasonprdRequired is true, whether an existing PRD path is available, and what decision is needed before UI/design worklimitations and unresolved risksAsk the user to choose one:
prdRequired is trueprdRequired is true and no PRD will be providedIf prdRequired is true and the user neither provides a PRD path nor explicitly approves proceeding without a PRD, stop. This recipe does not create PRDs.
After confirmation, set the final scale from the confirmed target file count (small 1-2, medium 3-5, large 6+), recompute adrRequired, adrReason, prdRequired, confidence, and documentTypeRationale, then carry the complete confirmed requirement context, including confirmed scope and user answers, into UI and design creation.
ADR-only path: run Steps 1, 2, 3, and 8. Also run Step 4 only when the ADR depends on external frontend resources, and Step 6 only when the ADR depends on existing UI facts beyond Step 2. Skip Steps 5 and 7.
Design Doc path: run Steps 1 through 8.
Both ADR and Design Doc path: run the Design Doc path, creating the ADR before the Design Doc in Step 8.
[STOP -- BLOCKING] Wait for user confirmation before proceeding.
For Design Doc output, run this step before UI fact gathering. For ADR-only output, run it only when the ADR depends on external frontend resources.
After scope confirmation, run the frontend domain hearing protocol from external-resource-context.
Persist project-level access methods in docs/project-context/external-resources.md. When the file already exists, ask whether to keep current axes, refresh all axes, or refresh selected axes.
[STOP -- BLOCKING] Complete external resource hearing before UI fact gathering. Proceed to UI fact gathering after project-level external resources are written or the update is explicitly skipped.
For Design Doc output only. Skip this step for ADR-only output.
After external resource hearing completes, ask the user about prototype code:
Ask the user: "Do you have prototype code for this feature? If so, please provide the path to the code. The prototype will be placed in docs/ui-spec/assets/ as reference material for the UI Spec."
[STOP -- BLOCKING] Wait for user response about prototype code availability. CANNOT proceed until user responds.
For Design Doc output, run this step before UI Specification creation. For ADR-only output, run it only when the ADR decision depends on existing UI facts beyond the Step 2 codebase analysis.
When Step 5 ran, use the prototype path as an input when one was provided. When Step 5 was skipped, set prototype_path to unavailable.
Spawn ui-analyzer agent: "Gather UI facts for frontend design. requirement_analysis: [confirmed requirement context]. requirements: [original user requirements]. target_paths: [confirmed frontend affected files and directories]. target_components: [frontend target components when known]. ui_spec_path: [path if an existing UI Spec covers this feature]. prototype_path: [path if provided]. Read docs/project-context/external-resources.md, resolve relevant UI external resources through declared access methods, and analyze component structure, props patterns, CSS layout, state displays, accessibility, generated artifacts, and candidate write set."
For Design Doc output only. Skip this step for ADR-only output.
After UI fact gathering completes, create the UI Specification:
[STOP -- BLOCKING] Present UI Spec for user approval. CANNOT proceed until user explicitly approves the UI Spec.
Create appropriate design documents according to confirmed scope and scale:
document_to_create for this invocation; documentTypeRationale describes the overall confirmed path. Codebase Analysis: [JSON from codebase-analyzer]. UI Analysis: [JSON from ui-analyzer, only if Step 6 ran]. Present at least two alternatives with trade-offs."document_to_create for this invocation; documentTypeRationale describes the overall confirmed path. Codebase Analysis: [JSON from codebase-analyzer]. UI Analysis: [JSON from ui-analyzer]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Fill External Resources Used from docs/project-context/external-resources.md and feature identifiers. Record only alternatives actually considered by Design Convergence; None is valid."
document_to_create: DesignDoc and adr_path: [ADR path]; the Design Doc must reference the ADR decision.[STOP -- BLOCKING] Present the created design documents and any recorded trade-offs, then obtain user approval. CANNOT proceed until user explicitly approves the design document.
ENFORCEMENT: Every stop point MUST be respected. Skipping user approval invalidates the entire workflow.
documentTypeRationale created and approvedFrontend design phase completed.