Dev Agent Setup

Run Kenny as an autonomous dev agent on your own machine: it picks up tasks from your Kanvas board, writes the code, opens a pull request, and walks it through CI — committing as Kenny rather than as you. This page is the self-serve guide for wiring Kenny to your repo and machine.

Overview

The dev agent is the local /kenny loop running in Claude Code on a machine you control (a spare Mac, a dedicated box, or a VM). It drains a board column by running /scope → /build → /ship on each task. You keep one machine signed in as Kenny; it works tasks unattended and leaves you PRs to review.

It is opt-in and machine-local — nothing runs until you start the loop on a box you own, against a repo you connect.

How it works

  1. You connect a GitHub repo to a Kanvas project and install the Kanvas GitHub App on it.
  2. On your machine, you sign Claude Code in, connect the Kanvas MCP as the Kenny user, and set git to commit as Kenny.
  3. You start the loop (/kenny --project <slug>). Kenny picks the top task, branches, implements, and pushes.
  4. The GitHub App webhook links the PR to the task and moves the card to PREVIEW as the PR opens.
  5. Kenny polls CI; for low-risk task types it can merge automatically, otherwise it leaves the PR for you to review.

Setup

1. Connect the repo. In Kanvas, open your project’s GitHub settings and connect the repository, then install the Kanvas GitHub App on it. Grant Contents: Read & write (push) and, if you want Kenny to open and comment on PRs as the app rather than as your account, Pull requests: Read & write. After changing any app permission you must approve the update on the installation — editing the app’s settings only requests it.

2. Prepare the machine. Install the prerequisites: Node 24+, git, gh, and jq. Sign in to Claude Code, and connect the Kanvas MCP authenticated as the Kenny user (the /kenny, /scope, /build, and /ship skills are served from that MCP — if it isn’t connected, /kenny won’t resolve).

3. Authenticate git for the repo. The simplest path is HTTPS plus gh auth setup-git. If you prefer SSH, register a key for the account with gh ssh-key add — a Permission denied (publickey) on clone or push means no key is registered for that account.

4. Set the commit identity to Kenny. Configure git so commits are authored as Kenny (your workspace’s Kenny commit email), not your personal identity. On a dedicated box, set it globally; on a shared machine, scope it to the shell that runs the loop. Commit author is independent of who pushes — see Edge cases below.

5. Start the loop. From the repo, run /kenny --project <your-project-slug>. Use a wrapper that re-fires it each cycle so it idles when the queue is empty.

Usage

  • Run one task end-to-end: start the loop with a single planned task on the board and watch it branch → implement → open a PR. Confirm the PR is linked to the task and the card moved to PREVIEW automatically — that confirms the GitHub App webhook is wired correctly.
  • Scope only / build only: pass --steps scope, --steps build,ship, etc. to run part of the pipeline.
  • Review queue: feature-type and large-blast-radius PRs are left open for you; enhancement/bug PRs with green CI and a small diff can auto-merge.

Edge cases & limits

  • Three identities on a PR, don’t conflate them. The commit author (your git identity → Kenny), the PR opener / pusher (whatever credential pushes — by default your machine’s gh account), and comments (the opener). The simplest working setup is good enough: Kenny authors the commits, your account pushes and opens the PR. Full [bot] attribution for the push and PR is an optional upgrade and is not required for the loop to work.
  • Vercel (or any deploy) author gate. If your repo deploys previews via Vercel on a Pro team, Vercel blocks a build whose git author isn’t a team member, with “git author … must have access”. It matches by GitHub login, not email — so an email invite, a GitHub-org membership, or the “auto-add committers” toggle will not clear it on their own. The fix: have the Kenny GitHub account sign in to Vercel (so a Vercel account is linked to that GitHub login) and accept the team invite, with access to the project. Until then the deploy check (and any E2E that needs the preview) stays red — but PR ↔ task linkage still works regardless of CI.
  • CI runs normally. Kenny’s commits trigger your GitHub Actions workflows like anyone else’s; nothing about the agent suppresses them.
  • The MCP is the source of truth for skills. If the Kanvas MCP isn’t connected as Kenny, /kenny fails — typing the word “kenny” does not substitute for the skill.
This site uses Just the Docs, a documentation theme for Jekyll.