Complete Version with Skill Creation Prompts for Claude/Codex: Just Copy and Paste to Start
You want to try making Agent Skills.
But when you actually open Claude or Codex, you stop at the very first word.
"I don't know what to instruct."
"I don't know what to write in SKILL.md."
"Even if I write many rules, I'm worried if it will actually follow them."
"I don't know how much of the specification I need to think of myself."
This is natural.
When a beginner makes a Skill, they don't need to think about YAML, evaluation metrics, trigger conditions, verification scripts, or sub-agent design from the start.
You only need four things:
- What you are doing repeatedly
- What success looks like
- What specific failures you want to avoid
- Whether there is a reference example close to the ideal
For the rest, just let Claude or Codex think as a "Skill Architect."
As of July 2026, both Codex and Claude Code adopt an Agent Skills mechanism that centers on SKILL.md and loads scripts, reference materials, and templates as needed. In Codex, it first looks at the Skill name and description and only reads the body when it decides it's necessary. Claude Code is similar; the Skill body is loaded at the time of use. In other words, the important thing is not to create a long prompt, but to design the trigger conditions, processes, verification methods, and termination conditions.
First, please use the following prompt as is.
Chapter 1: Complete Skill Creation Prompt for Beginners
Paste the following into the normal chat of Claude Code or Codex.
In Codex, you may call $skill-creator before pasting. The official Codex Skill Creator also checks "what the skill does," "when it triggers," and "whether to include scripts," but the following prompt is a complete version that adds quality evaluation and loop engineering.
You are a world-class
"Agent Skills Architect"
"Workflow Engineer"
"Evaluator Designer"
I am a beginner in Agent Skills production.
Even if I don't understand technical terms or file structures,
please create a completed Skill that can actually be used in Claude Code or Codex.
Do not end with just an explanation; if there are available file operation tools,
actually create the Skill folder and necessary files.
If files cannot be created in the environment,
output the complete content for each filename without omission.
━━━━━━━━━━━━━━━━━━
■ The Skill I want to create
━━━━━━━━━━━━━━━━━━
Skill to create:
【Write here in one sentence】
Environment:
【Codex / Claude Code / Both / Not sure】
What I want to achieve with this Skill:
【Write as much as you know. If not sure, "Leave it to you"】
Examples of requests I might actually ask:
【1-3 examples. If not sure, "Leave it to you"】
Failures I absolutely want to avoid:
【Example: Text sounds too AI-like, design looks like a template, buttons look functional but don't work, claiming completion without testing, etc.】
Reference examples, materials, websites, text, or code close to the ideal:
【List if any. If not, "None"】
Quality level:
【Simple / Professional Quality / Top Quality / Not sure】
Unknown items:
【You may supplement everything as you see fit】
━━━━━━━━━━━━━━━━━━
■ Beginner Support Rules
━━━━━━━━━━━━━━━━━━
- If information is insufficient, ask up to 7 questions at once at the beginning.
- For items I answer "Not sure" or "Leave it to you," provide 3 options and recommend the one with the highest reproducibility.
- For items that can proceed without my answer, adopt reasonable defaults and record them as assumptions in assumptions.md.
- When using technical terms, include a one-line explanation in parentheses for beginners.
- Do not automatically execute irreversible operations such as billing, publishing, deploying, deleting data, or changing credentials.
- When dealing with services, APIs, or libraries whose specifications change easily, check the current official documentation. Do not decide specifications based only on old memories.
━━━━━━━━━━━━━━━━━━
■ Essential Steps for Skill Design
━━━━━━━━━━━━━━━━━━
Please strictly follow this order.
STEP 1: Intent Compilation
Convert my ambiguous request into the following:
- Skill purpose
- Target audience
- Input
- Output
- Success conditions
- Absolute conditions
- Out of scope
- Expected failures
- Necessary tools
- Operations requiring human approval
Create the following:
- brief.md
- acceptance-criteria.md
- assumptions.md
STEP 2: Trigger Condition Design
Clarify "when to use" and "when not to use" the Skill.
Include the following in the description:
- What the Skill does
- For what user purpose it is used
- Situations where it should trigger even if the user doesn't say the Skill name
- Similar requests that should NOT trigger it
- Important target files, formats, and task names
Keep the description concise and place important uses at the beginning. Do not just write "I will make it high quality" or "I will be helpful."
STEP 3: Instruction Prioritization
Divide all instructions into the following three levels:
A. HARD GATES: Conditions that must never be broken. If violated, the entire result is failed.
B. DEFAULTS: Default values to follow basically. Can be changed if there is a clear project reason.
C. PREFERENCES: Preferences for making it better. Optimize after satisfying HARD GATES and DEFAULTS.
Instead of just writing "MUST," "Absolute," or "High Quality," convert them into tests, commands, JSON judgments, or check items where possible.
STEP 4: Skill Structure Design
As a rule, consider the following:
<skill-name>/
├── SKILL.md
├── USAGE.md
├── references/
│ ├── domain-knowledge.md
│ ├── quality-rubric.md
│ └── failure-patterns.md
├── templates/
│ ├── brief-template.md
│ └── scorecard-template.json
├── evals/
│ ├── trigger-evals.json
│ └── output-evals.json
└── scripts/
└── Necessary verification scripts
However, do not create unnecessary files. Write only the core steps needed every time in SKILL.md. Separate detailed knowledge, long examples, API specs, and style guides into references. Clearly state in SKILL.md "when to read" and "what to judge" for each reference. If the AI rewrites the same deterministic process every time, move it to scripts.
STEP 5: Creation of SKILL.md
Base SKILL.md on the following structure:
- Mission, When to use, When not to use, Inputs, Required context, Priority of instructions, Workflow, Hard gates, Quality rubric, Verification, Repair loop, Stop conditions, Completion report, Supporting files. Skill names should be lowercase, numbers, and hyphens only. Match the folder name with the name. Keep the main SKILL.md under 500 lines and approximately 5,000 tokens.
STEP 6: Loop Engineering
Do not make the Skill a one-shot generation procedure. Incorporate the following loop:
- PLAN, 2. BUILD, 3. RUN, 4. OBSERVE, 5. GRADE, 6. REPAIR, 7. RETEST, 8. STOP OR CONTINUE. However, do not use excessive loops for simple tasks. Iterate up to 3 times as an initial value. Stop if: HARD GATES are passed, the passing score is exceeded, there is no meaningful improvement in the last 2 rounds, the same failure is repeated twice, cost/time limits are reached, or human judgment is required. Adopt the highest-rated checkpoint, not necessarily the last version.
STEP 7: Separation of Generator and Evaluator
For complex or subjective deliverables, separate the Generator and Evaluator roles.
Generator: Creates the deliverable.
Evaluator: Reviews the deliverable from a clean context, grades strictly, and provides specific evidence.
Evaluation results should include: criterion_id, expected, observed, passed, evidence, severity, likely_cause, minimal_fix, retest_method. The Evaluator should, if possible, run the actual deliverable, not just check the source code.
STEP 8: Verification Scripts
Verify things that can be judged mechanically with scripts rather than LLM impressions. Follow script requirements: no interactive input, provide --help, show error causes/fixes, output JSON to stdout, diagnostic info to stderr, idempotent, provide --dry-run for destructive operations, return meaningful exit codes.
STEP 9: Trigger Evaluation
Create at least the following in trigger-evals.json:
- 8-10 examples that should trigger
- 8-10 near-miss examples that should NOT trigger Include variations: polite, colloquial, short, long, typos, implicit requests, requests buried in multiple steps.
STEP 10: Output Evaluation
Create at least 3 cases in output-evals.json: Normal, Ambiguous, and Boundary/Failure cases. Include prompt, expected_output, input_files, assertions, hard_gates, and human_review_points. If possible, compare with/without the Skill or old/new versions in a clean context.
STEP 11: Improvement
Improve the Skill up to 3 times based on evaluation results. Do not add special rules that only work for failure examples. Classify the root cause of failure (Trigger, Context, Procedure, Tool, Verification, Evaluator, Stop condition, Memory). Consider deleting unnecessary instructions as well.
STEP 12: Completion Report
Finally, report the following for beginners: Skill name, save location, folder structure, what it can do, trigger examples, non-trigger examples, manual call method, initial test method, verification results, remaining constraints, and files to look at for next improvement. Show executed verification commands and evidence.
What to write in this prompt
Truly, one sentence is enough.
For example, if you want to create a human-like Japanese writing Skill, write this:
Skill to create:
A Skill to create Japanese note articles or X posts while leaving human-like fluctuations and emotions.
Environment:
Codex
What I want to achieve with this Skill:
I want the text to be easy to read but not too perfectly polished like AI.
Examples of requests I might actually ask:
"Make this experience story into a note article."
"Fix this text into my own words."
Failures I absolutely want to avoid:
Consecutive identical sentence endings, excessive bullet points, abstract theories, fake experience stories.
Reference examples:
I will provide my past articles later.
Quality level:
Top Quality
If you don't know the rest, just write this at the end:
"I don't know the rest. Please choose the safest and most reproducible configuration for a beginner."
With this level of detail, Skill design can begin.
Chapter 2: How to Actually Save and Call the Skill
The save location differs slightly between Claude Code and Codex.
Codex
If it's project-specific, place it here:
Project/.agents/skills/skill-name/SKILL.md
If you want to use it in all your projects, place it here:
~/.agents/skills/skill-name/SKILL.md
In Codex, you can specify the Skill within a prompt or select it from the CLI/IDE using $. Automatic triggering is determined by matching the description.
Claude Code
If it's project-specific, place it here:
Project/.claude/skills/skill-name/SKILL.md
If you want to use it in all your projects, place it here:
~/.claude/skills/skill-name/SKILL.md
In Claude Code, you can execute it manually with /skill-name, and it will be loaded automatically if the description matches the request content.
For example, if the Skill name is human-japanese-writer, you call it in Claude Code like this:
/human-japanese-writer Please turn the following notes into a note article...
In Codex, you specify it like this:
Use $human-japanese-writer to turn the following notes into a note article...
In the beginning, it's easier to check the behavior by calling it explicitly rather than relying solely on automatic triggering.
Chapter 3: A Skill is Not a Long Prompt
The difference between a strong Skill and a weak Skill is not the amount of text.
A weak Skill writes like this:
"Please create a high-quality website. Make it a modern and sophisticated design. Make it responsive. Be sure to test it."
In this case, the meanings of "high quality," "modern," "sophisticated," and "test" are ambiguous.
On the other hand, a strong Skill thinks like this:
- Define who the site gives what emotions to.
- Decide on the Visual Identity.
- Compare 2-3 different design directions.
- Record the reason for selection.
- Create a static completed layout.
- Actually operate it in a browser.
- Check at 375px, 768px, and 1440px.
- Separately evaluate design quality, originality, precision, and functionality.
- Fix only the failed items.
- Adopt the highest-rated version.
The essence of a Skill is not "commanding the correct answer."
It is to ensure that the model cannot skip the process of approaching the correct answer.
Chapter 4: The Eight-Layer Design Used at the Global Forefront
1. Trigger Router — When to use
A Skill is meaningless unless it triggers before its content. Agent Skills do not read all Skill bodies at startup. Initially, they mainly look at the name and description and load only the necessary Skills. This mechanism is called Progressive Disclosure.
Therefore, a description like description: Supports website creation. is weak. It's unclear what it does or where the boundaries are.
An improved example would be:
description: > Use this skill when creating or redesigning production-quality websites that require original visual direction, responsive implementation, browser-based verification, accessibility checks, and iterative design review... Do not use for backend-only work, tiny text edits, or isolated utility functions.
2. Intent Compiler — Turning ambiguous requests into contracts
If a user asks for a "stylish reservation app," a good Skill doesn't start coding immediately. It first converts it into a brief: target users, core flows, AI's role, success conditions, out-of-scope items, and absolute conditions. This intermediate deliverable prevents the model's interpretation from drifting.
3. Context Loader — Reading only necessary knowledge
Do not cram all information into the Skill body. The standard spec recommends keeping SKILL.md under 500 lines and separating details into references/. Use conditional loading: "Read references/security.md only when changing authentication or permission processing."
4. Rule Compiler — Turning requests into inspections
Instead of just saying "Dummy implementations are prohibited," a strong Skill defines a HARD GATE. It lists specific failure conditions (e.g., buttons that don't change state, hardcoded API values) and defines verification steps like searching for "TODO" or testing in a real browser.
5. Maker — The role that creates
Break down large apps into meaningful units (e.g., Registration, Login, Booking). Define completion conditions for each unit. Don't let the model pass based on source code inspection alone if the artifact can be run.
6. Checker — Grading from a different perspective
A model that just created something is biased. The Checker should ideally run in a clean context and provide evidence for its grades (e.g., "Reloading returned an empty array"). Use scripts for mechanical checks and LLM for subjective ones.
7. Repair Loop — Fixing only the failed parts
If a website's "originality" score is low, don't reimplement the whole page. Identify the cause (e.g., generic hero composition) and fix only that. If the same problem repeats twice, change the underlying strategy.
8. Durable Memory — Leaving state outside the conversation
Don't rely on the model's memory for long tasks. Use files like state.json, decisions.md, or scorecard.json to track the current phase, best checkpoints, and failed criteria.
Chapter 5: Choose Loop Strength in Three Levels
- Level 1 (Execute + Self-check): Minor fixes, short text, simple conversion.
- Level 2 (Maker + Checker + 1-3 Fixes): Professional articles, web pages, single feature implementation.
- Level 3 (Planner + Maker + Evaluator + Real Environment): High-value apps, games, video, complex MCP integration.
Complexity doesn't always mean better. Level 2 is sufficient as an initial value for beginners.
Chapter 6: General-Purpose SKILL.md Template
(The article provides a detailed markdown template for SKILL.md including sections for Mission, Workflow, Hard Gates, and Quality Rubric, designed to be compatible with both Codex and Claude Code.)
Chapter 7: Prompt to Create a Skill from a Successful Conversation
Instead of thinking from scratch, analyze a successful job you did with Claude/Codex. Use a prompt to extract: additional info needed for success, corrections you made, project-specific gotchas, reusable steps, and automated verifications.
Chapter 8: Additional Instructions for Specific Use Cases
(The article provides specific additional prompt snippets for: Human-like Japanese Writing, Non-engineer Vibe Coding, Premium Web Design, App Development, Game Development, HyperFrames Video Editing, and Video Generation MCP.)
Chapter 9-11: Improving, Fixing Triggers, and Creating Scripts
- Improving: Classify failures and identify root causes rather than symptoms. Don't overfit to one failure.
- Fixing Triggers: If a Skill isn't being called, improve the description with 10 trigger examples and 10 near-miss examples.
- Verification Scripts: Extract rules that can be mechanically verified and turn them into scripts with clear error messages and exit codes.
Chapter 12: What Beginners Should Do in the First 30 Minutes
- Choose just one task (e.g., "Create a note article from my voice memos").
- Paste the complete prompt.
- Check the created folder.
- Call it manually.
- Try with three requests (Normal, Ambiguous, Boundary).
- Fix just one failure.
Chapter 13: Common Failures
- Using only abstract words (e.g., "beautifully").
- Only increasing prohibitions without providing alternatives.
- Putting everything in SKILL.md.
- Only providing good examples.
- Claiming completion based only on source code.
- Infinite loops without stop conditions.
Conclusion: The First Thing to Instruct in Skill Creation
A strong Skill doesn't just tell the model to "work harder." It creates an environment where the AI cannot start sloppily, cannot end without verification, and cannot hide failures.
A Skill is not a clever prompt. It is a small business system for AI to reproduce high-quality work.
