AI software delivery for engineering teams
Your team's process. Built into AI delivery.
Paqad brings requests, code, review, tests and documentation into one agreed process. Your engineers make the decisions, and the work leaves a record.
Open source. MIT licensed. Built by Eliyce.
The delivery story
One request, through your agreed process.
A request is understood and its requirements agreed before anything is built. Then it is built inside your rules, reviewed and tested, its documentation is brought up to date, and a person decides how it is delivered. Not every task runs every stage; the record shows the path taken.
- Understand the request AI Read as written, checked against project knowledge and earlier decisions, with research where the team has configured it. Open choices go to people.
- Agree the approach You A plan and a specification with how each point will be proven. A person confirms it. Small fixes may start after the plan; the specification is still required to complete.
- Build inside your rules AI The team's written rules and conventions are loaded on record before the first edit.
- Review and test AI Check The AI records a review with findings and a rollback plan; your own format, test and build commands run and their results are stored as they are.
- Update the documentation AI Documents the change made out of date are updated as part of the same change.
- Deliver through your tools You AI A person decides whether to open a pull request; the delivery command opens it on your code host and can attach the available verification record.
AI the AI tool does it Check a script confirms it You a person decides. How firmly each stage is enforced depends on the AI tool. Follow one request through the process.
Shared standards
One standard for the team, whoever is working.
Rules, conventions, the module map and resolved decisions live in the project, in files the team reviews like code. Every engineer and every supported AI tool works from the same set.
- Written once, applied everywhere Onboarding recognises your languages and frameworks and adds matching conventions. Your own rules sit beside them.
- Decisions carry forward Where an earlier decision matches, it can be reused with its source shown, subject to the team's confirmation rules.
- Rules can become checks Paqad can work out which written rules a script could test and generate those checks, so a rule no longer depends on anyone remembering it.
- Changes to the standard are reviewed Rules and documentation change through the same process as the code.
How firmly the process is applied depends on the AI tool. Claude Code and Codex CLI can stop an edit that skips a step; Gemini CLI records the work at the end of a turn; the other supported tools follow instructions without enforcement. See what each tool can enforce.
Tests and documentation
Tests and documentation are part of the change.
Every requirement says how it will be proven
The specification lists what the change must do and, for each point, how it will be checked. After building, your project's own test, format and build commands run and their results are stored. A test that fails is run again on its own, so an unreliable test is reported as unreliable rather than counted as a pass or a failure. A passing run shows those checks passed; it does not prove the code has no faults.
The documentation describes the software as it is now
Paqad can create and maintain a project's core documentation: the stack, how the modules fit together, which rules apply. When a change makes a document out of date, updating it is a step of that change. The AI consults the same documentation before planning. Updates are the AI's work and are reviewed by people like any other change.
The record
Every step leaves something you can open.
The record is written by Paqad's own commands and scripts as the work happens, not typed by the AI afterwards. It supports the whole delivery story, including the parts that did not go to plan.
| What was asked | The request or ticket as fetched, and the questions the team answered |
| What was agreed | The plan, and the specification with the name of the person who signed it off |
| Which rules applied | The rules loaded for the files being changed, with a fingerprint of their text |
| What was built and reviewed | The edits, the review with its findings and rollback plan |
| What was checked | Each format, test and build command with its result, or the fact that it did not run |
| What was documented | Which documents were updated as part of the change |
| What was delivered | The delivery decision, the branch, the commits, the pull request and the result of your continuous integration checks |
- ResultSafe to merge Every check that ran passed and every required step has its record. A statement about those checks, not a guarantee about the code.
- ResultNeeds your attention A check failed or a required record is missing. The result names which one.
- ResultInconclusive Something could not be confirmed, for example tests that never ran. Not confirmed is never rounded up to passed.
Paqad is built using Paqad. Eliyce publishes one complete record of a real change to Paqad itself, including the parts that ended inconclusive. What the record can and cannot prove: how it works.
Your tools
Works with the tools your team already has.
AI tools
The tools that do the work
Eleven AI coding tools are supported, including Claude Code, Codex CLI, Gemini CLI, Cursor and GitHub Copilot. Each gets the same rules and process; what differs is how much Paqad can enforce there.
Work tracker
Where requests come from
A change can start from a ticket. In the current release that means GitHub issues, fetched through your own GitHub login, or Jira, read by the AI through an Atlassian connection you configure in your AI tool.
Code host
Where changes are delivered
Delivery opens a pull request on GitHub, can wait for your continuous integration checks and can attach the available verification record. Your branch names, commit messages and review rules are configured, not replaced.
Paqad defines a general contract for trackers and code hosts, but the current release ships connections only for GitHub and Jira. Anything else needs validating before you rely on it. Checked against paqad-ai 1.91.1.
Try it, then decide
How a team evaluates Paqad.
Evaluate Paqad on one repository and one representative change, without changing how the rest of the team works.
- Agree the standard. Run onboarding on one project. It recognises the stack, adds matching conventions and writes the files each AI tool reads. Add the team's own rules and let Paqad document the modules.
- Set up the tools. Each engineer runs one command on their machine. Choose which AI tools the team uses and, for ticket intake and pull requests, connect your GitHub login and your Atlassian connection.
- Try a representative change. Pick a real ticket of medium size. Watch where the AI asks the team to decide, and where a step is refused until its record exists.
- Read the record. Open the change's folder, the pull request and the local dashboard. Check that what was recorded matches what happened.
- Decide the rollout. Which rules to enforce as checks, which to keep advisory, which tools to standardise on, and what to publish in the team's delivery conventions.
Start on one project
- Node.js 22 or later, checked with
node --version - A project folder, ideally a git repository
- An AI coding tool such as Claude Code, Codex CLI or Cursor, with its own account
npm install -g paqad-ai
cd your-project
paqad-ai onboard
paqad-ai doctorPaqad itself needs no account. Teammates joining an onboarded project run paqad-ai join. Quick start and installation guide.
Where data goes: the security page. How the process is configured: workflow settings. Where to ask: support. Teams that want help doing this on their own backlog can talk to Eliyce about guided adoption, a separate service; Paqad itself needs no contract.
Questions
What people ask first.
What is Paqad?
An open-source software delivery framework from Eliyce. It helps engineering teams use AI to turn requests into reviewed changes through an agreed process: understanding the request, agreeing a plan and specification, building inside the team's rules, review and tests, updating documentation, and delivery to the code host. Each step leaves a record.
Who is it for?
Engineering teams that want to use AI on real delivery work without losing consistency, and the leads who need to see how a change was made. It is designed for teams, including large ones, and a single developer can also install it on one project and use everything on this site.
Does it replace our AI tool, work tracker or code host?
No. Paqad works inside the AI tool you already use and connects to your existing tracker and code host. The AI tool still reads, plans and writes; Paqad supplies the process, the rules, the checks and the record. In the current release the tracker connections are GitHub issues and Jira, and the code host is GitHub.
Does every task go through every step?
No. Paqad first works out what kind of request it has: a code change, a question about the project, a documentation task, a security review and so on. Only code changes take the full delivery path, and small low-risk changes take a lighter version of it. The record shows which path was used.
How strictly is the process enforced?
It depends on the AI tool. In Claude Code and Codex CLI, small programs run before an edit and at the end of a turn, so a missing plan, specification or rule record can stop an edit. Gemini CLI records the work at the end of a turn without stopping anything. The other eight supported tools receive the rules and process as instructions, with nothing that forces them to comply.
Does Paqad send our code anywhere?
Not by itself. Paqad runs on your machine and keeps its files in your repository, with no usage tracking. Your AI tool sends code to its own provider as it does without Paqad, and connections you configure, such as your GitHub login or an Atlassian connection, carry only what those integrations need. In Claude Code and Codex it checks npm for a newer version of itself, which you can switch off. The security page lists every optional service.
What does it cost, and who maintains it?
The framework is free and MIT licensed, with no account or paid service needed. Eliyce B.V., a Dutch software company, builds and maintains it. Community help runs through GitHub. Teams that want guided adoption can look at Eliyce's AI Delivery Programme, a separate service.
See how one request moves through the process.
Then try it on a change of your own and read the record it leaves behind.
Evaluating it for a team? Start with the evaluation path, or ask Eliyce about guided adoption. About Paqad and Eliyce.