Menü
Use when debugging a CSS layouts, box-model mismatch, or DOM structure problem that keeps breaking under CSS tweaks.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when configuring custom providers for OpenCode.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill before start working.
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is the deliverable.
| name | frontend-debugging |
| description | Use when debugging a CSS layouts, box-model mismatch, or DOM structure problem that keeps breaking under CSS tweaks. |
| license | CC-BY-NC-4.0 |
Think in boxes, not classes. Most layout bugs are structural: the DOM is split wrong, a wrapper is redundant, or transient state is fighting normal flow.
Core principle: give the browser the correct DOM first; only then tune CSS.
Do not use this skill to keep retrying visual-only CSS changes.
Before changing CSS, answer:
The common failure modes are:
Prefer the smallest structural fix:
If you are tempted to add nowrap, inline-flex, grid, or more wrappers, pause and re-check the DOM first.
Useful browser concepts to search when needed:
display, white-space, and position values.Look for a fix that changes structure before style:
display, white-space, and position values?If the issue persists after a few structural attempts, stop and gather evidence:
Do not keep editing blindly once the DOM picture is unclear.