How to Show GitHub, Projects, and AI Tools on a Resume Without Looking Fake

The two audiences who will open your links

Recruiters click to see if the URL works and if the repo is empty. Engineers click to see if you thought. Those are different tests. A GitHub with your name, a pinned project, a README that runs, and recent commits passes the first. A repo with tests, an issue you closed, and a note about a failure passes the second. A green-square generator, a fork with no commits, or a “My-AI-Startup” org with one HTML file fails both. Put the URL in the MineResume header as a real link. Test it on a phone after export. Dead GitHub links are a joke that hiring managers have already heard.

If your best work is private, say so and describe the stack and your role. Do not paste secrets. Do not screenshot internal dashboards with customer names. A private repo you cannot share is still worth a bullet. A public repo of leaked company code is how you lose the offer and maybe more than the offer.

What a README has to do

Assume the reader will not run the project. The README should say what it is, who it is for, how to run it, what you would do next, and one thing that is still wrong. Screenshots help for UI. For data work, show a chart and the question it answers. For infra, show the diagram and the apply steps. If the README is a dumped homework prompt, it reads as homework. Rewrite it in your voice. Typos are human. Empty adjectives are not.

Commit messages do not need to be poetry. They should not all be “update” on one night. A week of work with messages that mention the bug you fixed looks like work. If you used Copilot for boilerplate, that is fine. The commits should still show you changing the design. A single paste of 4,000 lines titled “complete project” looks like a dump, because it usually is.

AI tools: mention them as tools, not as identity

Everyone uses a chatbot now. Listing “ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity” in Skills is like listing “Google.” It does not differentiate you. It sometimes hurts you, because it suggests you think the tool is the skill. Mention AI tools inside bullets when they changed how you worked: “Used Copilot for boilerplate tests; I still wrote the cases that caught the off-by-one in tax rounding.” Or: “Drafted a first-pass regex with a model, then verified on 200 sample rows.” That is adult. “Prompt engineer, 10x with AI” in the summary is how you get a smirk on the call.

If you are applying to a GenAI role, the model is the subject of the work, not a side tool. Then you do name APIs, eval, retrieval. That is a different resume. Use the GenAI guide for that. Do not mix the two. A marketing intern who used ChatGPT to write captions is not an AI engineer. A backend engineer who added a retrieval endpoint is not a researcher. Say the smaller true thing.

Course projects versus original work

Course projects are allowed. Label them. “Capstone: …” is honest. Copying a YouTube clone and deleting the comments is not original and interviewers have seen that repo. Change the domain, add a test, add a failure mode, write the README in your words. If you followed a tutorial, the next commit should be you breaking it on purpose and fixing it. That commit is the one you talk about.

Group class labs. You do not need ten similar CRUD apps. Pick the two that taught you something different. The rest clutter GitHub and make the pinned section look like a dump of a semester, which is exactly what it is.

Portfolios besides GitHub

Designers need images. Writers need links. Analysts can use a public notebook or a PDF of a study with sources. PMs can link a spec if it is not confidential. Teachers switching into L&D can show a lesson. Put one URL in the header, not five. The resume is not a link tree. If you need more, one “Portfolio” line is enough.

Custom domains are nice and also a place to go stale. A GitHub Pages site updated three years ago is worse than no site. Either maintain it or take it off. Stale is a signal that you start things. Hiring is about finishing the next thing.

What not to publish

Credentials, API keys, customer data, unreleased product names your NDA covers, hate speech in old commits, and assignment solutions that your university still uses. Clean the git history if you accidentally committed a key. Assume somebody will look. Because somebody will, especially if you apply to security or finance.

Also think about tone. A README that insults your professor or your last employer is a gift to a cautious recruiter: they can reject you without a conversation. Be blunt about technical tradeoffs. Be dull about people.

Putting it on the MineResume page

Header link. Project section with name, stack, two bullets, and optionally “GitHub: repo-name.” Do not make the whole resume a list of repos. Jobs still come first if you have jobs. Projects come first if you do not. After export, tap the link. If it 404s because of a typo, you just failed a test you wrote for yourself.

Once a quarter, unpin the dead stuff. The current market — especially for juniors competing with AI-generated portfolios — rewards a small amount of real work. One ugly repo you understand will beat a beautiful generated dashboard you cannot modify live. If you cannot modify it live, it is not yours. Do not put it on the page. Build something smaller that is yours. Then write the bullet like a human who was in the room when it broke.

A pre-apply GitHub checklist

Profile name matches the resume. Email in git config is not a joke you would not say in an interview. README on the pinned repo has a run section you followed last week. No keys in the tree. .gitignore actually ignores node_modules. License if you care; it is optional for a job hunt. Description line on the repo is a sentence, not “my project.” Topics tags can include the stack so GitHub search works. Then stop decorating.

If you have old offensive jokes in commits from school, you can still get hired, but a bank might not enjoy them. You can leave the history and grow up in new commits, or start a new repo for work you want associated with your name. Do not rewrite history on a team repo. Do rewrite your own homework repo if it is only yours and it contains a password.

Pair programming with a model, honestly

Using Copilot or ChatGPT while you work is normal in 2026. Interviewers may forbid it in a screen. Practice both: with the tool and without. If you cannot write a loop without a model, you are not ready for a lot of junior screens. The resume should not advertise that dependency. It should advertise systems you finished. If they ask how you use AI, tell the truth: boilerplate, rubber-duck, first drafts of regex, then you test. That answer is hireable. “I ship whatever the model writes” is how you get walked out of a take-home.

Do not paste a confidential spec into a public model. Companies have started asking about this. A sentence on the resume like “redacted prompts; no customer data in third-party tools” is oddly impressive for intern-level people because so few think of it. If you did not do that, do not write it. Start doing it, then write it.

When not to link GitHub

If the profile is empty, do not link it. If it is full of unfinished clones, do not link it until you pin one finished thing. An empty link is worse than no link. You can still get an analyst job with a SQL file attached as a gist or a PDF appendix if the posting allows. GitHub is a convention for software. It is not a moral requirement for every in-demand job. Teachers, nurses, and BAs should not panic-create a fake repo. Panic repos look like panic repos.

If you are a developer and you refuse to put any code public, be ready to talk about why, and offer a take-home. Some people have good reasons. “I do not have time to make a README” is not a good reason. Make the README. It is the cover letter of the repo. The resume points at it. Together they should sound like one person who finishes things.

One more pass before you apply: clone your own repo on a fresh folder and follow the README cold. If you cannot get it running, a stranger cannot either. Fix the steps, commit the fix, then export the PDF. That hour saves you from a silent rejection by an engineer who tried to be generous and then ran out of time. Generosity is limited. Make it easy to be kind to you.