skill-authoring

Stars10

Forks2

UpdatedJuly 10, 2026 at 21:42

How to write and maintain Modelibr agent skills — compactness budget, structure template, staleness rules, what belongs in a skill vs the code vs CLAUDE.md. Use when creating or editing anything under .claude/skills/.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

Papyszoo

Papyszoo/Modelibr

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

SKILL.md

readonly

name	skill-authoring
description	How to write and maintain Modelibr agent skills — compactness budget, structure template, staleness rules, what belongs in a skill vs the code vs CLAUDE.md. Use when creating or editing anything under .claude/skills/.

Skill authoring (keep skills compact and specific)

Skills are loaded into agent context. Every line that doesn't change agent behavior is context pollution. The litmus for each line: "would an agent do something wrong without this?" If no — delete it.

Budget & tone

Target one screen (~90 lines) per skill. Hard signal to trim: scrolling.
No history, no changelogs, no "recently changed/added in PR #X", no narrative, no praise. Git holds the history.
State facts in present tense as checkable claims naming a file/symbol (CustomWebDavHandler.WriteFileAsync checks Stream.Null), so a reader can verify against code in seconds.

Structure template (in this order, sections optional)

Cardinal rule / traps — the things that break production or data if an agent doesn't know them. First, always.
Map — files with one-line roles. No file trees.
Rules — imperatives ("never X", "always Y via Z"), grouped by topic.
Testing — what coverage exists, what's manual, what gates apply.
Verify — exact commands to run before claiming done.

Maintenance rules

Code wins. If a skill claim contradicts the code, fix the skill in the same session (CLAUDE.md rule). Don't soften with "may have changed".
Prefer replace/delete over append. A feature that changes behavior rewrites the stale line; it doesn't add a second paragraph beside it.
Temporary state ("until prompt N lands") is allowed ONLY with the trigger that removes it — and landing prompt N must delete the clause.
Prompt/PR references only when they're the pointer to fuller context an agent may need, never as attribution.
description: frontmatter = trigger conditions, concrete paths ("Use when creating or editing anything under src/X") — that's what decides loading.
Don't duplicate CLAUDE.md or another skill; name the other skill instead.
One domain per skill. If a section serves a different audience/task, it's a different skill (or belongs in none).

Review checklist before committing a skill edit

Every new line passes the litmus test
No stale claims left in touched sections (grep the named symbols)
Still one screen-ish; something got deleted if something got added
Verify commands still correct

More from this repository

same repository

release-workflow

Papyszoo/Modelibr

Modelibr git and release conventions — version-branch naming and protection, PR targeting, conventional commits (never an AI co-author trailer), and the version-branch→main release cadence. Use when branching, committing, opening PRs, cutting a release, or configuring branch protection.

2026-07-1210

test-triage

Papyszoo/Modelibr

Diagnose a failing test suite ("visual regression failed", "e2e is red", "backend tests broke") by locating the right logs and artifacts — test-report/logs, Playwright reports/traces, visual diff PNGs, TRX files — and analyzing the failure. Use whenever the user reports a test failure and wants to know what/why, or asks where test logs live.

2026-07-1210

backend-patterns

Papyszoo/Modelibr

Modelibr backend conventions — Clean Architecture boundaries, Result/Error, CQRS handlers, domain events, validation, DI, repositories, minimal API endpoints, known traps, xUnit naming. Use when creating or editing code under src/WebApi, src/Application, src/Domain, src/Infrastructure, or src/SharedKernel.

2026-07-1110

asset-processor-patterns

Papyszoo/Modelibr

Modelibr asset-processor (Node.js worker) conventions — config.js discipline, ProcessorRegistry/BaseProcessor lifecycle, job queue/timeout traps, RendererPool/Puppeteer rules, unified API-client usage, shared cross-runtime lib, offline-safe rendering, Vitest. Use when creating or editing code under src/asset-processor.

2026-07-1110

webdav-patterns

Papyszoo/Modelibr

Modelibr WebDAV virtual drive — middleware interception (Blender Safe Save), virtual store/collections, client-compat shims for macOS Finder/Windows Explorer/Blender, temp-file lifecycle, data-safety rules. Use when creating or editing src/WebApi/Infrastructure/WebDavMiddleware.cs, src/WebApi/Services/*WebDav*/RequestHandlerFactory, or anything under src/Infrastructure/WebDav.

2026-07-1010

design-system

Papyszoo/Modelibr

Modelibr design system — the --mod-* token vocabulary, the shared primitive catalog (feedback states, ListHeader, ListToolbar, asset tiles) with import paths, the card/page visual identity rules, Storybook gallery + light/dark themes, and the known drift to never copy. Use when styling anything, writing CSS, building or editing UI components, or adding Storybook stories under src/frontend.

2026-07-0610

name	skill-authoring
description	How to write and maintain Modelibr agent skills — compactness budget, structure template, staleness rules, what belongs in a skill vs the code vs CLAUDE.md. Use when creating or editing anything under .claude/skills/.

Skill authoring (keep skills compact and specific)

Budget & tone

Target one screen (~90 lines) per skill. Hard signal to trim: scrolling.
No history, no changelogs, no "recently changed/added in PR #X", no narrative, no praise. Git holds the history.
State facts in present tense as checkable claims naming a file/symbol (CustomWebDavHandler.WriteFileAsync checks Stream.Null), so a reader can verify against code in seconds.

Structure template (in this order, sections optional)

Cardinal rule / traps — the things that break production or data if an agent doesn't know them. First, always.
Map — files with one-line roles. No file trees.
Rules — imperatives ("never X", "always Y via Z"), grouped by topic.
Testing — what coverage exists, what's manual, what gates apply.
Verify — exact commands to run before claiming done.

Maintenance rules

Code wins. If a skill claim contradicts the code, fix the skill in the same session (CLAUDE.md rule). Don't soften with "may have changed".
Prefer replace/delete over append. A feature that changes behavior rewrites the stale line; it doesn't add a second paragraph beside it.
Temporary state ("until prompt N lands") is allowed ONLY with the trigger that removes it — and landing prompt N must delete the clause.
Prompt/PR references only when they're the pointer to fuller context an agent may need, never as attribution.
description: frontmatter = trigger conditions, concrete paths ("Use when creating or editing anything under src/X") — that's what decides loading.
Don't duplicate CLAUDE.md or another skill; name the other skill instead.
One domain per skill. If a section serves a different audience/task, it's a different skill (or belongs in none).

Review checklist before committing a skill edit

Every new line passes the litmus test
No stale claims left in touched sections (grep the named symbols)
Still one screen-ish; something got deleted if something got added
Verify commands still correct