Agent Certifier
This skill turns human certifications (e.g. PL-300, CPA, SAP B1, Azure AI)
into machine-certifiable agents with clear skills, benchmarks, and a signed
competency contract.
Use this skill when the user gives:
- A human cert or license name (e.g. "PL-300: Power BI Data Analyst")
- Optionally one or more reference repos or products (e.g.
microsoft/powerbi-desktop-samples)
- A target agent name/slug (e.g.
powerbi-bi-architect)
Your job is to emit a complete, market-ready bundle:
- A skills spec (YAML) with levels, benchmarks, and tools
- An agent spec (YAML) wired to those skills
- A human-readable
skills.md for documentation
- Optional certification JWT schema, compatible with an external CertificationAuthority
When to Use This Skill
Invoke this skill whenever the user wants to:
- Translate a human certification (Azure, SAP, CPA, Azure AI, etc.) into an agent certification ladder
- Define skills + tools + benchmarks for an agent in a reusable, model-agnostic way
- Produce ready-to-commit files for a repo:
skills/<domain>.yaml
agents/<agent_slug>.yaml
docs/<agent_slug>-skills.md
The output should be designed so it can be:
- Used by Claude Skills (this SKILL.md format)
- Loaded by OpenSkills (
anthropics/skills compatible)
- Reused by other agents (Gemini, OpenAI, etc.) via the same YAML contracts
Input Format
Assume the user will give you (in natural language, not strict JSON):
- Human cert(s) and level(s)
- e.g. "PL-300 + DP-500 + Power Platform Solution Architect Expert"
- Domain / role
- e.g. "Power BI / Fabric BI Architect for retail dashboards"
- Reference repos or artifacts (optional but common)
- e.g. GitHub URLs, product pages, sample
.pbix, .twb, etc.
- Target agent id/slug
- e.g.
powerbi_bi_architect
You must infer missing pieces safely and document assumptions.
What To Produce
Always produce three main artifacts (as copy-paste-ready blocks):
1. skills/<domain>.yaml
A YAML file that defines:
version, domain
human_analogs: list of human certs you are mirroring
sources: reference repos or artifacts (GitHub, sample files)
tools: logical tool contract names (e.g. pbix_reader, dax_analyzer)
skills:
- Each with
id, level (fundamentals/role_based/specialty/business/expert etc.)
human_analog, description
required_tools, optional prerequisites
benchmarks: each with id, description, repo_source, and success_criteria list
Keep tool names abstract so they can be mapped to OpenAI/Gemini/Claude tool schemas later.
2. agents/<agent_slug>.yaml
An agent spec that:
- References the domain and skill IDs from the skills YAML
- Lists required tools by id
- Defines
human_cert_analogs (strings)
- Defines
certification_policy:
- Levels (
fundamentals, associate, expert, etc.)
required_skills for each level
min_benchmarks_passed per level
issuance block:
title_template
validity_days
conditions (bullets)
Include a benchmarks_runtime block describing:
repo_sources (e.g. microsoft/powerbi-desktop-samples)
execution.runner (e.g. ci.pipeline.powerbi)
schedule (e.g. nightly)
3. docs/<agent_slug>-skills.md
A markdown doc for humans that:
- Explains which human certs this agent emulates
- Lists each skill level with:
- Human analog
- Capabilities (bullets)
- Benchmark(s) and pass criteria
- Explains the certification policy:
- What "Fundamentals / Associate / Expert Certified" means
- How the external
CertificationAuthority JWT is issued & used
Structure this as:
- Overview
- Human Certification Analogs
- Tools Required
- Skill Levels & Benchmarks
- Certification Policy
Instructions
When this skill is active:
Parse the user brief.
- Identify the domain (e.g. Power BI, SAP B1, Azure AI, Odoo).
- Extract all human certification names and their levels.
- Note any reference repos / products / sample files.
Define the skills ladder.
- Map human certs into 3–5 levels:
- fundamentals → role_based → specialty → business → expert
- For each level:
- Write a concise description of capabilities.
- Choose the tools needed (abstract names).
- Design 1–3 concrete benchmarks that can be evaluated automatically.
- Benchmarks must have clear, measurable pass criteria (e.g. KPI parity within 1%, build succeeds, tests green, etc.).
Design tool contracts.
- Keep tools model-agnostic:
- Do NOT hard-code OpenAI / Gemini / Claude APIs.
- Use logical names (e.g.
ocr_gateway, sap_b1_api_client, pbix_reader).
- Focus on what the tool does, not how it's implemented.
Generate the three artifacts.
- Emit them in this order, each in its own fenced code block:
skills/<domain>.yaml
agents/<agent_slug>.yaml
docs/<agent_slug>-skills.md
- Make them ready to commit (no placeholders like
TODO or ...).
State assumptions & risks briefly.
- At the end, add a short "Assumptions & Risks" section (3–6 bullets) outside the code blocks:
- List any big assumptions (e.g. data source, repos, tools).
- Flag anything that absolutely needs human review (compliance, PII, prod access).
Examples
Example 1 – Power BI Architect
"Create an agent that is equivalent to PL-300 + DP-500 + Power Platform Solution Architect, using microsoft/powerbi-desktop-samples as the benchmark repo. Agent slug: powerbi_bi_architect."
You should:
- Define
domain: "cloud_ai_platforms.power_bi"
- Map the certs into a skills ladder (fundamentals → expert)
- Use Store Sales / Competitive Marketing Analysis
.pbix as benchmarks
- Emit YAML + docs as specified above
Example 2 – Azure AI Engineer
"Build an agent certified at the same level as Azure AI Engineer Associate, focused on RAG systems for finance dashboards."
You should:
- Create a
cloud_ai_platforms.azure_ai_rag skills domain
- Define tools like
embedding_indexer, rag_query_runner, azure_openai_client
- Add benchmarks: end-to-end RAG flow, latency, accuracy, hallucination checks
- Emit all three artifacts.
Example 3 – Retail Analytics (Scout)
"Certify an agent at the same level as a Retail Analytics Data Engineer for sari-sari / FMCG dashboards, using the Scout dashboard as the benchmark."
You should:
- Create
retail_analytics.scout domain
- Define tools:
supabase_query_runner, kpi_validator, chart_renderer
- Add benchmarks: schema validation, KPI accuracy, dashboard render time
- Emit YAML + docs
Guidelines
- Prefer clear, testable benchmarks over vague descriptions.
- Keep everything implementation-agnostic:
- No hard-wiring to a single model provider.
- Assume tools can be backed by Claude, OpenAI, Gemini, or local models.
- Favor production-readiness:
- Think like a vendor shipping a marketplace agent, not a demo.
- Include governance/security considerations where relevant (RLS, PII, secrets).
- Never include real secrets or API keys in outputs.
Related Skills
engine-spec-writer – Creates engine.yaml specs for IPAI Platform
supabase-schema-designer – Designs Supabase schemas with RLS
dashboard-builder – Builds Next.js dashboards from specs
1---2name: agent-certifier3description: Given a human certification or license (e.g. PL-300, SAP B1, Azure AI Engineer), create a production-ready agent skill profile and certification ladder, including skills.yaml entries, agent YAML, and skills documentation, using the anthropics/skills SKILL.md conventions.4---5
6# Agent Certifier
7
8This skill turns **human certifications** (e.g. PL-300, CPA, SAP B1, Azure AI)
9into **machine-certifiable agents** with clear skills, benchmarks, and a signed
10competency contract.
11
12Use this skill when the user gives:
13- A human cert or license name (e.g. "PL-300: Power BI Data Analyst")
14- Optionally one or more reference repos or products (e.g. `microsoft/powerbi-desktop-samples`)
15- A target agent name/slug (e.g. `powerbi-bi-architect`)
16
17Your job is to emit a **complete, market-ready bundle**:
18- A skills spec (YAML) with levels, benchmarks, and tools
19- An agent spec (YAML) wired to those skills
20- A human-readable `skills.md` for documentation
21- Optional certification JWT schema, compatible with an external CertificationAuthority
22
23---
24
25## When to Use This Skill
26
27Invoke this skill whenever the user wants to:
28
29- Translate a human certification (Azure, SAP, CPA, Azure AI, etc.) into an **agent certification ladder**
30- Define **skills + tools + benchmarks** for an agent in a reusable, model-agnostic way
31- Produce **ready-to-commit** files for a repo:
32 - `skills/<domain>.yaml`
33 - `agents/<agent_slug>.yaml`
34 - `docs/<agent_slug>-skills.md`
35
36The output should be designed so it can be:
37- Used by Claude Skills (this SKILL.md format)
38- Loaded by OpenSkills (`anthropics/skills` compatible)
39- Reused by other agents (Gemini, OpenAI, etc.) via the same YAML contracts
40
41---
42
43## Input Format
44
45Assume the user will give you (in natural language, not strict JSON):
46
47- Human cert(s) and level(s)
48 - e.g. "PL-300 + DP-500 + Power Platform Solution Architect Expert"
49- Domain / role
50 - e.g. "Power BI / Fabric BI Architect for retail dashboards"
51- Reference repos or artifacts (optional but common)
52 - e.g. GitHub URLs, product pages, sample `.pbix`, `.twb`, etc.
53- Target agent id/slug
54 - e.g. `powerbi_bi_architect`
55
56You must **infer missing pieces** safely and document assumptions.
57
58---
59
60## What To Produce
61
62Always produce **three main artifacts** (as copy-paste-ready blocks):
63
64### 1. `skills/<domain>.yaml`
65
66A YAML file that defines:
67
68- `version`, `domain`
69- `human_analogs`: list of human certs you are mirroring
70- `sources`: reference repos or artifacts (GitHub, sample files)
71- `tools`: logical tool contract names (e.g. `pbix_reader`, `dax_analyzer`)
72- `skills`:
73 - Each with `id`, `level` (fundamentals/role_based/specialty/business/expert etc.)
74 - `human_analog`, `description`
75 - `required_tools`, optional `prerequisites`
76 - `benchmarks`: each with `id`, `description`, `repo_source`, and `success_criteria` list
77
78Keep tool names **abstract** so they can be mapped to OpenAI/Gemini/Claude tool schemas later.
79
80### 2. `agents/<agent_slug>.yaml`
81
82An agent spec that:
83
84- References the domain and skill IDs from the skills YAML
85- Lists required tools by id
86- Defines `human_cert_analogs` (strings)
87- Defines `certification_policy`:
88 - Levels (`fundamentals`, `associate`, `expert`, etc.)
89 - `required_skills` for each level
90 - `min_benchmarks_passed` per level
91 - `issuance` block:
92 - `title_template`
93 - `validity_days`
94 - `conditions` (bullets)
95
96Include a `benchmarks_runtime` block describing:
97
98- `repo_sources` (e.g. `microsoft/powerbi-desktop-samples`)
99- `execution.runner` (e.g. `ci.pipeline.powerbi`)
100- `schedule` (e.g. `nightly`)
101
102### 3. `docs/<agent_slug>-skills.md`
103
104A markdown doc for humans that:
105
106- Explains which human certs this agent emulates
107- Lists each skill level with:
108 - Human analog
109 - Capabilities (bullets)
110 - Benchmark(s) and pass criteria
111- Explains the **certification policy**:
112 - What "Fundamentals / Associate / Expert Certified" means
113 - How the external `CertificationAuthority` JWT is issued & used
114
115Structure this as:
116
1171. Overview
1182. Human Certification Analogs
1193. Tools Required
1204. Skill Levels & Benchmarks
1215. Certification Policy
122
123---
124
125## Instructions
126
127When this skill is active:
128
1291. **Parse the user brief.**
130 - Identify the **domain** (e.g. Power BI, SAP B1, Azure AI, Odoo).
131 - Extract all human certification names and their levels.
132 - Note any reference repos / products / sample files.
133
1342. **Define the skills ladder.**
135 - Map human certs into 3–5 levels:
136 - fundamentals → role_based → specialty → business → expert
137 - For each level:
138 - Write a concise description of capabilities.
139 - Choose the tools needed (abstract names).
140 - Design 1–3 concrete benchmarks that can be evaluated automatically.
141 - Benchmarks must have **clear, measurable pass criteria** (e.g. KPI parity within 1%, build succeeds, tests green, etc.).
142
1433. **Design tool contracts.**
144 - Keep tools **model-agnostic**:
145 - Do NOT hard-code OpenAI / Gemini / Claude APIs.
146 - Use logical names (e.g. `ocr_gateway`, `sap_b1_api_client`, `pbix_reader`).
147 - Focus on what the tool does, not how it's implemented.
148
1494. **Generate the three artifacts.**
150 - Emit them in this order, each in its own fenced code block:
151 1. `skills/<domain>.yaml`
152 2. `agents/<agent_slug>.yaml`
153 3. `docs/<agent_slug>-skills.md`
154 - Make them **ready to commit** (no placeholders like `TODO` or `...`).
155
1565. **State assumptions & risks briefly.**
157 - At the end, add a short "Assumptions & Risks" section (3–6 bullets) outside the code blocks:
158 - List any big assumptions (e.g. data source, repos, tools).
159 - Flag anything that absolutely needs human review (compliance, PII, prod access).
160
161---
162
163## Examples
164
165### Example 1 – Power BI Architect
166
167> "Create an agent that is equivalent to PL-300 + DP-500 + Power Platform Solution Architect, using `microsoft/powerbi-desktop-samples` as the benchmark repo. Agent slug: `powerbi_bi_architect`."
168
169You should:
170- Define `domain: "cloud_ai_platforms.power_bi"`
171- Map the certs into a skills ladder (fundamentals → expert)
172- Use Store Sales / Competitive Marketing Analysis `.pbix` as benchmarks
173- Emit YAML + docs as specified above
174
175### Example 2 – Azure AI Engineer
176
177> "Build an agent certified at the same level as Azure AI Engineer Associate, focused on RAG systems for finance dashboards."
178
179You should:
180- Create a `cloud_ai_platforms.azure_ai_rag` skills domain
181- Define tools like `embedding_indexer`, `rag_query_runner`, `azure_openai_client`
182- Add benchmarks: end-to-end RAG flow, latency, accuracy, hallucination checks
183- Emit all three artifacts.
184
185### Example 3 – Retail Analytics (Scout)
186
187> "Certify an agent at the same level as a Retail Analytics Data Engineer for sari-sari / FMCG dashboards, using the Scout dashboard as the benchmark."
188
189You should:
190- Create `retail_analytics.scout` domain
191- Define tools: `supabase_query_runner`, `kpi_validator`, `chart_renderer`
192- Add benchmarks: schema validation, KPI accuracy, dashboard render time
193- Emit YAML + docs
194
195---
196
197## Guidelines
198
199- Prefer **clear, testable benchmarks** over vague descriptions.
200- Keep everything **implementation-agnostic**:
201 - No hard-wiring to a single model provider.
202 - Assume tools can be backed by Claude, OpenAI, Gemini, or local models.
203- Favor **production-readiness**:
204 - Think like a vendor shipping a marketplace agent, not a demo.
205 - Include governance/security considerations where relevant (RLS, PII, secrets).
206- Never include real secrets or API keys in outputs.
207
208---
209
210## Related Skills
211
212- `engine-spec-writer` – Creates engine.yaml specs for IPAI Platform
213- `supabase-schema-designer` – Designs Supabase schemas with RLS
214- `dashboard-builder` – Builds Next.js dashboards from specs