How We Built It, Preface: A Token Is an Identity

This preface is republished with permission and credit from ScriptHammer — "A Token Is an Identity: Let Cursor Commit as Themselves". Chattanooga.Digital is built on the ScriptHammer discipline, and this series ends every post with an invitation to check the tutorial against the real code and open a ticket if something has drifted. For that to work, your AI assistant needs to act as you — so here is the two-minute setup, first.

The problem: a shared token erases who did what

The lazy way to let an AI tool touch a repository is to hand it a token — someone's token — and move on. Do not do this. The key idea is small and important:

A token does not grant access to a repository. It grants access as a person.

When your AI assistant commits or opens an issue with a shared token, every one of those actions is attributed to whoever owns the token, not to you. That quietly breaks three things at once: attribution (the history lies about who did the work), security (a shared token sidesteps each person's two-factor protection), and revocation (you can't cleanly cut off one contributor without cutting off everyone). The fix is to make sure the AI acts as you, using your own identity.

Option A: sign in with GitHub (recommended)

If you are using Cursor, the simplest path is the built-in one. Open the GitHub integration and click Sign in with GitHub. Cursor handles the OAuth handshake, and every commit and issue it opens on your behalf is correctly attributed to your account. No token to copy, paste, store, or leak. For most people, this is the whole answer — you are done.

Option B: a fine-grained personal access token (you create it)

If your tool does not support GitHub sign-in, or you specifically want a scoped token, create one yourself — never reuse someone else's. The word that matters is fine-grained: a modern GitHub token that is scoped to a single repository with the minimum permissions, not a legacy "classic" token with the keys to your whole account.

On GitHub, go to Settings → Developer settings → Personal access tokens → Fine-grained tokens, and create one scoped to just the repo you are contributing to, with only these permissions:

• Issues — Read and write (so your AI can open the tutorial-fix tickets)
• Contents — Read and write (so it can commit and push)
• Pull requests — Read and write (so it can open PRs)
• Metadata — Read (required, and granted automatically)

Set an expiration — 90 days is a sane default. A token that never expires is a liability you will forget about. When it lapses, you make a new one; that friction is the point.

Prove it worked

Whichever option you chose, confirm the identity is actually yours before you let the AI loose. One command answers it:

gh api user --jq .login

That prints the GitHub username the current credentials act as. If it is your handle, you are set: every issue your assistant opens and every commit it makes will carry your name, your history, your credit. If it is someone else's, stop and fix the credential before going further.

Why this matters for this series

Every post in "How We Built It" ends with a copy-paste prompt that asks your AI to read the post, explore the companion gig-city-drupal repo, and open an issue if the tutorial no longer matches the code. That is a real contribution to keeping open documentation honest — and it should show up in the record as your contribution. Set your identity up once, here, and every fix you surface across the rest of the series is properly yours.

Credit and full detail: ScriptHammer — A Token Is an Identity.

Start the series: Part 0 — Why This Stack →