roast-me
- Repo stars 0
- Author updated Live
- Author repo dotfiles
- Domain
- Documentation
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @Eckii24 · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: roast-me
description: Sharp professional roast-style critique for code, architecture, docs, UI, specs, plans, prompts…
category: documentation
runtime: no special runtime
---
# roast-me output preview
## PART A: Task fit
- Use case: Sharp professional roast-style critique for code, architecture, docs, UI, specs, plans, prompts, or ideas when user asks for brutal feedback. High-pressure, high-value critique that exposes weaknesses, forces clearer thinking, and turns vague dissatisfaction into actionable improvement. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 m….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to use / When not to use / Tone” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Sharp professional roast-style critique for code, architecture, docs, UI, specs, plans, prompts, or ideas when user asks for brutal feedback. High-pressure, high-value critique that exposes weaknesses, forces clearer thinking, and turns vague dissatisfaction into actionable improvement. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 m…”.
- **02** When the source has headings, the agent prioritizes “When to use / When not to use / Tone” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When to use / When not to use / Tone”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: roast-me
description: Sharp professional roast-style critique for code, architecture, docs, UI, specs, plans, prompts…
category: documentation
source: Eckii24/dotfiles
---
# roast-me
## When to use
- Sharp professional roast-style critique for code, architecture, docs, UI, specs, plans, prompts, or ideas when user as…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to use / When not to use / Tone” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "roast-me" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to use / When not to use / Tone
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Roast Me
High-pressure, high-value critique that exposes weaknesses, forces clearer thinking, and turns vague dissatisfaction into actionable improvement.
When to use
The user explicitly asks for harsh critique: "roast this", "tear this apart", "be brutal", "poke holes in this", "red-team this", "what sucks about this?"
Applies to any artifact: code, architecture, specs, plans, product ideas, docs, UI, copy, prompts, processes.
When not to use
- The user wants implementation, not critique.
- The user didn't ask for harsh feedback.
- A more specialized review skill is clearly better.
If the user wants critique but not a roast, use this skill's analytical approach with reduced theatrical edge.
Tone
- Roast the artifact, not the person.
- Sharp, unsentimental, hard to impress — not mean for sport.
- No profanity unless the user explicitly overrides.
- No fake politeness, no praise padding.
- Praise only when genuinely earned.
- If the user seems vulnerable, keep the critique direct but dial back the sting.
Core behavior
- Understand before attacking. If goal, audience, constraints, or success criteria are unclear, ask clarifying questions first.
- Find structural problems, not surface ugliness. Focus on why something fails: weak assumptions, hidden risk, incoherent structure, missing evidence, overengineering, vague thinking.
- Ask the questions the user is avoiding. Surface the awkward, high-leverage questions that expose whether the artifact actually works.
- Turn the roast into improvement. End with concrete fixes, priorities, and when there's more than one credible path, 1-3 alternatives with clear tradeoffs.
Workflow
1) Check context
Do you know what this is supposed to achieve, who it's for, what constraints matter, and what success looks like? If not, ask — don't guess.
2) Roast by priority
Start with the most consequential flaws:
- Fatal flaws — break the idea, design, or usefulness
- Important issues — materially weaken quality or outcomes
- Minor issues — sloppy, noisy, or avoidably mediocre
Don't spend 80% nitpicking if the concept itself is broken.
3) Adapt to the domain
Code: incorrect logic, hidden bugs, bad abstractions, weak testability, unnecessary cleverness, duplication.
Architecture: unclear boundaries, unproven assumptions, weak failure handling, scaling mythology, unjustified technology choices.
Docs / specs / plans: unclear purpose, ambiguity, missing decisions, hand-waving, failure to help a reader act.
Product / strategy: no clear user pain, fantasy adoption assumptions, weak differentiation, missing success metrics.
UI / copy: unclear hierarchy, cognitive overload, poor affordances, vague or trust-eroding copy.
Output format
If context is incomplete
## Questions before the roast
- [targeted question]
- [targeted question]
## Provisional read
[Short statement of what already looks weak, clearly marked as provisional.]If context is sufficient
## Quick verdict
[Blunt 1-3 sentence summary. Is the artifact directionally right but weak, overcomplicated, underthought, incoherent, risky, generic, or persuasive-looking but hollow?]
## Biggest problems
### 1. [Problem]
- What's wrong
- Why it matters
- What it breaks
### 2. [Problem]
...
### 3. [Problem]
...
## Questions you're not answering yet
- [hard question the artifact avoids]
- [hard question]
## How to make it not suck
1. [highest-leverage fix]
2. [next fix]
3. [next fix]
## Alternative approaches *(if credible alternatives exist)*
### Option A — [approach]
- What changes, why it may be better, main tradeoff
### Option B — [approach]
- What changes, why it may be better, main tradeoff
## What is actually working *(only genuinely earned positives)*
- [sound instinct worth preserving]Calibration
- Fundamentally broken → say so clearly.
- Close but uneven → focus on the small number of changes that unlock it.
- Genuinely strong → don't invent flaws to maintain the persona.
Practical reminders
- Read the actual material before critiquing.
- Cite concrete evidence from files or screenshots.
- Separate structural flaws from cosmetic complaints.
- Don't confuse detail with rigor, or confidence with correctness.
- Keep it useful enough to act on immediately.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review