Source profileQuality 86/100

code-yeongyu/oh-my-openagent/.agents/skills/tech-debt-audit/SKILL.md

tech-debt-audit

Thorough, file-cited technical debt audit across 9 dimensions using AST-grep (tree-sitter), grep, language-native tooling, and optionally CodeGraph knowledge graph. 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

Source repository stars
67,195
Declared platforms
0
Static risk flags
0
Last source update
2026-08-04
Source checked
2026-08-04

Decision brief

What it does—and where it fits

Model-agnostic technical debt audit for oh-my-openagent (OMO). Uses OMO's built-in tools (grep, glob, bash with sg, read, lspdiagnostics, task) plus optional CodeGraph MCP for enhanced code graph analysis when available. Produces a grounded, citable TECHDEBTAUDIT.md artifact.

Best for

  • Use when asked for codebase health check, tech debt audit, architecture review, code quality assessment, or cleanup planning.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/code-yeongyu/oh-my-openagent --skill ".agents/skills/tech-debt-audit"
Safe inspection promptEditorial

Inspect the Agent Skill "tech-debt-audit" from https://github.com/code-yeongyu/oh-my-openagent/blob/9cee074da29e2b17d709db35449c4f9c04cdc1bd/.agents/skills/tech-debt-audit/SKILL.md at commit 9cee074da29e2b17d709db35449c4f9c04cdc1bd. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Phase 0: Orient

    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-…

    glob("/.ts") / glob("/.py") / etc — map the language stackglob("/package.json") + read() — dependencies and build toolingbash("git log --oneline -200") — churn: find highest-change files
  2. 02

    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.

    bash("sg -p \"import { $$$ } from '$SRC'\" -l ts .") — map module graph, look for circular patternsbash("sg -p \"class $NAME { $$$ }\" -l ts .") — check for god classesgrep("TODO|FIXME|HACK|XXX|WORKAROUND|TEMP") — tagged debt markers
  3. 03

    Phase 2: Deeper Dives (Parallel Sub-Agents)

    For large codebases (50k LOC), delegate heavy dimensions to parallel sub-agents. Sub-agents CANNOT use CodeGraph — they use standard tools only:

    For large codebases (50k LOC), delegate heavy dimensions to parallel sub-agents. Sub-agents CANNOT use CodeGraph — they use standard tools only:Spawn 2-3 sub-agents for the heaviest dimensions, collect results in parallel, then synthesize. The main agent handles CodeGraph queries itself while sub-agents run the standard tool passes.
  4. 04

    Phase 3: Synthesize & Deliver

    1. Collect all findings from direct tool calls, CodeGraph queries (if available), and sub-agent results 2. Deduplicate — same issue mentioned by multiple dimensions 3. Classify severity: - Critical — Causes incorrect behavior, data loss, or security vulnerability - High — Will c…

    Collect all findings from direct tool calls, CodeGraph queries (if available), and sub-agent resultsDeduplicate — same issue mentioned by multiple dimensionsClassify severity:
  5. 05

    CodeGraph Enhancement (Optional)

    If you have CodeGraph installed (check with codegraph status), its MCP tools (codegraphsearch, codegraphcallers, codegraphcallees, codegraphimpact, codegraphexplore, etc.) can supersede or augment the standard tool searches in the dimensions marked below. CodeGraph gives you: -…

    Symbol search — instant by-name lookup via FTS5Call graph analysis — callers/callees for any functionImpact analysis — blast radius before changing any symbol

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score86/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars67,195SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
code-yeongyu/oh-my-openagent
Skill path
.agents/skills/tech-debt-audit/SKILL.md
Commit
9cee074da29e2b17d709db35449c4f9c04cdc1bd
License
NOASSERTION
Collected
2026-08-04
Default branch
dev
View the original SKILL.md

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, lsp_diagnostics, task) plus optional CodeGraph MCP for enhanced code graph analysis when available. Produces a grounded, citable TECH_DEBT_AUDIT.md artifact.

CodeGraph Enhancement (Optional)

If you have CodeGraph installed (check with codegraph status), its MCP tools (codegraph_search, codegraph_callers, codegraph_callees, codegraph_impact, codegraph_explore, etc.) can supersede or augment the standard tool searches in the dimensions marked below. CodeGraph gives you:

  • Symbol search — instant by-name lookup via FTS5
  • Call graph analysis — callers/callees for any function
  • Impact analysis — blast radius before changing any symbol
  • Smart context building — entry points, related symbols, and snippets in one call
  • Framework-aware routes — URL patterns linked to their handlers

To use CodeGraph, ensure the codegraph MCP server is configured in your project's .mcp.json or global MCP config. The skill will auto-detect CodeGraph by checking if codegraph MCP tools are available. Sub-agents spawned via task() cannot use CodeGraph — they use the standard tool fallback.


Output

Write results to TECH_DEBT_AUDIT.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

CodeGraph Enhancement (if available)

Instead of guessing module boundaries, query the code graph:

codegraph_explore(query="architecture overview and main modules")

This returns symbol relationships and source grouped by file. Use the structure as your architectural mental model instead of hand-inferring it from directory names.

codegraph_explore(query="main entry points and execution flow")

This surfaces entry points and call chains. Use these to understand how the code actually flows vs how the directory layout suggests it flows.

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 <file>") on each large file found in Phase 0

CodeGraph Enhancement (if available)

Dead code detection:

codegraph_callers(symbol="<suspected-dead-function>")
codegraph_callers(symbol="<suspected-dead-class>")

Run codegraph_callers on suspected dead exports found via grep/glob. If the result shows zero callers (excluding test files), it's dead code.

Circular dependency detection:

codegraph_impact(target="<module-or-file>", direction="upstream")

Use codegraph_impact on key modules to trace their dependents. If A depends on B and B depends on A, that's a cycle.

Architecture boundaries:

codegraph_explore(query="module dependencies and architecture boundaries")

Use codegraph_explore to survey actual module structure.

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 (CodeGraph: codegraph_callers)
  • 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="<src-dir>") — 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

CodeGraph Enhancement (if available)

Blast radius of core dependencies:

codegraph_impact(target="<core-utility-function>", direction="upstream")

Run this on a few key internal modules (logger, config loader, HTTP client) to see how widely they're used. A widely-depended-on module with poor error handling or type safety is a high-priority refactor target because changes to it ripple everywhere.

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

CodeGraph Enhancement (if available)

Trace error propagation through call chains:

codegraph_callers(symbol="<key-error-handler-or-middleware>")
codegraph_explore(query="how errors propagate through <key-error-handler>")

Use codegraph_callers to find who calls your error handlers. If errors are caught and swallowed at multiple levels, that's a finding.

Impact of changing error types:

codegraph_impact(target="<error-class-or-interface>", direction="upstream")

Check the blast radius of custom error classes. If changing an error type would break 20+ consumers, the error contract is too tight.

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. Sub-agents CANNOT use CodeGraph — they use standard tools only:

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. The main agent handles CodeGraph queries itself while sub-agents run the standard tool passes.

Phase 3: Synthesize & Deliver

  1. Collect all findings from direct tool calls, CodeGraph queries (if available), and sub-agent results
  2. Deduplicate — same issue mentioned by multiple dimensions
  3. Classify severity:
    • Critical — Causes incorrect behavior, data loss, or security vulnerability
    • High — Will cause problems in production; blocks maintenance
    • Medium — Reduces maintainability; violates conventions
    • Low — Cosmetic; should fix when in the area
  4. Estimate effort in hours per finding (conservative)
  5. Write TECH_DEBT_AUDIT.md with all required sections
  6. Report summary to the user

Severity Rubric

Critical = actively causing bugs or security holes
High     = will cause problems under normal operation; blocks changes
Medium   = reduces maintainability; inconsistent; violates team conventions
Low      = cosmetic; would be nice to fix when nearby

Quick Checks Before Finishing

  • Every concrete finding has file:line:col citation
  • No generic claims without evidence
  • "Looks Bad But Is Fine" section explains at least 2-3 patterns
  • Top 5 priorities ranked by impact/effort
  • Quick wins are things that can be fixed in <30 minutes each

Alternatives

Compare before choosing

Computed 10042,968

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 10023,781

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 100165

JasonColapietro/suede-creator-skills

suede-ab-testing

Suede-owned experimentation discipline for hypotheses, sample sizing, test duration, significance, and repeatable experiment programs. Use when comparing variants, deciding whether a result is reliable, or building an experiment backlog and cadence. NOT FOR: analytics instrumentation (use suede-analytics), post-click conversion diagnosis (use suede-site-alchemy), or writing the variant copy itself (use suede-copy).

Computed 1007

narrative-io/narrative-skills-marketplace

design-analysis

Translate a fuzzy analytical question into a rigorous investigation plan. Interrogates the ask, grounds the plan in the available data dictionary, applies analytical best practices, and produces a structured brief of query specifications for a downstream query-writing skill. Plans, does not write SQL. Use when: "why did X drop", "is there a relationship between A and B", "who are our highest-value customers", "what's driving the change in Y", "investigate this trend", "design an analysis for", "