Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

improve-codebase-architecture

Estrelas0

Forks0

Atualizado24 de junho de 2026 às 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.

Instalação

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ê.

Executar no Manus

Fonte

Allmight97

Allmight97/agents

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

Explorador de arquivos

3 arquivos

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.

Mais deste repositório

mesmo repositório

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.