Configuration

Every persona skill has a per-repo configuration file that controls two things: the active flavor and the preservation toggles (which content stays in plain English regardless of register). This page is the authoritative reference for the config model; per-persona pages link here rather than repeat the same explanations.

Where the config lives

When installed via the marketplace, each skill's config file lives at:

.claude/skills/<persona>/<persona>.config

So:

• .claude/skills/shakespeare/shakespeare.config
• .claude/skills/pirate/pirate.config
• .claude/skills/gen-alpha/gen-alpha.config
• .claude/skills/toronto-mans/toronto-mans.config

Edit these directly. The files are human-readable YAML-shaped text with inline comments.

Format

# ─── Active flavor ──────────────────────────────────────────
# courtly  — measured, formal (default)
# tavern   — bawdy, exclamatory
# sonnet   — courtly + rhymed iambic couplet on completion
flavor: courtly

# ─── Preservation toggles ───────────────────────────────────
preserve:
  commits:         true    # commit message subject, body, trailers
  pr_descriptions: true    # PR titles, bodies, checklists
  code_comments:   true    # comments and docstrings in source files
  safety_warnings: true    # destructive-op confirmations + warnings
  errors_verbatim: true    # stack traces + tool error output

One flavor: key, one preserve: block with five named toggles. Everything else in the file is a comment.

When Claude reads the config

• At the start of each session — automatically, when the skill first activates.
• On demand, mid-session — when the user says "reload <persona> config" (e.g., "reload pirate config"). Changes you make to the file during a session won't take effect until you ask for a reload.

The flavor: key

Selects which sub-register is active. Valid values per persona:

Persona	Default	Other flavors
shakespeare	courtly	tavern, sonnet
pirate	scurvy-dog	captain, drunk, shanty
gen-alpha	unhinged	corporate, tutorial
toronto-mans	mans	(single flavor in v1)

See each persona page for what each flavor sounds like.

Mid-session flavor switch — you don't need to edit the config and reload for a one-off switch. Just say "<flavor> flavor" (e.g., "tavern flavor", "captain flavor", "shanty flavor", "tutorial flavor"). The skill switches and persists for the rest of the session.

The preservation model

Preservation rules decide what content escapes the register and stays in plain English. Without them, a commits: false config would have Claude write Shakespearean commit messages — which your colleagues would hate.

Each toggle is independent. true means "preserve as plain English"; false means "let the register take over".

commits: true (default)

Controls: the text of commit messages Claude generates.

• true — "fix(auth): resolve null-check bug in login flow" (plain).
• false — with shakespeare active: "Hark, a most grievous bug in the auth;I hereby mend it`" (Bardic). Your reviewers will wonder what you're doing.

Default is true because commit history is forever and machine-readable.

pr_descriptions: true (default)

Controls: PR title + body text generated by Claude (e.g., via gh pr create).

• true — plain PR body with Summary, Test plan, etc.
• false — PR body adopts the register. Fun; gets flagged in review.

Default true for the same reason as commits.

code_comments: true (default)

Controls: comments and docstrings Claude writes into source files (not inline narration about the code, just content that ends up on disk).

• true — // Retry up to 3 times to absorb transient network blips.
• false — // Prithee, retry thrice, lest yon network fail thee.

The chat narration around the edit still follows the register in either case — only the text written to disk is affected.

safety_warnings: true (default, strongly recommended)

Controls: destructive-op confirmations and security warnings.

• true — "This will permanently delete src/legacy/ and 14 untracked files. Type yes to proceed, or no to cancel." (plain, verbatim).
• false — same warning in register. Less clear, easier to misclick.

Strongly recommended: leave this on. You want to know unambiguously when you're about to delete something. See Danger combos below.

errors_verbatim: true (default)

Controls: how Claude reports error text from tools (stack traces, compiler errors, failed commands).

• true — the error text is reproduced inside a fenced code block, verbatim, with optional narration around it in the active register.
• false — Claude may paraphrase or rewrite the error in register.

Default true because errors need to be accurate for debugging.

The backtick rule (hard, not configurable)

Any content inside single backticks or fenced code blocks always stays verbatim, regardless of flavor or preservation toggles. This is hard-coded in every skill's SKILL.md.

`parse_input()` stays literal even in the deepest Bardic soliloquy.

You cannot turn this off. File paths, identifiers, flags, error lines quoted inline — all safe.

Hard-locks

Some preservation toggles are hard-locked — the skill ignores any override you set in the config. Currently one case:

toronto-mans: safety_warnings is hard-locked to true. Even if you edit toronto-mans.config to set safety_warnings: false, the skill treats it as true and tells you once that the value was rejected.

This is intentional. The toronto-mans register touches culturally-sensitive territory; safety-critical prompts must stay unambiguous. See the toronto-mans page for the broader stereotype-drift guardrails.

Hard-locks are declared in rules/<persona>/_meta.json under preserve_locked. If you're extending chrysippus with a new persona, document the lock both in _meta.json and in the persona's instructions.md.

Reload mechanics

The skill caches config at activation. To pick up a mid-session edit:

reload shakespeare config

(or "reload pirate config", etc.). The skill re-reads the file and applies the new values. No restart needed.

New sessions always re-read the config, so if you don't care about mid-session changes, just close Claude Code and reopen.

Danger combos

Certain config combinations are actively dangerous or counter-productive. The docs call them out; the configs themselves carry inline warnings.

pirate flavor: drunk + safety_warnings: false

Destructive-op confirmations will render as a swaying drunken slur ("YARRRR, delete it all? TYPE YES ERE SUNDOWN, MATEY!"). Easy to misclick. Leave safety_warnings: true if you use drunk flavor.

Any toronto-mans override of safety_warnings

As above — no-op. The skill won't let you disable it.

Flipping everything to false

Tempting for the "full register" experience. Your commits, PRs, and code comments will all adopt the register. On a shared repo, your reviewers will notice. On a personal repo, knock yourself out.

Common recipes

See the Recipes page for worked examples — "Shakespeare for prose but plain commits", "full pirate git history", "drunk flavor with safety preserved", etc.