Remember Persona

Remember persona

personas.md is the user's own prose about the people they write to. Other skills read it so a note to a director does not read like a note to a vendor. This skill is the only thing that writes content into it.

Throughout this skill, personas.md means whatever profile.personas resolves to -- a local file by default, or a Google Drive file. Step 2 and Step 5 are where the two differ; everything else is the same work on the same prose.

Hard rules

Only what the user said. Every word written comes from what the user actually stated. Never infer a trait from a draft, from a thread, from a name, or from a role. If a description is thin, the entry is thin. A one-line entry that is true beats a paragraph that is half guessed.

Behavioural, never evaluative. Record what the person does, not what they are. "Challenges technical claims" is a lens someone can write toward. "Is obstructive" is a verdict, it is worse reviewer input, and this file is a liability if it is ever read over the user's shoulder.

One exception, and it is identity rather than character: Known as. An identifier the user states -- a full name, a handle, a chat ID, an email address -- is recorded verbatim under that label, because it is what lets a @handle in a ledger have a referent. It is the only field that is not a lens, and the only-what-the-user-said rule binds it harder than the rest: an identifier is never derived. See Step 4 § The Known as field.

Silent means append-only, and only for new people. Adding a section for someone with no entry is additive and reversible, so it is written without asking and reported after. Changing prose the user wrote by hand is a different act -- it is proposed, shown in full, and written only on approval.

Silent also means nobody was pasted. A first entry is written unasked only when the user described the person with no pasted material in play -- they told you about a colleague, and that is the whole input. When the description arrives alongside something the user pasted -- a draft, a thread, a transcript, an example, a borrowed template -- the entry is offered once and written on a yes, because material pasted whole can describe people who do not exist and nothing in the paste has to say so. This is a question about provenance, not about whether the text looks invented: asking is what the skill does when it cannot tell, and the confirmation is asked once per person and never again once they have an entry. See Step 1 § Where the description came from.

Scaffold, never hand-build. If the personas file does not exist when this skill has an entry to write, copy ${CLAUDE_PLUGIN_ROOT}/templates/personas.md verbatim and write the entry into the copy, the same way project-log scaffolds a missing ledger. setup-user's create-if-absent rule is untouched: it still copies the same template on its own run, and copying the template twice is idempotent. What changes is that this skill no longer stops and waits for setup-user to have run first.

Scaffolding covers local files only, and a write is never redirected. When profile.personas points at a Google Drive file, this skill writes to that file and never creates one -- setup-user is the only skill that creates a Drive file, per config-writers.md § Who writes what. If a Drive pointer does not resolve, write nothing, say so, and keep the entry in the conversation so the user can retry once the file is reachable. Never fall back to the local default: that would split the user's notes across two stores without telling them.

Never write the personas file from any other skill. A skill that needs an entry recorded runs this one.

Step 0: read the contracts

Read ${CLAUDE_PLUGIN_ROOT}/docs/config-resolution.md before writing anything -- how profile.personas resolves, and the failure-behavior table. Read ${CLAUDE_PLUGIN_ROOT}/docs/config-drive.md for the Drive-specific read and write mechanics, and ${CLAUDE_PLUGIN_ROOT}/docs/config-writers.md for who writes what. Read ${CLAUDE_PLUGIN_ROOT}/docs/response-format.md for how the report in Step 6 is shaped. Do not work from memory of them. If a contract and this skill ever disagree, the contract wins and you say so.

Step 1: get the material

• The user described someone. That description is the material. Use it.
• Another skill routed a description here. Same thing. The description came from what the user said while drafting, not from the draft's own contents.
• A person is named with nothing said about them. There is nothing to record. Say so in one line and write nothing. A name is not a persona.
• The user gave an identifier and nothing else ("Priya Nair is @priya", "D is dana@example.com"). That is material: it is a statement about who a handle refers to, which is the one thing a bare mention never carries. Record it under Known as and leave every other field out. See Step 4 § The Known as field.
• Nothing was given. Ask who, and what about them. Do not go reading threads or drafts to assemble a picture of somebody.

Never mine a draft, a thread or a transcript for traits. The user stating "M challenges every technical claim" is material. M having challenged a claim in a pasted thread is not.

Material that says it is synthetic is not material. Acceptance fixtures, worked examples and anything else that announces itself as invented describe people who do not exist, and this file is a record of real colleagues. Write nothing, say so in one line, and do not ask the user to confirm -- the file said it plainly enough:

That description comes from a test fixture, so I have not recorded it.

Where the description came from

That rule catches material that announces itself. Most invented people do not: a draft pasted on its own says nothing about being a worked example, and a person pasting one is not going to add a line saying so. So the declaration is the fast path, not the guard. The guard is where the description came from, and it is settled once, here, before Step 5 writes anything.

• The user described the person and pasted nothing. They typed it, or they said it while asking for something that carried no pasted block. Their own words about someone they work with. Write it silently, per Step 5.
• The description came in with pasted material, whether it sits inside the paste or in the sentences around it. Offer it, do not write it. A block pasted whole can be a worked example, a template someone sent, or a fixture, and the people in it may not exist. One question, answered once.
• The person already has an entry. No provenance question. Step 5 already proposes every addition to an existing entry, and the question is about the first write only.

When in doubt, offer. The cost of asking is one line the user answers with a word. The cost of guessing wrong is a person who does not exist sitting in a file this tool treats as a record of real colleagues, with nothing afterwards to mark them apart from the real ones.

The question never gates the caller. When another skill routed here, that skill finishes its own work and reports the offer as one line -- it does not wait for the answer, and a review or a draft is never held up by a persona. Offering costs the caller exactly what a silent write cost it: one line in the report. The user answering later runs this skill again for the write.

Step 2: resolve the file

Follow config-resolution.md § Resolution order.

1. Read ~/.claude/daikenja/daikenja.yaml. Malformed YAML is fatal -- report the first line that does not parse and stop. Never rewrite a file you cannot parse.
2. Resolve profile.personas per config-resolution.md § Resolving writing_style and personas. It may name a local file or a Drive file. Default ~/.claude/daikenja/personas.md.

A Drive pointer that resolves is read with the connector's file-download tool -- never the natural-language extraction tool -- and everything from Step 3 on is the same work on the same prose. Step 5 is where the write itself differs.

A Drive pointer that does not resolve ends the run: one notice naming the file and the reason, the entry shown in full so the user still has it, and nothing written anywhere. A download that comes back empty is this same case, not an empty personas file. An empty read cannot be told apart from a file with no entries, and writing on that assumption would replace the user's prose with a file containing one persona:

Your personas are in Drive as <name>, and I cannot read it right now
(<reason>). I have not written anything. Here is the entry, so you can keep it
or ask me again later:

If a local file does not exist, scaffold it. Say so plainly before doing anything else, mirroring project-log Step 3:

No personas.md at <path>. I will create one from the Daikenja template.

Create the parent directory if needed, copy ${CLAUDE_PLUGIN_ROOT}/templates/personas.md to <path> verbatim, and change nothing else in the template -- the placeholder block stays, per Step 3's rule for it. Scaffolding is silent and reported the same way an append is (Step 6): it needs no approval of its own, and the report in Step 6 names both the scaffold and the entry in the same message.

This never blocks a draft: whether the file already existed or was just scaffolded, the entry gets written either way. When this skill was routed to from another skill, the scaffold-and-write happens the same way, and the report goes back to the caller as one line.

Step 3: read what is already there

Read the whole file before writing.

Look for an existing entry for this person. Match on the section heading, generously -- "Sarah", "Sarah Kaur" and "S" are the same person if the user is plainly talking about the same person. When you cannot tell, ask rather than appending a second section for someone who already has one.

Note whether the shipped template placeholder is still present -- the Delete everything below this line marker and the ## <Name or group> example sections underneath it. If it is, leave it exactly as it is. It is the format hint for whoever opens the file next, and removing it is not this skill's call. Mention it once in the report.

Read nothing else out of the file and change nothing you were not asked to.

What you read here stays here. Reading the whole file is necessary to place an entry and to spot an existing one. Repeating what it says about anyone else is not: no summarising other people's entries, no listing who is already in there, no reasoning out loud about how they compare. These are the user's private notes on real colleagues, and they have a way of being read over a shoulder. Say a match exists or does not, and nothing about the neighbours.

Step 4: build the entry

Match the format the file already uses. Read how the existing entries are written -- the heading level, whether the name carries a role after it, whether the fields are bold labels or bullets -- and write the new entry the same way. The file is the authority on its own format, and a user who has settled on a shape has settled it for a reason.

The shape below is the fallback, for a file that has no entries yet to copy:

## Sarah

**Known as.** Sarah Kaur. `@sarah`, sarah.kaur@example.com.

**Who they are.** Director of platform engineering. Signs off on the migration
budget.

**What they want from you.** The decision and what it costs. No project
history.

**How to write to them.** Short. Lead with the ask.

*Recorded by Daikenja on 2026-08-16 from what you said while drafting. Edit or
delete this freely.*

Write only the fields the material supports. Five labels with two of them guessed is worse than one label that is true. The template's labels are Known as, Who they are, What they already know, What they want from you and How to write to them; use the ones that fit and drop the rest.

Relational context goes under Who they are -- "reports to V", "works closely with K's team". It is not a lens, but it is a fact the user stated and it matters for how a message lands. It gets no field of its own.

The Known as field

It holds the identifiers that mean this person: their full name, the handles they go by, a chat ID, an email address. It exists so that a @handle written in a project ledger has somewhere to resolve to: so /daikenja:meeting-review can attribute a transcript's speaker to the handle already recorded for them rather than deriving a new one, and so /daikenja:project-log can tell a genuinely new colleague apart from a second spelling of one already recorded -- see ${CLAUDE_PLUGIN_ROOT}/docs/ledger-format.md § Who an owner handle refers to.

Never derive an identifier. @priya does not follow from "Priya Nair", an address does not follow from a name, and a chat ID follows from nothing. Write the ones the user actually gave and leave the field out entirely when they gave none. A wrong identifier is worse than a missing one: it points a later reader at the wrong person with the same confidence as a right one.

That is not a contradiction of how a ledger entry is attributed. project-log and meeting-review do turn Priya Nair into @priya when nothing here says otherwise, and they are right to: an entry needs an owner token and that derivation is how one is minted. Writing it here is a different claim -- that the identifier is this person's, durably, for anything that resolves a handle later. Minting a token for one line is cheap to correct. Recording it as a fact is what a later reader trusts.

Write each identifier as the user wrote it. Do not normalize case, do not strip an @, do not expand an initial into a full name. The point of the field is to match what turns up elsewhere.

A person may have several. That is the field working: two handles listed here are what stops the second one being reported as somebody new.

It is optional, and an entry carrying only this field is still worth writing. A section with Known as and nothing under it says who a handle refers to without claiming to know how to write to them. That is the whole of what the user said, and it is what a bare mention of a name is not -- Step 1 keeps the two apart.

The provenance line is required on every entry this skill writes. Writes are silent, so the file has to say which entries came from Daikenja and when. Get the date from the environment with date +%Y-%m-%d -- the local date, never one recalled from memory, and never a relative date.

Step 5: write

New person whose description came in with pasted material. Write nothing yet. Show the entry in full and ask one question:

M has no entry, and that description came in with the draft you pasted. Add
them to ~/.claude/daikenja/personas.md?

  ## M

  **Who they are.** Runs the billing team.
  **How to write to them.** Short. Lead with the ask.

I have not written anything yet.

Approval is the user saying yes in this conversation, and it covers this one person. Anything else -- silence, a reply about the draft, a yes to a different question -- is not approval, and the entry stays in the conversation where the user can still use it. On a yes, the write is the append below and the report is Step 6's. On a no, write nothing and say nothing further about it.

When this skill was routed to from another skill, the question goes in that skill's report and the run ends there. The caller does not wait for an answer and nothing is written this run, per Step 1 § Where the description came from.

New person, no existing entry. Append the section at the end of the entries, immediately after the last persona section -- not at the end of the file. A file may carry trailing sections that have to stay last: standing drafting rules, notes to self, a template block. Dropping a person underneath those breaks the file's own structure.

In Drive, the placement is the same and the write is a replacement. The connector cannot update a file's content, so the write follows config-drive.md § Writing replaces the file: download, splice the entry into the downloaded bytes at the same position, create a new file with the same name in the same daikenja folder, read it back to confirm, and only then trash the old one. Never trash first -- a create that fails after the old file is gone destroys prose that cannot be recovered. A replacement created outside the folder is worse than a failed write: it holds everything and no longer resolves.

Splice, never regenerate. What gets written is exactly what was downloaded plus this one entry. Everything else -- hand-written sections, the template placeholder, spacing, trailing notes -- is carried across untouched. This skill already never reformats a local file, and a whole-file replace makes that rule load-bearing rather than merely polite.

Write it without asking. Touch nothing else -- no reordering, no reformatting, no tidying, and no normalizing a line a human wrote by hand.

Existing entry, and the user said something new about them. Do not write. Show the exact addition and the exact line it would sit after, and wait:

S already has an entry. I would add this under it:

  **How to write to them.** Short. Lead with the ask.

Add it?

Approval is the user saying yes in this conversation. Silence is not approval, and neither is the user replying about something else. Approval of one addition does not carry to the next.

Existing entry, and the user is correcting it. Same as above, and show what the current text says as well as what it would become. Rewriting the user's own prose always gets shown in full first.

Step 6: report

Silent means unannounced beforehand, not invisible. Every write is reported after it happens, naming the file and showing what landed, so it can be edited or deleted:

Learned: added S to ~/.claude/daikenja/personas.md.

  ## S

  **Who they are.** Director of platform engineering.
  **How to write to them.** Short. Lead with the ask.

When the file did not exist and this skill scaffolded it, the report says both in one message:

Created ~/.claude/daikenja/personas.md from the template, then learned: added
S to it.

  ## S

  **Who they are.** Director of platform engineering.
  **How to write to them.** Short. Lead with the ask.

When this skill ran inside another skill's work, that report is one line in the caller's own output rather than a block of its own -- Learned: added S to ~/.claude/daikenja/personas.md. The user can open the file to see the entry.

An entry that was offered and not written reports as one line too, and it says plainly that nothing was written:

Not learned: S came in with the material you pasted, so I have not added them
to ~/.claude/daikenja/personas.md. Say the word and I will.

Report the number of entries, not an assessment of them. Do not congratulate the user on the persona, and do not summarize what you think it means about the person. The report follows response-format.md: the result leads, and a write with nothing unusual about it earns nothing beyond the shapes above.

Failure cases

One notice line, then continue with reduced behavior. Hard-stop only when the missing thing is the task itself.

What this skill does not do

• It does not read personas.md on anyone's behalf. The skills that need a persona read it themselves.
• It does not inspect or overwrite personas.md when the file already exists. Scaffolding only happens on absence, the same test setup-user uses, and setup-user's own create-if-absent rule is untouched by this skill.
• It does not write daikenja.yaml. /daikenja:setup-user owns the profile: block, /daikenja:setup-project owns a project's projects: entry, and last_checkpoint belongs to project-catchup.
• It does not record project decisions or open items. That is /daikenja:project-log, which writes the ledger and never touches this file.
• It does not build a persona by reading past messages, threads or transcripts. Only what the user states is recorded.
• It does not decide whether a person is real by reading the text. It asks, once, whenever the description arrived with something the user pasted.
• It does not hold up the skill that routed to it. The question travels back as one line and is answered whenever the user gets to it.