com um clique
benchmark-evaluation
Run a strict research benchmark for a model that will
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Run a strict research benchmark for a model that will
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Create an Obsidian note
Research skill that produces Obsidian notes
Remove AI-generated code slop and clean up code style
Feature skill for new feature development
Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
| name | benchmark-evaluation |
| description | Run a strict research benchmark for a model that will |
Use this skill for evaluating the benchmarks for any model.
Start from this baseline
Establish adequate metrics, if those have not been already indicated by the user or used in previous iterations Run benchmakrs Prepare a report that clearly indicates the results and any failures across analyzed axes. For example, if the number of FPs has increased, indicate this clearly in the report and perhaps give some examples. Keep a score of benchmark results in SCORES.md. Each dataset should have a separate table in that file. Table columns must include run_name, metrics that are evaluated and a date. You can also add a column called
commentsto add any additional context or notes about the run -- for example, critical changes that were made for this run (ex.fixed parsing city formats)
Make sure that you always provide a delta relative to the baseline Clearly indicate the failures while running the benchmarks that might've skewed the score one way or the other Prefer to fail the benchmark if the code fails overly rather than doing try/except