mcclowes-skills

Max's house writing style and grammar for any prose you generate for him - docs, READMEs, PR descriptions, commit messages, Slack, emails, code comments, error messages, blog posts, and replies in chat. Use this whenever you are writing or editing English prose meant for Max or sent on his behalf, even when he doesn't explicitly ask for a particular style. Apply it by default to anything wordier than a one-line answer; favour warm-but-blunt, concise writing, US English, sentence case, the Oxford comma, and zero AI jargon. Do not use it for code itself, config, or data formats.

Use when deciding how to organise code in an AI-assisted codebase — whether to split or merge a file, where to draw module boundaries, how big a file should get, or whether to separate logic from rendering/styles/data. Triggers on "should I split this file", "this file is getting too big", "separate concerns", "where should this code live", reviewing or refactoring file/module organisation, structuring a new component or feature, or any architecture decision where part of the audience is an AI coding agent. Apply this whenever someone is choosing how to lay code out across files and an LLM will be reading or editing it, even if they only say "refactor this" or "clean up the structure" without mentioning AI.

Use when designing, reviewing, or implementing HTTP APIs — error and warning handling, resource state and lifecycle, read-endpoint structure, pagination, and authentication. Triggers on error responses and formats, response envelopes, webhook payloads, how an endpoint should fail; modelling a resource lifecycle (status fields, state machines, webhook event names, enum vs parseable string); structuring read endpoints (screen-shaped/BFF vs canonical resource, aggregation, cursor vs offset pagination); and auth design (security schemes, API keys vs bearer tokens, stepped-up tokens). Apply whenever an API surfaces a failure, state change, view of data, or auth requirement to a client.

Context-efficient codebase navigation and documentation using structured frontmatter headers. Use this when exploring an unfamiliar codebase, answering "where is X / how does Y work" questions, or when asked to add/maintain file-level documentation. Index a tree's headers in one pass instead of reading every file, and generate or validate frontmatter with the bundled scripts. Reach for it whenever token budget matters while navigating code, even if the user does not say "frontmatter".

Use when designing language features - covers lexer, parser, AST, and interpreter patterns