Use this skill when reviewing, diagnosing, restructuring, or rewriting Svelte 5 / SvelteKit frontend code, especially when bugs or complexity stem from weak architecture, poor state ownership, reactivity problems, bad component boundaries, or accumulated technical debt. This skill is diagnosis-first, skeptical, and findings-first. It should question the current solution shape before fixing it, and it may recommend or drive a parallel clean rewrite when the status quo is no longer a good foundation.
j13z0 星标2026年3月9日
职业
分类
代码质量
技能内容
Use this skill when reviewing, diagnosing, restructuring, or fixing non-trivial Svelte 5 frontend problems.
This skill is not limited to passive review. It should be used when the current implementation may be structurally wrong and the first step is to question the existing solution shape before implementing changes.
The primary goal is to detect and correct code that is technically functional but structurally weak, noisy, duplicated, awkward, fragile, or expensive to maintain.
Required reference loading
Before reviewing or changing code, read these files:
references/svelte-review-rubric.md
references/svelte-implementation-rules.md
Read this file as well when the task touches architecture, state ownership, reactivity, extraction, composition, or reusable abstractions:
references/patterns-and-anti-patterns.md
Use these files actively. Do not treat them as optional background material.
Primary objectives
Review or fix code for:
state ownership
相关技能
state structure
reactivity quality
logic extraction and modularization
component boundaries
correct component type selection
API quality
Tailwind duplication and composition quality
markup discipline
accessibility and semantics
maintainability over time
This skill is intentionally skeptical, but it should accept existing solutions when they are already structurally sound.
Use when
Use this skill for tasks like:
reviewing agent-generated Svelte code
auditing frontend architecture in a change set
identifying refactoring opportunities
checking whether a component should be split or extracted
reviewing Tailwind composition quality
checking whether effects/state are modeled correctly
evaluating whether an implementation is “good enough” or needs cleanup
fixing bugs that likely stem from technical debt, weak state modeling, synchronization issues, or poor architecture
deciding whether a local fix is valid or whether the implementation needs restructuring first
deciding whether a legacy area should still be improved in place or replaced with a cleaner parallel path
designing and implementing a targeted rewrite when the current structure is no longer a good foundation
Do not use this skill as the primary skill for:
greenfield visual design ideation
brand/style exploration
backend/domain reviews
broad non-frontend architecture reviews
simple generation tasks where no diagnosis or structural judgment is needed
Review mode
Operate in diagnosis-first, findings-first mode.
Do not simply restate what the code does.
Do not assume that the current solution shape is correct.
Identify what is structurally wrong, weak, noisy, risky, or likely to cause cleanup work later.
Prefer concrete critique over generic praise.
Take a position.
Do not stop at “possible improvements”. State clearly when a pattern, boundary, bridge, state model, or integration approach should no longer be extended.
Core requirement: propose a target architecture
Do not stop at critique alone.
When the current solution shape is weak, explicitly propose a target architecture.
That target architecture should:
define the intended ownership model
define the main component/module boundaries
state which existing structures should be kept, replaced, or removed
name the preferred path forward, not just multiple vague options
make clear whether the right path is:
a local fix
a targeted refactor
an architectural reshape
a partial or parallel rewrite
If multiple paths are possible, recommend one preferred path and explain briefly why it is the best tradeoff.
Do not end with only generic improvement ideas when a clearer architectural target can be stated.
Review workflow
For each component/module under review:
Read the required references first.
Review against references/svelte-review-rubric.md.
Use references/svelte-implementation-rules.md to judge whether the implementation follows the intended conventions.
Read references/patterns-and-anti-patterns.md as needed when the review touches non-trivial architecture or state questions.
Decide whether the issue is:
a local implementation bug
a weak but locally fixable design
a structural problem that requires reshaping the solution
a legacy area that should no longer be improved in place and should instead be replaced through a clean rewrite
Define the target architecture before proposing implementation steps.
Produce findings in a structured format.
If fixing is requested, implement the smallest clean fix that addresses the actual cause, not just the visible symptom.
If the current structure is not a good foundation anymore, say so explicitly and recommend a replacement path instead of incremental repair.
Review priorities
Prioritize issues in roughly this order:
broken or weak state ownership
duplicated or badly structured state
unnecessary or misused effects
wrong component boundaries
reusable logic trapped in components
wrong component type (primitive/composite/headless)
leaky or awkward public APIs
duplicated Tailwind structure
noisy markup / unnecessary wrappers
semantics / accessibility gaps
visual/UI noise
Hard-fix posture
When fixing a non-trivial bug, assume a structural issue first if the problem involves:
synchronization
feedback loops
commands
editor state
external updates vs local updates
competing write paths
repeated guards or suppression logic
state that is hard to explain clearly
In those cases:
identify the current ownership model
identify why it is failing
decide whether the bug is a symptom of a broader design problem
prefer reshaping the solution over adding another band-aid
Do not begin with the most obvious local fix. Start by diagnosing the ownership and synchronization model, then decide whether the visible bug is the true problem or only its symptom.
Do not default to guards, conditionals, or suppression logic unless they are clearly the correct final fix.
Rewrite posture
When the status quo is no longer a good foundation, do not force the solution to stay inside the legacy structure.
If the current area has accumulated enough architectural debt that incremental cleanup would mostly preserve the wrong boundaries, say so clearly.
In such cases, prefer one of these paths:
a targeted architectural reshape in place, if the current structure is still salvageable
a parallel clean rewrite in a new code path, if the legacy structure would otherwise keep dictating bad decisions
A rewrite recommendation should be concrete, not dramatic. Explain:
why the current structure is not a good base anymore
which responsibilities or boundaries should be redesigned
what the new target shape should be
whether the rewrite should be incremental or parallel
Do not recommend a rewrite lightly, but do not avoid recommending it when it is the cleaner and safer path.
Report format
Do not produce a report that is dominated by findings alone. Try to keep the findings report short, focus more on the on target design / architecture / proposed direction.
The report should make the target shape clearly visible and should not reduce it to a short appendix.
Use this structure when possible:
Overall assessment
Start with a clear conclusion:
Ready as-is
Needs targeted refactoring
Needs architectural restructuring
Needs partial or parallel rewrite
Then state, in 2–5 sentences:
what the real problem is
whether the current structure is still a good foundation
what kind of change is actually needed
Target architecture
This section is mandatory whenever the current structure is not already good enough.
Include:
the intended ownership model
the intended component/module boundaries
which existing structures should be kept
which structures should be removed or no longer extended
the preferred path forward
a lean target shape, not a feature-by-feature restatement of the current system
This section should be a major part of the report, not a small afterthought.
Findings
For each important finding:
Severity: high / medium / low
Category: state / reactivity / modularity / boundary / API / Tailwind / markup / a11y / maintainability
Issue: what is wrong
Why it matters: why it creates risk, noise, or cleanup cost
Recommended fix: the smallest clean corrective action
Prefer fewer, high-signal findings over long lists of minor observations. Keep each finding output short and precise. Format labels in bold / ensure the output is well scannable.
Preferred plan
Conclude with a concrete path forward:
what to do first
what to defer or drop
whether to refactor in place or rewrite in parallel
where the main boundaries of the first implementation step should be
Reporting requirements after changes
If you made code changes, do not end with a minimal changelog-style summary.
You must give a structured post-change report that evaluates the result against the intended target architecture and the requested goal.
Use this structure:
1. What changed
Briefly state:
which main files or modules changed
which old structures or patterns were removed
which new boundaries or ownership rules were introduced
2. Goal alignment
Evaluate the result explicitly against the intended goal or target architecture.
State:
which parts of the target shape are now in place
which parts are only partially achieved
which goals are still not achieved yet
Do not summarize only the implementation steps. Explicitly judge whether the current result actually matches the intended architecture.
3. Remaining gaps and risks
List what is still open, weak, or uncertain.
Include things like:
legacy patterns still present
temporary compromises
areas that still need restructuring
correctness risks
missing validation or QA
compile/type/runtime issues
places where the implementation may still be too complex
Do not hide unresolved issues behind a positive summary.
4. Confidence level
State your confidence carefully.
Use one of:
high confidence
moderate confidence
low confidence
If tests, typechecks, manual verification, or build checks were not run, do not claim high confidence.
5. Recommended next step
State the smallest sensible next step:
review the current architecture
fix compile/type/runtime issues
do manual QA
continue with the next rewrite slice
clean up remaining legacy structures
Review of execution discipline
Flag as issues when the implementation:
silently worked around missing dependencies or project prerequisites
reimplemented local project helpers without explicit instruction
continued despite clear blockers without reporting them
used unreported fallbacks that changed the implementation contract
applied a local patch where the real problem was structural
suppressed symptoms without fixing ownership or synchronization problems
kept extending a legacy structure that should have been challenged or replaced
Preferred review posture
be direct
be concrete
focus on structural quality
prefer high-signal findings
avoid generic positivity
avoid style-only nitpicks unless they indicate a structural issue
propose the smallest clean refactor that fixes the real problem
accept existing solutions when they are already structurally sound
when necessary, push for structural change instead of preserving a bad status quo
define the intended target shape, not only the current problems
after code changes, report against the target shape, not only against the diff
If asked to fix after review
When moving from review to fix:
address state ownership first
remove duplicated writable state
reduce or eliminate unnecessary effects
extract reusable non-visual logic
fix component boundaries
simplify API shape
deduplicate Tailwind structure
reduce markup noise
only then apply smaller local fixes if they are still needed
If the correct answer is a rewrite or a parallel replacement path, do not fall back to in-place patching just because it seems shorter.
If asked to rewrite
When asked to rewrite a problematic area:
identify the minimal replacement scope
define the new ownership model and boundaries first
keep the new path isolated from the legacy path
avoid carrying over legacy bridges, guards, and workaround layers unless they are still justified
prefer a lean target architecture over feature-for-feature structural imitation
make the migration path explicit
Final remarks
Before finishing your task, ask yourself: Did you push hard enough to work towards a sound code architecture, maintainable code base, high code quality, code that's coherent and easy to undestand, that can keep up with future grows, increasing complexity and changing requirements? If not, re-consider your work – but don't get lost in endless loops, propose partial solutions if required.
Resources
Use these resources as canonical references when needed: