resolved
GitHub
github.com/{org}/{repo}
landed in 38msBookSlash for GitHub · Engineering
Memorable shortcuts
for everything in GitHub.
Engineers reach the monorepo, the active PR queue, the latest release, and their team’s review board dozens of times a day. With BookSlash, each of those URLs gets a slug your whole team agrees on — and the link survives renames, repo migrations, and org changes.
repo
other shortcuts you might save
b/repob/prsb/reviewb/release
Suggested slug patterns
Steal these. They work for most teams.
Battle-tested shortcut conventions for GitHub, with notes on why each one survives the URL changes that break personal bookmarks.
- b/repo
The team monorepo or primary repository.
New engineers learn it day one. Survives if you ever migrate from a personal org to a company org.
https://github.com/{org}/{repo} - b/prs
Open pull requests assigned to or owned by the team.
Replaces a Slack pin to a saved GitHub search; updates instantly when you tweak the filter.
https://github.com/{org}/{repo}/pulls - b/review
Pull requests waiting on you for review.
A direct link to /pulls?q=is:pr+review-requested:@me — every engineer reaches it the same way.
https://github.com/pulls?q=is:pr+review-requested:@me - b/release
The latest release notes / changelog page.
Sales, support, and marketing all want this URL. Saving it as a slug stops the recurring "what link?" ping.
https://github.com/{org}/{repo}/releases/latest - b/runbook-<service>
Per-service runbook in the engineering wiki repo.
Pattern, not a single slug — pairs with PagerDuty alert payloads so on-call engineers go from page to runbook in one keystroke.
https://github.com/{org}/eng-wiki/blob/main/runbooks/{service}.md - b/branch-protection
Org-level branch protection settings page.
Eng managers and security review this quarterly. Not every team remembers the deeply nested URL.
https://github.com/{org}/{repo}/settings/branch_protection_rules - b/security
Security advisories + dependabot alerts dashboard.
Same URL the security team and engineering managers use during quarterly reviews.
https://github.com/{org}/security/advisories - b/actions
GitHub Actions workflow runs across the org.
Replaces a fragile Datadog/Jenkins bookmark per teammate.
https://github.com/{org}/{repo}/actions
Common workflows
Three patterns that pay back in week one.
01
On-call escalation in one keystroke
PagerDuty fires an alert at 3 a.m. The on-call engineer types b/runbook-checkout and lands on the right markdown file in the eng-wiki repo — even if the repo was renamed last week. The runbook itself can carry slugs back to b/dash-checkout (Datadog) and b/oncall (the active incident board).
02
Cross-team release coordination
Marketing and sales need the new release notes the moment they ship. Saving b/release on the GitHub release URL means the same link works for v1.4, v1.5, v2.0 — you update the destination once after each cut, and every team sees the new notes without anyone re-pinning a Slack message.
03
New-engineer ramp
Day-one onboarding boards (see /use-cases/onboarding) start with five GitHub slugs: b/repo, b/prs, b/review, b/runbook-<their-service>, and b/release. Five keystrokes replaces the half-week of "where do I find X?" pinging.
With and without
Same GitHub. Different team experience.
Without shortcuts
Each engineer keeps personal Chrome bookmarks to the repo and their review queue. Half the team’s bookmarks point at an old repo URL after a migration. New hires spend a week piecing together which dashboards matter.
With BookSlash
b/repo, b/prs, b/review, b/release. Every engineer types the same shortcut. URL changes propagate the moment one admin updates the slug. Day-one engineers are productive without asking for the link.
Frequently asked
BookSlash + GitHub
No. Slugs are URL → URL redirects; BookSlash never reads from or writes to your GitHub org. The destination URL is just a string we save and serve. That means there is nothing to authorise on the GitHub side and no per-repo permission to manage.
You can share the slug, but resolving it lands the user on the GitHub URL — which still requires a GitHub login if the destination is private. Most teams pair a private-repo slug (b/repo) with a public mirror slug (b/repo-public) so external partners reach the right place.
You update the slug to point at the new URL. End users keep typing b/release; the destination flips silently. Most release teams hook this into their post-deploy script: a single curl call to the BookSlash API updates the slug at the same time the release goes live.
Yes. Slugs accept any URL the user can reach in a browser, including GitHub Enterprise instances behind your VPN or zero-trust gateway. Authentication still happens at the destination — BookSlash never touches the auth flow.
Start with one team. Roll out when it sticks.
Your stack. Your shortcuts.
One keystroke for everyone.
2,400+ teams reach every important destination in their stack with a single keystroke. Save the first slug in 30 seconds.
Free for personal use · No credit card · 14-day team trial