Versioning a Person: Why Personas Ship Releases

You changed your mind about remote hiring in March. If your persona still argues the 2024 position, that is not you anymore, it is a fork of you that nobody agreed to maintain. This is why installs.me personas ship releases, with version numbers, changelogs, and rollback. A person is a moving target; the plugin that impersonates them has to move too, and it has to move the way software moves: in discrete, named, reversible steps.

A persona is a build artifact

Mechanically, a persona on installs.me is a Claude Code plugin: a .claude-plugin/plugin.json with a name and a version, a skills/ directory of SKILL.md files (YAML frontmatter, name and description, loaded on demand), and references/ directories holding the distilled corpus, the positions file, the voice guide, the decision heuristics. All of it is text. All of it diffs.

That last part matters more than it sounds. When Lautaro regenerates his persona after six months of new blog posts, calls, and calendar entries, the synthesis step produces new files, and you can git diff v1.2 against v1.3 and read, line by line, what changed about how he thinks. A changed sentence in references/positions.md is a changed opinion. That is a strange and useful object: a reviewable diff of a person's judgment.

Semver for judgment

Semantic versioning maps onto a person cleanly, once you decide what "breaking" means. For a persona, breaking means: advice that contradicts what an earlier version would have said.

• Patch (1.2.0 to 1.2.1): facts, not judgment. The bio said the exit was 2021, it was 2020. A typo in a reference file. A skill description reworded so it triggers more reliably. Anyone consuming the persona gets the same advice, better sourced.
• Minor (1.2.x to 1.3.0): additive judgment. A new skill appears, say angel-diligence/SKILL.md, because six months of investment memos gave the synthesis enough signal to model how he evaluates a seed deal. Old questions get old answers; new questions get answered at all.
• Major (1.x to 2.0.0): reversed judgment. The persona used to say "raise before revenue in LatAm because the window closes." Now it says "do not raise before $10k MRR." A founder who took the 1.x advice and asks 2.0 for a follow-up gets a contradiction. That is a breaking change in the only API a persona has: its opinions.

The discipline this forces is the point. If the regeneration diff flips a position and you find yourself typing 1.4.0, semver is telling you to stop and write the release note explaining the reversal instead.

Regenerate creates, publish points

The second rule: regeneration never mutates a live version. It creates a new one.

Every regenerate run reads the current sources (Drive, Calendar, transcripts, published writing) and synthesizes a fresh candidate build. That build gets a version number and sits unpublished. The creator reads the diff, corrects what the synthesis got wrong about them (it happens; a persona built partly from meeting transcripts will occasionally mistake a devil's-advocate riff for a held position), and only then publishes.

Publish is a pointer move. The marketplace, a marketplace.json served over a git-backed source, because plugin sources fetched over a URL must be git-backed and relative HTTP paths fail silently, points at exactly one version per persona. Publishing v1.3 means the pointer now resolves there. The v1.2 build still exists, immutable, addressable.

Rollback is the same operation in reverse. If v1.3 shipped with a hallucinated position, you do not regenerate under pressure and hope the synthesis lands better this time. You move the pointer back to v1.2, a known-good build, in seconds, and fix v1.3 offline. Anyone who has run production software recognizes this as the only sane deploy model. It is no less true for a deployed personality.

Consumers stay on whatever they installed until they update, which is exactly right: nobody's lautaro@lautaro-installs changes character mid-session because the source person had a productive weekend of journaling.

Release notes are for the humans who trust you

A persona's users installed it because they trust the person behind it. Silent updates burn that trust. Release notes are how a version of you introduces itself:

## 2.0.0
- REVERSED: no longer recommend raising pre-revenue in LatAm.
  Two portfolio companies raised early in 2025 and both stalled
  on the same problem. Position updated in references/positions.md.
- Added skills/angel-diligence: how I actually run a seed check.

## 1.2.1
- Fixed Sirena acquisition details in references/bio.md.

Notice what the major entry does: it does not just state the new position, it explains the evidence that flipped it. That is the difference between a persona and a chatbot with a system prompt. A person who changes their mind can tell you why. A persona that ships releases can too, and the changelog is where that reasoning lives permanently, greppable, next to the skill files it justifies.

There is also a subtler payoff. The version history becomes a record of intellectual trajectory. Diff v1.0 against v2.3 of any long-running persona and you get something no bio page offers: the positions held, the positions abandoned, and the dates. Careers get more legible when judgment has a git log.

The alternative is worse

Consider the unversioned persona: a single mutable bundle, regenerated in place whenever the creator remembers. No diff to review, so synthesis errors ship straight to users. No rollback, so a bad regeneration means scrambling to regenerate again from the same sources that just misfired. No changelog, so users discover reversed advice by getting burned by it. Every one of these failure modes was solved for software decades ago. Personas are software. Version them like it.

Install a person

installs.me turns your files, calendar and calls into a Claude Code plugin that thinks like you. Anyone installs it with two commands:

/plugin marketplace add https://installs.me/lautaro
/plugin install lautaro@lautaro-installs