Training · learner work
Your Repositories Already Wrote Your Resume
A developer's GitHub history is already proof of what they can do, and almost nobody can read it. A learner built Repo2Reputation to read the repositories through a six-phase pipeline and write the portfolio, deciding the role in code before the language model is allowed an opinion.
verified
All student projects- Organisation
- Colaberry
- Industry
- Career services and technical hiring
- Capability
- Repository grounded portfolio generation
- Status
- Shipped
- Built by
- Learner
- Published
- 2026-09-18
The situation
A GitHub profile is evidence of capability that almost nobody reads as evidence. The commits are there, the architecture decisions are there, the migrations and the error handling are there. What a recruiter sees in thirty seconds is a list of repository names and a coloured language bar.
The gap is not effort, it is translation. Describing accurately what a body of code demonstrates is a different skill from writing the code, and it is the one early-career developers are least equipped for and least confident about. Portfolio tools mostly respond by handing the developer an empty text box, which asks them to supply the exact thing they came without.
Repo2Reputation takes the other route: it reads the repositories and writes the description itself, so the developer edits a draft grounded in their own code instead of facing a blank field.
What it had to do
- Turn a selected set of repositories into a publishable portfolio, with headline, summary and project descriptions, with no manual writing required of the developer.
- Keep the downloadable PDF resume and the public portfolio page stating the same headline and the same summary.
- Let a recruiter search published portfolios by skill and domain rather than by repository name.
What constrained it
- The developer should not have to write the narrative. A tool that opens with an empty text box has returned the problem to the person who could not solve it.
- Generated claims have to follow from the repositories actually analysed, not from what a language model assumes a project of this shape usually contains.
- Private repositories have to be analysable without their contents reaching a public portfolio page.
- One person's work is often split across more than one GitHub account, and the portfolio has to treat the union as a single body of work.
Decisions that made the difference
Three choices shaped the system. Each one lives at a specific point in the drawing above.
- At Role decided in code
Decide the role in code before the model is asked
A language model asked to describe a body of code assumes what a project of this shape usually contains, and the developer least able to write the narrative is least able to correct it.
Framework detection reads the analysed technologies. When a frontend framework, a backend framework and a database are all present, a mandatory override is written into the prompt, labelled as outranking the model's own role signals. The model phrases the finding; it does not determine it.
Evidence Architecture narrative; roadmap: generated headline, summary and project descriptions, shipped; timeline, 27 August: role resolution tightened.
250words is the ceiling on a narrative that has to follow from the repositories actually analysed: repository names scrubbed, first-person substitutes forbidden, the phrasings that read as generated banned.
- At Six-phase analysis
Fail per unit, not per run
A slow or failing analysis must not block the page the developer is working in, and one failing agent must not cost the whole analysis.
Two subsystems: a background pipeline and a portfolio generator that reads its stored output. Each of the six phases stores its own status and its own error; inside the fifth, each of the eight agents runs through a wrapper that catches, records the agent by name and returns null.
Evidence Architecture narrative; roadmap: six-phase analysis pipeline with per-phase retry, shipped.
6phases, each retried on its own with completed output preserved, and an analysis that carries a first-class partial state: one failing agent costs one section of the portfolio.
- At Portfolio and PDF that agree
Make the PDF and the portfolio say the same thing
The downloadable resume recomputed its own headline and summary, so the PDF and the public page could describe the same person differently.
The final four commits stop the resume recomputing and make the PDF take its headline and summary from the same generated profile as the page.
Evidence Timeline, 7 September: the PDF and the portfolio are made to agree; roadmap: public portfolio URL and matching PDF resume, shipped.
7 Sepwas the day the two stopped disagreeing: a recruiter reads one headline and one summary whether they open the page or the PDF.
Who built it
- Learner: full-stack build, the six-phase analysis pipeline and the portfolio generator
The build
- Repository created
- First commit: GitHub search against a repository list
- Resume PDF rendering reaches a fixed executive layout
- One person, more than one GitHub account
- GitHub App connection and LinkedIn PDF import
- Repositories import and analyse without being asked
- Jupyter notebook analysis and private account connect
- Portfolio accuracy work and README media detection
- Any resume PDF becomes portfolio content
- The PDF and the portfolio are made to agree
Notes on 9 of the 10 steps
- First commit: GitHub search against a repository list. The build starts as a frontend that can search GitHub. Nothing is analysed yet.
- Resume PDF rendering reaches a fixed executive layout. Typography and page margins pinned so a Puppeteer render does not reflow: 32pt name, 13pt section titles, a three-sentence summary, and a corrected role map.
- One person, more than one GitHub account. Repositories from several connected accounts are treated as a single body of work.
- GitHub App connection and LinkedIn PDF import. Private accounts connect over OAuth; a LinkedIn PDF fills name, headline, location, experience, education and skills.
- Repositories import and analyse without being asked. On first login the top ten non-fork repositories import and queue for analysis, so the first thing the developer sees is a populated draft rather than an empty page.
- Jupyter notebook analysis and private account connect. Notebook repositories become analysable, which matters for data work that lives in .ipynb rather than in application code.
- Portfolio accuracy work and README media detection. Role resolution tightened, repositories auto-selected, and project images pulled from each repository README so a project card carries a picture of the project.
- Any resume PDF becomes portfolio content. Summary, experience and skills extract from an arbitrary resume PDF, not only a LinkedIn export.
- The PDF and the portfolio are made to agree. The final commits stop the downloadable resume recomputing its own headline and summary and make it read the same generated profile the public portfolio displays.
What was built
Two subsystems. A background pipeline analyses each imported repository across six phases, and a portfolio generator reads that stored analysis and produces the written portfolio. They are separated so a slow or failing analysis cannot block the page the developer is working in.
Stack
- JavaScript
- React
- Vite
- Express
- Tailwind CSS
- HTML
- CSS
More on what was built
The load-bearing design decision is that the role is decided in code, before the language model is asked. Framework detection reads the analysed technologies, and if a frontend framework, a backend framework and a database are all present the system writes a mandatory override into the prompt, labelled as outranking the model's own role signals. The model is used to phrase the finding, not to determine it. The same prompt caps the narrative at 250 words, forbids first-person substitutes, scrubs repository names, and bans a list of phrasings that made earlier output read as generated.
Failure is handled per unit rather than per run. Each of the six phases stores its own status and its own error, so a phase that fails can be retried on its own while completed phase output is preserved, and the analysis carries a first-class partial state. Inside the fifth phase each of the eight agents runs through a wrapper that catches, records the agent by name, and returns null, so one failing agent costs one section of the portfolio rather than the whole analysis.
Capabilities
- Repository grounded narrative generation
- Deterministic role resolution before inference
- Per phase retry and partial completion
- Failure isolated agent execution
- Multi account GitHub aggregation
- Linkedin and resume pdf extraction
Integrations
- GitHub API
- GitHub oauth
- OpenAI
- Puppeteer
Data stores
- PostgreSQL
The measurement
This record carries no figures, and that is deliberate.
What could be counted here is the system’s own construction: its phases, its agents, its endpoints, its migrations. Those describe how it was assembled. They do not tell a reader whether a developer got a portfolio worth reading, whether anybody recognised themselves in it, or whether it changed a hiring conversation.
Nothing here is measured from usage either. The system has no public deployment, so there is no traffic, no adoption and no outcome data to report, and none is claimed. Until there is a reader on the other end whose result can be measured, this record stands on what it describes and shows.
What happened next
Shipped
- Six-phase analysis pipeline with per-phase retry
- Generated headline, summary and project descriptions
- Public portfolio URL and matching PDF resume
- Multi-account GitHub aggregation and LinkedIn or resume PDF import
Not pursued
- Automated test coverage of the backend
- Public deployment
Notes on 6 of the 6 items
- Six-phase analysis pipeline with per-phase retry. Six phases, each storing its own status and error; failed phases retry individually and completed output is preserved.
- Generated headline, summary and project descriptions. Role resolved from detected frameworks in code and injected as a mandatory override above the model's own role signals.
- Public portfolio URL and matching PDF resume. The final four commits exist specifically to make the PDF take its headline and summary from the same generated profile the portfolio displays rather than recomputing them.
- Multi-account GitHub aggregation and LinkedIn or resume PDF import. Additional public and private accounts connect through OAuth; imported profile data fills name, headline, location, experience, education, certifications and skills.
- Automated test coverage of the backend. No test file exists under backend/. The repository records this in its own Known Limitations table.
- Public deployment. There is no public deployment at the pinned commit. The two repo2reputation.com hosts named in the README are illustrative; neither resolved when checked on 2026-09-08. The system runs locally against a local PostgreSQL instance.
Meet the builder
Learner, full-stack builder
Project contribution
Built the full stack of Repo2Reputation: the background pipeline that analyses each imported repository across six phases with eight agents, the portfolio generator that writes the headline, summary and project descriptions from the stored analysis, the GitHub App connection with multi-account aggregation, the LinkedIn or resume PDF import, and the public portfolio URL with a PDF resume that says the same thing.
Skills demonstrated
- Pipeline designSix phases, each storing its own status and error, so a failed phase retries alone with completed output preserved (architecture narrative; roadmap, shipped).
- Prompt governanceThe role is decided in code and injected as a mandatory override above the model's own role signals; the narrative is capped at 250 words, repository names scrubbed, generated-sounding phrasings banned.
- Failure containmentEach of the eight agents in the fifth phase runs through a wrapper that catches, records the agent by name and returns null, so one failing agent costs one section, not the analysis.
- Identity across accountsRepositories from several connected GitHub accounts, public and private over OAuth, are treated as one body of work (timeline, 20 and 28 June).
- ConsistencyThe final commits make the PDF resume take its headline and summary from the same generated profile as the portfolio page (timeline, 7 September).
From the repository record.
What this project shows
This record shows a learner deciding where a language model may and may not have an opinion: the role is settled in code, the narrative is grounded in the repositories analysed, and failure is contained to the unit that failed. It carries no figures, deliberately. The system has no public deployment at the pinned commit, so whether a developer got a portfolio worth reading or a hiring conversation changed is not measured and not claimed.
Keep reading
Build one of these