Overview

Claude Code reads three kinds of file. This repo holds mine.

Plain markdown in ~/.claude — output styles shape how Claude answers, skills add repeatable jobs, and CLAUDE.md sets the defaults. Nothing is a plugin; every file is text you can read and edit.

Kept in git so it survives a rebuild and anyone can lift one file. Output styles, CLAUDE.md, and skills are published; more arrive as they are generalised.

output-styles/Published

Replaces how Claude answers. Loads into the system prompt at session start and shapes every reply until you switch. Two are here.
CLAUDE.mdPublished

Standing instructions. Loads in every session, in every project — engineering defaults, comment style, and what needs approval.
skills/Available

A repeatable job in ~/.claude/skills/<name>/SKILL.md. Loads on demand when the task matches its description.

Published

Output styles

An output style is a markdown file with two frontmatter fields — name and description — and a body of writing rules. The body replaces Claude Code's default response guidance wholesale, so a style can change sentence length, banned words, and the shape of a result report.

The clearest way to see it: ask one question four times. The first two styles are in this repo. The last two are Claude Code's own built-ins — Concise, which leads with the result and skips preamble and narration (added in v2.1.237), and Default, the style selected until you change it. The diagnosis is the same in all four. What moves is the length, the wording, and how much unasked-for material rides along with the answer.

claude style: ASD-STE100

> why does GET /api/users return 404?

The router sits on a different path. One file needs a change.

- Verified: server.js mounts the router at /api/user. The
  request asked for /api/users. The plural broke the match.
- Updated: None yet.
- Next: Confirm which spelling you want, then I will change
  the mount in server.js.

The request fails because the server registers a different path.

In server.js the router is mounted at /api/user, with no s at
the end. The request asks for /api/users. Express compares the
two, finds no match, and answers with 404.

Tell me which spelling you want to keep. Then I will change either
the mount or the request, so both sides use one path.

Mount path mismatch in server.js: the users router is mounted at
/api/user, the request hits /api/users. Express prefix-matches the
mount exactly, so no handler is reached and the default 404 answers.

Fix either side — rename the mount to plural, or point the caller at
the singular. Which spelling is canonical?

The 404 originates from a discrepancy between the path at which the
router is registered and the path the client is requesting.

Within server.js, the Express application instantiates a router
dedicated to user resources and subsequently registers it against the
mount point /api/user. The incoming request, by contrast, targets
/api/users, which incorporates a pluralised resource segment.
Express performs exact prefix matching when resolving a mounted
router, so the supplementary character causes resolution to fail, and
the request falls through to the framework's terminal 404 handler
rather than arriving at the intended route handler.

This category of defect is comparatively prevalent in codebases where
route paths are not centralised, given that the mount path and the
calling path are declared in two separate locations and can therefore
diverge without any compile-time or lint-time signal.

Regarding remediation, there are essentially two avenues available.
The mount path could be amended to the plural form, which resolves
the immediate symptom whilst preserving the underlying duplication.
Alternatively, a shared route constant could be introduced and
imported by both sides, which would be materially more resilient over
the longer term. Let me know which direction you would prefer to
pursue.

46 words · one result line, three labels

Primary

ASD-STE100

Structured output following ASD-STE100 English standards that any reader can understand. Named after the controlled English for aircraft maintenance manuals — where a technician must not read a procedure two ways.

One term per meaning, held for the whole answer
Max 20 words per sentence, simple tenses, no -ing forms
Active voice, imperative instructions
Plain words preferred, unless the short word changes the meaning
Result first, then Verified: Updated: Skipped: Remaining: Next:
Each label once; two or more items nest under it

33 lines · 211 words

Lighter

Always Friday

Simple, clear output that's easy to read — like Friday afternoon. Short sentences and everyday words, with no label protocol. It reads as ordinary prose. Reach for it when you explain the work to a person instead of filing a result — a handover note, or a summary for someone who missed the session.

Answer first, detail after
Every fact, name, number, and path kept
One idea per sentence, everyday words
Code, commands, and log output left untouched
No labels, no preamble, no sign-off

40 lines · 221 words

Pick ASD-STE100 to get the job done with minimal words and structured output. Use Always Friday when you collaborate with AI on tasks beyond coding.

Want a word you hate banned by name? Keep a vocabulary table in your own style — the abstract rule does not hold on its own, an explicit row does. Copy the example from the README.

Available

Skills

A skill is a task procedure Claude Code loads on demand — repeatable, one way to do one job.

compact-markdown

Telegraphic markdown for AI-facing docs. Strips filler, keeps code, examples, and concrete detail — compact and still human-readable.
humanize

Remove AI writing patterns from prose. Use for human-facing writing where voice matters.
handoff

Compact the current conversation into a handoff doc for the next session.
writing-rulesClaude only

Author .claude/rules/*.md with correct paths: scoping and lazy-load.
html-landing-page

Design a distinctive static landing page. Plan palette, type, and one signature element before any HTML — and never ship the AI-default look.
git-merge

Merge a branch into yours without losing local unstaged work. Diagnose each conflict, then run the repo's own checks to catch the ones git merged cleanly but wrongly.
zoom-outManual only

Map an unfamiliar code area before touching it. Purpose, flow, callers, boundaries, risks, and the questions the codebase does not answer. Nothing is edited and no mutating command runs until the map is done. Invoked by hand with /zoom-out.

compact-markdown also ships references/skill-authoring.md — good practices distilled from Claude Code, Codex, and mattpocock/skills for writing effective skills.

Procedure

Install

Get the files, then copy the parts you want into ~/.claude/. There is nothing to build. Create a folder if it is not there yet.

No git? Download the ZIP and unzip it. It unpacks to dotclaude-main/ rather than dotclaude/, so adjust the paths below by that one word.

shell

git clone https://github.com/MithunWijayasiri/dotclaude.git

# output styles
mkdir -p ~/.claude/output-styles
cp dotclaude/output-styles/*.md ~/.claude/output-styles/

# standing instructions
cp dotclaude/CLAUDE.md ~/.claude/CLAUDE.md

# skills — one folder per skill
mkdir -p ~/.claude/skills
cp -r dotclaude/skills/* ~/.claude/skills/

Use a .claude/ folder inside a repo instead of ~/.claude/ to scope any of this to that one project. Copying CLAUDE.md replaces whatever sits at the target, so read your own first.

Turn on an output style

Copying the file does not select it. Type /config in a session and pick one under Output style. Claude Code saves that choice per project, in .claude/settings.local.json.

To make a style your default everywhere, set the field yourself:

~/.claude/settings.json

{
  "outputStyle": "ASD-STE100"
}

The value is the name: field from the file's frontmatter, not the filename. A style is part of the system prompt, so it takes effect after /clear or in your next session.