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] Before loading required skills, use `wc -c` to size the files and set both `exec_command.max_output_tokens` and the outer `// @exec: {"max_output_tokens": N}` budget to accommodate their contents, including the combined output of batched reads. Split oversized reads upfront; recover any truncated content before proceeding. 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. **Invocation rule**: Start each named agent with `spawn_agent` and `fork_turns="none"`. When invoking the same named agent again within this flow, use `followup_task` on its existing instance with the inputs specified for the current invocation. ## 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 Invoke `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, invoke `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] ```