review-context-hub
Skill2 starsChanged 5 months agoMITView on GitHub
Review a repo as a context hub. Use when the user wants an overview of the repo structure, recent changes, standing instruction files, installed skills, remotes, or who has access.
In this repository9 other files it gives its agents.
- automation-hitlistSkill
- build-websiteSkill
- call-external-aiSkill
- create-locked-down-skillSkill
- deploy-websiteSkill
- extract-scriptsSkill
- plan-websiteSkill
- pr-review-panelSkill
- retroSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
check remotes, ownership, or access
- Distinctive: line 36
If the user is really asking for implementation, debugging, or code review, do not use this as the primary skill.
- Distinctive: line 92
Check for skill directories such as:
- Distinctive: line 118
If the GitHub CLI is available and authenticated, try to determine:
- Distinctive: line 124
If you cannot verify access directly, say so clearly and infer only from remotes, org ownership, and visibility.
- Distinctive: line 128
Default to a short structured review:
- Distinctive: line 142
Suggested next checks: if useful
- Distinctive: line 147
Prefer orientation over exhaustiveness
- Distinctive: line 149
Call out uncertainty clearly
- Distinctive: line 150
Do not assume GitHub access if you cannot verify it
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review Context Hub
Review a repository as a context hub.
This skill is for understanding the what that lives in a repo:
- the outline of the repo
- recent changes
- standing instruction files
- installed skills
- git remotes
- who has access
Your job is not to make changes by default. Your job is to produce a useful orientation pass.
When to Use
Activate this skill when the user asks to:
- review a context hub
- inspect a repo before doing work
- explain what context an AI would pick up from this repo
- show what instruction files or skills are present
- check remotes, ownership, or access
If the user is really asking for implementation, debugging, or code review, do not use this as the primary skill.
Core Mental Model
- The context hub is about what
- Skills are about how
This skill reviews the what:
- what the repo contains
- what recent work happened
- what standing instructions exist
- what reusable skills are available
- what remotes and access boundaries exist
Review Pass
Work from the repo root.
1. Outline the repo
Get a quick sense of the top-level structure.
Look for:
- main folders
- docs or notes areas
- workflow output folders
- instruction/config folders
Summarize the structure in plain language. Do not dump giant file listings unless the user asks.
2. Review recent changes
Inspect recent git history and current worktree state.
Look for:
- current branch
- uncommitted changes
- recent commits
- whether the repo looks actively used or stale
3. Review standing instruction files
Check for:
CLAUDE.mdAGENTS.mdGEMINI.md- nested variants if relevant
Explain what each one appears to govern.
4. Review installed skills
Check for skill directories such as:
.claude/skills/.agents/skills/(shared by Codex and Gemini CLI).gemini/skills/
Give a high-level overview:
- which skill systems are present
- what kinds of skills exist
- whether the repo appears to rely on local/project skills
You do not need to read every skill in full. Prefer names, descriptions, and obvious categories first.
5. Review remotes and ownership
Inspect git remotes.
Explain:
- where the repo is hosted
- whether it appears personal or organizational
- what that suggests about who owns the hub
6. Review access
If the GitHub CLI is available and authenticated, try to determine:
- whether the repo is public or private
- who the owner is
- who has collaborator/admin access, if that can be checked safely
If you cannot verify access directly, say so clearly and infer only from remotes, org ownership, and visibility.
Output Format
Default to a short structured review:
Context Hub Review
- Repo outline: ...
- Recent changes: ...
- Instruction files: ...
- Skills present: ...
- Git remotes: ...
- Access/ownership: ...
- What this hub seems optimized for: ...
Then add:
- Gaps / risks
- Suggested next checks if useful
Good Behavior
- Be concise
- Prefer orientation over exhaustiveness
- Separate verified facts from inference
- Call out uncertainty clearly
- Do not assume GitHub access if you cannot verify it
Useful Commands
See reference/checklist.md for a lightweight command checklist.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.