skills-writer
- Repo stars 486
- Author updated Live
- Author repo Gum
- Domain
- Documentation
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @vchelaru · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: skills-writer
description: Creates and updates skill files (.claude/skills/*/SKILL.md). Triggers: creating/updating a skill…
category: documentation
runtime: no special runtime
---
# skills-writer output preview
## PART A: Task fit
- Use case: Creates and updates skill files (.claude/skills/*/SKILL.md). Triggers: creating/updating a skill, documenting a subsystem for agent context. A skill is a map and a list of landmines — not an encyclopedia. It points an agent at the right code and docs, and warns about things that are not obvious from reading either. If a fact is already in source or in doc….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Mental Model / Authoritative Sources (do not duplicate) / Process” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Creates and updates skill files (.claude/skills/*/SKILL.md). Triggers: creating/updating a skill, documenting a subsystem for agent context. A skill is a map and a list of landmines — not an encyclopedia. It points an agent at the right code and docs, and warns about things that are not obvious from reading either. If a fact is already in source or in doc…”.
- **02** When the source has headings, the agent prioritizes “Mental Model / Authoritative Sources (do not duplicate) / Process” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Mental Model / Authoritative Sources (do not duplicate) / Process”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skills-writer
description: Creates and updates skill files (.claude/skills/*/SKILL.md). Triggers: creating/updating a skill…
category: documentation
source: vchelaru/Gum
---
# skills-writer
## When to use
- Creates and updates skill files (.claude/skills/*/SKILL.md). Triggers: creating/updating a skill, documenting a subsys…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Mental Model / Authoritative Sources (do not duplicate) / Process” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skills-writer" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Mental Model / Authoritative Sources (do not duplicate) / Process
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Skills Writer
Mental Model
A skill is a map and a list of landmines — not an encyclopedia. It points an agent at the right code and docs, and warns about things that are not obvious from reading either. If a fact is already in source or in docs/, the skill should link, not restate.
Think signpost, not explanation: a short pointer plus a direction ("the wiring lives in X; watch out for Y"), never a lengthy walkthrough or a code dump. Brevity is a feature, not a compromise — every line is re-read into context on every load, so a skill that explains less but points accurately is doing its job better than a thorough one.
Authoritative Sources (do not duplicate)
Before writing anything, identify where the ground truth already lives:
- Source code — class outlines, property lists, method signatures, call sites.
docs/GitBook tree — user-facing behavior, layout rules, control APIs, tutorials. If a topic has a docs page, link to it.- Other skills — cross-reference instead of copying. (
gum-layoutandgum-layout-engine, for example, deliberately split shallow vs. deep.)
A skill earns its place by covering what these sources don't: internal architecture, why pieces fit together, and gotchas.
Process
- Read the relevant source files.
- Check
docs/SUMMARY.mdfor existing user-facing pages on the topic. - Skim a few existing skills in
.claude/skills/to match style and depth. - Write only the non-obvious distillation.
Skill File Rules
- Length: aim under 100 lines. Hard ceiling 500. Bloat costs agent context on every load.
- Naming: kebab-case noun phrases (e.g.,
gum-tool-undo). - Frontmatter:
nameanddescription. The description is loaded into every session's skill listing — it pays for itself in context tokens forever. Keep it brutally short. See "Writing the description" below. - Structure:
##sections. Tables for file maps. Prose for relationships and gotchas. - Progressive disclosure: keep SKILL.md to high-level architecture; spill advanced content into sibling files (e.g.,
[xnafiddle.md](xnafiddle.md)) only when it's bulky enough to justify a second file.
Writing the description
The description's only job is to tell future-Claude when this skill is relevant. It is a trigger, not a summary.
Hard rules:
- One sentence. Under ~250 chars. Ideally under 200. The skill body covers the rest.
- Drop boilerplate. No "Reference guide for…", no "Load this when working on…", no "Covers Gum's…". The fact that this is a skill is implicit — these phrases are dead weight on every entry.
- Lead with the topic, then trigger identifiers. Format:
<Topic> — <one-line hook>. Triggers: <distinctive identifiers, file paths, or scenarios>. - Pick the 3–8 most distinctive triggers, not all of them. Generic words ("file", "system", "behavior") don't help; specific class names, file paths, and method names do. The rest belong inside the file.
- No multi-line YAML (
description: >). Keep it on one line. It folds anyway, and one line is easier to scan when auditing.
Example. Same triggers, ~40% fewer tokens:
Good:
description: Gum's undo/redo. Triggers: History tab, UndoManager, UndoPlugin, UndoSnapshot, stale references after undo.Bad (boilerplate, padded):
description: Reference guide for Gum's undo/redo system. Load this when working on undo/redo behavior, the History tab, UndoManager, UndoPlugin, UndoSnapshot, or stale reference issues after undo.Multiply by every skill, every session. It adds up.
Include
- Architecture: how major pieces fit together and why.
- Gotchas: surprising behavior, ordering dependencies, naming mismatches, "looks like X but actually Y."
- Key file map: one-line table of file → purpose.
- Pointers: links to relevant
docs/pages, key source files, and related skills. - Specific identifiers only when the name itself is misleading or the behavior is surprising.
Exclude
- Anything already in
docs/— link instead of restating. - Full class outlines or property lists — read source directly.
- Code examples unless the snippet captures an irreplaceable pattern.
- Time-sensitive info (versions, dates, migration notes).
- Anything Claude already knows from general C# or .NET knowledge.
Output
Write to .claude/skills/<skill-name>/SKILL.md. Create the directory if needed. Add sibling detail files only when content is too large for the main file.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review