swfte
Contact Us

Integration guide

GitHub integration for AI agents and workflows

Swfte Studio has a GitHub node with four actions in its shipped data: create an issue, add a comment to an issue, list open issues and list open pull requests. Nothing in the data pushes code, merges a pull request or approves one, so a GitHub workflow here reads and writes issues and leaves the code alone.

GitHub is listed in the catalogue under development, and the MCP tool list has a GitHub server that asks for a GITHUB_TOKEN. If your agent writes code, the product built for that is Nexus, which puts policy, approval and audit around coding agents. This page covers the workflow node. The catalogue also lists a LangChain GitHub document loader, which is a different thing: it reads a repository into a knowledge pipeline.

Built in Swfte Studio, run as a governed workflow, and held to the same rules as any governed agent.

Build with AITalk to our team

GitHub at a glance

Catalogue
Development
Actions in the shipped data
4 (2 read, 2 write)
Credential type shown
A stored credential, referred to by id
MCP server
Github, needs GITHUB_TOKEN
Shipped templates that use it
github issues workflow, multi integration daily digest

What you can do with GitHub

Every action below is read from a node in a shipped workflow template. Nothing is listed that the data does not show.

GitHub actions in the shipped workflow templates
ActionTypeOperationWhat the data shows
Create GitHub IssueWritecreate_issueCreates an issue in a named owner and repository, with a title, a body and labels.
Add Comment to IssueWritecreate_commentAdds a comment to an issue, by its number.
Fetch Open IssuesReadlist_issuesLists open issues in a repository. The digest template asks for ten.
Fetch Open PRsReadlist_prsLists open pull requests in a repository. The digest template also asks for ten.

Two writes and two reads, and the writes are on issues. Nothing here changes a branch, the state of a pull request or a repository’s settings.

Both templates start without a GitHub event. An issue being opened, for example, is not in the data: <GitHub trigger events - founder to fill>.

Public by default is the risk on GitHub

Many repositories are public, and issues in them are public too. An agent that files an issue or leaves a comment there speaks for the organisation to anyone, including search engines. Even in a private repository an issue is part of an engineering team’s working record, and a flood of automated issues or a wrong label makes the real ones harder to find.

The shipped issue workflow sets an owner and a repository once at the top, creates an issue with two labels and adds a comment recording when the run finished. The daily digest does the reverse: it lists up to ten open issues and ten open pull requests and summarises them, without writing anything. Between them they are the write half and the read half of a sensible setup.

How to connect GitHub

The shipped templates point at a stored credential by id, and the MCP tool entry asks for GITHUB_TOKEN, a token. The data does not name the credential type for the node itself: <GitHub credential type - founder to fill>.

  1. 01

    Use a token with narrow scope

    Create a fine-grained token limited to the repositories the workflow serves, with issue access and nothing on code.

  2. 02

    Set owner and repository once

    As the shipped template does, set them in one place at the top of the workflow so they cannot drift between steps.

  3. 03

    List before you write

    Run the list actions and read what comes back before you add a create or a comment.

  4. 04

    Gate public writes

    Any workflow that can write to a public repository gets a human-input step in front of the write.

Three governed GitHub workflows to build in Studio

Each has a label. A starting point builds on a shipped template, which is an integration test with no approval step. A design is intent only.

Daily engineering digest

Starting point

Builds on the shipped template “multi integration daily digest” (10 nodes), which you can find in the template library.

Give an engineering lead one message each morning on open issues and pull requests.

  1. List open issues and open pull requests.
  2. A code node compiles the counts and picks out the oldest items.
  3. An LLM node writes a two-sentence summary.
  4. The digest goes to the lead through an output step, or to a private channel.

Where the approval sits. No write happens, so no approval is needed. The shipped digest also reads Trello and a calendar and sends its text to OpenAI, so decide whether each of those sources belongs in your version.

Bug report to issue, approved by triage

Starting point

Builds on the shipped template “github issues workflow” (6 nodes), which you can find in the template library.

File a well-formed issue from a user report once the triage owner has seen the draft.

  1. An agent turns the report into a title, a body and labels.
  2. A policy check blocks or redacts secrets and personal data in the draft.
  3. A human-input step sends the draft to the triage owner.
  4. On approval, the create action files the issue and the comment action links it back to the report.

Where the approval sits. The shipped template creates and comments with no gate. The gate and the redaction are the changes to make.

Stale-issue nudge for maintainers

Designed

Remind owners of issues nobody has touched, without commenting in public.

  1. List open issues.
  2. A code node picks the oldest.
  3. An agent drafts a short reminder for each owner.
  4. The reminders go to a private channel. A comment is posted on GitHub only after a person approves it.

Where the approval sits. Comments on public issues are visible to everyone, so each needs an approver. A private reminder does not.

Shipped template
A governed template with its approval step already in it ships in the platform.
Starting point
A shipped template runs the same actions. It is an integration test with no approval step, so you add the gate.
Designed
Design intent. It uses the actions listed above plus generic nodes, and nothing has been built as a template.

Approvals and records for GitHub

A GitHub write is an act in public or in your team’s permanent record. Gate it.

Needs a person’s approval

  • Any issue or comment in a public repository.
  • Issues created from text that came from outside the company.
  • Bulk issue creation.

Can run without one

  • Listing open issues and pull requests for a private digest.
  • Counting items for an internal report.

What is recorded

  • Each create, comment and list action, with the run it belongs to.
  • The triage owner’s decision on a draft, and when they gave it.
  • Policy decisions on the draft text, such as a deny when it contained a secret.

Nexus is the product built to put policy, approval and audit around coding agents that write code. The node on this page is a narrower surface for issues, and the controls described here are the workflow ones: the human-input step, the policy engine and the run ledger.

A policy step in a design below describes the intent. The policy engine acts only on runs that have a policy attached, and a self-serve way to author policies is not something we describe as built.

Swfte’s own security position and any attestations are on the trust page. How approvals, policy and records fit together is on the governed agents page.

Comparing tools for GitHub work

These comparison pages are dated and sourced. Each says who should pick the other tool.

GitHub questions

Can a Swfte workflow merge a pull request?

Not with the actions in the shipped data, which create issues, comment on issues and list open issues and pull requests. Nothing there merges, pushes or approves.

Is there a GitHub MCP server in Swfte?

Yes. The MCP tool list has a GitHub entry, described as a repository management MCP server, and it asks for GITHUB_TOKEN. The tools it exposes are not in the data, so check them before you hand the server to an agent.

Which token scopes should the workflow have?

A fine-grained token limited to the repositories involved, with issue access and no access to code. The narrower the token, the less a mistake in the workflow can do.

Is there a GitHub template to start from?

Two. The github issues workflow creates an issue and comments on it, and the multi integration daily digest lists open issues and pull requests. Both are integration tests with no approval step, so treat them as starting points.

Will comments appear as me?

That depends on the token. A token from a bot account posts as the bot, and a token from a person posts as that person. Use a bot account so the origin of a comment is obvious.

Keep reading

Build a governed GitHub workflow

Begin with a read-only workflow on a test account, then add one write with an approval in front of it.

Build with AITalk to our team

Build this in Studio

Describe what you need in plain language. Studio builds the agents and workflows, and you keep every version.

Start building freeLearn more