From an empty folder to a reviewed deliverable

Cover

What it does

Three things the plugin gives a coding agent, before any deliverable is asked for: the engagement context, a workspace the whole team shares, and a memory that carries between sessions.

The pages that follow show how each one gets built on a new engagement.

Step 01

One command sets up the engagement folder

A consultant makes a folder for a new deal, Project Atlas, which I made up for this walkthrough, and runs the setup command, /setup. Without another prompt, it builds the folder structure, initializes version control, connects three public data sources, registers the hooks and writes the permission set.

Every step is idempotent, so a second run skips what is already there instead of rebuilding it. That matters because the common case is a teammate joining a workspace that already exists.

Step 02

It asks what the deal is, then classifies the engagement

Next it interviews the practitioner, and the interview is one question: who the parties are, what type of engagement this is, and what the firm's role is. That is everything a person has to supply before research starts; every other attribute is derived from the answer or looked up in a public source.

From that answer it classifies the engagement: deal type, side, stage, industry and role. Then it reasons about which documents ought to exist at this point in the deal, so a missing document later reads as a finding instead of a blank.

Step 03

It researches the deal, then asks for corrections and documents

With the deal described, it kicks off researcher subagents to find what is public about it: filings, company registries and the web. Each researcher works in a separate context that is discarded when it returns, so only a compressed summary comes back, with every finding tagged confirmed, inferred or unknown.

Then it asks the practitioner to review: it drafts what it believes first and asks to be corrected, and the correction is the value used downstream. It also asks which deal documents the team can provide now, because not having a document yet is information too.

Step 04

It writes the deal context into six files

What comes out is six files: four context layers, each with one job and a scope written at the top of the file, plus an entity dashboard and a record of practitioner corrections. A fact that belongs to another layer gets pointed at rather than copied, so there is exactly one place to correct it.

Every non-obvious line carries a source marker or an assumption marker. A reader can tell, line by line, whether a claim came from a filing, from a person, or from the machine filling a gap.

Step 05

It reads every document once, and the team queries what it learned

Bulk ingest: drop a folder of deal documents on it. A script counts the files first, so the model never decides how many there are. Then one agent per file parses, a second agent grades each extraction against the original document in a fresh session, and the index is written only when every counted file shows up as parsed or unreadable. When two documents disagree, the way the term sheet and the separation plan disagree on the transition exit date, both values are kept, both sources are cited, and the conflict stays flagged until a person resolves it.

Substrate: everything found lands in a shared record inside the workspace, tagged with a fingerprint of the file it came from, so when a teammate runs the same folder only new or changed files get read. Any teammate can then ask a question in plain language and get the team's current answer with source and date attached, plus warnings: what that answer replaced, and what still contradicts it.

Step 06

It logs every work session automatically, for the whole team

After substantive work, the session appends an entry: what changed, what is still open, and a key back to the full transcript. Open items are the part worth keeping, because the transcript already holds everything else.

The log is also per-person. A whoami check at the start of every session resolves who is working, entries route to that person's own file, and the team's files are read together as one log. The same view answers what you did this week and what the rest of the team has been doing on the deal, and a guard stops any session from writing into a teammate's file.

Nobody types it, and nobody is asked for permission to write it. A log that depends on someone remembering is a log that stops after week two.

Step 07

It backfills sessions nobody logged

On the first session of a day, a reconciler reads the recent transcripts and looks for sessions that did real work and never logged. It backfills those and skips anything trivial, because a missing row beats a noisy one.

It writes its own daily marker only after it finishes, so a failed run comes back tomorrow instead of marking itself done. Older entries roll into a monthly archive file.