Menu
Internal authoring template and manual canary. Copy this directory to start a new techne skill.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | _template |
| description | Internal authoring template and manual canary. Copy this directory to start a new techne skill. |
| disable-model-invocation | true |
Use this file as the starting point for a new techne skill. Keep the skill body tool-neutral: the guidance here should make sense outside any one host, with tool-specific loading handled by plugin manifests.
A techne skill must force a move the model can make but often skips. It is not a place to restate common knowledge, collect vague advice, or duplicate what the platform or superpowers already handles well.
Before authoring, identify:
State the triggering situation in concrete terms. Prefer user intents, task conditions, and failure signals over broad domain labels.
Write the smallest set of instructions that reliably forces the move. Use direct commands, checks, and stop conditions. Avoid product-specific paths, local tool names, or host-only features unless they are documented as optional references.
Each real skill should include an eval.md alongside SKILL.md. The eval file
records the empirical acceptance test from WORKFLOW.md: baseline behavior,
with-skill behavior, what counts as improvement, and the pass bar.
For scaffold-only or template changes, direct mechanical validation is enough.
Optional files live next to SKILL.md when they remove noise from the main
skill:
eval.md for the empirical acceptance test.scripts/ for executable helpers the model may run.reference.md for longer material loaded only when needed.Do not add empty support folders. Add them only when the skill actually needs them.
Reproduce a behavioral bug before fixing it, record the failing probe, and verify the fix with the same probe. Use for bug reports, failing tests, crashes, hangs, regressions, wrong output, and observable behavior that should change.
Interrogate a written engineering implementation brief before work starts. Use when a user brings a ticket, PRD, design note, or substantive engineering task brief and wants to begin implementation planning; force every fixed rubric element to be accounted, cite present/weak claims against the brief, surface gaps, solution-as-goal traps, contradictions, and questions, then emit an intent-level plan. Do not use for bare one-line requests, non-engineering artifacts, code diff review, bug fixing, or execution itself.
Evidence-gated diff review for PRs, branches, commit ranges, staged code changes, and merge readiness checks. Use when an AI reviewer must review a concrete git-anchored diff, judge whether code is safe to merge, inspect a PR URL or branch, cross-examine PR or commit claims, account blast radius, or render approve/request-changes/blocked verdicts. Do not use for design-only review, whole-codebase audits, bug fixing, or code authoring without a git diff under judgment.
Draw a faithful architecture or structure diagram of a real codebase or project by scanning the actual repo, never guessing. Use for system architecture, request lifecycle, data model, state transitions, type structure, draw the architecture, map this project, 画架构图.