Client Intake

Client Intake

What this does

Takes a client's own account of a matter — however disorganised, repetitive, or blended with opinion — and restructures it into a chronology and matter summary, with every piece of information tagged by how solid it actually is: something the client directly observed, something they were told by someone else, their own interpretation of another party's motive or intent, or something they are simply assuming without having checked. It does not analyse the legal position. A narrative read once and structured is the product; a legal conclusion is not.

Before you start

The narrative itself. A transcript, notes, an email, or a direct account. This is the only blocking input — there is nothing to structure without it.

Not blocking, ask once and proceed on a reasonable default without it: what the summary is for — a file note, a brief to counsel, the basis for an initial advice. This shapes emphasis, not content: a brief to counsel should foreground the chronology and the gaps; a file note can be flatter.

Method

1. Read the whole narrative once before structuring anything. Clients rarely tell a story in order, and a detail mentioned in passing halfway through is often the fact that reframes something said at the start. Structuring on a first pass produces a chronology with the wrong emphasis.

2. Identify every party named, their role, and their relationship to the client and to each other, exactly as the client describes them — do not infer a legal relationship (employer, guarantor, agent) the client has not actually stated.

3. Build the chronology strictly from what is actually said. For each event, record the date as Confirmed (the client gave a specific date), Approximate (a range or relative reference — "a few months ago," "sometime last spring"), or Undated (no time reference given at all). Do not convert an approximate reference into a specific date to make the chronology look tidier.

4. Tag every substantive statement by its evidentiary status. First-hand fact — the client directly did or observed this. Secondhand fact — the client was told this by someone else; name who, if given. Inference — the client's own reading of another party's motive, intent, or state of mind ("they did this to force us out"). Assumption — something the client is treating as established without having actually verified it ("I assume they got my email since I sent it"). Keep these categories visibly separate; do not fold an inference into the chronology as if it were a fact of what happened.

5. State what the client actually wants, separately from the facts. Clients routinely narrate the story and the desired outcome in the same breath; pull the sought outcome out as its own line so it is not mistaken for a fact about what happened.

6. Note every document the client refers to but has not supplied — an email, a contract, a text message, a report — as an evidence gap, not as something whose contents can be assumed from the client's description of it.

7. Flag internal contradictions in the narrative itself — a date or an account of an event that does not square with something said elsewhere in the same narrative. Note both versions and the discrepancy; do not silently pick the one that seems more likely or more favourable.

8. Stop at structure. Do not name a cause of action, assess whether the facts amount to anything actionable, or estimate a likely outcome. If the user wants that, say plainly that this skill only organises the account and point to issue-spotter or legal-risk-assessor for the analysis.

Output

1. Header. Client, matter, date of intake, source of the narrative (call, email, meeting notes, other).

2. Parties. A short table: party, role, relationship to client, as described — not inferred.

3. Chronology. A table ordered by date: Date (with Confirmed/Approximate/Undated marked) | Event | Source (first-hand / secondhand / inference).

4. What the client wants. One or two plain sentences, stated separately from the facts above.

5. Assumptions to test. A distilled list of the inferences and assumptions identified in step 4 of the method, framed as points the lawyer should verify before relying on them — not as findings.

6. Documents referred to but not supplied.

7. Contradictions and gaps. Anything in the narrative that does not square with itself, or a material point the narrative leaves unclear.

Do not

Do not draw a legal conclusion, name a cause of action, or assess risk. That is a different skill's job; this one only structures the raw account.

Do not smooth over a contradiction in the client's own narrative. Flag it and record both versions.

Do not convert an approximate or undated reference into a specific date to make the chronology look more complete than the account actually is.

Do not treat the client's characterisation of another party's motive or intent as an established fact. It is an inference, and belongs in that category.

Do not infer a legal relationship — employment, agency, guarantee — the client has not actually stated, even where the facts suggest one.

Do not assume the contents of a document the client has described but not supplied. Record it as a gap.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rohasnagpal
• Source: rohasnagpal/legal-ai-skills
• License: MIT

Install and usage instructions live in the source repository linked above.