> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jinn.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Jinn for developers

> Ask a skipped call what was decided, find out why the code was written that way, and hand the spec to your coding assistant as Markdown.

This page sets Jinn up for development work, so you can skip the sync without missing what was
decided. Once it's set up, you get:

* The decisions from a call you skipped, written up for a developer and open to questions
  ([step 2](#2-get-a-developers-write-up-after-a-meeting), [step 3](#3-ask-the-meeting-what-you-missed))
* The reason behind code nobody can explain, from the meetings and docs where it was decided
  ([step 4](#4-find-out-why-it-was-built-this-way))
* The spec as Markdown, ready for your coding assistant
  ([step 6](#6-take-the-spec-into-your-own-tools))

Step 1 you do once. Steps 2–6 are what you do every week.

## 1. Get into your team's project

Everything below happens inside a [project](https://docs.jinn.so/projects/manage-projects.md): the one where your team's
calls and specs land.

1. Ask whoever has **Full access** on that project to add you.
2. Ask for **Can edit** access rights. **Can view** is enough to read meetings and ask
   questions, but writing a doc needs edit rights.

## 2. Get a developer's write-up after a meeting

Somebody on the call records it, and Jinn writes out who said what. Then AI
[agents](https://docs.jinn.so/agents/add-an-agent.md) write it up, each one reading the meeting through a particular
role. **Default** is built into every project and writes a summary and the action items for
everyone, on its own. A developer agent reads the same meeting for what changes in the code:
decisions about APIs, data and dependencies, who made them, and estimates nobody questioned. It
starts only when you ask:

1. Open the project, go to **Recordings** and open the meeting.
2. Click **Add agent** at the end of the row of agents, and pick your team's developer agent.
3. Read its write-up next to Default's. If a point is wrong, fix it in place — what you write is
   what everyone reads from then on.

There's no ready-made developer role among the agents, so a workspace admin sets one up from
**Start blank**. If your team doesn't have one yet, send your admin what it should read for.

> [!TIP]
>
> For example: *You read engineering discussions the way a senior developer does. Note every
> decision that changes an API, a data model or a dependency, and who made it. List open
> technical questions and estimates nobody challenged. Ignore small talk and status updates.*

## 3. Ask the meeting what you missed

When the write-up doesn't answer your question, ask the recording instead of listening to it.

1. On the same recording, click **Chat**. The chat reads only this meeting: its transcript and
   what the agents wrote about it.

2. Ask the question you'd have asked on the call.

   > [!TIP]
   >
   > For example: *What did we agree about the payments API? Did anyone take on the migration,
   > and by when?*

3. If an answer sounds off, check it against the transcript on the same page, where the audio
   is there to play.

See [reviewing a meeting](https://docs.jinn.so/meetings/review-a-meeting.md).

## 4. Find out why it was built this way

Git blame tells you who changed a line. It doesn't tell you what was said on the call before
they changed it.

1. Open the project and click **Chat**. The chat starts on that project and reads all of its
   recordings and docs.

2. Ask in plain words.

   > [!TIP]
   >
   > For example: *Why did we drop the old checkout? Who decided, and what was the alternative?*

3. Open the link under the answer and read the original conversation instead of trusting a
   summary of it.

When you want the passage itself rather than an answer about it, press **⌘K** from anywhere
and describe it. [Search](https://docs.jinn.so/find/search.md) finds what was said by meaning, even where nobody used
the word you typed.

## 5. Write the spec with the team

A spec with five versions in five chats isn't a spec.

1. Click **Add** in the left sidebar, then **New doc in project**, and pick the project.
2. Write. When a teammate has the same doc open, your changes reach them without a reload.
   Markdown shortcuts work: `## ` makes a heading, `- ` and `1. ` start lists.
3. Type `@` to link the docs the spec depends on.
4. To go back to what it said before the last edit, open the doc's **⋯** menu and choose
   **View history version**.

See [writing a doc](https://docs.jinn.so/docs/write-a-doc.md).

## 6. Take the spec into your own tools

Docs and write-ups leave Jinn as Markdown, which is what a coding assistant reads best.

* **A doc.** Open the doc's **⋯** menu and choose **Export as Markdown**.
* **A write-up.** Click **Export** above an agent's text and save it as Markdown, or **Copy** to
  put the whole of it on your clipboard for a ticket or a prompt.

There's no automatic hand-off to a tracker, so action items go there by copy and paste. Leave the
reasoning in Jinn: the tracker says who's doing what, and the project says why.

## Where to go next

> [card] [Jinn for QA engineers](https://docs.jinn.so/for/qa-engineers.md)
>
> Know what to retest after every meeting, and find the earlier report.

> [card] [How your AI is powered](https://docs.jinn.so/workspace/ai-and-indexing.md)
>
> Whose account the AI runs on, and what stops quietly.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.