메뉴
Create and validate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | BuildSkill |
| version | 0.1.0 |
| description | Create and validate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions. |
Create and validate skills following forge conventions. Skills are markdown files (SKILL.md) with YAML frontmatter that teach AI coding tools new capabilities. Load only the companion relevant to the current task.
| Workflow | Trigger | Companion |
|---|---|---|
| Create | "create a skill", "new skill", "write a skill" | @CreateWorkflow.md |
| Validate | "validate skill", "check skill structure" | @ValidateWorkflow.md |
| Topic | Companion |
|---|---|
| SKILL.md structure, frontmatter, body layout, naming | @SkillStructure.md |
Dynamic context injection (!): open a Claude skill with live state | @DynamicContextInjection.md |
Multi-provider routing via defaults.yaml | @MultiProviderRouting.md |
| Wrapping a CLI tool in a skill | @CliToolIntegration.md |
Platform-agnostic writing — no placeholders or / prefix | @PlatformAgnostic.md |
| User-config schema for AI-first artifacts (autoMode mirror) | @UserConfigSchema.md |
Claude-only features: @ refs, skill discovery, allowed-tools | @ClaudeSkill.md |
| When to author a per-skill INSTALL.md | @SkillInstallation.md |
| Thought | Reality |
|---|---|
| "Put argument-hint in SKILL.md frontmatter" | Obsidian Linter reformats frontmatter. Provider-specific fields go in SKILL.yaml. |
"Use /SkillName inside a skill body" | Slashes are user-facing invocation syntax, not internal references. |
"Skip the USE WHEN clause" | Claude uses it to route. Missing trigger = skill never fires. |
| "Leave a stub section as a placeholder" | Skill bodies are plain prose. Delete empty sections, don't scaffold them. |
| "Inline every example in the SKILL.md" | SKILL.md should stay slim. Move static reference material to companion files. |
| "Skill directory can have any name" | Directory name must match the name: frontmatter field exactly. |
"Put a ! injection in a companion file" | ! runs only in the SKILL.md body; in a companion it renders as literal text. See @ClaudeSkill.md. |
"Inject a secret value with ! (e.g. pass show)" | Injection lands in the transcript. Inject structure/status (names, vault list), never secret values. |
| "It ran in my sandbox, so the probe is done" | Your sandbox has tooling (uv, personal paths, aliases) the target machine lacks — resolve interpreters at preflight and assume a clean environment. |
name: and description: in frontmatterUSE WHEN trigger phrasesname: fieldCreate, validate, evaluate, and iterate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions, test a skill, run skill evals, benchmark a skill, skill not triggering, optimize skill description. Not for adopting community skills (AdoptArtifact) or shipping artifacts downstream (PublishArtifact).
Create, validate, or place behavioral rules in forge modules. USE WHEN create rule, new rule, write rule, capture rule, add a rule, graduate a correction or convention to a rule, validate rule, rule conventions, where does this rule belong, or the user runs /Rule.
Scaffold a workshop project: a VCS spine (git + jj colocate + entire + forge hooks), the private/public/assets flow layout with a .tlp manifest, a .claude/ that mounts the knowledge vault, and on-demand satellites (vault folder-note, data dir, private remote). USE WHEN starting a new project, initializing a folder for work, adding a vault note or data dir or remote to a project, archiving a project, or the user runs `project` / `atlas`.
Collaborative ideation before implementation — explore context, clarify intent, propose approaches. USE WHEN starting creative work, new features, design decisions, or modifying behavior.
Write a formal design spec from brainstorming output or requirements. USE WHEN design approved, write spec, formalize design, spec document.
Execute an implementation plan inline — task by task in a single session — then finish the work: verify, present integration options (merge, PR, keep, discard), and clean up the workspace. USE WHEN executing plan, run plan, implement plan, inline execution, implementation complete, deciding merge strategy, finishing a feature branch or workspace.