メニュー
Create or edit agent skills with proper structure, a discoverable description, progressive disclosure, and bundled resources. Use when the user wants to write, create, build, or revise a skill, or asks how skills should be structured.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | write-a-skill |
| description | Create or edit agent skills with proper structure, a discoverable description, progressive disclosure, and bundled resources. Use when the user wants to write, create, build, or revise a skill, or asks how skills should be structured. |
A skill is a reference guide for a proven technique, pattern, or workflow that a future agent can find and apply. Skills are reusable — they are not narratives about how you solved one problem once.
Create a skill when: the technique wasn't obvious, you'd reference it again across projects, it applies broadly, and a judgment call is involved.
Don't create one for: one-off solutions, things well-documented elsewhere, project-specific conventions (those go in CLAUDE.md / a docs/ file), or mechanical constraints enforceable with a script or hook (automate those instead).
SKILL.md; split heavy or distinct content into separate files; add scripts for deterministic operations.skill-name/
├── SKILL.md # Main instructions (required)
├── REFERENCE.md # Heavy reference, if needed (API docs, long syntax)
├── EXAMPLES.md # Usage examples, if needed
└── scripts/ # Utility scripts for deterministic ops, if needed
Flat namespace — every skill lives at skills/<skill-name>/ in one searchable namespace.
Keep inline: principles, concepts, code patterns under ~50 lines.
Split into a separate file when: SKILL.md exceeds ~100 lines, the content has distinct domains, or a section is advanced/rarely-needed. Add a script when an operation is deterministic (validation, formatting) — scripts save tokens and are more reliable than regenerated code.
---
name: skill-name
description: <one-line capability>. Use when <specific triggers / symptoms / contexts>.
---
# Skill Name
## Overview
What is this? Core principle in 1–2 sentences.
## When to Use
Bullet list of symptoms and situations · when NOT to use.
## Core pattern / Workflow
Steps, or a before/after comparison. Checklists for multi-step processes.
## Quick reference
A table or bullets for scanning common operations.
## Common mistakes
What goes wrong + the fix.
The description is the only thing the agent sees when deciding whether to load your skill — it's surfaced in the system prompt alongside every other skill. Get it right:
# ❌ Summarizes the workflow — the agent follows this and skips the skill
description: Use for TDD - write test first, watch it fail, write minimal code, refactor
# ❌ First person / too abstract
description: I can help with flaky async tests
# ✅ Capability + triggers, no workflow
description: Test-driven development with red-green-refactor. Use when implementing any feature or bugfix, before writing implementation code.
Keyword coverage: include words the agent would search for — error messages, symptoms ("flaky", "hanging"), synonyms, tool/library names. Naming: active, verb-first, by what you DO (condition-based-waiting > async-test-helpers); gerunds work well for processes.
@path syntax, which force-loads the file and burns context before it's needed.SKILL.md tight; push depth into referenced files that load only when needed. Reference one level deep.If you didn't watch an agent fail without the skill, you don't know the skill teaches the right thing.
RED Run a realistic pressure scenario with a fresh subagent, WITHOUT the skill.
Document the exact choices and rationalizations it makes (verbatim).
GREEN Write the minimal skill that addresses those specific failures.
Re-run the scenario WITH the skill — the agent should now comply.
REFACTOR Agent found a new loophole? Add an explicit counter. Re-test until solid.
For discipline-enforcing skills (rules), pile on pressure (time + sunk cost + exhaustion) and confirm the rule holds; capture every excuse in a rationalization table and a red-flags list, and state early that violating the letter is violating the spirit — it cuts off a whole class of rationalizations. For technique/pattern/reference skills, test that a fresh agent can apply the technique to a new scenario and find what it needs. See testing-skills-with-subagents.md and Anthropic's official guidance in anthropic-best-practices.md.
name uses only letters, numbers, hyphens; matches the directorySKILL.md is tight (≈ under 100 lines); depth pushed to referenced files@path linksQuery or contribute to syv.ai's shared company brain — the private 1brain GitHub repo (kunder, tilbud, teknik, strategi, wiki) — from any session, regardless of the current directory. Bootstraps a local clone when needed. Use when the user asks what syv.ai knows about a client or topic ("hvad ved vi om Krifa?", "har vi løst noget lignende før?"), wants something added to the brain ("tilføj til hjernen", mødenoter, læringer, nye dokumenter), or mentions 1brain or hjernen. All brain content is in Danish.
Write a syv.ai client proposal (tilbud, forslag, offer, PoC-beskrivelse, bud på udbud) in the company's fixed format and style, and render it as a branded PDF. Works from any session — bootstraps the private 1brain repo where the full proposal skill, templates and Typst PDF pipeline live. Trigger on opgavebeskrivelser, kravspecifikationer, SKI-udbud, RFPs and "lav et tilbud til …", also when the word "tilbud" isn't used directly.
Interviews the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Zooms out to give broader context or a higher-level perspective on a section of code. Use when you're unfamiliar with an area of code or need to understand how it fits into the bigger picture.
How to add or restyle a D3 diagram in the playbook docs (MkDocs Material). Use for any flowchart, diagram, chart, or graphic in docs/.
Use when a plan is multi-file, architecture-heavy, data-heavy, UI-heavy, ambiguous, or risky enough that the wrong direction would be expensive to undo. Renders the plan as a single self-contained HTML review surface — diagrams, file maps, annotated code, open questions — opened in the browser, with decisions captured in the terminal.