From rafayels-engineering
Refines brainstorm and plan documents by assessing clarity, completeness, specificity, YAGNI, and scope issues, then auto-fixes minor problems or proposes substantive changes before next workflow steps.
npx claudepluginhub rafayelgardishyan/rafayels-marketplace --plugin rafayels-engineeringThis skill uses the workspace's default tool permissions.
Improve brainstorm or plan documents through structured review.
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.
Improve brainstorm or plan documents through structured review.
If a document path is provided: Read it, then proceed to Step 2.
If no document is specified: Ask which document to review, or look for the most recent brainstorm/plan in docs/brainstorms/ or docs/plans/.
Read through the document and ask:
These questions surface issues. Don't fix yet—just note what you find.
Score the document against these criteria:
| Criterion | What to Check |
|---|---|
| Clarity | Problem statement is clear, no vague language ("probably," "consider," "try to") |
| Completeness | Required sections present, constraints stated, open questions flagged |
| Specificity | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
| YAGNI | No hypothetical features, simplest approach chosen |
If invoked within a workflow (after /workflows:brainstorm or /workflows:plan), also check:
Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.
Present your findings, then:
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
Don't simplify:
After changes are complete, ask:
After 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.
Return control to the caller (workflow or user) after selection.