Decide what to measurebefore the feature ships
The tracking plan is the document everyone agrees is essential and nobody writes: which events fire, what properties they carry, who reads the dashboard afterwards. Khint drafts it from the feature spec you already wrote, matches the event names your team is already using, and publishes it where the engineers will find it.
The spec is written,
the measurement is not
Instrumentation is decided last, in a hurry, usually in a thread the week before release. Then the feature ships, the dashboard is empty, and nobody can say whether it worked. The work is not hard, it is tedious: read the spec, list every user action worth counting, name each event the way the last twelve were named, and say what each one carries. Khint runs that pass from the spec file itself, with an agent you save once and reuse on every feature.
The real palette running a saved workflow: the drafting steps run first, then the last step writes the finished plan into the tool your engineers read.
From feature spec to an agreed tracking plan
Instrumenting a “Checkout v2” release, from the spec you already have.
Open a session for the release
Start a Memory session called “Checkout v2 instrumentation”. Every agent you run from now on is logged to it, and Khint keeps a compact running summary that rides along on the next prompt. So when you draft the events for step four of the funnel, the model already knows the three you settled on earlier and the property names you chose. See how Memory works.
Point the agent at the spec file, not a copy of it
A PRD is twenty pages, so pasting it is the wrong gesture. Give the agent a Document input and pin the file: Word, PowerPoint, Excel, a text or Markdown draft, or a PDF that has a real text layer. Khint reads it locally, and for a long document it works from a compact digest it caches and only regenerates when the file actually changes. See how document agents work.
Draft the events, the properties, and the triggers
Save an agent like “Draft the tracking plan”. No prompt yet? Type a one-line description and press Generate, then Improve to sharpen it later. Ask it for the shape your team reviews: one row per event, with the user action that triggers it, the properties it carries, the screen it fires on, and the question the event is supposed to answer. Anything the spec does not decide comes back as an open question instead of an invented answer.
Match the names you already use
A plan that invents a thirteenth naming style is worse than no plan. Turn on Search Knowledge on the agent and it searches your own indexed Jira and Confluence for the events already documented, then reuses that vocabulary. The index is built on your machine and searched locally, at no credit cost. If the catalog only exists inside your analytics tool, capture that screen instead and Khint reads the names off it. See how Knowledge and Capture work.
Publish it, then file the ticket
Connect Atlassian and the palette adds a Confluence Create page row: the plan lands as one page the engineers can comment on, and the page URL comes back as the result. From the same shortcut, a Jira Create issue row turns it into the instrumentation ticket, with the project, issue type, assignee, and labels filled in on the card before anything is written. One write per run, so publishing stays deliberate. See how integrations work.
Spec to published plan, in one shortcut
Up to five steps in series: AI agents first, then the write that puts the plan where the team reads it.
The second agent is the one that earns its place. It reads the drafted plan and checks it against the convention: no two events with the same meaning, property names in one style, every event tied to a question somebody actually asks. Swap either step for your own house version, and the whole thing stays one workflow behind one shortcut. You can describe the workflow in plain language and let Khint build the steps, then adjust them on the rail.
What it will not do for you
A tracking plan is a contract between product and engineering, so it is worth being exact about where the machine stops.
It does not read your codebase
The plan is drafted from what you point it at: the spec file, the selected text, the captured screen. Khint has no access to your repository, so it cannot tell you which events are already implemented, only which ones are already written down.
It does not instrument anything
The output is a document, not code. Nothing is added to your analytics SDK and no event is sent anywhere. The implementation stays with the engineers, which is exactly why the plan has to be readable before they start.
It will not invent your convention
Event naming is reused from what your indexed Jira and Confluence already contain. With nothing indexed yet, the agent proposes a consistent scheme and says so, rather than pretending it matched a standard it never saw.
It writes once, when you say so
A workflow ends with a single Confluence or Jira write, and the palette shows you the target before the call. Nothing is published in the background, and a run you cancel never lands a page or a ticket.
Why not just ask a chatbot for an event list?
A chatbot will happily produce twenty plausible event names, and none of them will be the ones your team uses. That is the whole difficulty of a tracking plan: the vocabulary already exists, scattered across old tickets and a wiki page somebody wrote two quarters ago. Khint reads the spec file in place, searches your own indexed Jira and Confluence for the names in use, carries the release context through Memory, and publishes the result where the build team reads it. The spec never leaves your machine except as the text you deliberately send, and the index that makes the matching possible is stored locally and never synced.
Common questions
What does Khint actually produce for a tracking plan?
A written plan you can review and publish: one entry per event, with the user action that triggers it, the properties it carries, the screen or step it fires on, and the question the event exists to answer. You define that shape once in a saved agent, so every feature comes back in the same format. Anything the source material does not decide is returned as an open question rather than a guess, which is what makes the plan safe to hand to engineering.
Can it read the PRD file directly, or do I have to paste it?
Directly. An agent can take a Document as its input: pin the file once and run the agent on it from the palette. Khint reads Word, PowerPoint, Excel, OpenDocument, RTF, plain text and Markdown, and PDFs that carry a real text layer. Long documents are condensed into a compact digest that is cached on your machine and only regenerated when the file changes, so a twenty-page spec does not have to be re-read from scratch on every run.
How does it reuse the event names we already have?
Khint can keep a local index of your Jira, Confluence, Notion and Linear content in a database on your own machine. Turn on Search Knowledge for the tracking-plan agent and each run searches that index for the events and properties already documented, then feeds the closest matches to the model as context. The search runs locally, costs no credits, and adds no noticeable delay. Nothing is indexed until you connect a source and switch it on.
What if our event catalog only exists in the analytics tool?
Capture it. The palette can select a region of your screen and pull the text out of it, so the event list sitting in your analytics tool's UI becomes text the drafting agent can use. There is also a Capture and ask mode if you want to question the screenshot first, for example to have the naming pattern described before you draft anything new.
Does our unreleased feature spec leave the device?
An agent only ever sees what you point it at: the text you selected, the document you pinned, plus the compacted summary of your active Memory session if you opted in. Memory sessions live in a local SQLite database and are never synced to Khint's servers, and the Knowledge index is built and searched on your machine only. You can also switch on PII redaction per agent, so emails and phone numbers are replaced before anything is sent.
Write the tracking plan before the launch, not after
Free with 300 credits a month, about 10 AI actions a day. No credit card. Save the agent once, run it on every feature you ship.