一键在 Manus 中运行任何 Skill

overengineering-review

星标7

分支1

更新时间2026年6月16日 00:14

Review code for overengineering and avoidable complexity, then write an HTML findings report. Use when the user asks whether code is too abstract, too layered, too generic, prematurely extensible, hard to follow, or more complex than the problem requires.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

jeremymcs

jeremymcs/skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Overengineering Review

Use this skill to inspect code for avoidable complexity and produce a self-contained HTML report.

Workflow

Define scope.
- Identify the files, diff, branch, feature, or subsystem under review.
- Inspect nearby callers, tests, docs, and sibling patterns before judging complexity.
- Prefer evidence from the codebase over generic simplicity advice.
Map the actual problem being solved.
- State the concrete behavior or user need the code supports.
- Identify current scale: number of callers, variants, data shapes, plugins, integrations, and lifecycle states.
- Separate real requirements from speculative future flexibility.
Look for overengineering signals.
- Extra layers that only forward calls or rename concepts.
- Generic abstractions with one real implementation.
- Factories, registries, adapters, managers, or strategy objects before there is meaningful variation.
- Configuration that duplicates code paths or exposes internals to callers.
- Types, schemas, or inheritance hierarchies that are broader than the supported behavior.
- File or package splits that make a simple change require cross-module navigation.
- Tests that mainly protect the abstraction instead of user-visible behavior.
Check the blast radius before recommending simplification.
- Trace callers, public APIs, tests, generated artifacts, migrations, and integration points.
- Mark each recommendation as Low, Medium, or High risk based on likely breakage.
- Avoid deleting abstraction that already protects real variability, external contracts, or hard-won operational boundaries.
Produce findings.
- Lead with actionable findings ordered by severity.
- Include specific file paths and line references when available.
- Explain why the code is more complex than the current need, not just that it feels complex.
- Recommend the smallest simplification that preserves behavior.
Write the HTML report directly.
- Create one self-contained .html file with inline CSS and no external assets.
- Include findings, file evidence, impact, recommendation, risk, positive signals, open questions, and verification.
- Escape code snippets and copied source text so review content renders as text, not markup.
- Open or inspect the HTML file when possible before claiming the artifact is ready.

HTML Structure

Use this structure unless the task needs a different layout:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Overengineering Review</title>
  <style>
    /* Inline, readable report styles. */
  </style>
</head>
<body>
  <main>
    <header>
      <h1>Overengineering Review</h1>
      <p><strong>Scope:</strong> Files, diff, feature, or subsystem reviewed.</p>
      <p>Short conclusion and highest-priority theme.</p>
    </header>
    <section>
      <h2>Findings</h2>
      <article>
        <h3>High - Abstraction has one implementation and hides the real behavior</h3>
        <p><strong>Category:</strong> Premature abstraction</p>
        <p><strong>Evidence:</strong> Path and line evidence, caller count, tests, or runtime proof.</p>
        <p><strong>Impact:</strong> Why this makes future work harder or riskier.</p>
        <p><strong>Recommendation:</strong> Smallest safe simplification.</p>
        <p><strong>Risk:</strong> Medium</p>
      </article>
    </section>
    <section>
      <h2>Positive Signals</h2>
    </section>
    <section>
      <h2>Open Questions</h2>
    </section>
    <section>
      <h2>Verification</h2>
    </section>
  </main>
</body>
</html>

Output Standards

The final deliverable must be an .html file, not a prose-only answer.
The report must be useful to a maintainer deciding what to simplify next.
Do not recommend broad rewrites when a smaller deletion, inline move, rename, or module merge solves the problem.
Do not treat complexity as automatically bad. Name the requirement that would justify keeping it.
Do not credit any AI in the report.

同仓库更多 Skills

同仓库

test-writer

jeremymcs/skills

Use when implementing, changing, refactoring, reviewing, or accepting any code, config, build, migration, script, UI, API, dependency, or test change that needs strict executable proof instead of grep, source-text checks, snapshots-only assertions, import-only checks, or manual verification.

2026-06-157

github-repo-hygiene

jeremymcs/skills

Audit and improve GitHub repository hygiene using evidence from local files, package manifests, dependency metadata, and GitHub settings. Use when the user asks for best practices, repo cleanup, repository hygiene, project health, package.json or dependency hygiene, monorepo health, npm/package publishing readiness, GitHub setup, maintainer readiness, contribution workflow, security posture, CI checks, issue or PR templates, branch protection, Dependabot, CodeQL, licensing, release readiness, or open-source/private repository governance.

2026-06-077

dumb-it-down

jeremymcs/skills

Explain confusing ideas in extremely plain language, using simple references, analogies, examples, and step-by-step breakdowns. Use when the user asks to dumb something down, simplify, explain like they are new to the topic, make a problem easier to understand, turn dense writing into plain English, unpack jargon, or create beginner-friendly explanations for technical, business, academic, legal, medical, financial, or code-related material.

2026-05-277

from-issue

jeremymcs/skills

Research and implement a code change from an existing issue, ticket, or issue-like artifact. Use when the user says "$from-issue", asks Codex to work from a GitHub issue, local markdown issue, tracker ticket, bug report, feature issue, or AFK implementation ticket, and expects codebase research, linked PR verification, blast-radius analysis, targeted questions, a patch, verification, branch push, and pull request creation.

2026-05-257

system-diagrammer

jeremymcs/skills

Slowly walk codebases and related project evidence to diagram data flow, workflows, dependencies, integrations, and connections between systems; record findings; verify each edge; and recommend fixes for breaks, edge cases, missing links, and disconnects. Use when the user asks to create, audit, validate, or troubleshoot architecture diagrams, workflow diagrams, integration maps, service maps, data lineage diagrams, sequence diagrams, system dependency maps, or cross-system debugging reports.

2026-05-167

zero-techdebt

jeremymcs/skills

Review code changes for avoidable tech debt through function scope, naming, and file organization. Use when the user wants to know whether a change fits the existing codebase, introduces shallow abstractions, uses misleading names, or places code in the wrong module or directory.

2026-05-157

name	overengineering-review
description	Review code for overengineering and avoidable complexity, then write an HTML findings report. Use when the user asks whether code is too abstract, too layered, too generic, prematurely extensible, hard to follow, or more complex than the problem requires.

Overengineering Review

Use this skill to inspect code for avoidable complexity and produce a self-contained HTML report.

Workflow

Define scope.
- Identify the files, diff, branch, feature, or subsystem under review.
- Inspect nearby callers, tests, docs, and sibling patterns before judging complexity.
- Prefer evidence from the codebase over generic simplicity advice.
Map the actual problem being solved.
- State the concrete behavior or user need the code supports.
- Identify current scale: number of callers, variants, data shapes, plugins, integrations, and lifecycle states.
- Separate real requirements from speculative future flexibility.
Look for overengineering signals.
- Extra layers that only forward calls or rename concepts.
- Generic abstractions with one real implementation.
- Factories, registries, adapters, managers, or strategy objects before there is meaningful variation.
- Configuration that duplicates code paths or exposes internals to callers.
- Types, schemas, or inheritance hierarchies that are broader than the supported behavior.
- File or package splits that make a simple change require cross-module navigation.
- Tests that mainly protect the abstraction instead of user-visible behavior.
Check the blast radius before recommending simplification.
- Trace callers, public APIs, tests, generated artifacts, migrations, and integration points.
- Mark each recommendation as Low, Medium, or High risk based on likely breakage.
- Avoid deleting abstraction that already protects real variability, external contracts, or hard-won operational boundaries.
Produce findings.
- Lead with actionable findings ordered by severity.
- Include specific file paths and line references when available.
- Explain why the code is more complex than the current need, not just that it feels complex.
- Recommend the smallest simplification that preserves behavior.
Write the HTML report directly.
- Create one self-contained .html file with inline CSS and no external assets.
- Include findings, file evidence, impact, recommendation, risk, positive signals, open questions, and verification.
- Escape code snippets and copied source text so review content renders as text, not markup.
- Open or inspect the HTML file when possible before claiming the artifact is ready.

HTML Structure

Use this structure unless the task needs a different layout:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Overengineering Review</title>
  <style>
    /* Inline, readable report styles. */
  </style>
</head>
<body>
  <main>
    <header>
      <h1>Overengineering Review</h1>
      <p><strong>Scope:</strong> Files, diff, feature, or subsystem reviewed.</p>
      <p>Short conclusion and highest-priority theme.</p>
    </header>
    <section>
      <h2>Findings</h2>
      <article>
        <h3>High - Abstraction has one implementation and hides the real behavior</h3>
        <p><strong>Category:</strong> Premature abstraction</p>
        <p><strong>Evidence:</strong> Path and line evidence, caller count, tests, or runtime proof.</p>
        <p><strong>Impact:</strong> Why this makes future work harder or riskier.</p>
        <p><strong>Recommendation:</strong> Smallest safe simplification.</p>
        <p><strong>Risk:</strong> Medium</p>
      </article>
    </section>
    <section>
      <h2>Positive Signals</h2>
    </section>
    <section>
      <h2>Open Questions</h2>
    </section>
    <section>
      <h2>Verification</h2>
    </section>
  </main>
</body>
</html>

Output Standards

The final deliverable must be an .html file, not a prose-only answer.
The report must be useful to a maintainer deciding what to simplify next.
Do not recommend broad rewrites when a smaller deletion, inline move, rename, or module merge solves the problem.
Do not treat complexity as automatically bad. Name the requirement that would justify keeping it.
Do not credit any AI in the report.