recipe-front-adjust

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] subagents-orchestration-guide -- agent coordination rules
2. [LOAD IF NOT ACTIVE] llm-friendly-context -- adjustment handoff and verification context

Load external-resource-context in Step 1 only when a named external source is required for the requested adjustment.

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

Execution Pattern

Parent responsibility: Run the UI adjustment and verification loop in the parent session.

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 Protocol:

1. Delegate bounded one-shot work to ui-analyzer and quality-fixer-frontend.
2. Run evidence resolution, edits, and verification in the parent session.

Adjustment request: $ARGUMENTS

Execution Flow

Step 1: External Resource Hearing

Identify whether the requested adjustment depends on an external design or verification source unavailable from the repository or supplied input. Reuse a matching recorded resource when available. Otherwise run the focused external-resource-context hearing for that exact source. When repository or user-supplied evidence defines the target, continue with no external resource.

Step 2: UI Fact Gathering

Spawn ui-analyzer:

exploration_mode: [mode from Analysis Assignment]. 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]. externalResourceRefs: [{label, featureIdentifier} selected in Step 1, or []]. Analyze existing UI code and populate candidateWriteSet[].

Step 3: Resolve Write Set and Route

Resolve the smallest write set supported by the request, candidateWriteSet[], repository evidence, and applicable simplifications[] with their conditions. Search by component ownership and call sites when the first candidates are incomplete; ask the user only when the requested UI target still cannot be identified.

• The requested outcome and actual consumer obligations can be preserved by the local adjustment, including removing unwanted UI and now-unused code: proceed to Step 4 and update affected local design statements.
• An unresolved user-outcome decision or wider design coordination is needed: return the concrete issue through Orchestrator Escalation Resolution. Use recipe-front-design only when that coordination needs it; an internal component or routing reduction alone does not require restarting design.

Concise adjustment context:

• request
• resolved write set
• relevant focusAreas[]
• relevant external resource entries with summaries and access methods
• repository paths changed while recording a required external resource

Step 4: Adjustment and Verification

For each adjustment unit:

1. Start the Per-Task Change Set with any repository paths changed in Step 1, then plan the edit from focusAreas[], resolved write set, and relevant external resource summaries.
2. Apply the edit in the parent session and add its paths and generated artifacts to taskWriteSet.
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. Correct differences required by the design source or user-confirmed target, then stop when the selected verification observes that result. Report a remaining evidence or authority limitation through Orchestrator Escalation Resolution.

Step 5: Quality Verification

Review reception: Unnecessary repairs create lasting work. Before assigning a fix, use Review Resolution to judge no change, removal or narrowing, and reuse first; record why any retained or added mechanism is necessary.

For each unit, spawn quality-fixer-frontend with filesModified: taskWriteSet and the Step 4 verification evidence. Repair reported stubs in the parent session, accumulate every repair and quality-fixer path, and rerun quality-fixer. On pass, reconcile and commit the Per-Task Change Set; resolve blocked results through Orchestrator Escalation Resolution.

Completion Criteria

• The UI target is grounded in repository, supplied, or focused external evidence
• ui-analyzer returned JSON with external resource status and candidateWriteSet
• The write set is supported by the request and repository evidence
• Route completed:
  • Direct adjustment: edits verified, quality-fixer passed, and units committed
  • Frontend design: request, resolved write set, and relevant focusAreas[] handed to recipe-front-design

Output Example

Frontend adjustment completed.
- External resources: docs/project-context/external-resources.md (updated|unchanged)
- Route: direct adjustment | frontend design
- Result: [committed adjustment count | frontend design handoff]