From theclauu
Use when at a development junction with multiple viable approaches — architecture choices, refactoring strategies, where to put new code, or which pattern to follow. Triggers on 'which approach', 'how should I', 'Option A vs B', or any point where the next step isn't obvious and the wrong choice creates rework.
npx claudepluginhub artemis-xyz/theclauu --plugin theclauuThis skill uses the workspace's default tool permissions.
Structured multi-dimensional evaluation for development junctions.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Structured multi-dimensional evaluation for development junctions.
Enter Plan Mode. Call EnterPlanMode to enter deliberation mode. All analysis is read-only — plan mode enforces this. If the user declines plan mode, proceed normally.
You are mid-development — implementing a feature, executing a plan, or refactoring — and you hit a fork:
This is for junctures — moments where the next step isn't obvious and the wrong choice creates rework. Not for trivial decisions (naming, formatting) or situations where one option is clearly correct.
Analyze first, recommend second. You are an analyst presenting all perspectives, not an advocate arguing for a predetermined pick. Evaluate every option against every dimension before synthesizing a recommendation.
State clearly:
For each option, evaluate against all 7 dimensions. Do not skip dimensions. Do not evaluate only your preferred option.
| Dimension | What to Evaluate |
|---|---|
| Elegance | Simplicity, clarity, minimal moving parts. Does it feel like the natural solution? |
| Existing Patterns | Does it leverage code paths, conventions, and architecture already in the codebase? |
| Extension | Does it extend current code naturally, or require new abstractions? |
| DRY | Does it reduce duplication, or introduce new redundancy? |
| Separation of Concerns | Are responsibilities cleanly divided? Does it mix unrelated concerns? |
| Future-Proofing | How well does it accommodate likely future changes without over-engineering for unlikely ones? |
| Plan Alignment | Does it support upcoming plan phases, or create obstacles for future steps? |
Present a table. Every cell must be filled. No blanks, no "N/A".
| Dimension | Option A | Option B | Option C |
|---------------------|-----------------|-----------------|-----------------|
| Elegance | [assessment] | [assessment] | [assessment] |
| Existing Patterns | [assessment] | [assessment] | [assessment] |
| Extension | [assessment] | [assessment] | [assessment] |
| DRY | [assessment] | [assessment] | [assessment] |
| Separation | [assessment] | [assessment] | [assessment] |
| Future-Proofing | [assessment] | [assessment] | [assessment] |
| Plan Alignment | [assessment] | [assessment] | [assessment] |
For each option, synthesize across dimensions:
State your recommendation with: