Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

improve-codebase-architecture

Étoiles0

Forks0

Mis à jour24 juin 2026 à 20:43

Architecture smell scan when the user explicitly asks for refactor targets, deep-module candidates, or an architecture review. HTML report in OS temp; stop after report unless the user picks a candidate.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Allmight97

Allmight97/agents

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

3 fichiers

SKILL.md

readonly

name	improve-codebase-architecture
description	Architecture smell scan when the user explicitly asks for refactor targets, deep-module candidates, or an architecture review. HTML report in OS temp; stop after report unless the user picks a candidate.

Improve Codebase Architecture

Surface architectural friction and deepening opportunities — shallow modules worth refactoring for testability and navigability.

User must request this scan explicitly. Do not publish issues unless asked.

Use codebase-design vocabulary (module, interface, depth, seam, adapter, leverage, locality) in every suggestion.

Read the repo glossary and architecture spine named in root or nested AGENTS.md (for ABB: docs/ubiquitous-language.md, docs/system-map.md). Respect docs/DECISIONS.md or docs/adr/ — surface ADR conflicts only when friction warrants reopening.

Process

1. Explore

Read domain glossary and decision notes for the touched area. Walk the codebase and note friction:

Understanding one concept requires bouncing across many modules?
Interface nearly as complex as the implementation?
Pure helpers extracted for testability but bugs hide in composition?
Tightly coupled modules leak across seams?
Untested or hard to test through the current interface?

Apply the deletion test on suspected shallow modules.

2. HTML report

Write a self-contained HTML file to OS temp: <tmpdir>/architecture-review-<timestamp>.html. Open it for the user and give the absolute path.

Each candidate card: Files, Problem, Solution, Benefits, Before/After diagram, Recommendation strength (Strong | Worth exploring | Speculative).

End with Top recommendation.

Use domain vocabulary from the repo glossary and architecture terms from codebase-design.

See HTML-REPORT.md for scaffold and styling.

Do not propose interfaces yet. Ask which candidate to explore.

3. After pick

Use grill-me or repo alignment skill when capture is next. Propose glossary or decision-note updates only when the user asks. Use codebase-design DESIGN-IT-TWICE.md for interface alternatives.

Plus depuis ce dépôt

même dépôt

use-proton-pass

Allmight97/agents

Read credentials and secrets from Proton Pass through pass-cli with scoped agent sessions and non-disclosing handoffs. Use when retrieving passwords, TOTP codes, pass:// references, attachments, or other vault fields; logging into a website or application; running commands with Proton Pass secrets; inspecting vault, item, share, agent, or access-token metadata; using Proton Pass SSH keys; or diagnosing pass-cli installation, authentication, session, and permission failures.

2026-07-180

code-review

Allmight97/agents

Read-only review of a PR, branch, diff, or worktree changes for correctness, requested behavior, regressions, scope creep, proof gaps, and merge readiness. Use when asked to review changed code or decide whether work is safe to merge. Route over-engineering-only reviews to whittle-review and repository-wide structural scans to improve-codebase-architecture.

2026-07-120

whittle-review

Allmight97/agents

Review for over-engineering without applying fixes: find what to delete, replace with stdlib/native, or shrink. Use when asked to review a diff or audit a repo for unnecessary complexity, bloat, deletion candidates, or YAGNI violations. Correctness, requested behavior, merge readiness, security, and performance are out of scope; route ordinary code review to code-review.

2026-07-120

write-sharp-docs

Allmight97/agents

Write, rewrite, critique, and manage high-taste technical program and engineering documents. Use when asked for better docs, specs, RFCs, decision memos, launch or readiness docs, completion records, Google Docs-ready drafts, less LLM-y writing, senior TPM or staff-engineer polish, document pruning, audience fit, decision clarity, or durable knowledge management.

2026-07-120

consult-pro

Allmight97/agents

Build, refine, and synthesize ChatGPT Pro consultation prompts. Use when the user asks for a paste-ready Pro prompt, wants Pro to audit, review, or critique a repo or plan, needs a follow-up after a Pro response, wants Pro feedback checked against local evidence, or wants a manual Pro consultation loop without browser monitoring.

2026-07-120

diagnose

Allmight97/agents

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

2026-07-120

name	improve-codebase-architecture
description	Architecture smell scan when the user explicitly asks for refactor targets, deep-module candidates, or an architecture review. HTML report in OS temp; stop after report unless the user picks a candidate.

Improve Codebase Architecture

Surface architectural friction and deepening opportunities — shallow modules worth refactoring for testability and navigability.

User must request this scan explicitly. Do not publish issues unless asked.

Use codebase-design vocabulary (module, interface, depth, seam, adapter, leverage, locality) in every suggestion.

Process

1. Explore

Read domain glossary and decision notes for the touched area. Walk the codebase and note friction:

Understanding one concept requires bouncing across many modules?
Interface nearly as complex as the implementation?
Pure helpers extracted for testability but bugs hide in composition?
Tightly coupled modules leak across seams?
Untested or hard to test through the current interface?

Apply the deletion test on suspected shallow modules.

2. HTML report

Write a self-contained HTML file to OS temp: <tmpdir>/architecture-review-<timestamp>.html. Open it for the user and give the absolute path.

Each candidate card: Files, Problem, Solution, Benefits, Before/After diagram, Recommendation strength (Strong | Worth exploring | Speculative).

End with Top recommendation.

Use domain vocabulary from the repo glossary and architecture terms from codebase-design.

See HTML-REPORT.md for scaffold and styling.

Do not propose interfaces yet. Ask which candidate to explore.

3. After pick

Use grill-me or repo alignment skill when capture is next. Propose glossary or decision-note updates only when the user asks. Use codebase-design DESIGN-IT-TWICE.md for interface alternatives.