メニュー
Use when auditing a software repository for beginner-level best-practice violations, repo health, Git history hygiene, issue and PR usage, branch discipline, tests, docs, coding style, CI, security basics, or maintainability signals.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a pull request on the current branch has review comments, failing CI checks, or coverage gaps to address — guides a triaged cleanup pass that fixes feedback in priority order without bundling unrelated changes.
Use when you have a GitHub issue and want to open a PR carrying an implementation plan — guides fetching the issue, brainstorming an approach with the user, writing a plan file, and pushing a plan-only PR ready for implementation (manual or automated).
Use when setting up or writing a research documentation/report site — scaffolds a fresh site (Makefile, build script, GitHub Pages workflow, HTML templates) or refreshes templates in an existing setup. Output is a single-page index with download cards, rendered markdown prose, and PDF viewers, all sharing the same neutral-academic stylesheet (ink + terracotta on warm paper). The build pipeline is a single Python script driven by a doc registry; the visual identity is fixed; the contents are yours.
Use when a code change is finished but not yet committed — dispatches a fresh-context subagent to review the diff for design principles (DRY/KISS/HC-LC), test quality, and (where applicable) public-API ergonomics, then consolidates findings and applies the clear fixes automatically.
Use when building a scroll-snapped, two-column slide deck in a neutral-academic house style — research-style and formal — for research talks, project briefings, group-meeting decks, anywhere a one-figure-plus-commentary rhythm beats bulleted Keynote slides. Forces a two-phase workflow — agree on the logic flow first, then design each page — so the deck has a thesis before it has visuals. The output is a single self-contained HTML file (CSS, JS, fonts via CDN) with arrow-key navigation, page indicators, and a section component library (masthead, spec list, stats grid, data table, conclusion 2x2, voice-quote wall, tool stack, key-links). The visual identity is fixed; the contents are yours.
Use when given a topic and a list of sources (URLs, arxiv IDs, DOIs, PDFs, local notes) and asked to collect what each source says about the topic and synthesize them into a single cited report. Drives a three-pass workflow — per-source extraction, cross-source synthesis, structured write-up — and grounds every claim in a specific source.
| name | repo-hygiene-audit |
| description | Use when auditing a software repository for beginner-level best-practice violations, repo health, Git history hygiene, issue and PR usage, branch discipline, tests, docs, coding style, CI, security basics, or maintainability signals. |
Audit a repository as a beginner-friendly scorecard. Ground every judgment in visible evidence, and give concrete next steps instead of vague advice.
Use these references as needed:
references/scorecard-rubric.md: default checks and severity rules.references/git-history-audit.md: commit, branch, issue, and PR checks.Prefer read-only commands:
pwd
find . -maxdepth 3 -type f | sort | head -200
git status --short
git branch -a -vv
git log --oneline --decorate --all -n 120
git remote -v
find .github -maxdepth 3 -type f | sort
If GitHub CLI is configured, optionally enrich the local evidence:
gh pr list --state all --limit 30 --json number,title,state,headRefName,baseRefName,mergedAt,closedAt,author
gh issue list --state all --limit 30 --json number,title,state,labels,createdAt,closedAt,author
Do not rewrite history, delete branches, push, create issues, or edit files unless the user explicitly asks for remediation.
Start with a compact summary:
Overall: Warn
Best signals: ...
Highest-risk gaps: ...
Recommended first fixes: ...
Then provide a scorecard:
| Area | Status | Evidence | Why it matters | Next step |
|---|---|---|---|---|
| README | Pass | README.md has setup and examples | New users can start | Keep current |
Use statuses exactly:
Pass: visible evidence meets beginner expectations.Warn: usable, but confusing, incomplete, stale, or inconsistent.Fail: missing or likely to block contributors.Not visible: cannot be assessed from local evidence.End with a short prioritized fix list. Keep it practical and ordered by value.
Do not over-penalize small or early repos. A beginner repo can still pass if it has clear setup, tests, and review flow.
Use Fail for gaps that block basic collaboration:
Use Warn for teachable inconsistencies:
update.