The FrankX Skill Creation Methodology

This guide is a field method for building AI skills that actually compound.

It is built with gratitude for the people and teams moving this space forward: Anthropic for making Agent Skills concrete, the open-source builders publishing working examples, the AI teams stress-testing these ideas in production, and the operators turning raw model capability into useful work.

The move here is additive. We do not need to subtract from the work already done. We can stand on it, learn from it, and raise the operating standard.

Anthropic's Agent Skills gave the ecosystem a clean primitive: a folder with a SKILL.md file, metadata, instructions, and optional references, scripts, and assets. The official repository and documentation show the anatomy. The deeper opportunity is to turn that primitive into a full skill creation methodology: one that supports solo builders, startup teams, and enterprise AI Centers of Excellence.

That is what this guide covers.

The Core Thesis

The next AI advantage is not better prompting.

It is the ability to convert repeatable work into reusable, evaluated, governed operating knowledge.

Prompts are useful. They are also fragile. They live in chats, docs, bookmarks, private memory, and half-remembered workflows. A skill is different. A skill packages a workflow so an AI agent can recognize when to use it, load the right context, run deterministic checks, follow a quality standard, and produce a result that a team can trust.

The FrankX method treats skills as operating knowledge units.

Each skill should answer:

• What repeatable work does this encode?
• Who benefits from the output?
• When should the agent use it?
• What references matter?
• What steps must not be skipped?
• What should be verified by code instead of language?
• What quality bar does the output need to meet?
• What risk does this introduce?
• Who owns it?
• How do we know it still works?

If those answers are missing, the asset is not yet a real skill. It is a prompt with a folder around it.

The Five Layers

The FrankX Skill Creation Method has five layers.

1. Intent

Start with the work, not the file structure.

The first question is not "What should the SKILL.md say?" The first question is "Which workflow deserves to become reusable?"

Good candidates are:

• frequent
• valuable
• context-heavy
• teachable
• easy to evaluate
• painful when done inconsistently

Poor candidates are:

• vague
• rarely used
• dependent on hidden judgment
• too broad to test
• risky without clear approval gates

Example of a weak intent:

Help with content.

Example of a strong intent:

Turn a research brief into a founder-grade blog post with a clear thesis, practical examples, internal links, source notes, and a final quality checklist.

The second version can become a skill. The first version is an aspiration.

2. Knowledge

Every useful skill carries knowledge the agent should not have to rediscover.

That knowledge may include:

• style guides
• templates
• pricing rules
• evaluation rubrics
• examples of good work
• examples of bad work
• customer language
• product constraints
• compliance language
• architecture patterns
• team preferences
• decision rules

The main SKILL.md should not become a giant knowledge dump. Use progressive disclosure:

• Put routing and workflow instructions in SKILL.md.
• Put deeper references in references/.
• Put reusable templates in assets/.
• Put deterministic checks in scripts/.

The skill should feel like a smart onboarding guide for a new teammate: clear enough to act, structured enough to scale, and humble enough to know when to look up the source material.

3. Execution

A skill must tell the agent what to do.

Not "be strategic."

Not "write high quality output."

Actual steps:

1. Read the brief.
2. Validate required inputs.
3. Load the relevant reference file.
4. Draft the output in the approved structure.
5. Run the checklist.
6. Mark assumptions.
7. Return the result with next actions.

For deterministic work, use scripts:

• validate required fields
• parse a document
• compare schemas
• check word count
• scan for banned phrases
• verify links
• calculate metrics
• inspect a repository
• generate a report

Language models are excellent at synthesis. They should not be asked to manually perform every repeatable check that code can perform better.

4. Evaluation

Skills need proof.

At minimum, create three evaluation scenarios:

• a clean success case
• an incomplete input case
• a misuse or boundary case

For serious use, evaluate:

• trigger accuracy
• false positives
• step adherence
• reference loading
• script usage
• output quality
• policy compliance
• coexistence with other skills
• regression across versions

The quality bar is simple: a skill is not ready because it worked once. It is ready when it works repeatedly against representative tasks.

5. Governance

Skills are operational artifacts. They deserve ownership.

Every shared skill should have:

• name
• purpose
• owner
• version
• status
• risk tier
• intended users
• required tools
• allowed data
• evaluation set
• last reviewed date
• rollback version

For a founder, this can be a simple table.

For a startup, this should live in the repo.

For an enterprise, this belongs in the AI Center of Excellence operating model.

The Skillforge Canvas

Use this canvas before writing the skill.

If the canvas is weak, the skill will be weak.

Folder Standard

Recommended structure:

skill-name/
  SKILL.md
  references/
    style-guide.md
    examples.md
    policy.md
  scripts/
    validate-inputs.py
    check-output.py
  assets/
    template.md
  evals/
    scenarios.md

Not every skill needs every folder. But every important skill needs the discipline behind them.

Use references/ when the content is too detailed or situational for the main file.

Use scripts/ when an operation should be deterministic.

Use assets/ when there is a reusable template or source artifact.

Use evals/ when the skill will be shared or maintained over time.

The SKILL.md Standard

A strong SKILL.md has this shape:

---
name: customer-discovery-synthesis
description: Synthesizes customer interviews into patterns, objections, jobs-to-be-done, risks, and product implications. Use when the user provides interview notes, call transcripts, discovery notes, or asks for customer research synthesis.
---

# Customer Discovery Synthesis

## Purpose

Turn raw customer conversations into actionable product and go-to-market intelligence.

## Required Inputs

- At least one interview note, transcript, or call summary
- Target customer segment if known
- Current product or offer context if relevant

## Workflow

1. Read the source material.
2. Extract direct customer language.
3. Cluster pain points and desired outcomes.
4. Separate evidence from interpretation.
5. Identify objections, buying triggers, and unresolved questions.
6. Produce the output using the approved structure.
7. Run the quality checklist before returning.

## Output Structure

- Executive summary
- Customer language
- Pain patterns
- Desired outcomes
- Objections
- Product implications
- Sales implications
- Follow-up questions

## Quality Checklist

- No invented quotes
- Claims tied to source evidence
- Assumptions marked clearly
- Recommendations separated from observations
- Follow-up questions are specific

The description matters because it is the routing layer. The body matters because it is the operating procedure.

Risk Tiers

Use a simple risk model.

Do not over-govern simple work.

Do not under-govern sensitive work.

The craft is matching friction to risk.

The FrankX Quality Bar

A skill is strong when:

• it has a narrow job
• it has explicit trigger language
• it names required inputs
• it separates evidence from interpretation
• it uses references instead of relying on memory
• it uses scripts for deterministic checks
• it has real examples
• it includes anti-patterns
• it has a quality checklist
• it can be evaluated
• it has an owner

A skill is weak when:

• it tries to cover a whole department
• it says "use best practices" without defining them
• it hides important knowledge in vague language
• it cannot be tested
• it has no data boundary
• it creates outputs nobody reviews
• it depends on the agent guessing the real workflow

How This Connects to an AI CoE

An AI Center of Excellence should not only govern models and tools. It should govern reusable operating knowledge.

For skills, the CoE should maintain:

• a skill registry
• role-based skill bundles
• naming standards
• evaluation requirements
• risk tiers
• approval paths
• deployment rules
• version history
• deprecation rules

The CoE should also prevent the common failure mode: becoming a bottleneck.

The right model is central standards, federated execution. The CoE sets the operating system. Teams ship within it.

Startup Version

For a startup, keep this lightweight:

• one shared skills/ repository
• one owner per skill
• three eval scenarios per skill
• one monthly review
• risk tiers only for sensitive work
• a simple registry table

The first startup skills should come from recurring leverage:

• customer discovery synthesis
• PRD builder
• release note writer
• sales proposal builder
• support escalation analyst
• investor update generator
• weekly operating review

Enterprise Version

For an enterprise, skills become part of AI operating governance.

Add:

• security review for third-party skills
• source control and signed commits
• version pinning
• rollback plan
• cross-surface distribution management
• audit logs where tools are involved
• legal/privacy review for sensitive workflows
• coexistence tests for active skill bundles

Enterprises should also design role-based bundles:

• sales
• engineering
• support
• legal
• finance
• HR
• executive operations

The goal is not to activate every skill for everyone. The goal is to make the right operating knowledge available to the right people at the right moment.

The Book Perspective

This guide is the seed of a larger book.

Working title:

Operating Knowledge: How to Build AI Skills, Agents, and Centers of Excellence That Compound

Possible structure:

1. The end of prompt chaos
2. Skills as operating knowledge
3. The anatomy of a useful skill
4. Progressive disclosure and context design
5. Scripts, references, and deterministic checks
6. Evaluation as the new craft
7. Skill libraries for founders
8. Skill registries for startups
9. AI CoE governance for enterprises
10. Security and semantic supply-chain risk
11. Role-based bundles and agent teams
12. The future: self-improving operating systems

The book should not be another tool guide. It should be a standard for how serious builders turn AI into durable capability.

What To Read Next

• Building Custom Skills for ACOS
• Why Everyone Needs Their Own AI Center of Excellence
• Agent Card A2A Spec
• Research: Agent Skills as Operating Knowledge
• Research Hub

Source Base

• Anthropic Agent Skills engineering post
• Anthropic Skills repository
• Claude Agent Skills overview
• Claude Skill authoring best practices
• Claude Skills for enterprise
• Microsoft AI Center of Excellence guidance
• AWS enterprise generative AI scaling guidance
• IBM AI Center of Excellence overview