recipe-front-adjust

Explicit User Instruction: The user explicitly instructs and authorizes every subagent call named in this recipe. Execute each applicable call when its prerequisites are met.

Execute Skill: llm-friendly-context before writing Agent prompts, handoffs, or generated artifacts.

Context: UI adjustment on already-implemented features. The verification loop (edit → check against the design source → refine) runs in the parent session.

Execution Pattern

Core Identity: "I am a guided executor. I run the adjustment and the verification loop myself; subagents handle one-shot tasks."

Execution Protocol:

1. Delegate to subagents (one-shot calls): quality-fixer-frontend.
2. Run in the parent session (multi-step loops and user dialogs): conditional external-evidence resolution, with AskUserQuestion for missing decision-relevant inputs, write-set inspection, scale judgment, adjustment-context approval, adjustment edits, verification against the design source, iteration until acceptance.
3. Stop at every [Stop: ...] marker before proceeding.

Execution Gate

Complete Steps 1-7 in order for the adjustment outcome. Advance only through the current step's stated evidence, quality result, or user stop; skip work only when its stated condition is false. Report completion after every applicable Completion Criterion and retained-limitation retry is satisfied.

Workflow Overview

Adjustment request → conditional external resource evidence
                                  ↓
                     existing-pattern and write-set inspection
                                  ↓
                     structural boundary judgment on candidate write set
                                  ↓
                     local existing-pattern adjustment → [Stop]
                                  ↓
                     adjustment + verification (parent session)
                                  ↓
                     quality-fixer-frontend (subagent: typecheck/lint/test)
                                  ↓
                     commit

Scope Boundaries

Included in this skill:

• Conditional external-evidence resolution per the external-resource-context skill
• Existing-pattern and write-set inspection in the parent session
• Structural boundary judgment via documentation-criteria
• Adjustment edits and verification against the design source (run in this session)
• Quality verification via quality-fixer-frontend
• Commit the adjustment outcome

Responsibility Boundary: This skill completes when the adjustment is committed after its quality cycle and any retained proof limitation receives its final retry. Adjustment work is end-to-end within this recipe; parent session owns edits, verification loops, quality-result routing, and commits.

Escalation Boundary: Escalate to the full frontend design phase when the request crosses a responsibility or approved UI boundary, requires a complete Design Doc, or contains a technical choice that passes documentation-criteria's Choice and Durability filters.

Adjustment request: $ARGUMENTS

Execution Flow

Step 1: External Resource Evidence

Execute Skill: external-resource-context when external evidence is required.

Resolve only external evidence that can change the current adjustment target or verification result; use existing access details and ask only for missing decision-relevant inputs. Otherwise continue with the existing repository/UI Spec evidence and record no external references.

Step 2: Determine the Route and Write Set

Execute Skill: documentation-criteria.

Inspect the named or current UI and the smallest sufficient repository evidence needed to identify the likely write set and preserved visible behavior. Include a generated artifact only when repository tooling shows that a candidate write triggers its generator. When the UI Spec creation condition applies, route to recipe-front-design and stop. Otherwise record the evidence-backed candidate write set for this existing-pattern adjustment.

Step 3: Scale Judgment

1. Read the candidate write set from Step 2.
2. Apply Structural Scale to the adjustment outcome and responsibility boundary. Use write-set count as supporting evidence only:
   • 0 files: The adjustment request did not map to any existing file. Escalate to the user with the message "No write target identified from the adjustment request. Please clarify which component(s) should change, or run the full frontend design phase if this is a new feature." Stop this recipe.
   • Direct adjustment: One coherent UI outcome follows existing component, state, interaction, and verification patterns inside one responsibility boundary. Continue directly to adjustment context even when generated or tightly coupled files increase the count.
   • Design required: The change crosses a responsibility or approved UI contract, coordinates independently valuable outcomes, or needs a durable technical choice between credible alternatives. Escalate to the full frontend design phase.

Step 4: Adjustment Context

No work plan. Build a minimal adjustment context for the parent session:

• Adjustment request (verbatim)
• Existing UI pattern and preserved visible behavior relevant to the adjustment
• Evidence-backed affected files list from the candidate write set
• External resources fetched_summary and access methods that the verification loop will use

Present the adjustment context to the user for review.

• [STOP]: User confirms the adjustment context covers the work.

Step 5: Adjustment + Verification (parent session)

Execute Skill: ai-development-guide and read its references/frontend.md before planning or applying adjustment edits. Execute Skill: typescript-rules before planning or applying adjustment edits. Execute Skill: implementation-approach before planning or applying adjustment edits. Execute Skill: testing-principles before adding or changing tests.

Implement the adjustment outcome across its affected files:

1. Plan the edit from the Step 4 adjustment context and relevant external resource (e.g., design origin's fetched_summary).
2. Apply the edit using Edit / Write / MultiEdit on the affected files.
3. Verify the adjustment target using applicable repository/UI Spec evidence and any external source selected in Step 1. Reuse its available access or verification method; compare rendering, interaction or tokens only where they determine the requested adjustment.
4. Refine and re-verify until the adjustment matches the design source, or matches the user-confirmed adjustment target when no separate design source exists.
5. When the complete adjustment matches the adjustment target, proceed to Step 6.

When required proof is unavailable, use sufficient file-based or other available evidence; retain an exact proof limitation otherwise. Ask for manual confirmation only when a user-owned interpretation is needed to determine the adjustment target.

Step 6: Quality Verification

• Invoke quality-fixer-frontend using Agent tool
  • subagent_type: "dev-workflows-frontend:quality-fixer-frontend"
  • description: "Quality verification for adjustment"
  • direct_scope: Copy the adjustment request and preserved visible behavior from Step 4 unchanged.
  • governing_sources: Pass the existing UI and design source references used for the adjustment unchanged.
  • observable_verification: Pass the adjustment request from Step 4 and applicable acceptance criteria from the governing sources unchanged.
  • Pass qualityCommand when available (caller first, otherwise current task).
• Route the quality-fixer-frontend response by status:
  • pass → proceed to Step 7
  • stub_detected → return to Step 5 to complete the adjustment, then re-invoke quality-fixer-frontend
  • verification_incomplete → retain the complete result for final retry and proceed to Step 7
  • blocked → Apply subagents-orchestration-guide Specialist Result Acceptance using the result's semantic evidence, changed files, and repository state

Step 7: Commit

Before committing, use repository state at the commit boundary as the primary evidence and account for every actual change by mapping it to the adjustment, preserved pattern, or a necessary dependency, test, or generated artifact. Every required change is ready for the adjustment commit, accidental changes introduced during the adjustment are removed, and existing worktree changes unrelated to the adjustment remain intact.

Commit the adjustment after pass or verification_incomplete. For the latter, derive and append one Verification-Limitation: <reason> and Verification-Affected: <affected check or command> trailer pair per retained limitation.

On continuation, reconstruct retained limitations from the verification trailers on commits already completed for this request. After the adjustment is committed, retry each retained verification limitation once with quality-fixer-frontend. When the retry returns pass, remove that limitation from retained state. Commit any resulting fixes through Steps 6→7, and include only a repeated limitation in the completion report.

Completion Criteria

• Decision-relevant external evidence was resolved or its exact limitation retained; no record is required when repository/UI Spec evidence suffices
• UI Spec applicability and the candidate write set were determined from the requested UI and sufficient repository evidence
• Structural boundary judgment applied; changes requiring complete design or a qualifying durable decision escalated
• Adjustment context, including the affected files, was presented and confirmed once
• The adjustment outcome is implemented; each declared verification mechanism ran, received manual confirmation where required, or retained its exact proof limitation after final retry
• The adjustment completed quality-fixer-frontend before commit; retained proof limitations were retried and reported
• The adjustment is committed

Output Example

Frontend adjustment completed.
- External resources: docs/project-context/external-resources.md (updated|unchanged)
- UI evidence: existing pattern [path], external sources [fetched|partial|not_recorded]
- Scale: direct existing-pattern adjustment
- Adjustment commit: [commit hash]
- Quality status: all passed | [remaining proof limitations]