What GitHub is and how Kite uses it
GitHub is where software teams store their code, review each other's changes through pull requests, and track bugs and requests as issues. For a lot of companies, the marketing website lives there too. That usually means every headline change or new landing page waits in an engineer's queue.
An AI marketing agent with access to GitHub can work on that website directly. It can also read what the product team ships and turn it into marketing. Kite does both. It edits the site's code and proposes the change for your developers to review, and it reads merged pull requests and repository contents to find launches worth announcing. You connect it by installing the Kite GitHub App and granting it the repositories the work needs.
Marketing jobs Kite can do with GitHub
Kite's GitHub work falls into two groups. The first covers your website's code, whether your developers built the site or Kite did. The second covers what your engineering team ships and finds, which Kite turns into launch content and tracked fixes.
Work on the marketing website your developers keep in GitHub
If your site is a Next.js project in GitHub, Kite can import the repository and work on it like the rest of your team. It rewrites a pricing page that isn't converting, builds a landing page for a new campaign, adds a comparison page, or fixes metadata, structured data, redirects, and internal links.
Your repository stays the source of truth. Kite does each piece of work on its own branch and gives you a preview link, so you can see the new page before anyone merges it. When the work is ready to publish, Kite opens a pull request against your default branch. Your branch rules and required reviews decide when it merges, and your own deployment ships the result.
Say your head of sales mentions in Slack that prospects keep asking whether you integrate with HubSpot. Kite checks the site, finds no page that answers the question, and writes one. Your marketing lead approves the preview in Slack, and your developer sees a pull request with the new page, its metadata, and a link from the integrations section.
When your developers push their own changes, Kite pulls the latest code from the connected branch before it starts new work. That way its next change builds on what they shipped.
Keep the code for the sites Kite builds in your own repository
Kite can also build and host a website for you, and every site it builds gets its own GitHub repository. If your team has connected a GitHub organization, Kite creates that repository there, so your engineers can open the code, review its history, and see each change Kite publishes.
You can choose the repository yourself, too. Ask Kite to create a new one with the name you want, or attach an empty repository you already made, and Kite pushes the site's code there. Once Kite confirms your repository holds the same code as the site, it can make yours the site's main repository. Later changes then land there. If you'd rather not connect GitHub at all, Kite can export the website code instead.
This matters when a website outgrows its first version. Your developers can take over part of the code, add a product feature, or move hosting later without starting from scratch.
Turn what your team ships into launch content
Your product team announces most of its work in pull requests, and those announcements rarely reach customers. Kite can read the pull requests merged in a repository over a given week, along with their titles, descriptions, and authors. It can also read files in the repository, such as a README or a changelog.
From that, Kite picks the changes a customer would care about and writes the marketing around them. That might be a changelog entry, a short launch post for the blog, a customer email about a new feature, or a set of social posts. Kite writes in your brand voice and checks what the change does before it describes it.
You can ask for this once, as in "Write up what we shipped this week," or put it on a weekly schedule. When it runs on a schedule, Kite brings the draft announcements to Slack every week for approval.
Report website problems to your developers as GitHub issues
Kite checks websites for problems as part of its marketing work. It might find a broken link on your pricing page, a page missing its title and description, or a slow page that hurts your search rankings. When the fix belongs to your developers, Kite can open a GitHub issue in the right repository with a clear title, what it found, the page it affects, and the change it recommends.
That puts the problem in the queue your engineers already work from, instead of in a Slack message that scrolls away. Kite can read the issue later to see whether it's been closed.
Hand a finished project to your engineers in a new repository
Sometimes Kite builds something your engineers want to run themselves, such as a small calculator for a campaign page or the files for a standalone microsite. Kite can create a new repository in your GitHub organization and push the files to it in one commit. The repository is private unless you ask for a public one.
This is a one-time handoff. Kite returns the repository link, and from then on the code belongs to your team.
What Kite reads and changes in GitHub
Information Kite can read
- Repositories the Kite GitHub App can accessKite searches and lists them, so it can find the one you mean when you ask it to import "the website repo."
- Website code in a connected repositoryKite reads the pages, components, and content files of an imported Next.js site and pulls your developers' latest changes from the connected branch.
- Pull requestsKite reads open and merged pull requests, including their titles, descriptions, authors, and merge dates, which is how it finds launches worth announcing.
- IssuesKite reads issues and their status, so it can check whether a problem it reported has been fixed.
- Repository filesKite reads files such as a README or changelog when it needs to understand what a change does.
- The connected accountKite reads which GitHub account the app is installed on and whether that account can create repositories.
Information Kite can create or change
- Draft branchesKite commits each piece of website work to its own branch, with a preview link for review.
- Pull requestsKite opens a pull request against your default branch when work on an imported site is ready to publish.
- Website codeKite pushes the code of a site it built to that site's connected repository each time it publishes a change.
- RepositoriesKite creates a new repository in your organization, either for a site it builds or for a one-time handoff of files.
- IssuesKite opens issues that describe a website problem and the recommended fix.
How Kite connects to GitHub
Connect GitHub by installing the Kite GitHub App, either from the Integrations page in Kite or from the link Kite sends in Slack the first time a job needs it. During the install, you choose the GitHub account and the repositories Kite can reach. You can grant every repository or only the ones that hold your website. Kite works with the repositories and permissions you grant at install time. You can change that list later in GitHub's settings for the app.
If you install the app on a GitHub organization, an organization owner may need to approve it first. Kite tells you when an install is waiting for that approval. An organization install lets Kite create new repositories. On a personal account, Kite works with repositories that already exist, so you create the repository on GitHub and then connect it.
You can start with a plain request, such as "Import our website from GitHub and fix our homepage headline" or "Write up what engineering shipped this week." Kite finds the repository, proposes the change, and asks before it publishes anything.
Where GitHub fits in Kite's marketing work
GitHub holds the code for every site Kite builds. When your team has a GitHub organization connected, the new site's repository lives there from day one, so your engineers have the code the moment the site launches.
When your website lives in your own GitHub repository, GitHub is how Kite's content updates reach it. Kite rewrites outdated pages, adds new articles, and updates product details on a branch, then proposes each change as a pull request for your developers to merge.
On a site your developers keep in GitHub, Kite writes the conversion fix into the code, such as a shorter signup form or a clearer pricing table. It delivers the change as a pull request with a preview link. After your deployment ships it, Kite compares conversion before and after the change through your connected analytics product.
Limits and product-specific details
- Imports work with Next.js sites. Kite can import and edit a website built with Next.js, including one that sits in a subfolder of a larger repository. A repository built with another framework can't be imported, though Kite can still read it, open issues in it, and read its pull requests.
- Creating repositories needs an organization. Kite creates repositories only under a GitHub organization. On a personal account, create the repository yourself and connect it.
- Hosting and built-in analytics come with the sites Kite hosts. A site imported from your repository keeps running on your own deployment, so Kite measures it through the analytics product you connect.
Common questions
Does my marketing team need to know Git to work with Kite on a GitHub site?
No. Your marketing team asks for changes in Slack and reviews each one through its preview link. Your developers see the same work as a normal pull request, so each side reviews it in the tool they already use.
What happens to the secret keys my website needs?
You add them yourself. When Kite imports your repository, it checks which secret keys the code expects, such as an API key for your analytics or forms, and posts a message naming any that aren't set yet. You then add those values to the site in Kite, and Kite works with the key names only.