Your team is already using AI to write code. The problem is that everyone is doing it differently. One developer is in Claude Code, another in Copilot, someone on the new team swears by Cursor, and there is always one person on Codex. Each of them has set up their assistant by hand, with their own prompts, their own half-remembered configuration, and no shared idea of how the AI should approach a ticket.
So the result is inconsistent, the knowledge lives in people's heads, and none of the assistants can actually see the Jira ticket or the Confluence spec the work is based on. You end up pasting context into a chat window, over and over, for every assistant on the team.
Helper AI (HAI) is a free, open-source npm CLI that gives your whole team one shared AI workflow, whatever editor each member happens to use. It sets up Claude Code, Copilot, Cursor, and Codex the same way, with the same subagents and the same slash-commands, then pulls your Jira tickets and Confluence specs into plain Markdown the AI can actually read.
Everyone keeps their editor. Everyone gets the same setup. And every assistant on the team can finally reach the tickets and specs the work depends on.
The Same Setup, Wherever Your Developers Work
Four developers on four different editors should not mean four different AI workflows, four different sets of prompts, and four different results on the same kind of task.
HAI installs into each environment where that environment expects to find things. Claude Code gets its config in .mcp.json, Copilot in .vscode/mcp.json, Cursor in .cursor/mcp.json, and Codex in .codex/config.toml. There is an "Any editor" mode too, which lays everything out under .ai/ for manual wiring. Whichever one a developer runs, they get the same MCP server, the same seven subagents, and the same six commands. The team matches without anyone agreeing on an editor first.
Your Tickets and Specs, as Readable Markdown
A lot of the context an AI needs to do a task well does not live in the codebase. The reasoning is in a ticket. The acceptance criteria are in a spec. The screenshot showing the bug is an authenticated attachment nobody can fetch without credentials.
HAI closes that gap. Jira issues and Confluence pages land in a local .ai/ directory as plain Markdown, with comments, links, custom fields, and the page tree kept intact. Because it is Markdown on disk, your assistant reads it the same way it reads your source. It is all git-ignored by default, with no database and nothing proprietary, so switching ticket providers later does not change how anyone works.
Since files are pulled directly from the developer's environment, AI doesn't need to use long and costly searches using standard MCP plugins, everything it needs is already there.
Attachments get handled too. Since they sit behind auth, an AI cannot fetch them directly, so the image_download tool pulls them with the right credentials and caches them locally. Your assistant just reads the file.
Hand It a Ticket, Get Code Back
Setup is a one-time thing. After hai init wires up an editor and runs the first sync, the day-to-day is a single command: hand your AI a Jira key with /implement JIRA-123 and it runs the whole job.
It pulls the ticket over MCP, grabbing every issue that ticket links to in a single pass so the AI has the full picture. It researches the specs and the surrounding code. It drafts a plan. Then, once you approve, it implements the work, running the domain agents in parallel and checking each one.
That last part leans on the seven subagents HAI installs, each with a clear job. A researcher and an architect that read and plan but never touch code. Backend, frontend, and refactoring agents that write it. A security reviewer and a verifier that checks it. The implement command splits work across them by domain and runs them at the same time rather than one after another.
Free, Open Source, and Two Commands to Set Up
HAI is released under Apache 2.0 and runs on Node 16 or newer. It is one npm package, and each teammate sets themselves up with two commands:
npm install -g @2amtech/hai
hai inithai init walks through picking an AI provider, a ticket source, and a spec source, then runs the initial sync for you, so the .ai/ folder is ready right away. There is no separate pull to run on day one. Reach for hai pull later, mainly when specs change and you want the latest copy locally.
On the source side you can point it at Atlassian for Jira and Confluence, at a Local provider that reads tickets and specs from folders on disk, or at None when you only want the subagents and commands with no ticket system attached.
Everything stays in the repository and out of git. The tickets, the specs, and the credentials are all local. Nothing about your project leaves for anywhere it was not already going.
Check it out at: https://hai.2am.tech
Build captivating apps and sophisticated B2B platforms
Stunning solutions for web, mobile, or cross-platform applications.
Learn More