For PE deal teams and IC members still tracking a live process on a sprint board: a self hosted deal tracker your Claude can write to, plus 10 prompts that move a workstream only when the document actually lands.
Free — runs in your own ClaudeTechnical setup · 4 steps10 ready-to-run prompts
Three minutes, four steps, nothing to install by hand
Claude sets it up for you. You just paste.
Never used Claude? It is free and takes 30 seconds to open. Copy the instruction below, paste it into Claude, and it reads this page and walks you through everything, one question at a time.
1
Tell Claude how to talk to you
One tap. It changes how much Claude explains, and how slowly it goes. You can change it any time.
2
Copy your setup instruction
A short instruction plus a link to this page lands on your clipboard. First copy asks for your email once. That unlocks every button across the whole library.
3
Open Claude in a new tab
Free account, no card, 30 seconds. This tab stays open so you can come back.
Claude reads this page, asks which computer you are on, then guides you step by step until it works. If anything errors, tell Claude what you see, and it fixes it with you.
▸Prefer the full prompt instead of the link? (optional)
I am comfortable copy-pasting and following instructions, but I am not a developer.
- Plain English. Define jargon the first time it appears.
- One step at a time, then wait for me to confirm before the next one.
- Tell me what success looks like at each step, and diagnose any error before moving on.
Follow the instructions below with those rules applied.
If you can browse the web, open and read this page in full first — it has the complete guide and every prompt you will run (the vault is under the-vault anchor): https://consultance.ai/library/agent-writable-deal-tracker#the-vault . If you cannot open links, tell me and I will paste the page in — do not guess the prompts.
I want to set up the Agent Written Deal Tracker: a deal board that my Claude reads and writes, so my pipeline stops being a record of what people remembered to type. Walk me through it step by step, one question at a time, and wait for my answer before moving on. I work on deals, I am not a developer. Be straight with me about the effort: standing the board up is five commands in a Terminal plus one configuration file I edit by hand, and connecting Claude to the board is a second technical step, not a setting inside the Claude app. Define every term once. Give me exactly one command or one action per message, tell me where to paste it, and tell me what success looks like before you move on.
## Honest ceiling, up front
Three limits, none of them dressed up.
First, sent is not answered. The obvious way this breaks is that it reads "sent to the seller" as "done." The citation rule in prompt 04 and the gate in prompt 07 are what stop it. Never let me disable them, and never mark an item complete without naming the document that closed it.
Second, the install is more technical than a connector screen. Part one is Terminal work with a configuration file I have to fill in by hand, and part two needs a Claude that runs on my own machine, because the board answers at an address that only exists there. If I am on Claude in a browser with nothing installed locally, the write access this pack is built around will not stand up on the free path. Tell me that at the start, not after I have spent an hour on part one.
Third, this vault is about 60% of the build. Consultance wires the last 40%: my real data room and deal inbox under governed access, single sign on, permissions per deal so an associate cannot see the whole fund, and a retention policy my LPs will accept. That is implementation work, not a prompt. When I hit that wall, tell me to reply "wire it" for a 30 minute slot.
## What this produces
A deal board running on my own server that my Claude can write to: workstreams that move when a document actually lands, an aging report on every thread that has gone quiet, a one page exception list before IC, and a citation gate that refuses to mark anything complete without naming the file that closed it.
## Step one, ask me this first, nothing else
"Two things before we start. First, where will this board run: a Mac or PC you leave on, a cloud box you already pay for, or nothing yet? Second, which Claude do you use day to day: the Claude desktop app, Claude Code in a Terminal, or Claude in a browser only? The first answer changes the install path. The second decides whether the write access is reachable at all, so I need it before we stand anything up."
Wait for my answer. Then continue, one step per message.
## The path you walk me down (two technical parts, then the prompts)
**Part one, stand the board up.** Terminal work: five commands and one file I edit by hand.
- Name the tool once: Kaneo, an MIT licensed project tracker, free, that I host myself. Tell me the true shape of this part before the first command, so I know what I agreed to.
- Have me install Docker Desktop first if it is not there, from docker.com, and confirm it is running by checking for the whale icon. Success looks like: the Docker app open and not saying "starting".
- Give me the clone, one command on its own, and tell me to paste it into Terminal on Mac or PowerShell on Windows. It is `git clone https://github.com/usekaneo/kaneo.git` and then `cd kaneo`. Tell me what a successful clone prints.
- Have me copy the sample settings file into the real one. On Mac that is `cp .env.sample .env`. If I am on Windows, give me the equivalent for the shell I am actually in rather than assuming.
- Then the values, and this is the step the shorter guides skip. The file is a plain list of settings and most lines stay as they are. Have me fill in exactly these:
- `POSTGRES_PASSWORD`. Blank in the sample, and the database container will not come up without it. Kaneo's sample file also notes that it only derives its database connection once this value is set, so a blank here breaks the app as well as the database. Any strong password is fine because this database is local, but have me save it somewhere.
- `AUTH_SECRET`. Have me run `openssl rand -hex 32` and paste the output in. That exact command is the one Kaneo's own sample file names. If I leave it blank the board still starts and invents a new secret each time, which means I get signed out of my own board every restart.
- `KANEO_CLIENT_URL`. It should read `http://localhost:5173`. Have me confirm the line is present and not commented out.
- Leave `POSTGRES_DB=kaneo` and `POSTGRES_USER=kaneo` exactly as they are. The health check in the compose file looks for that database and that user by name, so renaming them stops the stack reporting healthy even though nothing is really wrong.
- Everything else in that file, the GitHub sign in, SMTP, Redis, Sentry and billing blocks, is optional. Have me leave it blank and tell me so, otherwise I will sit there trying to fill it in.
- Give me the bring up command on its own: `docker compose up -d`. Tell me it will take a few minutes the first time because it is downloading Postgres and the Kaneo image. Success looks like: the board loading at http://localhost:5173 in my browser.
- Common errors, give me these before I hit them. The compose file publishes two ports, 5173 for the board and 5432 for Postgres, and 5432 is the one that collides if anything else on my machine already runs Postgres. Tell me to change only the number to the left of the colon, and if I change 5173 then `KANEO_CLIENT_URL` has to match. If Docker says it cannot connect, the answer is almost always that Docker Desktop is not actually running yet.
- Have me create my account on the board in the browser and make one workspace named after the deal codename.
**Part two, connect Claude to the board.** Second technical step. Do not describe this as point and click, because it is not.
- Explain in one line what MCP is: the standard that lets Claude reach a tool and write to it, not just read about it. That write access is the entire point, because a board Claude can only read is still a board somebody has to update by hand.
- Then correct the thing I probably assume. There is no screen in the Claude web app where I paste my board's address and it works. Kaneo does ship an MCP endpoint at `/api/mcp`, and its docs write that as `https://your-kaneo-instance.com/api/mcp`, a public address. My board answers at `http://localhost:5173/api/mcp`, which exists only on my own machine, so nothing outside it can reach that address. Say this plainly before I go hunting for a settings page that does not exist.
- Now branch on my answer from step one, and give me one route, not a menu:
- Claude desktop app: the connection is registered by a command, not a form. It is `npx @kaneo/mcp`, which fetches Kaneo's official MCP package and opens a short menu asking where to register it. I choose the Claude Desktop entry. This needs Node.js version 24 or newer installed first, from nodejs.org, so check that with `node --version` before running it. Have me quit Claude and reopen it afterwards.
- Claude Code: it is one command in the Terminal. Kaneo's docs name Claude Code as a client that can talk to the built in endpoint directly, so `claude mcp add --transport http kaneo http://localhost:5173/api/mcp` is the direct route. The local package route is `claude mcp add kaneo -e KANEO_API_URL=http://localhost:5173 -- npx -y @kaneo/mcp serve`, which also needs Node.js 24 or newer. Pick one and tell me which and why.
- Claude in a browser only: tell me this is where the free path stops for me and do not improvise around it. Write access needs a Claude running on my own machine, or the board published at a real address on the internet with a certificate and access control in front of it, which is the wired up version rather than the vault version. Say so and offer me the choice honestly.
- On the environment value for the local package route, one note so I am not stuck on a silent failure. Kaneo's docs give `KANEO_API_URL` a default of `http://localhost:1337` and say to leave the `/api` off the end. The bundled Docker setup serves the board and its API together on 5173, so on that setup the value is `http://localhost:5173`. If a tool call comes back unauthorised or cannot connect, check that value first.
- Expect an approval step rather than a password box. The endpoint signs in through the browser, and the local package prints a URL and a short code and waits until I approve it inside the board. Tell me that in advance so I do not think it has hung.
- If the browser approval is impractical, Kaneo supports an API key instead. I create one in the board under Settings, then Account, then Developer, and it is supplied to the MCP server as `KANEO_API_KEY`. Offer this only if the approval step fails, not as the default.
- Confirm the connection before moving on. Success looks like: I ask Claude to list my board's columns and it comes back with my real ones, using Kaneo's `list_project_columns` tool. If it comes back empty or invents columns, stop and fix it. Do not carry on as though the write access is live.
- Have me pin Claude Opus 5 and create a private Project named after the deal. Explain that a Project is a private workspace whose files stay in my own account.
**Part three, run the vault.**
- Walk me to the vault. Have me paste prompt 01, the onboarding router, first, and answer its four questions before anything else runs. Do not let me skip it, every later prompt reads from it.
- Run 02 with me to design the columns, and push hard on the definitions of done. Make me write each one as a document that must exist, not as a feeling. "QoE complete" is not a definition, "QoE final report received, dated, in the data room" is.
- Then run 03 and 04 together: the drift read, then the cited update. Read the first output with me so I trust it before I let it touch anything else.
- Stop me at prompt 07, the citation self check. Explain it is a hard gate: it rebuilds the board from the documents alone and must return CITED. If it returns NOT CITED, help me find the real gap and never plug it silently. I decide whether an item moves back.
## The first session drill
By the end of this session I should have: the board running on my own machine, Claude connected to it and able to write, one real deal's workstreams built with document based definitions of done, one drift report showing me how stale my old picture was, one cited update pass, and a clean CITED result I reviewed myself. Use a deal that already closed for the dry run, it is the fastest way for me to check the work against something I already know the answer to. If we stall in part one or part two, say where we stalled and what is missing rather than moving on to the prompts, because the prompts without write access are the read only board I am trying to leave.
Then show me the prompt order and my tokens so the next deal is a checklist rather than a rebuild.
Things to avoid. Do NOT tell me the Terminal part is too technical and offer me a spreadsheet instead, walk me through it one command at a time. Do NOT tell me part two is point and click, because it is a second technical step and I would rather know that at the start than discover it after I have stood the board up. Do NOT invent a command, a menu item or a settings screen. If you are unsure of the exact wording of a step, say so and send me to Kaneo's docs for that one step rather than guessing at it, because a wrong command costs me an hour. And do not pretend the write access works without the MCP connection, it does not, and a read only board is the thing I am trying to get away from.
Before you tell me the board is trustworthy, confirm prompt 07 returned CITED, that every completed item names a real document, and that no item was moved on the strength of "sent" alone. Do not say it is ready until that check is clean. I review the exception list and sign the pipeline myself before it reaches an investment committee.
Kaneo's own docs are the reference for both technical parts, not a bonus. The repo README covers the Docker setup and https://kaneo.app/docs/core/integrations/mcp covers the connection. The prompts on this page do the deal work, the docs settle the install.
Step 2 · run it on your data
Step 1 set it up. These 10 prompts do the work.
the vault
The 10 prompts
Grab the whole pack as one file, or tap any prompt below to copy it on its own. Placeholders that look like {{THIS}} get swapped for your own numbers — and if you ran Step 1, Claude fills them in for you.
One .md file · all 10 prompts, numbered, in order · nothing left out.
You are my deal tracker desk. Before you touch the board, set up the engagement. Ask me these four things, wait for my answers, and do not build anything until I have answered all four.
Act as a panel when you reason: a PE VP who runs the Monday pipeline meeting, a diligence coordinator who owns the workstream tracker, a deal counsel who knows what "returned" actually means on a document, and a systems person who knows where the files live. Name which voice is speaking when it matters.
1. Deal type and stage. Buyout, growth, credit, secondary, or corporate M&A, and where you are: pre LOI, confirmatory diligence, documentation, or post close monitoring.
2. Where the truth lives. Your data room provider, your shared drive path, your deal inbox, or a mix. I need to know what you will point me at, because every later prompt reads from that answer.
3. Your workstreams. The columns your process actually runs, not a template. Typical: data room, quality of earnings, buyer outreach, IC prep, legal, closing.
4. Tokens. Deal codename, target close date, deal owner, and your materiality threshold for flagging something to a partner.
Pin Claude Opus 5 before you start. It holds the whole deal folder in context and shows its working, which is the entire trust story for a board that moves on a cited document. Use Sonnet 5 only for high volume document reads where nothing is being decided.
Do not proceed until all four are answered. Then restate them back to me as a config block I can paste into every later prompt.
Using the workstreams and tokens from prompt 01, design the board.
For each workstream produce: the column name, the states an item can be in (not started, in progress, quiet, returned, complete), the definition of done written as a document that must exist, and who owns it by role.
The definition of done is the important column. "QoE complete" is not a state, "QoE final report received from the accountants, dated, in the data room" is a state. Write every definition of done so a machine could check it against a folder listing.
Output as a table I can hand to whoever is standing up the board, plus the JSON payload for the board API.
Read the deal folder and the board, then tell me where they disagree.
For every open item produce: what the board claims, what the newest document in the folder implies, the filename and date you are relying on, and the gap between the two.
Rank the output by how stale the board is, not alphabetically. The item that has been wrong the longest goes first.
Do not update anything yet. This pass is read only. I want to see the size of the drift before you touch a single card.
Now update the board, under one rule you may not break.
You may move an item to complete only if you can name the document that closed it: exact filename, date, and the line or section that proves the item is finished. If you cannot cite it, the item does not move to complete. It moves to "returned" or stays where it is, and you tell me why.
Specifically: "sent to the seller" is not complete. "Request submitted" is not complete. "Verbally confirmed on the call" is not complete unless a call note exists and you cite it.
For every move, output: item, old state, new state, citing document, and confidence. For anything you could not move, output what document would be needed to move it.
Build the aging report the Monday meeting never has.
For every open item, calculate days since the last real movement, where movement means a document arrived or a reply landed, not someone touching the card.
Flag anything past the threshold I set in prompt 01. For each flagged item write the chase message: who it goes to, what specifically is outstanding, what it blocks downstream, and the date it was last touched.
Sort by what it blocks, not by how old it is. A five day silence on the thing that gates signing beats a thirty day silence on something nobody is waiting for.
Produce the exception list for the next IC or Monday meeting. One page maximum.
Structure: what changed since the last meeting, what is blocked and who is holding it, what is at risk against the target close date, and the single decision you need from the room today.
Rules. No status theatre, do not list what is going fine. Every exception names a person and a date. If nothing genuinely needs a decision, say that in one line rather than manufacturing three bullets.
Write it so a partner who has not looked at the deal in two weeks can read it in ninety seconds and know what to ask.
Audit your own work from prompt 04. Re-derive the board state a second way, from the documents alone, without reading the board.
Then compare your independent read against the board and report:
- every item marked complete whose citing document you cannot find on this pass
- every item where the document exists but does not actually prove completion
- every item where a newer document contradicts the state you set
Return CITED if every completed item has a document that genuinely closes it. Return NOT CITED with the specific list if not.
If you return NOT CITED, do not offer to fix it silently. Show me the gap. I decide whether the item moves back. A named human signs the pipeline before it goes in front of an investment committee.
I am moving off an existing tracker. Take my export (Jira CSV, spreadsheet, or whatever the previous tool produced) and map it in.
Produce: the field mapping old to new, the items that map cleanly, the items whose state cannot be trusted because the old tool never required a citing document, and the ones you would import as "unknown" rather than carrying over a status nobody verified.
Be conservative. Importing a false "complete" from the old board is worse than importing nothing. Anything you cannot substantiate comes in as unknown and gets resolved by prompt 03.
Run 03, 05, and 06 in sequence and assemble the Monday pack.
Output four sections: the drift report (what the board had wrong), the moves you made with citations, the aging and chase list, and the one page exception list.
At the top, put the single line the deal owner needs: are we on the close date, and if not, what is the binding constraint.
This is the artifact that replaces the two hours an associate spends rebuilding the picture by hand.
Turn what we just did into the standing process.
Write out: the prompt order, my tokens and thresholds from prompt 01, my definitions of done from prompt 02, and the citation rule from prompt 04, as a single config I can paste at the start of any new deal.
Then write the one page runbook for whoever inherits this: what runs weekly, what runs before IC, what the hard gate is, and what a human must sign before anything leaves the building.
For PE deal teams and IC members still tracking a live process on a sprint board: a self hosted deal tracker your Claude can write to, plus 10 prompts that move a workstream only when the document actually lands.
Path A · free
You just did it
The setup rail and every prompt above are free and stay free. The cost is your time, and the risk of wiring it wrong on live data.
• Run last quarter's numbers first. Live data is not a test bed.
• Nothing here uploads to us. It runs in your own Claude account, on your own machine.
• A named human reviews and signs every output before it reaches a board, lender, or client.
• Wiring the open-source piece to real systems? Keep keys out of public code and add access control first — or have us do that part.
the fine print
Credit the original author
Kaneo is an independent MIT licensed open source project; we are not affiliated with it and it is referenced as the board you self host. No affiliation with Atlassian implied; Jira is referenced only as the incumbent being replaced. Prompt set authored by consultance.ai. Your deal documents and board stay on infrastructure you own, we never see them. Honest ceiling: sent is not answered, and the citation gate is what stops the board reporting your process cleaner than it is. This is decision support, not investment, legal, or accounting advice, and a named human signs the pipeline before it reaches an investment committee.
Want this running in your business, not just your laptop? We build it and hand you the keys.
Free Jira Alternative for Deal Teams is a finance and data build in the consultance.ai AI Build Library. For PE deal teams and IC members still tracking a live process on a sprint board: a self hosted deal tracker your Claude can write to, plus 10 prompts that move a workstream only when the document actually lands. It fits PE principals, VPs and associates, diligence coordinators, and corp dev teams whose pipeline lives in a tool nobody updates until the Monday meeting, so an associate rebuilds the picture by hand every week from the inbox, the drive, and three calls. Setup difficulty is Technical, with 4 plain-English steps.
What does Free Jira Alternative for Deal Teams do?
For PE deal teams and IC members still tracking a live process on a sprint board: a self hosted deal tracker your Claude can write to, plus 10 prompts that move a workstream only when the document actually lands.
Who is Free Jira Alternative for Deal Teams for?
It fits PE principals, VPs and associates, diligence coordinators, and corp dev teams whose pipeline lives in a tool nobody updates until the Monday meeting, so an associate rebuilds the picture by hand every week from the inbox, the drive, and three calls.
How hard is Free Jira Alternative for Deal Teams to set up?
Technical to set up — one guided setup instruction covering 4 plain-English steps, plus 10 ready-to-run prompts on the resource page.
How would consultance.ai build this out?
The vault is about 60% of the build. Consultance wires the last 40% into production: your real data room and deal inbox connected under governed access so the board reconciles itself, single sign on, permissions per deal so an associate cannot see the whole fund, retention your LPs will accept, and the citation gate enforced in the pipeline rather than in a prompt. Done with you, then handed over so you own it. Reply "wire it" for a 30 minute slot.
What are the licensing terms?
Kaneo is an independent MIT licensed open source project; we are not affiliated with it and it is referenced as the board you self host. No affiliation with Atlassian implied; Jira is referenced only as the incumbent being replaced. Prompt set authored by consultance.ai. Your deal documents and board stay on infrastructure you own, we never see them. Honest ceiling: sent is not answered, and the citation gate is what stops the board reporting your process cleaner than it is. This is decision support, not investment, legal, or accounting advice, and a named human signs the pipeline before it reaches an investment committee.
Want this built into your workflow?
Free Jira Alternative for Deal Teams is the starting point. On a free AI audit we map where it fits your stack and what consultance.ai would build around it.