Tahti ⭐

Tahti (Finnish for “star”) is an open-source tool we built to automate software development workflows. It runs autonomous AI bots that write code, fix bugs, and manage GitLab merge requests — while you focus on other things.

We use it ourselves to maintain our own projects. If it sounds useful for your work, you’re welcome to use it too.

How it works

Tahti is an MCP (Model Context Protocol) server. It integrates with GitHub Copilot CLI as the AI execution engine. Once configured, you control it through natural language prompts in your Copilot session.

The core concepts:

Jobs are units of work: a task description, a GitLab repository, and a branch. Each job gets its own isolated local clone so multiple bots can work in parallel.

Bots execute jobs. A bot works through the task cycle by cycle, commits progress after each cycle, and when done creates a merge request. If CI passes, the MR can be auto-merged.

Monitors watch for conditions and create jobs automatically — for example, creating a fix job whenever a CI pipeline fails.

Schedules drive automatic bot execution — picking up pending jobs and running them at a set interval without manual intervention.

Job lifecycle

A job moves through these stages:

1. Created — Job exists with a task description and target repository. No bot is running yet.
2. Running — A bot is actively working. It reads the TODO list, makes changes, and commits after each cycle.
3. MR open — The bot finished its work and created a merge request. CI is running.
4. Merged — The MR was merged (manually or auto-merged after CI passed). Job moves to archive.
5. Archived — Workspace cleaned up, logs and artifacts saved.

Jobs can also be paused (bot stopped, work preserved) or failed (bot gave up after too many errors). Paused jobs can be resumed at any time.

Getting started

Install Tahti:

npm install -g @kotocoop/tahti

Add it to your MCP configuration (e.g. ~/.copilot/mcp-config.json):

{
  "mcpServers": {
    "tahti": {
      "command": "tahti"
    }
  }
}

Then open a Copilot session in your workspace directory. Copilot will ask for permission to use Tahti tools — approve once and you’re set.

You’ll need a GitLab API token and a GitHub Copilot subscription for the bots.

Full setup instructions are in the Tahti repository.

Working with jobs

Jobs are the basic unit of work. Create one by describing the task in plain language.

Example prompts:

“Create a job for kotocoop/myapp on the develop branch — add input validation to the login form”

“List all jobs”

“Show me what the coverage-improvement job has done so far”

“Start a bot on the login-validation job”

“Pause all running bots”

Monitors

Monitors run in the background and create jobs automatically when conditions are met. Each monitor checks at a configured interval and respects a cooldown period to avoid creating duplicate jobs.

Example prompts:

“Create a CI monitor for kotocoop/myapp on the develop branch, check every 5 minutes”

“Show monitor status”

“Trigger the SonarQube monitor now”

“Stop the CI monitor for myapp”

CI pipeline monitor

Watches a branch for failing pipelines. When the latest pipeline fails, a fix job is created.

Key settings:

• project — GitLab project path (e.g. myteam/myapp)
• branch — branch to watch (default: develop)
• status — pipeline status to trigger on (default: failed)
• interval — how often to check, in seconds (e.g. 300 = every 5 minutes)
• cooldown — minimum time between triggers (e.g. 3600 = 1 hour)

Coverage analysis monitor

Downloads coverage reports from CI artifacts and checks if any files fall below a threshold. Creates improvement jobs grouped by coverage tier.

Key settings:

• project — GitLab project path
• threshold — coverage % below which files trigger a job (default: 80)
• jobName — CI job that produces the coverage artifact (default: test:unit)

SonarQube monitor

Polls a SonarQube server for open issues. Creates fix jobs for issues above the configured severity level.

Key settings:

• serverUrl — SonarQube server URL
• projectKey — SonarQube project key
• token — SonarQube API token
• severities — which severity levels to act on (default: ["CRITICAL", "MAJOR"])
• issuesPerJob — max issues per fix job (default: 10)
• fileCooldownMinutes — skip files recently modified on the branch (default: 120)

Merge conflict monitor

Checks open merge requests for conflicts against the target branch. Creates a resolution job for each conflicted MR.

Key settings:

• project — GitLab project path
• targetBranch — branch to check against (default: develop)

Test failure monitor

Detects failed test jobs in the latest CI pipeline and creates debug jobs with the failure logs included.

Key settings:

• project — GitLab project path
• branch — branch to check

TODO file monitor

Watches markdown files for unchecked task items (- [ ]). Each new item becomes a job. Tracks state so already-processed items aren’t re-triggered.

Key settings:

• files — list of markdown files to watch (e.g. ["README.md", "ROADMAP.md"])
• onlyWhenIdle — only create jobs when no other jobs are active (default: true)

Code comment monitor

Scans source files for TODO, FIXME, and HACK comments. Creates cleanup jobs when new comments appear.

Key settings:

• extensions — file types to scan (e.g. [".js", ".ts"])
• excludeDirs — directories to skip (e.g. ["node_modules", "dist"])
• commentTypes — which comment types to track
• threshold — minimum new comments to trigger a job (default: 1)

MR creation failure monitor

Scans job workspaces for failed merge request creation attempts and creates retry jobs.

Complexity auto-split monitor

Finds jobs flagged as too complex by bots and automatically breaks them into smaller subtasks.

Custom script monitor

Runs a shell script and triggers a job when the output matches a regex pattern. Use this for any condition the built-in monitors don’t cover.

Key settings:

• scriptPath — path to the script
• successPattern — regex to match against script stdout

Schedules

Schedules run pending jobs automatically at a set interval. Without a schedule, you start bots manually.

Example prompts:

“Create a recurring schedule that runs 2 jobs every 10 minutes”

“Show active schedules”

“Pause the recurring schedule”

Recurring schedules run at a fixed interval and start a configured number of bots from the pending job pool. Jobs are selected by priority, or randomly when priorities are equal.

One-time schedules trigger a single run after a delay — useful for deferred starts.

Typical uses

Automated CI fixes. A CI monitor watches the develop branch. Pipeline fails → fix job created → bot diagnoses and fixes → merge request created. No manual reaction needed.

Test coverage improvement. A coverage monitor creates jobs when files drop below your threshold. A recurring schedule runs through them over time.

Code quality. A SonarQube monitor creates fix jobs for issues above a severity threshold. Run them in parallel or one at a time.

Roadmap execution. Put tasks in a markdown file as checkboxes. The TODO file monitor turns them into jobs and a recurring schedule runs them.

Parallel work. Run several bots simultaneously on different repositories, features, or maintenance tasks — each isolated in its own workspace.

A note on AI and privacy

Tahti’s bots use GitHub Copilot CLI for AI execution. When a bot works on your code, that code is sent to GitHub/Microsoft and processed according to their terms of service. Tahti itself runs locally and does not send your code anywhere.

Source & license

Tahti is developed by Koto Co-op and published as open-source software.

• Source: gitlab.com/kotocoop/software/tahti
• npm: @kotocoop/tahti

Learn more about Koto Co-op →