Mmcp.market

tech-debt-audit skill

by code-yeongyu·code-yeongyu/oh-my-openagent·70k stars

Thorough, file-cited technical debt audit across 9 dimensions using AST-grep (tree-sitter), grep, LSP, and language-native tooling. Produces TECH_DEBT_AUDIT.md with severity, effort estimates, and prioritized fixes. Use when asked for codebase health check, tech debt audit, architecture review, code quality assessment, or cleanup planning. Triggers: 'tech debt', 'technical debt', 'debt audit', 'code health', 'technical debt audit', 'codebase health check', 'find tech debt', 'debt analysis', 'audit code quality'.

A100/100content scan

Is the tech-debt-audit skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the tech-debt-audit skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/code-yeongyu/oh-my-openagent.git /tmp/oh-my-openagent
mkdir -p ~/.claude/skills
cp -r /tmp/oh-my-openagent/.agents/skills/tech-debt-audit ~/.claude/skills/tech-debt-audit
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Tech Debt Audit Protocol

Model-agnostic technical debt audit for oh-my-openagent (OMO). Uses OMO's built-in tools (grep, glob, bash with sg, read, lspdiagnostics, task). Produces a grounded, citable TECHDEBT_AUDIT.md artifact.

Output

Write results to TECHDEBTAUDIT.md in the repo root with:

  1. Executive Summary — 3-5 sentences: overall health, worst dimension, quick wins count
  2. Mental Model — the repo's architecture in 1 paragraph (what it does, stack, module boundaries)
  3. Findings Table — columns: ID, Category, File:Line, Severity (Critical/High/Medium/Low), Effort (Hours), Description, Recommendation
  4. Top 5 Priorities — ranked by impact/effort ratio
  5. Quick Wins Checklist — items under 30 minutes each
  6. "Looks Bad But Is Fine" — patterns that look like debt but are intentional
  7. Open Questions — things the maintainer should clarify

Phase 0: Orient

Standard (always run)

  1. glob("/.ts") / glob("/.py") / etc — map the language stack
  2. glob("**/package.json") + read() — dependencies and build tooling
  3. bash("git log --oneline -200") — churn: find highest-change files
  4. glob("/") + basic math — find largest files (>300 LOC are candidates)
  5. Cross-reference high-churn + large = debt hot zones
  6. Write the mental model paragraph in your own working context

Phase 1: Audit Across 9 Dimensions

Use OMO tools for each dimension. Run parallel tool calls within each dimension. Every finding MUST cite file:line:col.

1. Architectural Decay

Standard (always run)

  • bash("sg -p \"import { $$$ } from '$SRC'\" -l ts .") — map module graph, look for circular patterns
  • bash("sg -p \"class $NAME { $$$ }\" -l ts .") — check for god classes
  • grep("TODO|FIXME|HACK|XXX|WORKAROUND|TEMP") — tagged debt markers
  • grep("async|await") on sync-looking files — misplaced async boundaries
  • bash("wc -l ") on each large file found in Phase 0

What to flag

  • Files > 500 LOC (god files)
  • Functions > 80 LOC or > 4 nesting levels
  • Classes with > 15 methods or > 400 LOC
  • Import cycles (A → B → A)
  • Dead exports: function/class defined but never imported elsewhere (confirm with lspfindreferences)
  • Commented-out code blocks (>3 consecutive consecutive lines)

2. Consistency Rot

Standard (always run)

  • bash("sg -p \"import $CLIENT from '$PKG'\" -l ts .") — multiple HTTP clients
  • grep("console.log|console.error|console.warn") — direct console use vs logger
  • bash("sg -p \"try { $$$ } catch ($$$) { $$$ }\" -l ts .") — error handling patterns
  • grep("as any|@ts-ignore|@ts-expect-error|as unknown") — type escapes
  • grep("eslint-disable|prettier-ignore") — lint suppressions

What to flag

  • 3+ ways of doing the same thing (HTTP, logging, validation, config)
  • Mixed naming conventions (camelCase + snake_case + PascalCase)
  • Multiple date/time handling libraries
  • Mixed error response shapes across modules

3. Type & Contract Debt

Standard (always run)

  • bash("sg -p \"$VALUE as any\" -l ts .") — runtime type escapes
  • grep("@ts-expect-error") — suppressed errors
  • grep("@ts-ignore") — suppressed errors (legacy)
  • bash("sg -p \"$NAME: any\" -l ts .") — typed as any
  • lsp_diagnostics(filePath="") — current type errors

What to flag

  • any types on public APIs and exported interfaces
  • Untyped function parameters
  • Missing schema validation at API/IO boundaries
  • LSP type errors grouped by file

4. Test Debt

Standard (always run)

  • glob("/.test.ts") — find all test files
  • bash("bun test 2>&1 | grep -E '(fail|skip|todo)'") — current test health
  • Cross-reference Phase 0 high-churn files with test existence

What to flag

  • Critical-path files with zero tests
  • Skipped tests (test.skip, describe.skip)
  • Tests asserting implementation details vs behavior
  • Slow tests (>1s each)

5. Dependency & Config Debt

Standard (always run)

  • bash("npm audit --omit=dev 2>&1 | head -40") — known CVEs (if node_modules present)
  • read("package.json") — check dependency count and stale deps
  • grep(".env|process.env|Bun.env") — env var usage
  • grep("API_KEY|SECRET|PASSWORD|TOKEN") in non-config files — hardcoded config

What to flag

  • Outdated major-version deps
  • Dependencies that do the same thing (duplicate libraries)
  • Referenced env vars not documented in README
  • Hardcoded environment-specific values

6. Performance & Resource Hygiene

Standard (always run)

  • bash("sg -p \"for ($$$ of $$$) { $$$ await $$$ }\" -l ts .") — async-in-loop
  • grep("await.map|await.filter|await.*forEach") — sequential async iteration
  • grep("Promise\\.all|Promise\\.allSettled") — existing parallel patterns (good signal)
  • grep("addEventListener|on\\(|subscribe") without removeEventListener|off\\(|unsubscribe nearby — listener hygiene

What to flag

  • await inside for/of loops (sequential when parallel possible)
  • N+1 query patterns
  • Missing cleanup on event listeners, intervals, handles
  • Unnecessary serialization/deserialization

7. Error Handling & Observability

Standard (always run)

  • bash("sg -p \"catch ($$$) { $$$ }\" -l ts .") — catch blocks
  • grep("catch.{}|catch.{\\s*}") — empty catch blocks
  • grep("console.error|logger\\.error|log\\.error") — actual error logging
  • bash("sg -p \"throw new $ERR($$$)\" -l ts .") — error types used

What to flag

  • Empty catch blocks (worst offense)
  • Generic catch (e) { console.error(e) } without recovery
  • Inconsistent error shapes across modules
  • Missing structured logging on critical paths
  • Errors swallowed in promise chains (.catch(() => {}))

8. Security Hygiene

Standard (always run)

  • grep("api[Kk]ey|api_secret|password|secret|token|credential") in source files (not config or env)
  • grep("SELECT . FROM|INSERT INTO|UPDATE.SET|DELETE FROM") — SQL construction
  • grep("innerHTML|dangerouslySetInnerHTML") — XSS vectors
  • grep("eval\\(|Function\\(|setTimeout\\(.string|setInterval\\(.string") — code injection

What to flag

  • Hardcoded secrets in source
  • String-concatenated SQL
  • innerHTML / dangerouslySetInnerHTML usage
  • eval() or string-based setTimeout/setInterval
  • Permissive CORS or auth middleware

9. Documentation Drift

Standard (always run)

  • read("README.md") — check if claims match reality
  • grep("@param|@returns|@throws") — docstring coverage
  • grep("FIXME|TODO|HACK|XXX|WORKAROUND") — fixme density
  • Compare README API examples with actual signatures

What to flag

  • README claiming features that don't exist
  • Public functions without any doc comment
  • Comments that contradict the code
  • Stale architecture decision records (ADRs) if present

Phase 2: Deeper Dives (Parallel Sub-Agents)

For large codebases (>50k LOC), delegate heavy dimensions to parallel sub-agents. Each sub-agent runs the standard tool passes for its dimensions:

task(category="unspecified-low", run_in_background=true, load_skills=[], prompt="[CONTEXT] Tech debt audit. [GOAL] Audit dimensions 1 (Architecture) and 2 (Consistency). [REQUEST] Run ast_grep and grep searches for dimensions 1-2 from the tech-debt-audit skill. Report every finding with file:line:col. Tag severity: Critical/High/Medium/Low.")
task(category="unspecified-low", run_in_background=true, load_skills=[], prompt="[CONTEXT] Tech debt audit. [GOAL] Audit dimensions 3 (Type debt) and 7 (Error handling). [REQUEST] Run searches for dimensions 3 and 7 from the tech-debt-audit skill. Report every finding with file:line:col. Tag severity.")

Spawn 2-3 sub-agents for the heaviest dimensions, collect results in parallel, then synthesize.

Phase 3: Synthesize & Deliver

More skills from code-yeongyu/oh-my-openagent

  • Aast-grepSearches and rewrites code by AST shape across 25 languages. Use when the target is a syntax pattern (every call/class/import shaped like X, a codemod, a YAML rule) rather than literal text; for plain strings, comments, or filenames, use rg.
  • AbrowserDrives a real browser through the omowright library from the js eval kernel: sites the user is already signed into, forms and clicks, JS-rendered pages, screenshots, web QA, extension popups, a human handoff for login, CAPTCHA or OTP, and a browser you own for scraping, bot-scored targets, network capture and QA traces. Use for any interactive browser task; not for a plain search or an unblocked static fetch.
  • Acodex-qaQA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.
  • Acoding-agent-sessionsFinds, reads, and reconstructs coding-agent sessions across Codex, Claude, OpenCode, OMO/Senpi, and other local agent logs. Use when asked to find or search past sessions, transcripts, or subagent runs, or to recover what an earlier session did.
  • Acomment-checkerUse when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.
  • Adag-libraryStores a DAG definition once and re-runs it by name, instead of pasting the definition into every run. Use when the user wants to save a DAG, run a saved one, or schedule the same multi-agent graph repeatedly.
  • Ddata-scientistProcesses and analyzes data with resident-kernel engines (DuckDB, Polars) and one-shot tools. Use for CSV/parquet/JSON analysis, group-by/join/aggregation, time series, distributions, cleaning, or plotting a dataset.
  • AdebuggingRuns a hypothesis-driven debugging loop across any language or binary, escalating to orthogonal oracle angles and locking the fix with a failing test. Use for crashes, silent failures, hangs, wrong responses, memory leaks, async misbehavior, or reverse engineering.
  • Adev-browserBrowser automation with persistent page state. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", or any browser interaction request.
  • CfrontendBuilds, styles, and polishes web UI and UX. Use for any frontend, page, component, styling, layout, animation, or visual-quality task, or when asked to make an interface look or feel a certain way.
  • AfrontendBuilds, styles, and polishes web UI and UX. Use for any frontend, page, component, styling, layout, animation, or visual-quality task, or when asked to make an interface look or feel a certain way.
  • Aget-unpublished-changesCompare HEAD with the latest published npm versions and list all unpublished changes by release layer. Triggers: unpublished changes, changelog, what changed, whats new.

All agent skills → · MCP servers