Jinn for developers

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, step 3)
• The reason behind code nobody can explain, from the meetings and docs where it was decided (step 4)
• The spec as Markdown, ready for your coding assistant (step 6)

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: 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 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.

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.
   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.

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.
   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 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.

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