Audit GitHub Actions that run AI agents for prompt injection, unsafe interpolation, sandbox gaps, and permissive actor rules. Use for agentic CI workflows, not general application code review.
日本語の概要は準備中です。原文の説明を表示しています。
Operational rubric that turns "don't make AI slop" into observable properties, severity levels, evidence requirements, and repair actions for interface design. Use as the reference rubric when building or reviewing marketing sites, product interfaces, dashboards, portfolios, or e-commerce pages, especially alongside frontend-design.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Scope: marketing sites, product interfaces, dashboards, portfolios, editorial pages, and e-commerce. Complements frontend-design: that skill builds the interface, this one is the detailed rubric for judging whether the result is generic ("AI slop") or genuinely fit for the product.
This is not a universal style guide. It does not ban a visual style merely because AI systems use it often — a gradient, card grid, serif headline, glass surface, or dark theme may be appropriate. It becomes a slop signal when used by reflex rather than because the product, audience, content, interaction, or brand requires it.
MUST/MUST NOT are required for acceptance; SHOULD/SHOULD NOT are default rules whose deviations need a written rationale; MAY is optional and context-dependent.
AI slop is superficially competent output that lacks sufficient intention, grounding, specificity, coherence, truthfulness, or product fit. It usually shows up as one or more of:
Output is not slop merely because AI helped produce it — a result can be AI-assisted and still strong when it's grounded in real product/user context, deliberately art-directed, specific, factually honest, coherent, accessible, edited, browser-validated, and hard to transplant unchanged to another product. Human-made work can also be slop; the classification concerns the output, not proof of authorship.
PRODUCT.md (or equivalent) with explicit users, jobs, constraints, and a traceable reason per section. Repair: cut unsupported sections, rewrite around concrete user tasks.[NEEDS INPUT], "Price on request," or clearly labeled sample data instead; keep an evidence ledger for verifiable claims; mark fictional demo data as demo data.DESIGN.md with semantic tokens (color, type, spacing, radius, elevation, motion) that components actually consume, and a documented exception when something breaks the system.Classify the result as slop when: one blocking issue exists, three or more dimensions score 3, the same reflex repeats across multiple registers (color + typography + layout + copy), or both quick tests fail.
PRODUCT.md: product/offer, target users, primary jobs, key tasks, real facts vs. assumptions, non-goals, content gaps, accessibility target, success criteria.DESIGN.md: art-direction sentence, brand attributes, anti-references, extracted principles from visual references, palette and semantic color roles, typography roles, spacing/grid system, radius/border/elevation/material rules, imagery direction, motion rules, component vocabulary, responsive principles, intentional exceptions.EVIDENCE.md: for every externally verifiable claim — exact claim, source, confidence, allowed wording, where it appears. Unsupported claims MUST NOT ship.A single self-review is insufficient. Gate through, in order:
Track two separate results — never collapse them into one number:
When slop is detected: name the failed dimension, cite visible/source-level evidence, identify whether the cause is missing context, a model reflex, incomplete implementation, or weak review, remove unsupported content before adding polish, fix the system or rule (not just the symptom), re-run the deterministic/browser/screenshot checks, compare pairwise against the previous version, and record what changed and why.
Do not turn "anti-slop" into another recognizable house style. Don't automatically replace dark-neon with cream-editorial, sans-serif with giant italic serif, cards with arbitrary asymmetry, gradients with flat beige, polished copy with forced quirkiness, or standard layouts with scroll gimmicks. The goal isn't to look less like one AI default by adopting another — it's decisions justified by the project.
Separate rules into two layers so the rubric doesn't fight yesterday's cliché while ignoring tomorrow's:
dark-purple-cyan-glass-default (current LLM tech-product default — flag when used without brand rationale) or overused-default-fonts: Inter, Roboto, Geist, Plus Jakarta Sans, Space Grotesk (exception: Roboto Mono for monospace, Roboto Condensed for display). Review temporal rules at their review date; drop them if the trend faded, otherwise renew. A temporal rule MUST NOT become a new predictable default — after banning a trend, check whether the agent just adopted the next fashionable alternative instead.No blocking issue remains; primary tasks work in the browser; claims are supported or explicitly labeled; the accessibility target is met; screenshots pass responsive review; the design is internally coherent; prominent decisions have written rationale; the substitution test doesn't reveal broad interchangeability; pairwise review prefers the final result over its control/previous version; remaining known limitations are documented.
AI slop is superficially polished but insufficiently intentional, grounded, specific, coherent, truthful, or product-fit output. Don't judge styles in isolation — detect default reflexes, interchangeability, unsupported content, system inconsistency, decorative excess, incomplete interaction, and unreviewed defects. Ground every major decision in PRODUCT.md/DESIGN.md, verify claims through EVIDENCE.md, test real browser tasks and responsive screenshots, and use pairwise review instead of a self-assigned score. A common visual treatment is fine when deliberate, coherent, accessible, and justified by the project.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Audit GitHub Actions that run AI agents for prompt injection, unsafe interpolation, sandbox gaps, and permissive actor rules. Use for agentic CI workflows, not general application code review.
日本語の概要は準備中です。原文の説明を表示しています。
Audit and improve project-rules files (AGENTS.md, CLAUDE.md, .agents/instructions, local overrides) so the agent keeps accurate project context. Use when the user asks to check, audit, review, update, improve, or fix their AGENTS.md or CLAUDE.md, mentions "project rules maintenance" or "agent context optimization", or when the codebase has changed enough that the rules file may be stale. Scans the repository for every rules file, grades each against a quality rubric, outputs a quality report, and applies targeted edits only after user approval.
日本語の概要は準備中です。原文の説明を表示しています。
Capture learnings from the current session into the project-rules file (AGENTS.md, CLAUDE.md, or local override) so future sessions benefit. Use when the user says "revise the rules", "update AGENTS.md / CLAUDE.md with what we just learned", "save this to project memory", "remember this for next time", or at the end of a productive session when valuable context has emerged that is not yet documented. This complements agents-md-improver — improver audits, while this one captures.
日本語の概要は準備中です。原文の説明を表示しています。
Design a feature architecture by analyzing existing codebase patterns and conventions, then provide a comprehensive implementation blueprint with specific files to create or modify, component designs, data flows, and a build sequence. Use this skill when the user asks for an architecture design, an implementation plan for a non-trivial feature, or when dispatched as a sub-task during feature-dev architecture phase.
日本語の概要は準備中です。原文の説明を表示しています。
Deeply analyze an existing codebase feature by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies. Use this skill when you need to understand how a feature works before modifying or extending it, when dispatched as a sub-task during feature-dev exploration, or when the user asks "how does X work in this codebase".
日本語の概要は準備中です。原文の説明を表示しています。
Agents should invoke this skill for code reviews, linting/formatting setup, maintainability checks, complexity concerns, warning cleanup, coding standards, or quality gates in Rust, TypeScript, Python, shell, and mixed repos.
日本語の概要は準備中です。原文の説明を表示しています。