How do I install the Bootstrap Repo Analysis skill?

Run npx skillmds@latest add tomevault-io/bootstrap-repo-analysis in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Bootstrap Repo Analysis safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Bootstrap Repo Analysis?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Bootstrap Repo Analysis free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Bootstrap Repo Analysis?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Bootstrap Repo Analysis by tomevault-io

Name: Bootstrap Repo Analysis
Author: tomevault-io

Bootstrap Repo Analysis

First-time analysis of a repository with no prior reviewer outcomes. Crawl historical merged-PR review feedback with the gh CLI (plus any preloaded samples), extract the team's review norms, and synthesize the initial per-repo review-style prompt. Use this for a cold-start repo; use continual-learning instead once the reviewer has accumulated finding outcomes. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

Bootstrap repo analysis

You are writing the first review-style prompt for the repository named in the system prompt. There is no outcomes history yet, so your signal comes entirely from the repo's own historical PR review feedback. Do not call read_finding_outcomes in this mode — it will be empty.

Always invoke gh as: GH_TOKEN=dummy gh <command>.

1. Research (required)

Browse historical merged PR review feedback until you have catalogued at least 8 substantive human review comments (skip [bot] accounts and obvious automation like codecov / dependabot). Useful commands:

GH_TOKEN=dummy gh pr list --repo <owner>/<repo> --state merged --limit 30
GH_TOKEN=dummy gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/reviews
GH_TOKEN=dummy gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/comments
GH_TOKEN=dummy gh api repos/<owner>/<repo>/issues/<PR_NUMBER>/comments

If the first batch is sparse, raise --limit or walk older PR numbers. The user message may include preloaded samples — verify and extend them with gh, don't just trust them.

Identify the top ~5 human reviewers by volume and note their phrasing, what severity they assign, and what they routinely ignore.

2. Extract concrete, repo-specific patterns

The highest-value content is a bug taxonomy tied to this repo's stack — concrete "hunt for X" rules a maintainer would catch on first read — plus a calibrated "do not flag" list. Pair each pattern with the failure mode and, where you saw it, the kind of diff that triggered it. Avoid generic advice that would apply to any repo.

Cover:

What the team routinely flags vs. skips (paraphrased patterns, not invented quotes)
Severity calibration tied to user-visible / runtime consequence
Tone and test expectations
Repo-specific conventions (frameworks, repository/data-access boundaries, naming)
Anti-patterns the reviewers here deliberately avoid

Stay aligned with the reviewer-agent themes in the system prompt (high-signal, diff-anchored defects — not nits).

3. Save

Only after real research, call save_review_style_prompt once with:

custom_prompt: 400–1200 words teaching the reviewer this repo's norms.
analysis_summary: 2–4 sentences for the dashboard.
top_reviewers (comma-separated logins), prs_sampled, reviews_sampled.

Do not save a generic guide after one or two commands. Only after ~25+ merged PRs with zero human feedback may you save a short, conservative guide — and say so in analysis_summary.

Source: langchain-ai/open-swe — distributed by TomeVault.

---name: bootstrap-repo-analysisdescription: First-time analysis of a repository with no prior reviewer outcomes. Crawl historical merged-PR review feedback with the gh CLI (plus any preloaded samples), extract the team's review norms, and synthesize the initial per-repo review-style prompt. Use this for a cold-start repo; use continual-learning instead once the reviewer has accumulated finding outcomes. Use when this capability is needed.---# Bootstrap repo analysisYou are writing the **first** review-style prompt for the repository named in thesystem prompt. There is no outcomes history yet, so your signal comes entirely fromthe repo's own historical PR review feedback. Do not call `read_finding_outcomes` inthis mode — it will be empty.Always invoke gh as: `GH_TOKEN=dummy gh <command>`.## 1. Research (required)Browse historical **merged** PR review feedback until you have catalogued at least**8 substantive human** review comments (skip `[bot]` accounts and obvious automationlike codecov / dependabot). Useful commands:```GH_TOKEN=dummy gh pr list --repo <owner>/<repo> --state merged --limit 30GH_TOKEN=dummy gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/reviewsGH_TOKEN=dummy gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/commentsGH_TOKEN=dummy gh api repos/<owner>/<repo>/issues/<PR_NUMBER>/comments```If the first batch is sparse, raise `--limit` or walk older PR numbers. The usermessage may include **preloaded samples** — verify and extend them with `gh`, don'tjust trust them.Identify the top ~5 human reviewers by volume and note their phrasing, what severitythey assign, and what they routinely ignore.## 2. Extract concrete, repo-specific patternsThe highest-value content is a **bug taxonomy tied to this repo's stack** — concrete"hunt for X" rules a maintainer would catch on first read — plus a calibrated "do notflag" list. Pair each pattern with the failure mode and, where you saw it, the kind ofdiff that triggered it. Avoid generic advice that would apply to any repo.Cover:- What the team routinely flags vs. skips (paraphrased patterns, not invented quotes)- Severity calibration tied to user-visible / runtime consequence- Tone and test expectations- Repo-specific conventions (frameworks, repository/data-access boundaries, naming)- Anti-patterns the reviewers here deliberately avoidStay aligned with the reviewer-agent themes in the system prompt (high-signal,diff-anchored defects — not nits).## 3. SaveOnly after real research, call `save_review_style_prompt` once with:- `custom_prompt`: 400–1200 words teaching the reviewer this repo's norms.- `analysis_summary`: 2–4 sentences for the dashboard.- `top_reviewers` (comma-separated logins), `prs_sampled`, `reviews_sampled`.Do **not** save a generic guide after one or two commands. Only after ~25+ merged PRswith zero human feedback may you save a short, conservative guide — and say so in`analysis_summary`.---> Source: [langchain-ai/open-swe](https://github.com/langchain-ai/open-swe) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions