메뉴
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.