Graduation day: fluency, not driving lessons
Five sessions ago a GitHub link was a foreign country. Now you own a repo, run a task board, review proposals, and publish a live website. What is left is the fluency layer: the green checks that appear on commits and pull requests, the health read that tells you whether a repo deserves your trust, and the vocabulary developers actually use in meetings. None of it requires writing anything - it requires knowing how to read.
The green checks: Actions at literacy level 5 min live
GitHub Actions are robots that run when something happens: a merge, a schedule, a pull request opening. Each robot runs its checklist and reports back as the little icons you have already seen on commits and PRs - the green check, the red X, the yellow dot. You never need to build a robot. You need to read its verdict.
LiveReading the robot's verdict3 min▶
- Green check ✓ next to a commit or on a PR: every automated check passed. For a non-dev this reads as "safe to merge" - the robots found nothing wrong.
- Red X ✗: at least one check failed. Not a catastrophe - it means "ask before merging". Someone who understands that check decides whether it matters.
- Yellow dot ●: the robot is still running. Wait; it turns into a check or an X within minutes.
- Robots run on events: a merge landing, a PR opening, a fixed schedule. That is why the checks appear by themselves - nobody is pressing a button.
Self-studyThe Marketplace: robots you install without writing anything2 min read▶
The GitHub Marketplace is an app store for robots. Thousands of ready-made Actions install with clicks, not code:
- Spell-checkers that flag typos in every proposed change to your handbook.
- Link-checkers that test every hyperlink on a schedule and open an issue when one dies.
- Greeters that welcome first-time contributors with a friendly comment.
Installing means committing a small config file GitHub writes for you - you click the green Commit button, exactly like editing any other file. Writing new robots (the YAML inside) is tech-track territory, and you never need it to benefit from them.
Reading a repo like a pro 5 min live
Professionals do not read a repo's code first - they read its vital signs. Six stops, 90 seconds, and you know whether a project is alive, maintained, and legal to use. This is data literacy applied to software: these are health metrics for tools your team might adopt.
LiveThe six stops, and what each one tells you3 min▶
- README: does it say what this is and how to start, above the fold? A repo that cannot introduce itself will not document anything else either.
- Last commit date: is it alive? Activity in the last six months is the pulse check that outweighs everything else.
- Issues: are recent questions answered or ignored? Responsive maintainers are the difference between a tool and a liability.
- Releases: named, dated versions signal a project that ships deliberately rather than drifting.
- License: no license file means you technically cannot reuse it at work. A 30-second check that saves legal headaches.
- Stars, in context: 1,000+ means a community trusts it - but a 50-star niche tool can be perfect for a niche job. Context beats raw count.
Tech due diligence runs this exact read. When a professional evaluates an open-source tool before recommending it - to a team, a client, or an investment committee - they check maintenance activity, issue responsiveness, release discipline and license terms before a single line of code. You are learning the same read; it just takes you 90 seconds instead of a consulting engagement.
Self-studyStars in context: popular is not the same as healthy2 min read▶
Star counts are applause accumulated over a project's whole life - they never go down. That makes them a trust signal with a blind spot:
- A repo with 20,000 stars and no commit in three years is a museum piece: admired, abandoned, and risky to depend on.
- A 50-star repo maintained weekly by a specialist can be exactly the right tool for a specialist job.
- Rule of thumb: stars answer "did people ever love this?"; the last commit answers "does anyone still care?". You need both, and the second matters more.
The phrasebook 4 min live
Ten words cover 90% of developer-speak in an office. You already own half of them from Sessions 1-5; here is the full set, each with the sentence you will actually hear.
LiveTen words, ten office sentences4 min▶
| Word | Plain meaning | As heard in the office |
|---|---|---|
| fork | your personal copy of someone else's repo, changeable freely | "Just fork it and experiment on your own copy." |
| clone | download a repo to a laptop - CLI-land, tech track | "I will clone it tonight and poke around locally." |
| push / pull | send changes up / get changes down - also CLI-land | "Pushed my edits, pull before you start." |
| upstream | the original repo you forked from | "Sync your fork with upstream first." |
| CI | the robot checks - continuous integration | "CI is red, do not merge yet." |
| merge conflict | two edits collided on the same lines; a human must choose | "There is a conflict, I will resolve it after lunch." |
| release | a named, frozen, dated version for the world | "We cut a release on Fridays." |
| stale | no activity for a long time | "That branch is stale, close it." |
| LGTM | looks good to me - approval slang in a review | "LGTM, merging after the checks go green." |
Fork, upstream, CI, release, stale and LGTM you can now use yourself. Clone, push and pull are the CLI verbs - recognize them, point at the tech track, and stay happily in your browser.
Self-studySafety basics: the four rules that keep you out of the news2 min read▶
- Public means the whole internet can read it. Not "people with the link" - everyone, forever, including search engines and AI training crawlers.
- Never commit passwords, API keys, or personal data. History is permanent (superpower 1 cuts both ways) - deleting a secret in a later commit does not unpublish it from history.
- GitHub scans for leaked secrets and alerts you, but prevention beats scanning. Treat every commit box like a public noticeboard.
- Private repos plus organization roles are the workplace default. Your company's work lives in private repos where access is invitation-only and role-based - public is a deliberate choice, never an accident.
Evaluate a real repo ★ 8 min · everyone scores
Run the 90-second read for real, with a scorecard keeping you honest.
Together first: open github.com/github/docs and run the read as a group - README, last commit, Issues, Releases, License, stars. Tick the scorecard as you go.
Solo: each person picks a repo from their own world - a tool your team uses, a template you starred in Session 1 - and scores it.
Compare verdicts. Anyone find a museum piece? A hidden gem with 40 stars? The disagreements are the learning.
Install one robot ★ 7 min · everyone hires
You will install a ready-made Action on your handbook repo and watch it work. No YAML editing beyond clicking Commit - the point is reading robots, not writing them.
Open your handbook repo → Actions tab → New workflow. GitHub suggests ready-made workflows and links to the Marketplace.
Pick a simple one - the greetings workflow (welcomes first-time contributors) or a link checker from the suggestions both work well.
Click Configure, then commit the file GitHub wrote for you via the green Commit changes button. You just hired a robot with two clicks.
Open a small test pull request on your handbook (Session 4 muscle memory) and watch the robot show up - a comment, a check, a yellow dot turning green.
Visit the Actions tab again: your robot now has a run history, right next to the Pages deploy robot that has been working for you since Session 5.
Phrasebook check ★ 6 min · everyone translates
Six sentences overheard in real offices. Translate each to its GitHub concept - if you can sort these, you can follow the standup.
The graduation lap ◐ 30 min total
- Run the health read on 3 repos from your world - a tool, a template, something trending. By the third one it takes you under two minutes.
- Install one more robot if the first felt good - a spell-checker or link-checker earns its keep on a handbook.
- Write the capstone handbook page: "How we use GitHub" - your team's conventions for issues, branches, PRs and publishing, using everything from Sessions 1-5. Propose it as a PR, naturally.
- Star this course's repo 😉 - you know exactly what that signal means now.
- Tech-track teaser: if the driving lessons now tempt you - git CLI, branching strategies, conflict surgery, writing your own Actions - they live in the tech track, now live. This track's promise stands: you never needed them.
Three questions before you graduate 🎯 ◐ 90 seconds
1 · A pull request shows a red X. As a non-dev, what does that mean for you?
Red X = at least one robot check failed. It is a "pause and ask" signal, not a verdict on the idea. Green check first, then merge.
2 · A repo has 20,000 stars but its last commit was 3 years ago. Your read?
Stars never go down, so they measure the past. The last commit measures the present - and the present is what you would be depending on.
3 · A repo you want to use at work has no license file. What does that mean?
Public to read is not licensed to reuse. No license file means the author kept all rights - a 30-second check that belongs in every health read.
Official GitHub Skills coverage
The honest map of what this session covers versus GitHub's own Skills courses - and what stays out on purpose.