Skill Authoring Workflow
Turn raw PM content into a compliant, publish-ready Claude skill via 6 phases (preflight → generate → tighten → validate → integrate → package) using repo-native scripts.
You wrote a great skill, skipped validation, forgot to update the README counts, and shipped anyway. Now references are broken, catalog numbers are inconsistent, and contributors don't trust the system. The fix isn't more discipline — it's a workflow that bakes in `find-a-skill.sh`, `add-a-skill.sh`, `test-a-skill.sh`, metadata checks, and README updates as steps you can't skip.
Who it's for: Skill contributors to deanpeters/Product-Manager-Skills, plugin authors, repo maintainers, anyone authoring Claude custom skills with strict standards
Example
"Turn workshop notes into a new interactive PM skill" → Phase 1 search for duplicates → Phase 2 `add-a-skill.sh research/notes.md` → Phase 3 manual tighten → Phase 4 `test-a-skill.sh --smoke` + metadata + trigger checks → Phase 5 README catalog update → Phase 6 optional zip for upload
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Skill Authoring Workflow
Turn raw PM content (workshop notes, half-baked prompts, research dumps) into compliant, publish-ready skills that pass validation. Six-phase workflow for creating or updating skills without breaking standards.
Use it when you want to ship a skill without "looks good to me" roulette.
## Dogfood First
Repo-native tools before custom processes:
- `scripts/find-a-skill.sh` — search existing
- `scripts/add-a-skill.sh` — content-first generator
- `scripts/build-a-skill.sh` — guided wizard
- `scripts/test-a-skill.sh` — smoke tests
- `scripts/check-skill-metadata.py` — frontmatter validation
- `scripts/check-skill-triggers.py` — description triggers
## Pick the Right Path
- **Guided wizard** (`build-a-skill.sh`) — idea but no final prose
- **Content-first generator** (`add-a-skill.sh`) — already have source content
- **Manual edit + validate** — tightening existing skill
## Definition of Done (No Exceptions)
1. Frontmatter valid (`name`, `description`, `intent`, `type`)
2. Section order compliant
3. Metadata limits (`name` ≤64, `description` ≤200 chars)
4. Description: what + when to trigger
5. Intent: fuller summary, doesn't replace trigger description
6. Cross-references resolve
7. README catalog counts/tables updated
## The 6 Phases
### Phase 1: Preflight (Avoid Duplicate Work)
```bash
./scripts/find-a-skill.sh --keyword "<topic>"
```
Decide type:
- **Component** — one artifact/template
- **Interactive** — 3-5 adaptive questions + numbered options
- **Workflow** — multi-phase orchestration
### Phase 2: Generate Draft
Source material exists:
```bash
./scripts/add-a-skill.sh research/your-framework.md
```
Guided prompts:
```bash
./scripts/build-a-skill.sh
```
### Phase 3: Tighten
Manual review for:
- Clear "when to use" guidance
- One concrete example
- One explicit anti-pattern
- No filler / no consultant-speak
### Phase 4: Validate Hard
```bash
./scripts/test-a-skill.sh --skill <skill-name> --smoke
python3 scripts/check-skill-metadata.py skills/<skill-name>/SKILL.md
python3 scripts/check-skill-triggers.py skills/<skill-name>/SKILL.md --show-cases
```
### Phase 5: Integrate Repo Docs
For new skills:
1. Add to README category table
2. Update skill totals + category counts
3. Verify link paths resolve
### Phase 6: Optional Packaging
```bash
./scripts/zip-a-skill.sh --skill <skill-name>
# or category:
./scripts/zip-a-skill.sh --type component --output dist/skill-zips
# or preset:
./scripts/zip-a-skill.sh --preset core-pm --output dist/skill-zips
```
## Common Pitfalls
- Shipping vibes, not standards
- Choosing `workflow` when it's really a component template
- Bloated descriptions exceeding upload limits
- Description says what skill is but not when to trigger
- Description hits 200-char limit and gets cut mid-thought
- Letting `intent` substitute for weak trigger description
- Forgetting README count updates after adding
- Treating generated output as final without review
## References
- `README.md`, `AGENTS.md`, `CLAUDE.md`
- `docs/Building PM Skills.md`
- `docs/Add-a-Skill Utility Guide.md`
- Anthropic, *Complete Guide to Building Skills for Claude*
What This Does
Six-phase workflow with explicit Definition of Done (frontmatter valid, metadata within limits, cross-references resolve, README counts updated). Uses repo-native scripts at every step instead of inventing custom validation.
Specific to the deanpeters/Product-Manager-Skills repo, but the pattern applies to any structured Claude Skills repo.
Quick Start
mkdir -p ~/Documents/SkillAuthoring
mv ~/Downloads/CLAUDE.md ~/Documents/SkillAuthoring/
cd ~/Documents/SkillAuthoring
claude
Provide source material (workshop notes, prompt drafts, research file path) and target skill type. Claude orchestrates the 6 phases including tool invocations.
The 6 Phases
| Phase | Tool/Action | Output |
|---|---|---|
| 1. Preflight | find-a-skill.sh --keyword |
No duplicate; type chosen |
| 2. Generate Draft | add-a-skill.sh or build-a-skill.sh |
Skill folder created |
| 3. Tighten | Manual review | Clear when-to-use + example + anti-pattern |
| 4. Validate | test-a-skill.sh --smoke + metadata + triggers |
All checks pass |
| 5. Integrate | Update README catalog + counts | Catalog reflects new skill |
| 6. Package | zip-a-skill.sh (optional) |
Upload-ready zip |
Tips & Best Practices
- Search before authoring.
find-a-skill.shsaves you from rebuilding what exists. - Pick
componentfirst.workflowis for true multi-phase orchestration, not "I have several sections." - Description = trigger, not description. Say when Claude should use it, not just what it is.
- 200 chars is hard. Drafts that hit 200 mid-sentence get truncated by uploaders.
- Always run
--smoke. It's the difference between "I think it works" and "the structural checks pass."
Common Pitfalls
- Skipping
find-a-skill.shand duplicating an existing skill - Choosing
workflowfor what's really acomponent - Writing 250-char descriptions that fail upload validation
- Forgetting to update README counts after adding a skill
- Treating
add-a-skill.shoutput as final without manual review