From conversation to Skill
Use this when an effective repeated conversation pattern is worth packaging.
- Name the repeated user problem in one sentence.
- Separate the reusable method from project-specific facts.
- Write the trigger and non-trigger boundary.
- Define the output artifact.
- Add one accepted example.
- Add one rejected, unsafe, or out-of-scope example.
- Add provenance and sanitization notes.
- Add a validator when the artifact has a stable structure.
- Register the Skill in the catalog and plugin package.
Public Skill skeleton
---
name: dayan-example-skill
description: One sentence that tells a stranger exactly when to use it.
---
# Dayan Example Skill
## Use when
- ...
## Do not use when
- ...
## Workflow
1. Frame the request.
2. Produce the artifact.
3. Verify the boundary.
4. State known evidence gaps.
## Output contract
- ...
## Safety
- ...
Evidence rule
Do not turn internal success into public maturity. A clean public Skill can honestly say:
- installable;
- structurally validated;
- fixture-tested;
- not yet proven across every host runtime.