/CreateSkill

name: CreateSkill
version: 1.1.31
description: "Mandatory orchestrator for all LifeOS skill work — creating, editing, adding a workflow or tool, renaming, validating, or canonicalizing any skill. Handrolling skill files is forbidden; owns the full lifecycle: scaffold, validate, canonicalize, test, improve. USE WHEN create skill, new skill, make a skill, build a skill, set up a skill, private skill, make a X skill, add a workflow, add a tool, edit/change/update/rename a skill, skill frontmatter, validate skill, check skill, canonicalize, scaffold skill, test skill, improve skill, optimize description, skill not triggering, overtriggering. NOT FOR TypeScript CLI generation (use CreateCLI)."

Customization

**Before executing, check for user customizations at:** `~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CreateSkill/`

If this directory exists, load and apply any PREFERENCES.md, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

🚨 MANDATORY: Voice Notification (REQUIRED BEFORE ANY ACTION)

**You MUST send this notification BEFORE doing anything else when this skill is invoked.**

1. **Send voice notification**:

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the CreateSkill skill to ACTION"}' \
     > /dev/null 2>&1 &

2. **Output text notification**:

   Running the **WorkflowName** workflow in the **CreateSkill** skill to ACTION...

**This is not optional. Execute this curl command immediately upon skill invocation.**

CreateSkill

Complete skill development lifecycle: **structure** (create, validate, canonicalize) + **effectiveness** (test, improve, optimize triggers). Structural workflows ensure skills follow LifeOS conventions. Effectiveness workflows — inspired by Anthropic's skill-creator — ensure skills actually work and trigger reliably.

Authoritative Source

**Before creating ANY skill, READ:** `~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md`

**Canonical example to follow:** any well-formed public skill in `~/.claude/skills/` (e.g. `Research/SKILL.md`, `Daemon/SKILL.md`, `CreateSkill/SKILL.md` itself).

Naming Convention — Public vs Private

**Skill name encodes its public/private status. There are exactly two valid forms.**

| Skill type | Directory format | Example | Allowed content | |------------|------------------|---------|-----------------| | **Public** | `TitleCase` | `Blogging`, `Daemon`, `CreateSkill` | Templated, safe, generic, ready for public release | | **Private** | `_ALLCAPS` (underscore prefix, all uppercase) | `_MYSKILL`, `_MYINBOX`, `_MYINFRA` | Personal-scoped *function*; body publishable-clean, all sensitive data referenced from `LIFEOS/USER/` |

**The leading underscore is the public-release boundary.** Release tooling skips `_*` skills entirely — they never leave `~/.claude`. Public skills (no underscore) are mirrored into the LifeOS public release and MUST contain only generic, templated content.

**Sub-file naming (both public and private skills):**

| Component | Format | Example | |-----------|--------|---------| | Workflow files | `TitleCase.md` | `Create.md`, `UpdateDaemonInfo.md` | | Reference docs | `TitleCase.md` | `ProsodyGuide.md`, `ApiReference.md` | | Tool files | `TitleCase.ts` | `ManageServer.ts` | | Help files | `TitleCase.help.md` | `ManageServer.help.md` |

**Wrong (NEVER use):**

• Skill dirs: `createskill`, `create-skill`, `CREATE_SKILL` (no underscore + caps for public; no kebab/snake for private)
• Files: `create.md`, `update-info.md`, `SYNC_REPO.md`

Choosing public vs private — the decision rule

Ask: **"Could this skill be dropped, as-is, into a stranger's `~/.claude/skills/` and just work?"**

• **Yes** → public skill (`TitleCase`). Body must be generic; user-specific config layers in via `LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/`.
• **No, because it references my identity, my contacts, my business, my customer, my paid API, my private infra, my domain, my private repo, my partner, or my financial/health/security data** → private skill (`_ALLCAPS`).

**When in doubt, build it private first (`_ALLCAPS`). Promoting `_FOO` → `Foo` later is easy. Discovering a public skill leaks your life is permanent.**

---

Public Release Readiness (MANDATORY)

**Public skills (`TitleCase`) ship to the world. Private skills (`_ALLCAPS`) never leave the local repo.** Sensitivity is decided by skill name, not by per-file scrubbing at share-time.

The Bright Line

**Public skill (`TitleCase`) — content rule:**

ONLY templated, safe, public, ready content. Period.

• ✅ Generic instructions any LifeOS user could follow
• ✅ Templated patterns with placeholders for user-specific values
• ✅ Public API references and dependencies on public tools
• ❌ Real names (people, products, companies, customers)
• ❌ Real domains, hostnames, IPs, internal URLs
• ❌ API keys, tokens, credentials, session cookies, OAuth secrets — even example-looking ones
• ❌ Private repo paths or references (`github.com/<org>/<private-repo>`)
• ❌ Customer data, customer-specific workflows, customer engagement context
• ❌ First-person war stories tied to a specific incident, project, or person
• ❌ User-specific filesystem paths (`/Users/<name>/...`, `/home/<name>/...`)
• ❌ Identity-bound preferences (DA name, principal name, partner name, pet name, financial figures, health data)

**Private skill (`_ALLCAPS`) — content rule (2026-07-23 separation directive):**

Same publishable-clean standard as public skills. The underscore is still the release boundary (release tooling skips `_*` — that safety net stays), but it no longer licenses embedding personal content. A private skill's body — SKILL.md, workflows, tools — holds only generic code and instructions; everything sensitive lives under `LIFEOS/USER/` and the skill reads it