Coherent GitHub profile curation
Curate a profile as a professional decision page: one credible narrative and a small set of proof-bearing projects. A profile review is not permission to edit its README, source list, pins, or GitHub state.
Establish usable evidence
Read the profile README and any maintained profile runbook, supplied public repository inventory, pin state, and portfolio links before selecting work. Treat a repository as eligible only when evidence shows it is public, original, active, and has a verified project or portfolio destination. If a read or link check is unavailable, use only explicit supplied facts and label everything else unverified.
| Do not select by default | Include only when the user explicitly elects it |
|---|---|
| Forks, archived projects, non-public projects, or projects without a verified durable destination. | State the exception and its supplied evidence; never expose non-public details not supplied for the review. |
Do not optimise for stars, streaks, follower counts, or activity graphs. Add a badge or widget only when it directly supports a stated user goal and its target is verified.
Build the narrative
Write one positioning statement that connects the selected work around a credible role, audience, and capability. Choose four to six eligible projects that together substantiate that statement; prefer complementary proof over near-duplicates or popularity. Follow any maintained profile runbook's ordering, source-of-truth, and review requirements.
For every selection, retain concrete supplied evidence and the verified link target. A repository name or plausible URL alone is not sufficient.
Return a reviewable recommendation
Return, in this order:
- Positioning statement: exactly one concise sentence.
- Project selection: four through six projects, each with its narrative role, supplied evidence, and verified destination.
- Proposed profile copy: a concise, review-only README fragment that includes both the opening statement and the selected-project links, so the narrative is visible in the copy itself.
- Boundaries: facts not verified, runbook constraints followed, and that supplied pins remain unchanged unless a pin change was explicitly requested.
Keep the copy professional and specific. When there are fewer than four eligible projects, explain the shortage rather than filling the list with an ineligible project.
Review-only boundary
Unless the user explicitly requests a mutation, do not edit the profile README or its source list, alter pins, stage or commit files, contact GitHub, or make remote changes. Present any pin change as a separate, clearly requested next action.