Writing styles

A writing style is the convention set the agent follows when it writes your specification — how the spec is structured and sliced, how things are named, the tone, and which tags it reaches for. It exists so the result reads the way you plan, rather than however the model defaults from one query to the next.

One style is active per project. You pick it when you first set the project up, and you can change it — or clear it back to None — anytime from the Settings page. With no style selected, the agent simply writes with its own defaults until you choose one.

How a style reaches the agent

Under the hood, a writing style is a specially prepared skill — a bundle of instructions the agent loads before it works. claude4spec applies your currently selected style on every agent turn, so its conventions ride along with each message the agent drafts. That also means switching styles in Settings takes effect on the very next turn — no restart, no reload.

The same style guides the agent everywhere it writes for you: in regular chat, when it generates a release brief, and when it resolves a patch against your spec.

Choosing a style

The first time you run claude4spec in a project, onboarding shows a short form: your project name and a list of writing-style cards with descriptions. Pick one — or choose None and set it later.

You can change the style at any time:

1. Open Settings

   Go to Settings → Project in the editor.

2. Pick a style

   Choose a style from the writing-style dropdown (or None). Your choice is saved to config.writingStyle.

3. Keep working

   It takes effect on your next chat turn — no restart, no reload.

The default for a fresh project is None: the agent writes without any house style until you pick one.

Built-in writing styles

claude4spec ships with built-in styles so you have something to pick on day one. Today there is one reference style, Layered Vertical Slices (slug layered-vertical-slices): it models the spec as a 2-axis grid — vertical modules (domain slices) crossed with horizontal layers — and gives the agent the structure, naming, and tagging conventions that go with it.

More built-in styles will follow. And if none of them fits how you plan, you can write your own — that's the next section.

Authoring your own

Because a writing style is a skill, you author one exactly the way you'd author any skill: as a directory you drop into a skills root. The directory name is the slug, and a SKILL.md inside it carries the conventions plus a small frontmatter block. Any supporting files live in that same directory.

1. Create the skill directory

   Put it in your project at .claude/skills/<slug>/, or in your home directory at ~/.claude/skills/<slug>/ to make it available across all your projects.

2. Write SKILL.md frontmatter

   The loader requires these fields:

   Field	Required	Notes
   title	yes	Human label shown in the onboarding and settings cards
   description	yes	One line; also doubles as the agent-facing trigger/summary
   version	yes	A number, e.g. 1
   language	yes	e.g. en

   Below the frontmatter, write the conventions in prose — this is what the agent reads on every turn.

3. Split content into subdirectories (optional)

   A single SKILL.md is enough — everything can live in that one file. As a style grows, though, a good practice is to keep SKILL.md thin and let it act as a router: it triages the situation up front — which kind of task is the agent doing right now — and then points to a separate file under workflows/ that holds the detailed steps. Reusable scaffolds go in templates/ (or examples/) the same way.

   The win is token efficiency. The lean router is what loads on every turn; a full procedure is pulled in only when its situation actually applies, instead of carrying every workflow inline in the prompt all the time.

4. Restart and select it

   Restart the server so the registry picks up the new directory, then select your style in Settings → Project.

To restart after adding a style:

Where styles live, and precedence

You can add a style in either of two places, highest precedence first:

<project>/.claude/skills/   # this project only — wins
~/.claude/skills/           # global — available across all your projects

A project style takes precedence over a global one, and either one overrides a built-in style with the same slug — so you can shadow a style that ships with claude4spec just by giving yours the same name. The styles you see in onboarding and settings are the built-in ones plus whatever you've added in these two locations.