How CodeRelay works

Registration uses an email address and a password. GitHub sign-in is optional and is never required. Your teammates assign you sprint tasks by that same email, so use the one you want to be reachable at.

Open the dashboard and fill in the “Add your keys” card under Settings. Both values are checked against the real services before they are stored, so a typo is rejected immediately rather than failing on the next push.

• GitHub personal access token with repo scope, from github.com/settings/tokens. It reads commits, diffs and file contents.
• Groq API key from console.groq.com/keys. It writes briefs, runs the AI review pass, and transcribes voice notes.

Without a Groq key the deterministic review rules still run; the brief and the AI pass do not.

Add the owner and repository name on the dashboard, then create the webhook in GitHub under Settings → Webhooks → Add webhook:

Payload URL:  https://<your-deployment>/api/webhooks/github
Content type: application/json
Secret:       the per-repo secret, or GITHUB_WEBHOOK_SECRET
Events:       Just the push event

CodeRelay ignores pushes from repositories that are not registered, so the webhook is safe to add before the project exists.

The review runs in two passes. The first is deterministic: it reads the added lines with comments and string literals stripped out, and checks each identifier against the language's reserved words and standard library.

Before it reports a misspelling it builds a symbol table from the files in the change — functions, macros, classes, variables, imports. Write prinf("hi") in C and you get the file, the line, the expected token and the corrected line. Declare your own prinf() anywhere in the change and nothing is reported, because it is a real function, not a slip.

The second pass sends the numbered diff to Groq for the defects that need reading comprehension. Everything it returns is re-checked against the real diff: a finding on a line the change did not add, or about a symbol you did declare, is dropped before you ever see it.

Every finding carries the file, the line, what is wrong, what happens at runtime because of it, and the fix. If one is wrong, use Not a problem to dismiss it.

On the sprint board, name the task, click the days on the calendar, and list the work planned for each one. Items are added with Enter, reordered with the arrows, and the running plan is shown underneath as you build it.

Behind the calendar it is just a feature key plus dated lists, and you can paste that directly with Paste JSON instead:

{
  "key": "Hero section",
  "whatwork": {
    "2026-09-12": [
      "navbar",
      "click 4 menu dynamic page url set",
      "login menu set"
    ],
    "2026-09-13": ["login feature dynamic"]
  }
}

Each line becomes a tracked work item. Assign the task to a registered teammate by email; if the address has no account yet, you are told so rather than the task being created half-assigned.

Creating a task issues one token for the feature and one for every planned day. The day token carries the date in the middle, so git log stays scannable:

CR-HERO-7F3K9A2B        the whole feature
CR-HERO-0912-4F7KQ2     just the 12th

git commit -m "feat: navbar with 4 dynamic menu links [CR-HERO-0912-4F7KQ2]"

On the next push the commit is attached to that day. Every work item is judged against the commit messages and the files they touched, and the board shows which items are done, which are underway, and which one to pick up next.

A commit with no token is still tracked. It is attributed by matching the git author against the assignee - email, then GitHub username, then name - and the commit date against the plan. Those commits are labelled inferred on the board with the reason they were attached, and they can move an item to in-progress but never to done on their own. If two tasks fit equally well, neither is chosen and the ambiguity is reported.

A status you set by hand is pinned and the pipeline will not overwrite it until you hand it back to automatic tracking.