Who Is Working?
The persona defines responsibilities, values, and non-goals.
PersonaKit makes the most sense when you stop asking whether it replaces prompts, skills, memory, or compression. It does not. PersonaKit composes schema-backed project context into a resolved contract for the role, rules, stop points, allowed capabilities, and forbidden actions of a specific handoff.
That matters more as agents get better. A capable agent with good memory and useful skills can still do the wrong extra thing unless the active work mode is visible before the work begins.
How It Compares To What You Already Use
You already use prompts, skills, memory, and maybe the Managed Agents API. PersonaKit does not replace them. It fills the gap each one leaves open, and the through-line is the same in every row: availability is not authorization.
| What you already have | What it does well | What it can't do | Where PersonaKit fits |
|---|---|---|---|
System prompt, CLAUDE.md, AGENTS.md | Sets project-wide defaults the agent always sees. | Cannot tell work modes apart in the same repo. Everything runs under one set of rules. | PersonaKit layers sessions on top: same repo, a different contract per work mode. |
| Saved prompts, slash commands | Reusable task starters that are easy to invoke. | Rules live in plain text, so they cannot be validated, composed from pieces, or proven before handoff. | PersonaKit makes the rules schema-backed, composable, and verifiable, not just text you paste. |
| Model memory | Remembers preferences across conversations. | Not authoritative, not inspectable by a teammate, not version-controlled, not proven before work starts. | PersonaKit is a committed artifact, not a recalled preference. Anyone can read it and git tracks it. |
| Skills, host or API | Teach the agent how to do something: a procedure. | The skill exists whether or not it should run in this work mode. | PersonaKit declares which skills are authorized for this session, not just which ones exist. |
| Managed Agents API | Versioned, reusable agent configs with model, tools, and system prompt. | The boundary is fixed when the agent is created. There is no per-session layer for "this one is read-only, that one implements." | PersonaKit is per-session and per-work-mode. The same agent setup can run under different contracts. |
| MCP servers | Connect external context and capabilities to the agent. | Connecting a server still only makes it available. It does not say whether it should be used this session. | PersonaKit MCP exposes the resolved contract as read-only grounding, so the agent checks what is authorized before acting. |
Recommended path
Learn With ReleaseDesk
ReleaseDesk is the sample product: a tiny release-readiness dashboard with a real bug, a local readiness skill, and a completed PersonaKit root. Start by building its foundation, then continue with the same project through a normal engineering workday.
-
Build The ReleaseDesk Foundation
Fix the readiness bug, then add PersonaKit only when agent boundaries become useful.
Start the product lab -
Continue Into The Workday
Use that same ReleaseDesk project for review, approved follow-up, docs, and a host handoff. Return here after the foundation lab, or use the next-step card at the end of that tutorial.
Next after foundation
Use a host skill Read the contract Compose the pieces Turn a prompt into a contract Export handoff context
Use A Host Skill As The Front Door
If your agent host supports skills, a small grounding skill can make PersonaKit easier to invoke through autocomplete, fuzzy search, or a command palette. The host skill is only the front door: it resolves the PersonaKit contract before action, and PersonaKit remains the authority for what is allowed.
Use $personakit-grounding to resolve the requested PersonaKit session before acting.Open the PersonaKit grounding skill example
Read The Contract
A resolved contract answers the questions that usually get scattered through chat history.
What Kind Of Work?
The directive defines steps, acceptance criteria, verification, and stop points.
Which Rules Apply?
Kits and grounding skills carry durable project guidance into the resolved payload.
Which Capabilities Are Allowed?
Skill authorization makes allowed and forbidden capabilities visible before work begins.
Compose The Pieces
You define a session as the entry point. PersonaKit composes reusable parts into the resolved contract. Operators should not have to copy the same careful-review paragraph into every prompt or maintain several nearly identical skills just to change a boundary.
Persona
Who is acting.
Directive
What kind of work this is, and when to stop.
Kit
Rules that should travel across related sessions.
Skills
Capabilities that may be authorized or forbidden, plus Markdown grounding that applies to this lane.
Session
The composed lane that selects the pieces to resolve together.
Review Composition Example
Review work shows why the pieces stay separate:
| Composition | Result |
|---|---|
behavior-reviewer + behavior-preserving-review | The existing read-only review lane reports findings without becoming the implementer. |
| Same reviewer + a different directive and session | A conceptual implementation-after-approval lane could be separate instead of mutating the read-only lane. |
| Shared review kit or grounding skill | Review discipline can travel across lanes without being pasted into each task prompt. |
| Same skill catalog, different sessions | A capability can stay reusable while authorization is decided by the resolved contract. |
Turn A Prompt Into A Contract
Start with a loose prompt:
Review this bugfix carefully. Stay read-only. Watch for behavior changes and missing tests. Do not edit code unless I approve a fix.PersonaKit asks which parts are durable enough to become reusable structure:
| Prompt Fragment | Contract Piece |
|---|---|
| Review this bugfix carefully. | Persona: behavior reviewer. |
| Stay read-only. | Skill boundary: authorize review, forbid editing. |
| Watch for behavior changes and missing tests. | Directive: review steps and acceptance criteria. |
| Do not edit code unless I approve a fix. | Stop point: implementation requires operator approval. |
The next prompt can shrink because the contract carries the repeated setup:
Operate under behavior-review. Review the current diff and report findings.Study the review-session example
Export Handoff Context
The practical loop is small and inspectable:
- Validate the authored PersonaKit root.
- Resolve the session contract.
- Inspect or export the context.
- Copy the exported grounding into the coding tool you use for the actual work.
personakit validate --root .personakit
personakit contract --root .personakit --session behavior-review
personakit export --root .personakit --session behavior-review