recipe-front-adjust git:20260801.00c4c63A

Immutable. This exact content is served forever at /api/v1/blob/cd7c1f77d715d4cf.

---
name: recipe-front-adjust
description: "Adjust an implemented UI with external resource context, focused write-set confirmation, verification, and quality checks."
---

**Context**: UI adjustment for implemented frontend features. The parent session owns the edit and verification loop; subagents handle bounded fact gathering, planning, and quality checks.

## Required Skills [LOAD BEFORE EXECUTION]

1. [LOAD IF NOT ACTIVE] `documentation-criteria` -- scale and planning criteria
2. [LOAD IF NOT ACTIVE] `external-resource-context` -- external resource hearing and lookup
3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination rules
4. [LOAD IF NOT ACTIVE] `llm-friendly-context` -- clear prompts, handoffs, and generated artifacts

**Spawn rule**: every `spawn_agent` call uses `fork_turns="none"` so the subagent receives only the task message and explicitly provided context.

## Execution Pattern

**Core Identity**: "I am a guided executor. I run the UI adjustment and verification loop in the parent session."

**Execution Plan Gate**: Call `update_plan` with first "Map active rules to this task", the applicable adjustment steps, and final "Verify outputs and rule adherence" before external-resource hearing. While work remains, keep exactly one step `in_progress`; after final verification evidence exists, mark every step `completed`.

**Execution Protocol**:
1. Delegate bounded one-shot work to `ui-analyzer`, `work-planner`, and `quality-fixer-frontend`.
2. Run user dialogue, write-set confirmation, edits, and verification in the parent session.
3. Respect every `[STOP]` marker before moving to the next phase.

Adjustment request: $ARGUMENTS

## Execution Flow

### Step 1: External Resource Hearing

Run the frontend domain hearing protocol from `external-resource-context`.

### Step 2: UI Fact Gathering

Spawn `ui-analyzer`:

`requirement_analysis: { affectedFiles: [files inferred from request], purpose: "UI adjustment", technicalConsiderations: [] }. requirements: [adjustment request]. target_paths: [paths named or inferred from request]. target_components: [components named in request]. ui_spec_path: [path if available]. Read docs/project-context/external-resources.md, resolve relevant UI sources through declared access methods, analyze existing UI code, and populate candidateWriteSet[].`

### Step 3: Confirm Write Set and Scale

1. Present `candidateWriteSet[]` to the user.
2. Ask the user to confirm high-confidence entries, confirm all entries, or provide an edited file list.
3. Apply documentation-criteria Creation Decision Matrix to the confirmed write set:
   - `0 files`: ask the user for the component or path that owns the change, then pause this recipe.
   - Small structural scale: proceed with direct adjustment.
   - Medium structural scale: create a focused work plan.
   - Large structural scale: route to the frontend design flow.
   - Any ADR condition: route to the frontend design flow even when the scale is Medium.

### Step 4: Plan Creation When Needed

For Medium structural scale, spawn `work-planner`:

`Create a focused UI adjustment plan. Adjustment request: [verbatim]. ui_analysis: [ui-analyzer JSON]. External resources: docs/project-context/external-resources.md. Confirmed write set: [files]. Each phase should be implementable as 1-3 commits. Include visual verification, accessibility, i18n parity, and generated artifact checks when relevant. Output path: docs/plans/[YYYYMMDD]-adjust-[short-description].md.`

**[STOP]** Present the plan and wait for approval.

For Small structural scale, present a concise adjustment context:
- request
- confirmed write set
- relevant `focusAreas[]`
- relevant external resource summaries and access methods

**[STOP]** Wait for user confirmation that the context covers the work.

### Step 5: Adjustment and Verification

For each adjustment unit:
1. Plan the edit from `focusAreas[]`, confirmed write set, and relevant external resource summaries.
2. Apply the edit in the parent session.
3. Verify against declared access methods:
   - design origin: compare implementation target to the recorded design source
   - visual verification: use the recorded browser, test runner, Storybook, dev server, or manual confirmation path
   - design system: confirm tokens, variants, and usage rules through the recorded source
4. Refine until the implemented UI matches the design source or the user-confirmed adjustment target.

### Step 6: Quality Verification

Spawn `quality-fixer-frontend` for each unit:

- Direct adjustment: pass `filesModified: [edited files]`
- Planned adjustment: pass `task_file: [work plan path]` and `filesModified: [edited files]`

Route `quality-fixer-frontend` results:
- `approved`: proceed to commit
- `stub_detected`: complete the implementation gap and rerun quality verification
- `blocked`: surface missing prerequisites or unclear specification points to the user

### Step 7: Commit

Commit each approved adjustment unit with affected files and relevant generated artifacts.

## Completion Criteria

- [ ] External resource hearing completed or update explicitly skipped
- [ ] `ui-analyzer` returned JSON with external resource status and `candidateWriteSet`
- [ ] User confirmed write set before scale judgment
- [ ] Scale judgment completed with matching branch
- [ ] Direct context or work plan approved
- [ ] Adjustment units edited and verified through declared resource paths
- [ ] Each unit passed `quality-fixer-frontend`
- [ ] Each approved unit committed

## Output Example

```
Frontend adjustment completed.
- External resources: docs/project-context/external-resources.md (updated|unchanged)
- UI analysis: [N] components, [M] focus areas
- Scale: small | medium | large (structural)
- Work plan: path | N/A
- Adjustment units committed: [count]
- Quality status: approved
```