मुख्य सामग्री पर जाएं

​
लक्ष्य

वर्तमान workflows को तोड़े बिना या व्यापक refactors में जोखिम छिपाए बिना application को अधिक साफ, तेज और maintainable product की ओर ले जाएँ। काम छोटे, reviewable हिस्सों में land होना चाहिए, हर touched surface के proof के साथ।

​
सिद्धांत

  • वर्तमान architecture को सुरक्षित रखें, जब तक कोई boundary स्पष्ट रूप से churn, performance cost, या user-visible bugs का कारण न बन रही हो।
  • हर issue के लिए सबसे छोटा सही patch पसंद करें, फिर दोहराएँ।
  • आवश्यक fixes को optional polish से अलग रखें ताकि maintainers subjective decisions का इंतज़ार किए बिना उच्च-मूल्य वाला काम land कर सकें।
  • Plugin-facing behavior को documented और backwards compatible रखें।
  • regression fixed होने का दावा करने से पहले shipped behavior, dependency contracts, और tests verify करें।
  • मुख्य user path को पहले बेहतर बनाएँ: onboarding, auth, chat, provider setup, Plugin management, और diagnostics।

​
Phase 1: Baseline audit

बदलाव करने से पहले वर्तमान application की inventory बनाएँ।
  • शीर्ष user workflows और उन्हें own करने वाली code surfaces की पहचान करें।
  • dead affordances, duplicate settings, unclear error states, और expensive render paths की सूची बनाएँ।
  • हर surface के लिए वर्तमान validation commands capture करें।
  • issues को required, recommended, या optional के रूप में mark करें।
  • known blockers document करें जिन्हें owner review चाहिए, खासकर API, security, release, और Plugin contract changes।
Definition of done:
  • repo-root file references वाली एक issue list।
  • हर issue में severity, owner surface, expected user impact, और proposed validation path हो।
  • speculative cleanup items को required fixes में mix न किया गया हो।

​
Phase 2: Product और UX cleanup

Visible workflows को prioritize करें और confusion हटाएँ।
  • model auth, Gateway status, और Plugin setup के आसपास onboarding copy और empty states को tighten करें।
  • जहाँ कोई action संभव नहीं है, वहाँ dead affordances हटाएँ या disable करें।
  • fragile layout assumptions के पीछे important actions छिपाने के बजाय responsive widths पर उन्हें visible रखें।
  • repeated status language consolidate करें ताकि errors के लिए one source of truth हो।
  • core setup को fast रखते हुए advanced settings के लिए progressive disclosure जोड़ें।
Recommended validation:
  • first-run setup और existing user startup के लिए manual happy path।
  • routing, config persistence, या status derivation logic के लिए focused tests।
  • बदली हुई responsive surfaces के लिए browser screenshots।

​
Phase 3: Frontend architecture tightening

व्यापक rewrite के बिना maintainability सुधारें।
  • repeated UI state transformations को narrow typed helpers में move करें।
  • data fetching, persistence, और presentation responsibilities को अलग रखें।
  • new abstractions के बजाय existing hooks, stores, और component patterns पसंद करें।
  • oversized components को केवल तब split करें जब इससे coupling घटे या tests स्पष्ट हों।
  • local panel interactions के लिए broad global state introduce करने से बचें।
Required guardrails:
  • file splitting के side effect के रूप में public behavior न बदलें।
  • menus, dialogs, tabs, और keyboard navigation के लिए accessibility behavior intact रखें।
  • loading, empty, error, और optimistic states अब भी render होते हैं, यह verify करें।

​
Phase 4: Performance और reliability

व्यापक theoretical optimization के बजाय measured pain को target करें।
  • startup, route transition, large list, और chat transcript costs measure करें।
  • जहाँ profiling value prove करती है, वहाँ repeated expensive derived data को memoized selectors या cached helpers से replace करें।
  • hot paths पर avoidable network या filesystem scans घटाएँ।
  • model payload construction से पहले prompt, registry, file, Plugin, और network inputs के लिए deterministic ordering रखें।
  • hot helpers और contract boundaries के लिए lightweight regression tests जोड़ें।
Definition of done:
  • हर performance change baseline, expected impact, actual impact, और remaining gap record करता है।
  • cheap measurement उपलब्ध होने पर कोई perf patch केवल intuition के आधार पर land न हो।

​
Phase 5: Type, contract, और test hardening

उन boundary points पर correctness बढ़ाएँ जिन पर users और Plugin authors निर्भर हैं।
  • loose runtime strings को discriminated unions या closed code lists से replace करें।
  • external inputs को existing schema helpers या zod से validate करें।
  • Plugin manifests, provider catalogs, Gateway protocol messages, और config migration behavior के आसपास contract tests जोड़ें।
  • compatibility paths को startup-time hidden migrations के बजाय doctor या repair flows में रखें।
  • Plugin internals से test-only coupling से बचें; SDK facades और documented barrels का use करें।
Recommended validation:
  • pnpm check:changed
  • हर changed boundary के लिए targeted tests।
  • lazy boundaries, packaging, या published surfaces बदलने पर pnpm build।

​
Phase 6: Documentation और release readiness

User-facing docs को behavior के साथ aligned रखें।
  • behavior, API, config, onboarding, या Plugin changes के साथ docs update करें।
  • changelog entries केवल user-visible changes के लिए जोड़ें।
  • Plugin terminology को user-facing रखें; internal package names केवल contributors के लिए जरूरत होने पर use करें।
  • release और install instructions अब भी current command surface से match करती हैं, यह confirm करें।
Definition of done:
  • Relevant docs behavior changes वाली same branch में updated हों।
  • touched होने पर generated docs या API drift checks pass हों।
  • handoff किसी भी skipped validation और उसके skipped होने का कारण नामित करे।
Scoped Control UI और onboarding pass से शुरू करें:
  • first-run setup, provider auth readiness, Gateway status, और Plugin setup surfaces audit करें।
  • dead actions हटाएँ और failure states स्पष्ट करें।
  • status derivation और config persistence के लिए focused tests add या update करें।
  • pnpm check:changed run करें।
यह limited architecture risk के साथ high user value देता है।

​
Frontend skill update

इस section का उपयोग modernization task के साथ supplied frontend-focused SKILL.md को update करने के लिए करें। अगर इस guidance को repo-local OpenClaw skill के रूप में adopt कर रहे हैं, तो पहले .agents/skills/openclaw-frontend/SKILL.md बनाएँ, उस target skill में belonging frontmatter रखें, फिर body guidance को नीचे दी गई content से add या replace करें। 
# Frontend Delivery Standards

Use this skill when implementing or reviewing user-facing React, Next.js,
desktop webview, or app UI work.

## Operating rules

- Start from the existing product workflow and code conventions.
- Prefer the smallest correct patch that improves the current user path.
- Separate required fixes from optional polish in the handoff.
- Do not build marketing pages when the request is for an application surface.
- Keep actions visible and usable across supported viewport sizes.
- Remove dead affordances instead of leaving controls that cannot act.
- Preserve loading, empty, error, success, and permission states.
- Use existing design-system components, hooks, stores, and icons before adding
  new primitives.

## Implementation checklist

1. Identify the primary user task and the component or route that owns it.
2. Read the local component patterns before editing.
3. Patch the narrowest surface that solves the issue.
4. Add responsive constraints for fixed-format controls, toolbars, grids, and
   counters so text and hover states cannot resize the layout unexpectedly.
5. Keep data loading, state derivation, and rendering responsibilities clear.
6. Add tests when logic, persistence, routing, permissions, or shared helpers
   change.
7. Verify the main happy path and the most relevant edge case.

## Visual quality gates

- Text must fit inside its container on mobile and desktop.
- Toolbars may wrap, but controls must remain reachable.
- Buttons should use familiar icons when the icon is clearer than text.
- Cards should be used for repeated items, modals, and framed tools, not for
  every page section.
- Avoid one-note color palettes and decorative backgrounds that compete with
  operational content.
- Dense product surfaces should optimize for scanning, comparison, and repeated
  use.

## Handoff format

Report:

- What changed.
- What user behavior changed.
- Required validation that passed.
- Any validation skipped and the concrete reason.
- Optional follow-up work, clearly separated from required fixes.