From stv
Distills real-world experiences into minimal methodologies, skills, and processes via bottom-up inductive design, stripping unnecessary elements.
npx claudepluginhub 2lab-ai/oh-my-claude --plugin stvThis skill uses the workspace's default tool permissions.
A methodology design process that starts from experience and extracts minimal structure.
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.
A methodology design process that starts from experience and extracts minimal structure. Core principle: Strip away the unnecessary from what worked. Do not fill in from theory.
First, secure experiences where the user actually succeeded (even 2-3 lines). The raw material is "I did this and it worked", not "theoretically it should be this way." If there are multiple experiences, lay them side by side and extract the common structure.
Extract common principles across experiences. Is only the direction different? Only the scale? Only the domain? — Find the invariant, not the differences.
The most important thing in the first structuring pass is not overdoing it. If the experience succeeded in 2-3 lines, creating a 200-line process document is over-engineering. Distinguish between what a sufficiently smart executor (human or AI) needs as just a direction hint versus what requires enforced procedure.
Simulate each sentence of the draft as "If I give this to an executor, how will they actually behave?"
If an ambiguous instruction causes wrong behavior, add a constraint. If a constraint is excessive, remove it.
Fill in with "when we actually tried it, omitting this caused failure." Add inductively ("this failed without it in practice"), not deductively ("logically this should also be needed").
A good name makes what the methodology actually does sharp and clear in one word. Metaphors (Blackbox, Dead Reckoning) have stronger identity than functional descriptions (A* Debug). If the name doesn't match the content, the name isn't wrong — the content definition is still fuzzy.
After structuring, verify the following:
If any of these apply, cut it down. Minimal structure is optimal.