name: mojo-skill-creator description: This skill should be used when the user asks to "create a skill", "make a new skill", "build a skill", "improve a skill", "boost a skill", "upgrade a skill", "audit a skill", or needs guidance on skill design, cross-platform skill creation, or skill quality improvement for any AI agent platform.
Mojo Skill Creator
Create and upgrade agent skills for distribution across Claude Code, Codex, Gemini CLI, and OpenClaw. Every decision accounts for end users who receive the skill package, not just the author.
Stance
Thinks constraints not instructions. Designs from end-user (recipient) perspective. Defines constraints before guidance.
Sub-Commands
new: Create from scratch →references/new-workflow.md(~1900w)boost: Diagnose and upgrade →references/boost-workflow.md(~1900w)
Ask if unspecified.
Core Design Principles
- Distribution-first — Self-contained, zero-config for recipients
- Constraints before guidance — Red lines first, every constraint mechanically checkable
- Acceptance criteria upfront — 3-5 testable standards from user perspective
- Stance over role — Cognitive position, not identity
- Atomic + composable — One skill, one job. Complex tasks = composition
- 4-layer token architecture — Metadata (~100w) → Router (≤1000w) → Workflow (≤2000w) → Reference (on-demand)
- Dual-axis constraints — Think (cognitive) + Do (structural); high-stakes red lines need both axes
See: references/design-philosophy.md (~1100w)
Red Lines
- No platform-specific tool names in skill instructions (use semantic verbs)
- No "You are an expert/senior/experienced..." role assignments
- No SKILL.md body exceeding 2000 words without layer decomposition
- No subjective acceptance criteria. Test: two reviewers must independently agree on pass/fail
- No red line uncheckable via output scan
- No workflow file exceeding 2000 words without phase-gated loading
- No assumption that end users have pre-installed tools or global packages — distributed skills work out of the box
- No phase/step completes without mandatory artifact in diagnosis/ (boost) or build/ (new). Check: artifact exists before next step
- No domain research completed with < 5 independent sources. Check: research artifact contains ≥ 5 entries with name, finding, and implication
- No high-stakes red line in a produced skill left cognitive-only when structural enforcement is feasible. Check:
build/constraint-enforcement-plan.mdclassifies each red line's enforcement axis - No architecture decision (affecting ≥2 files or constraining future changes) without an ADR. Check:
docs/adr/contains entry with all 5 sections - No breaking change to published interfaces (semver-tagged or distributed) without deprecation. Check: diff interface sections against previous version tag
- No secret (password, API key, token) transits LLM conversation or appears in logs. Check: grep for credential patterns in transcripts and source
Acceptance
- Deploys to 4 target platforms without modification
- SKILL.md: ≥5 red lines, ≥3 acceptance criteria, stance (not role)
- Always-loaded tokens ≤ 3000 words
- Design decisions traceable to named files/headings
- Constraint enforcement plan classifies ≥30% of red lines with Do-axis mechanisms
Development Practices
Engineering discipline for MSC development [A] and produced skills [B]. Full rules + ADR template + CHANGELOG spec: references/development-practices.md
- P1 [AB] Zero-dependency preference — justify every added dependency
- P2 [AB] Every new feature ships with tests
- P3 [AB] Every decision has a research trail, not convention alone
- P4+P5 [AB] Architecture decisions and non-decisions recorded as ADRs
- P6 [AB] Backward compatibility — published interfaces cannot break
- P7 [AB] Linter zero warnings as CI gate
- P8 [AB] CHANGELOG in hybrid format (narrative header + Keep a Changelog)
- P10 [AB] Secrets never transit LLM conversation or logs
- P12 [AB] Prove existing mechanisms insufficient before adding features
- P13 [AB] Investigate actual user behavior before adding or cutting features
Conditional (B only, in reference file): security layered design (P9), anti-duplicate counting (P11).
References
| File | Content | Load When |
|---|---|---|
references/new-workflow.md (~2000w) | new workflow (10 steps + 3d enforcement) | User invokes new |
references/boost-workflow.md (~2000w) | boost workflow (4 phases incl. enforcement audit) | User invokes boost |
references/design-philosophy.md (~1100w) | 7 design principles with examples | Designing red lines, stance, structure |
references/constraint-enforcement-guide.md (~1100w) | Think/Do axis model + 4 enforcement mechanisms | new Step 3d / boost Phase 1.9 |
references/platform-adaptation.md (~900w) | 4-platform tool mapping + fallbacks | Cross-platform decisions |
references/anti-patterns-by-domain.md (~750w) | Domain failure pattern checklists | Designing domain red lines |
references/domain-research-guide.md (~1100w) | How to study expert workflows + synthesize findings | new Step 2 / boost Phase 1.7-1.8 |
references/quality-ladder.md (~1200w) | Knowledge layer diagnosis + case methodology | boost diagnosis |
references/se-kit-integration.md (~650w) | Optional self-evolution via skill-se-kit | new Step 6b / boost Phase 1.6 |
references/behavioral-eval-guide.md (~900w) | Optional behavioral eval + surgical fix loop | new Step 10 |
references/development-practices.md (~900w) | Development practices, ADR template, CHANGELOG spec | Designing red lines, reviewing changes |