Turn a tested process into a Skill
You will write one project Skill, invoke it deliberately and test correct, incorrect and missing-source cases. Outputs are illustrations.
Sources checked September 30, 2026 describe Skills as instructions in SKILL.md with optional supporting files. Older custom commands remain compatible, but the Skill directory adds richer structure. A Skill does not create external account access.
Test the process first
Before installation, try the review instructions in chat:
Compare my draft with the supplied source.
Separate facts, proposals and missing details.
List unsupported claims, return a corrected draft and explain changes.
Do not edit files, send, publish or connect services.
If the source is missing, ask for it.
Use a real repeated need, not a one-off preference, to justify a Skill. Keep the process small enough to test.
Create a project-scoped Skill
In the practice repository create .claude/skills/course-update-check/SKILL.md:
---
name: course-update-check
description: Review a supplied course-update draft against its source.
disable-model-invocation: true
---
# Course update check
Use only the source and draft supplied for this request.
Separate facts, proposals and missing information.
Return unsupported claims, a corrected draft and a change list.
If no source is supplied, ask for it.
Do not edit files, send, publish or connect services.
The invocation-control field makes this a manually triggered process in Claude Code. It is not a filesystem deny rule. Do not add broad allowed-tools simply because another sample contains it: that field can affect approval behavior during invocation.
Project scope avoids applying a course-specific process globally. Keep keys, customer data and temporary facts out of the file.
Invoke and test three cases
Use the command exposed by your actual installation, such as /course-update-check, then supply:
Source: Chapter 1 ready; Chapter 2 under review; no date set.
Draft: All chapters ready and launch is Sunday.
Run the course-update-check process on this pair only.
Illustrative output:
Unsupported: all chapters ready; Sunday launch.
Corrected: Chapter 1 is ready, Chapter 2 remains under review and no date is set.
Changes: removed an unsupported generalization and date.
Test an accurate draft too. It should not invent defects or add new facts. Finally omit the source. Success is a source request or explicit inability to verify, not a confident approval.
Check discovery and edits
Inspect the / menu and loaded Skill behavior. Current sources describe live SKILL.md text detection, while other plugin components can require reloading. Controls differ by version, so test behavior after changes instead of assuming listing equals activation.
Some frontmatter fields are Claude-Code-specific and are not accepted by every Claude skill-upload route. Do not upload the same file elsewhere without checking that product's schema.
Add supporting material only when needed
A short reference or output template can live beside SKILL.md and be linked from it. Scripts are executable code, not merely documentation. This exercise includes no script, dynamic shell injection or network call.
If a Skill needs deployment or sending later, keep invocation and approval decisions explicit. A process written in a file is not permission to act for another person.
Graded practice
Easy: correct scope
Create the project Skill. Success: correct directory and no global side effects.
Intermediate: test cases
Run accurate and inaccurate drafts. Success: factual correction without invention.
Challenging: missing source
Run without evidence. Success: the process stops short of approval.
Troubleshooting
Command missing: inspect path, frontmatter and product/version.
Wrong trigger: tighten description and manual invocation control.
Unexpected tool approval: inspect allowed-tools and actual permission settings.
Skill works once, fails later: rerun the three test cases after edits.
Too much material: keep main instructions short and reference only necessary supporting content.