Integrations
Does Paqad fit the tools your team already uses?
Paqad touches three kinds of tools: the AI tools that do the work, the work tracker that holds requests, and the code host where changes are reviewed and merged. This page says which are connected in the current release, what is verified, and what each tool can enforce.
Checked against paqad-ai 1.91.1 on 25 September 2026, from the source code. A source review, not a live test of every connection.
At a glance
What is connected today.
| Kind of tool | Connected in 1.91.1 | How it was verified | Not connected |
|---|---|---|---|
| AI tools that do the work | Eleven tools, at three enforcement levels (below) | Adapter source code for each tool | Any tool not in the list |
| Work tracker, where requests come from | GitHub issues, through your own GitHub command-line login. Jira, read by the AI through an Atlassian MCP connection configured in your AI tool | Provider source and the intake command | GitLab issues, Azure Boards, Linear, Trello and others: no provider ships. The provider contract exists, so one could be written |
| Code host, where changes are delivered | GitHub: branch, commit, push, pull request, continuous integration status and a comment carrying the record, through your GitHub login | Provider source, the delivery command and the CI gate | GitLab, Bitbucket, Azure Repos and others: no provider ships |
Paqad defines general contracts for trackers and code hosts, so the design is not tied to GitHub or Jira. A contract is not a connection, though: anything not named above needs validating before a team relies on it.
AI tools
Three enforcement levels.
Every supported tool gets the same rules and the same way of working. What differs is whether the tool lets Paqad step in: some let it stop an edit, one lets it record after the fact, and the rest only accept instructions.
Level 1
Blocks and checks
The tool runs Paqad's hooks (small programs it starts automatically) before certain edits and when the AI finishes a turn. A missing plan or an unloaded rule can stop the edit, and a hard failure at the end holds the turn open.
Claude Code, Codex CLI
Level 2
Records at the end
After each turn, a hook writes the record and a verification result into the project. It never blocks an edit and says nothing in the chat.
Gemini CLI
Level 3
Instructions only
The tool is given the rules and the method in its own instruction file. Nothing stops it ignoring them. A record exists only if the AI runs Paqad's commands itself.
Cursor, GitHub Copilot, Windsurf, Continue, Junie, Aider, Google Antigravity, JetBrains AI Assistant
Every AI tool
What onboarding writes for each tool.
You choose the tools during paqad-ai onboard. Each one gets a short entry file that points to the installed framework, plus hook settings where the tool supports hooks.
| Tool | Level | Files Paqad writes in the project | Guide |
|---|---|---|---|
| Claude Code | Blocks and checks | CLAUDE.md, .claude/settings.json (hooks) | Claude Code |
| Codex CLI | Blocks and checks, after you approve the hooks once with /hooks in Codex | AGENTS.md, .codex/hooks.json | Codex CLI |
| Gemini CLI | Records at the end | GEMINI.md, .gemini/settings.json (hook) | Gemini CLI |
| Cursor | Instructions only | .cursor/rules/paqad.mdc, .cursor/mcp.json | Cursor |
| GitHub Copilot | Instructions only | .github/copilot-instructions.md, .vscode/mcp.json | GitHub Copilot |
| Windsurf | Instructions only | .windsurfrules, .windsurf/mcp.json | Windsurf |
| Continue | Instructions only | .continue/rules/paqad.md, .continue/mcp.json | Continue |
| Junie | Instructions only | .junie/AGENTS.md, .junie/mcp/mcp.json | Junie |
| Aider | Instructions only; Aider reads the file only if you name it with --read | CONVENTIONS.md, .aider.conf.yml | Aider |
| Google Antigravity | Instructions only | ANTIGRAVITY.md, .antigravity/mcp.json | Google Antigravity |
| JetBrains AI Assistant | Instructions only | .aiassistant/rules/guidelines.md | Overview |
The Claude Code plugin for JetBrains IDEs runs the real Claude Code command line, so it has the first level. The Claude agent inside JetBrains AI Assistant is a different product and has the third.
Some mcp.json files above are the tool's own project settings file, and onboarding replaces them. Back up an existing .cursor/mcp.json or .vscode/mcp.json before you onboard. The MCP guide explains what these files contain.
Work tracker and code host
Taking in a ticket and delivering a pull request.
Paqad can start a change from a ticket and end it with a pull request, applying your team's delivery conventions in between. Here is exactly what each connection does in the current release and what it needs.
| Connection | What Paqad does with it | What it needs | Verified how |
|---|---|---|---|
| GitHub issues (tracker) | paqad-ai intake fetch #123 fetches the issue as written: title, status, type, link, detected acceptance criteria and description. The specification is grounded in that text. | The GitHub command line (gh) logged in to an account that can read the repository | Provider and command source |
| Jira (tracker) | A Jira key such as PROJ-123 is recognised, and the AI is told to fetch it through the Atlassian MCP connection in its session and ground the work in it. Paqad can then transition the ticket, comment on it and, if the team chooses, write refined requirements back, all through that connection. The command line itself does not fetch Jira tickets. | An Atlassian MCP connection configured in your AI tool, signed in with your own Atlassian account. Which AI tools can hold that connection depends on the tool | Provider and intake source. The Jira path was reviewed in source; it was not exercised against a live Jira instance for this page |
| GitHub (code host) | paqad-ai deliver checks the recorded open-a-pull-request decision, then creates the branch, commits, pushes and opens the pull request with the configured title, body, base, reviewers and labels. Depending on the setting it waits for continuous integration checks, reads them once, or skips them, and on green it can post the available verification record as a comment. | gh logged in with push rights, and a delivery policy file with the team's conventions (onboarding detects sensible defaults) | Delivery, CI gate and provider source |
Your conventions, not Paqad's
Branch names, commit messages, pull request titles and bodies come from templates in docs/instructions/workflows/delivery-policy.yaml. The continuous integration gate can wait for green (the default), warn only, or be switched off. In 1.91.1 the wait is bounded by a poll count; the configured minute limit is not reliably applied by the command line. The policy also names the status a Jira ticket should move to when a pull request opens or turns green; in this release the command computes that status but does not apply it, so moving the ticket is an action for the AI through the tracker connection. Delivery policy settings.
What delivery does not do
- It does not deploy. The process ends at a pull request with your CI checks applied; merging and releasing stay with your team.
- It does not push without asking. Opening a pull request is always preceded by a question with three answers: open, open as draft, or commit only.
- It does not silently fall back. If the remote rejects a push or the pull request cannot be opened, the chain stops with the reason and a suggested remedy.
- Posting the record to the pull request is best effort and happens only when the gate waits for green. If the comment fails, the CI result stands and the record remains on disk.
- It does not update the ticket. The tracker status configured in the delivery policy is computed but not applied by the command in 1.91.1; the AI can update the ticket through the configured connection.
Other trackers and hosts: if your team uses GitLab, Bitbucket, Azure DevOps or another system, treat Paqad as not connected to it today. Say so in GitHub Discussions; the provider contract in the source is where a new connection would start.
Honest limits
Where even the first level stops.
- Before an edit, the hooks see the tool's own file-editing actions. A change made through a shell command is not stopped beforehand; the end-of-turn check still sees it, because it reads the files on disk.
- The end-of-turn check holds a turn open only for a hard failure, and at most once per turn. An inconclusive result is reported but does not block.
- If the installation is broken or a hook script is missing, the hook lets work continue rather than locking you out.
paqad-ai doctorreports this. - Anyone can switch Paqad off for a project with
paqad-ai disable. Work completed while it is off is noted in the record. - Hook settings are stored per machine and are not committed, so each teammate runs
paqad-ai joinonce. - By default, rules that have been turned into scripts warn rather than block. A team can make them blocking with the
rule_compliancesetting.
Every tool, at every level, also gets two git hooks that link each commit and merge to the change it belongs to. They record only and never block a commit.
Your stack
Stack packs: ready-made conventions for the frameworks you use.
When Paqad onboards a project it recognises the languages and frameworks in use and adds the matching stack packs. A pack is a set of rules and conventions written for one framework. Twenty-two packs ship with paqad-ai 1.91.1.
- Built-in stack packs: the packs that ship with the current release
- Stack detection: how Paqad recognises what a project uses
- Creating custom packs and which pack wins
Set up the tools you use.
Install Paqad, run paqad-ai onboard in your project and pick your AI tools. Sign in to gh for GitHub issues and pull requests, and configure an Atlassian connection in your AI tool if you use Jira. You can add another AI tool later by running onboarding again with --providers.