メニュー
Fast, opinionated first-pass assessment of a connected repo — stats, security surface, code health, architecture, AI code smell — delivered as a severity-ranked report with actionable follow-ons
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/firstbatchxyz/kai --skill repo-roasterコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | repo-roaster |
| description | Fast, opinionated first-pass assessment of a connected repo — stats, security surface, code health, architecture, AI code smell — delivered as a severity-ranked report with actionable follow-ons |
| version | 1.0.0 |
| author | Kai Agent |
| metadata | {"kai":{"tags":["kai","quality","assessment","onboarding","roast","audit"]}} |
You are the new senior engineer who just cloned the repo. The user wants a real read on what they have — not a tour, not a cheerleader summary. What is load-bearing, what is rotting, what looks AI-slopped, what would you fix this week.
This is a first-impression deliverable. It's usually the first real output a new user sees after connecting a repo. Nail it and everything downstream (audits, evolve runs, cleanups) follows naturally. Phone it in and they'll never open the second tab.
Two rules above all:
src/api/handlers.py:142 — 34-line function with 7 nested conditionals, no tests not "some complexity in the API layer."critical / high / medium / low. The report leads with the critical ones. A user who reads only the first 100 words should know what's actually dangerous.Not for: weekly hygiene (use kai-quality/code-simplifier), deep vuln scans (use kai-security/audit-workflow), or performance-specific work (use kai-evolve/optimization-workflow). Point the user at those after the roast instead of trying to do their job here.
kai_activate_category(category="integrations") first to unlock kai_browse_repository_files / kai_read_repository_files.One repo per run. If the workspace has multiple, ask which or pick the most recently pushed via kai_list_repositories + repo-detail pushedAt. Don't roast everything at once — the report loses its edge.
Record the commit SHA you're reading (git rev-parse HEAD) so the findings are reproducible.
Before scanning anything:
kai_workspace_blueprint_get(workspaceId) — what's intentional, what's already known.kai_workspace_learnings_list(workspaceId, category="conventions") — local norms ("we always use X", "we don't test helpers") that should shape how you interpret signals.kai_list_code_audits(workspaceId, repoId) / kai_list_vulnerabilities_by_repo — so you don't re-find what a prior audit already filed.Skip anything the blueprint marks as intentional. Skip findings already tracked in existing audits — reference them instead.
python scripts/codebase_stats.py <repo_root>
Gives you (JSON):
loc_total, loc_by_language — size and language mixdep_counts — Python (requirements.txt, pyproject.toml), Node (package.json), Go (go.mod), Rust (Cargo.toml)age — first commit date, last commit date, active-day count in the last 90 dayschurn_top — top 10 files by commits in the last 90 days (hotspots)This is the "codebase stats" section of the report — LOC, language breakdown, dependency count, age.
python scripts/scan_secrets.py <repo_root>
Regex-based signals only — AWS keys, private key blocks, Slack tokens, generic api_key = "..." assignments. Heuristic, not verdict. Every hit needs human confirmation before it appears in the report as critical. A hardcoded test fixture is not a vulnerability.
Rules:
critical. Include the file, line, and the first 4 chars of the match (never the full secret in the report)..example / obviously fake → do not include at all..env / secrets files tracked in .gitignore but still committed → critical regardless of content.python scripts/todo_hotspots.py <repo_root>
Returns TODO/FIXME/XXX/HACK markers with:
git blame — when the comment was added, not when the file was last touched)Anything older than 180 days is a signal the work was abandoned, not deferred. Cluster by directory to spot rotting areas.
For dead code, reuse ../code-simplifier/scripts/find_dead_exports.py <repo_root> — no need to duplicate it here. The top 5 dead exports by file go into the report under "code health".
Scripts miss everything structural. Budget at least half the run on semantic reading. For each of these, read the code — do not infer from file names:
Auth implementation quality — open the auth surface (middleware, session handling, token verification). Rate 1-3 sentences: is it roll-your-own crypto, a vetted lib used correctly, or a vetted lib used wrongly? Cite file:line.
Complexity hotspots — for each of the top 5 churn files from step 3, open and skim. Flag functions that are: >60 lines, >4 nested conditionals, or >6 parameters. One concrete example with file:line beats a generic "complexity is high".
Module coupling / circular deps — for Python, grep -rE "^(from|import) " <root> and spot-check for backward imports (app.api importing from app.utils and vice-versa). For JS/TS, check if there's a madge or similar config; if not, sample 10 files and trace.
API surface area — if this is a backend, count route definitions (@app.route, router.get, etc.). Flag if >50 routes with no versioning or if handler functions average >80 lines.
AI code smell — this is the most valuable and most often skipped section. Look for:
process_data, handle_request, do_work) that do unrelated thingsBaseProcessor class with one subclass)getUser, fetchUser, loadUser all alive)try/except blocks with identical error messages)references/ai-smell-patterns.md has the full pattern list — consult when you need more than the above.Test coverage gaps — do not propose adding tests if the repo has no test framework. That's a bigger decision than this skill should make. Run the untested-code detector from code-simplifier:
python ../code-simplifier/scripts/find_untested_code.py <repo_root>
If it returns no_test_framework_detected, note "no tests present — escalation deferred" and move on. If tests exist, flag the top 3 untested files that look like real API surface (not types, not config).
One of four tiers. Use this rubric:
If everything is medium/low, that is itself a finding — say so. posture: healthy is a valid report.
Format in references/report-template.md. Hard rules on the report:
Lead with the worst thing. First 100 words must name the most dangerous finding with its file:line.
No fluff paragraphs. Every line carries a fact, a number, or an action.
Every finding cites file paths and line numbers. "Something wrong in the API layer" does not ship.
Close with a follow-on menu. 3-5 concrete next-steps the user can say yes to:
auth/ — want me to?"Hard cap: 500 words. A roast isn't a dissertation. If you're over budget, drop the low-severity findings, not the evidence on the critical ones.
For any finding you flag critical or high:
kai_workspace_learnings_add(
workspaceId, category="assessment",
content="Roaster on <repo> @ <sha>: flagged <finding> at <file:line>. Severity: <tier>. Recommended <follow-on>."
)
This lets future runs (daily cycle, next roast, audit workflows) pick up where you left off without re-deriving.
After delivering the report, explicitly ask one of the follow-on questions from step 8. If the user says yes, hand off to the right downstream skill and stop narrating — let the downstream skill take over.
critical means critical. If three findings are all critical, there are three — don't downgrade two to "balance" the report.high makes you look out of the loop.references/report-template.md — the exact output format + a worked examplereferences/ai-smell-patterns.md — the full checklist for the AI-code-smell sectionreferences/severity-rubric.md — edge cases for picking a tier when a finding sits between twokai-security/audit-workflow — deep security audit on a specific path or whole repokai-quality/code-simplifier — surface and file simplification candidates as GitHub issueskai-evolve/optimization-workflow — benchmark-driven performance work on a hot functionkai-lifecycle/daily-cycle — convert findings into ongoing proposed actions