Skill creator

Create new skills, modify and improve existing skills, and measure skill performance.

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/skill-creator-2, including the files SKILL.md points to.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit himself65/finance-skills/plugins/skill-creator/skills/skill-creator#main ~/.claude/skills/skill-creator-2

For one project only, change the path to .claude/skills/skill-creator-2. This skill also uses lowercase-hyphenated.md — copying SKILL.md alone won't be enough. See the folder on GitHub.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Skill creator

Show the full text286 lines
namedescription
skill-creator> Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or iterate on skill quality. Triggers: "create a skill", "make a new skill", "build a skill for", write a skill that", "skill for doing X", "I want a skill to", "new skill", "design a skill", scaffold a skill", "improve this skill", "optimize this skill", "this skill isn't working well", evaluate this skill", "score this skill", "how good is this skill", "run evals on", benchmark this skill", "test this skill's quality", "skill quality", "skill performance". Also triggers when a user describes a repeatable workflow they want to automate, says I keep doing X manually", "can you remember how to do X", or "turn this into a skill".

Skill Creator

Create, evaluate, and iterate on high-quality agent skills. This skill guides the entire lifecycle: planning what the skill should do, writing SKILL.md and reference files, scoring quality against a rubric, and iterating until the skill meets production standards.

Philosophy: A great skill is not a long skill. It is a precise skill: exhaustive triggers, explicit defaults, clear steps with exit gates, deferred complexity via reference files, and a structured output template.

Core rule — always dynamic, never static: Skills MUST detect what tools, libraries, and auth are available at runtime and adapt their behavior accordingly. Never hardcode a single method. Always provide a detection flow with a decision tree and fallback paths. See references/dynamic-calling.md for the complete pattern catalog.


Step 1: Understand What the User Wants

Classify the request into one of these modes:

User Intent Mode Jump To
Create a brand-new skill Create Step 2
Improve / fix an existing skill Improve Step 6
Evaluate / score a skill's quality Evaluate Step 7

If ambiguous, ask: "Do you want to create a new skill, improve an existing one, or evaluate one?"

Gather Requirements (for Create mode)

Before writing anything, answer these questions (ask the user if unclear):

Question Why it matters
What task does the skill automate? Defines the core workflow
Who is the target user? Determines complexity and terminology level
What tools/APIs/CLIs does it use? Determines dependencies and platform restrictions
What does the user provide as input? Defines parameters and defaults
What should the output look like? Defines the response template
Does it need API keys or credentials? Determines required_environment_variables
Should it work on Claude.ai or only CLI? Determines platform field and dynamic commands

Step 2: Plan the Skill Architecture

Before writing SKILL.md, plan the structure. Read references/architecture-patterns.md for detailed guidance on each pattern.

Choose a Structural Pattern
Pattern When to use Steps Example
Linear Single workflow, no branching 5-7 earnings-preview, etf-premium
Router Multiple sub-tasks under one umbrella 3 + sub-skills stock-correlation (4 sub-skills)
Methodology Complex domain framework with sequential gates 7-9 sepa-strategy (9-step trading methodology)
Widget Generates interactive UI output 4-5 options-payoff (extract + compute + render)
API Wrapper Wraps an external API with many endpoints 3-5 + heavy references fintel-data (6 steps, 1 reference file)
Plan the Step Outline

Write out the step names before writing content. Every skill should have:

  1. Detection flow (Step 1) -- dynamically detect available tools, auth state, and runtime environment; build a decision tree for which method to use
  2. Core methodology (Steps 2-N) -- the actual work, with pass/fail gates; each step that calls an external tool should have method alternatives based on what Step 1 detected
  3. Respond to user (Final step) -- structured output template

Target 5-9 steps total. More than 9 means the skill should be split or use a router pattern.

Plan the Detection Flow

Every skill that touches external tools MUST start with a runtime detection flow. Read references/dynamic-calling.md for all patterns. The detection flow answers:

Question How to detect Decision
Is the CLI tool installed? command -v tool CLI path vs Python fallback
Is the user authenticated? tool auth status / echo $API_KEY Skip auth setup vs guide through it
Which runtime has the library? import lib in terminal vs execute_code Route to correct runtime
Is a richer tool available? gh --version vs git --version Rich path vs minimal path
Is live data reachable? curl -s endpoint Live data vs cached/default

The detection output feeds into a decision tree that the rest of the skill follows. Never assume — always check.

Plan Reference Files

Decide what goes in SKILL.md vs references/:

In SKILL.md (under ~250 lines) In references/
Step-by-step workflow Detailed API documentation
Routing/decision tables Code templates (>20 lines)
Parameter defaults table Formulas and edge cases
Output format template Troubleshooting database
Quick examples (1-3) Comprehensive examples (4+)

Step 3: Write the SKILL.md

Read references/writing-guide.md for detailed instructions on writing each section. Read references/frontmatter-guide.md for the complete YAML field reference.

Key Rules
  1. Frontmatter first: name (lowercase-hyphenated, max 64 chars) and description (exhaustive trigger list, max 1024 chars) are required. Description needs 5+ triggers including sideways entry points.

  2. Step 1 = detection flow: Use !command`` with fallbacks to detect available tools, auth state, and runtime. Build a decision tree with multiple method paths (e.g., CLI preferred, Python fallback, built-in tools last resort). Never hardcode a single tool — always detect and adapt. See references/dynamic-calling.md.

  3. Core steps with method alternatives: Each step that calls an external tool should offer at least 2 paths based on what Step 1 detected. Use pattern: "If TOOL_A detected → Method 1, otherwise → Method 2." Each step gets ## Step N: [Verb] [Object], a decision table if routing, a pass/fail gate if evaluative, and a reference pointer for deep content.

  4. Defaults table: Every parameter MUST have an explicit default. No skill should ever stall waiting for input.

  5. Final step = output template: Number every output section. Specify exactly what data goes in each. Include a verdict/grade system if evaluative.

See references/skill-examples.md for annotated examples of each pattern.


Step 4: Write Reference Files

Read references/writing-guide.md for the full reference file authoring guide.

Key Rules
  1. Naming: lowercase-hyphenated.md, one file per concept-cluster
  2. Size: Quick lookup 50-150 lines, deep guide 150-400 lines, catalog 400-900 lines
  3. Structure: H1 title, H2 sections, code blocks, tables, edge cases section at end
  4. Linking: Use backtick paths in SKILL.md steps and a ## Reference Files section at the end

Step 5: Quality Check Before Delivery

Run the skill through the quality rubric in references/quality-rubric.md. Score each dimension.

Quick Checklist
  • Frontmatter has name and description (both required)
  • Description has 5+ distinct trigger phrases
  • Description includes sideways entry points
  • SKILL.md is under 300 lines (ideally under 250)
  • Every parameter has an explicit default
  • Steps are numbered (## Step N: ...)
  • Each step has a clear exit condition or deliverable
  • Final step specifies exact output structure with numbered sections
  • Complex content is in reference files, not inline
  • Reference file pointers use backtick paths
  • Step 1 has a detection flow with !command`` checks and fallbacks (|| echo "...")
  • Detection flow produces a decision tree with 2+ method paths
  • Core steps adapt behavior based on detection results (not hardcoded to one tool)
  • Separate runtimes treated as separate environments (terminal vs execute_code)
  • Legal/ethical disclaimers included where appropriate
  • No hardcoded ticker lists, tool paths, or static data that will go stale

If any item fails, fix it before delivering to the user.


Step 6: Improve an Existing Skill

When the user asks to improve a skill:

6a: Read the Current Skill

Load the skill with skill_view(name) or read the SKILL.md directly. Also read all reference files.

6b: Score It Against the Rubric

Use the quality rubric from references/quality-rubric.md. Present the score breakdown to the user:

Dimension Score Issue
Trigger quality 6/10 Missing beginner phrasing
Defaults coverage 3/10 No defaults table
Step structure 8/10 Good, but Step 3 lacks exit gate
Output template 4/10 Vague "summarize results"
Reference usage 7/10 Good split, but missing troubleshooting
6c: Propose Specific Improvements

List concrete changes ranked by impact:

  1. [Highest impact] Add defaults table with 8+ parameters
  2. [High impact] Rewrite description with 10+ trigger phrases
  3. [Medium impact] Add structured output template to final step
  4. ...
6d: Apply Changes

After user approval, edit the skill. Use skill_manage(action='patch', ...) for targeted changes or skill_manage(action='edit', ...) for full rewrites.


Step 7: Evaluate a Skill

When the user asks to evaluate or score a skill:

7a: Load and Analyze

Read the full SKILL.md and all reference files. Count lines, steps, triggers, defaults, reference files.

7b: Score Against Rubric

Use the comprehensive rubric from references/quality-rubric.md. Score each of the 10 dimensions on a 1-10 scale.

7c: Present the Scorecard
## Skill Quality Scorecard: [skill-name]

| # | Dimension | Score | Notes |
|---|---|---|---|
| 1 | Trigger quality | 8/10 | 12 triggers, includes sideways entries |
| 2 | Defaults coverage | 9/10 | All 11 parameters have defaults |
| 3 | Step architecture | 8/10 | 5 clear steps with gates |
| 4 | Reference file strategy | 7/10 | 2 files, could use troubleshooting |
| 5 | Dynamic content | 10/10 | Dep check + live data injection |
| 6 | Output template | 9/10 | 5 numbered sections + verdict |
| 7 | Error handling | 6/10 | Missing data handling unclear |
| 8 | Code/formula quality | 8/10 | Working JS, copy-paste ready |
| 9 | SKILL.md conciseness | 7/10 | 196 lines, well within target |
| 10 | Domain accuracy | 9/10 | BS formulas correct, edge cases covered |

**Overall: 81/100** -- Production quality

### Top 3 Improvements
1. ...
2. ...
3. ...
Benchmark Reference

For context, here are scores for known high-quality skills in this repo:

Skill Score Why
sepa-strategy ~90/100 9 steps, 7 refs, exhaustive triggers, structured verdict
options-payoff ~85/100 Strong defaults, working code, live data, clean output
stock-correlation ~80/100 Router pattern, 4 sub-skills, good defaults

Step 8: Respond to the User

For Create mode

Deliver:

  1. The complete SKILL.md content
  2. All reference files
  3. A README.md for the skill directory
  4. The quality scorecard (from Step 5)
  5. Suggested next steps (test it, iterate, publish)
For Improve mode

Deliver:

  1. Before/after quality scores
  2. Summary of changes made
  3. Remaining improvement opportunities
For Evaluate mode

Deliver:

  1. The full quality scorecard
  2. Comparison to benchmark skills
  3. Prioritized improvement list

Reference Files

  • references/dynamic-calling.md -- Core reference: Detection flows, decision trees, method fallbacks, runtime awareness, and multi-tool adaptation patterns with annotated examples from production skills
  • references/writing-guide.md -- Detailed instructions for writing SKILL.md sections, environment checks, defaults tables, output templates, and reference files
  • references/architecture-patterns.md -- Linear, Router, Methodology, Widget, and API Wrapper patterns with examples and anti-patterns
  • references/frontmatter-guide.md -- Complete YAML frontmatter field reference (name, description, platform, env vars, config, credentials)
  • references/quality-rubric.md -- 10-dimension scoring rubric with 1-10 scales, benchmark scores, and score interpretation
  • references/skill-examples.md -- Annotated excerpts from top skills showing why specific patterns work
1---
2name: skill-creator
3description: >
4 Create new skills, modify and improve existing skills, and measure skill performance.
5 Use when users want to create a skill from scratch, update or optimize an existing skill,
6 run evals to test a skill, benchmark skill performance with variance analysis, or iterate
7 on skill quality. Triggers: "create a skill", "make a new skill", "build a skill for",
8 "write a skill that", "skill for doing X", "I want a skill to", "new skill", "design a skill",
9 "scaffold a skill", "improve this skill", "optimize this skill", "this skill isn't working well",
10 "evaluate this skill", "score this skill", "how good is this skill", "run evals on",
11 "benchmark this skill", "test this skill's quality", "skill quality", "skill performance".
12 Also triggers when a user describes a repeatable workflow they want to automate, says
13 "I keep doing X manually", "can you remember how to do X", or "turn this into a skill".
14---
15 
16# Skill Creator
17 
18Create, evaluate, and iterate on high-quality agent skills. This skill guides the entire lifecycle: planning what the skill should do, writing SKILL.md and reference files, scoring quality against a rubric, and iterating until the skill meets production standards.
19 
20**Philosophy:** A great skill is not a long skill. It is a *precise* skill: exhaustive triggers, explicit defaults, clear steps with exit gates, deferred complexity via reference files, and a structured output template.
21 
22**Core rule — always dynamic, never static:** Skills MUST detect what tools, libraries, and auth are available at runtime and adapt their behavior accordingly. Never hardcode a single method. Always provide a detection flow with a decision tree and fallback paths. See `references/dynamic-calling.md` for the complete pattern catalog.
23 
24---
25 
26## Step 1: Understand What the User Wants
27 
28Classify the request into one of these modes:
29 
30| User Intent | Mode | Jump To |
31|---|---|---|
32| Create a brand-new skill | **Create** | Step 2 |
33| Improve / fix an existing skill | **Improve** | Step 6 |
34| Evaluate / score a skill's quality | **Evaluate** | Step 7 |
35 
36If ambiguous, ask: "Do you want to create a new skill, improve an existing one, or evaluate one?"
37 
38### Gather Requirements (for Create mode)
39 
40Before writing anything, answer these questions (ask the user if unclear):
41 
42| Question | Why it matters |
43|---|---|
44| What task does the skill automate? | Defines the core workflow |
45| Who is the target user? | Determines complexity and terminology level |
46| What tools/APIs/CLIs does it use? | Determines dependencies and platform restrictions |
47| What does the user provide as input? | Defines parameters and defaults |
48| What should the output look like? | Defines the response template |
49| Does it need API keys or credentials? | Determines `required_environment_variables` |
50| Should it work on Claude.ai or only CLI? | Determines platform field and dynamic commands |
51 
52---
53 
54## Step 2: Plan the Skill Architecture
55 
56Before writing SKILL.md, plan the structure. Read `references/architecture-patterns.md` for detailed guidance on each pattern.
57 
58### Choose a Structural Pattern
59 
60| Pattern | When to use | Steps | Example |
61|---|---|---|---|
62| **Linear** | Single workflow, no branching | 5-7 | earnings-preview, etf-premium |
63| **Router** | Multiple sub-tasks under one umbrella | 3 + sub-skills | stock-correlation (4 sub-skills) |
64| **Methodology** | Complex domain framework with sequential gates | 7-9 | sepa-strategy (9-step trading methodology) |
65| **Widget** | Generates interactive UI output | 4-5 | options-payoff (extract + compute + render) |
66| **API Wrapper** | Wraps an external API with many endpoints | 3-5 + heavy references | fintel-data (6 steps, 1 reference file) |
67 
68### Plan the Step Outline
69 
70Write out the step names before writing content. Every skill should have:
71 
721. **Detection flow** (Step 1) -- dynamically detect available tools, auth state, and runtime environment; build a decision tree for which method to use
732. **Core methodology** (Steps 2-N) -- the actual work, with pass/fail gates; each step that calls an external tool should have method alternatives based on what Step 1 detected
743. **Respond to user** (Final step) -- structured output template
75 
76Target **5-9 steps** total. More than 9 means the skill should be split or use a router pattern.
77 
78### Plan the Detection Flow
79 
80Every skill that touches external tools MUST start with a runtime detection flow. Read `references/dynamic-calling.md` for all patterns. The detection flow answers:
81 
82| Question | How to detect | Decision |
83|---|---|---|
84| Is the CLI tool installed? | `command -v tool` | CLI path vs Python fallback |
85| Is the user authenticated? | `tool auth status` / `echo $API_KEY` | Skip auth setup vs guide through it |
86| Which runtime has the library? | `import lib` in terminal vs execute_code | Route to correct runtime |
87| Is a richer tool available? | `gh --version` vs `git --version` | Rich path vs minimal path |
88| Is live data reachable? | `curl -s endpoint` | Live data vs cached/default |
89 
90The detection output feeds into a **decision tree** that the rest of the skill follows. Never assume — always check.
91 
92### Plan Reference Files
93 
94Decide what goes in SKILL.md vs references/:
95 
96| In SKILL.md (under ~250 lines) | In references/ |
97|---|---|
98| Step-by-step workflow | Detailed API documentation |
99| Routing/decision tables | Code templates (>20 lines) |
100| Parameter defaults table | Formulas and edge cases |
101| Output format template | Troubleshooting database |
102| Quick examples (1-3) | Comprehensive examples (4+) |
103 
104---
105 
106## Step 3: Write the SKILL.md
107 
108Read `references/writing-guide.md` for detailed instructions on writing each section. Read `references/frontmatter-guide.md` for the complete YAML field reference.
109 
110### Key Rules
111 
1121. **Frontmatter first**: `name` (lowercase-hyphenated, max 64 chars) and `description` (exhaustive trigger list, max 1024 chars) are required. Description needs 5+ triggers including sideways entry points.
113 
1142. **Step 1 = detection flow**: Use `!`command`` with fallbacks to detect available tools, auth state, and runtime. Build a decision tree with multiple method paths (e.g., CLI preferred, Python fallback, built-in tools last resort). Never hardcode a single tool — always detect and adapt. See `references/dynamic-calling.md`.
115 
1163. **Core steps with method alternatives**: Each step that calls an external tool should offer at least 2 paths based on what Step 1 detected. Use pattern: "If `TOOL_A` detected → Method 1, otherwise → Method 2." Each step gets `## Step N: [Verb] [Object]`, a decision table if routing, a pass/fail gate if evaluative, and a reference pointer for deep content.
117 
1184. **Defaults table**: Every parameter MUST have an explicit default. No skill should ever stall waiting for input.
119 
1205. **Final step = output template**: Number every output section. Specify exactly what data goes in each. Include a verdict/grade system if evaluative.
121 
122See `references/skill-examples.md` for annotated examples of each pattern.
123 
124---
125 
126## Step 4: Write Reference Files
127 
128Read `references/writing-guide.md` for the full reference file authoring guide.
129 
130### Key Rules
131 
1321. **Naming**: `lowercase-hyphenated.md`, one file per concept-cluster
1332. **Size**: Quick lookup 50-150 lines, deep guide 150-400 lines, catalog 400-900 lines
1343. **Structure**: H1 title, H2 sections, code blocks, tables, edge cases section at end
1354. **Linking**: Use backtick paths in SKILL.md steps and a `## Reference Files` section at the end
136 
137---
138 
139## Step 5: Quality Check Before Delivery
140 
141Run the skill through the quality rubric in `references/quality-rubric.md`. Score each dimension.
142 
143### Quick Checklist
144 
145- [ ] Frontmatter has `name` and `description` (both required)
146- [ ] Description has 5+ distinct trigger phrases
147- [ ] Description includes sideways entry points
148- [ ] SKILL.md is under 300 lines (ideally under 250)
149- [ ] Every parameter has an explicit default
150- [ ] Steps are numbered (## Step N: ...)
151- [ ] Each step has a clear exit condition or deliverable
152- [ ] Final step specifies exact output structure with numbered sections
153- [ ] Complex content is in reference files, not inline
154- [ ] Reference file pointers use backtick paths
155- [ ] Step 1 has a detection flow with `!`command`` checks and fallbacks (`|| echo "..."`)
156- [ ] Detection flow produces a decision tree with 2+ method paths
157- [ ] Core steps adapt behavior based on detection results (not hardcoded to one tool)
158- [ ] Separate runtimes treated as separate environments (terminal vs execute_code)
159- [ ] Legal/ethical disclaimers included where appropriate
160- [ ] No hardcoded ticker lists, tool paths, or static data that will go stale
161 
162If any item fails, fix it before delivering to the user.
163 
164---
165 
166## Step 6: Improve an Existing Skill
167 
168When the user asks to improve a skill:
169 
170### 6a: Read the Current Skill
171 
172Load the skill with `skill_view(name)` or read the SKILL.md directly. Also read all reference files.
173 
174### 6b: Score It Against the Rubric
175 
176Use the quality rubric from `references/quality-rubric.md`. Present the score breakdown to the user:
177 
178| Dimension | Score | Issue |
179|---|---|---|
180| Trigger quality | 6/10 | Missing beginner phrasing |
181| Defaults coverage | 3/10 | No defaults table |
182| Step structure | 8/10 | Good, but Step 3 lacks exit gate |
183| Output template | 4/10 | Vague "summarize results" |
184| Reference usage | 7/10 | Good split, but missing troubleshooting |
185 
186### 6c: Propose Specific Improvements
187 
188List concrete changes ranked by impact:
189 
1901. [Highest impact] Add defaults table with 8+ parameters
1912. [High impact] Rewrite description with 10+ trigger phrases
1923. [Medium impact] Add structured output template to final step
1934. ...
194 
195### 6d: Apply Changes
196 
197After user approval, edit the skill. Use `skill_manage(action='patch', ...)` for targeted changes or `skill_manage(action='edit', ...)` for full rewrites.
198 
199---
200 
201## Step 7: Evaluate a Skill
202 
203When the user asks to evaluate or score a skill:
204 
205### 7a: Load and Analyze
206 
207Read the full SKILL.md and all reference files. Count lines, steps, triggers, defaults, reference files.
208 
209### 7b: Score Against Rubric
210 
211Use the comprehensive rubric from `references/quality-rubric.md`. Score each of the 10 dimensions on a 1-10 scale.
212 
213### 7c: Present the Scorecard
214 
215```
216## Skill Quality Scorecard: [skill-name]
217 
218| # | Dimension | Score | Notes |
219|---|---|---|---|
220| 1 | Trigger quality | 8/10 | 12 triggers, includes sideways entries |
221| 2 | Defaults coverage | 9/10 | All 11 parameters have defaults |
222| 3 | Step architecture | 8/10 | 5 clear steps with gates |
223| 4 | Reference file strategy | 7/10 | 2 files, could use troubleshooting |
224| 5 | Dynamic content | 10/10 | Dep check + live data injection |
225| 6 | Output template | 9/10 | 5 numbered sections + verdict |
226| 7 | Error handling | 6/10 | Missing data handling unclear |
227| 8 | Code/formula quality | 8/10 | Working JS, copy-paste ready |
228| 9 | SKILL.md conciseness | 7/10 | 196 lines, well within target |
229| 10 | Domain accuracy | 9/10 | BS formulas correct, edge cases covered |
230 
231**Overall: 81/100** -- Production quality
232 
233### Top 3 Improvements
2341. ...
2352. ...
2363. ...
237```
238 
239### Benchmark Reference
240 
241For context, here are scores for known high-quality skills in this repo:
242 
243| Skill | Score | Why |
244|---|---|---|
245| sepa-strategy | ~90/100 | 9 steps, 7 refs, exhaustive triggers, structured verdict |
246| options-payoff | ~85/100 | Strong defaults, working code, live data, clean output |
247| stock-correlation | ~80/100 | Router pattern, 4 sub-skills, good defaults |
248 
249---
250 
251## Step 8: Respond to the User
252 
253### For Create mode
254 
255Deliver:
2561. The complete SKILL.md content
2572. All reference files
2583. A README.md for the skill directory
2594. The quality scorecard (from Step 5)
2605. Suggested next steps (test it, iterate, publish)
261 
262### For Improve mode
263 
264Deliver:
2651. Before/after quality scores
2662. Summary of changes made
2673. Remaining improvement opportunities
268 
269### For Evaluate mode
270 
271Deliver:
2721. The full quality scorecard
2732. Comparison to benchmark skills
2743. Prioritized improvement list
275 
276---
277 
278## Reference Files
279 
280- `references/dynamic-calling.md` -- **Core reference**: Detection flows, decision trees, method fallbacks, runtime awareness, and multi-tool adaptation patterns with annotated examples from production skills
281- `references/writing-guide.md` -- Detailed instructions for writing SKILL.md sections, environment checks, defaults tables, output templates, and reference files
282- `references/architecture-patterns.md` -- Linear, Router, Methodology, Widget, and API Wrapper patterns with examples and anti-patterns
283- `references/frontmatter-guide.md` -- Complete YAML frontmatter field reference (name, description, platform, env vars, config, credentials)
284- `references/quality-rubric.md` -- 10-dimension scoring rubric with 1-10 scales, benchmark scores, and score interpretation
285- `references/skill-examples.md` -- Annotated excerpts from top skills showing why specific patterns work
286 

Discussion

Alternatives

Also in MonitoringSee all 533 in Development →
Professional Full-Stack Developer for Network Mapping & Monitoring ApplicationAct as a professional full-stack developer tasked with building a web application for mapping and monitoring networks using Mikrotik Netwatch API. Implement multi-user role-based management to handle devices, monitor their status, and manage user subscriptions.Coding · CC0-1.0Prompt refinerHigh-end Prompt Engineering & Prompt Refiner skill. Transforms raw or messy user requests into concise, token-efficient, high-performance master prompts for systems like GPT, Claude, and Gemini. Use when you want to optimize or redesign a prompt so it solves the problem reliably while minimizing tokens.Data & AI · CC0-1.0Constraint driven developmentEstablishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.Coding · MITObservability and instrumentationInstruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.Coding · MIT