skill-authoring

Estrellas10

Forks2

Actualizado10 de julio de 2026 a las 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/.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

Papyszoo

Papyszoo/Modelibr

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Otras ocupaciones informáticasOcupaciones informáticas y matemáticas·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

Más de este repositorio

mismo repositorio

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

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