Run any Skill in Manus with one click

improve-codebase-architecture

Stars0

Forks0

UpdatedJune 24, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Allmight97

Allmight97/agents

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

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.

More from this repository

same repository

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.