Example

Review Session

A read-only review contract that produces findings without becoming the implementer.

Persona behavior-reviewer
Directive behavior-preserving-review
Kits review-guardrails
Authorized Skills read-only-review
Forbidden Skills code-editing, deployment-runner

Adopt This Root

  1. Copy the closest example root into your project.
  2. Rename the copied folder to .personakit.
  3. Revise the session, persona, directive, kits, and skills for your lane.
  4. Run personakit validate before relying on the root.
  5. Inspect the resolved contract before exporting handoff context.

Inspect The Contract Pieces

Start with the session file; it shows which persona, directive, kits, and skills compose this lane.

This example is intentionally non-executing. It shows how PersonaKit can define a review identity without authorizing code editing, deployment, or tool-driven follow-up work.

Use this when the important boundary is separation of authority: the reviewer can identify defects, but cannot quietly become the fixer.

Authority Split

The reviewer reports confirmed defects, risks, and missing validation. If a fix is needed, implementation waits for explicit approval and a separate work mode.

Key Contract Signal

forbiddenSkillIds: code-editing, deployment-runner

Runnable Commands

cd Site/public/examples/review-session
personakit validate --root personakit-root
personakit contract --root personakit-root --session behavior-review
personakit export --root personakit-root --session behavior-review

Expected Validation Shape

Validation summary: personas=1 kits=1 directives=1 intents=0 references=0 skills=3 essentials=1 errors=0

What To Inspect

Why This Matters

Without a separate review session, an assistant may blend reviewer and implementer behavior. PersonaKit makes review identity explicit and keeps execution authority separate.