Skill Hub — Foundation

Skill Page Template

The standard structure for every Skill Hub page. All skill pages must follow this template. Reviewers use this to judge completeness.

Template structure

Every skill page must include the following sections in this order:

1. What this skill is for

Explain the practical job-to-be-done. One to three sentences. Avoid generic definitions. Focus on what the user will be able to do after applying this skill.

Good: "This skill helps identify why bad data exists, where it entered the lifecycle, what business process it affects, who owns the correction, and what prevention control is required."

Bad: "Data quality is important because organizations need accurate data."

2. When to use this skill

List real project situations where this skill is needed. Use bullet points. Each bullet should describe a recognizable work moment.

Good: "Use it when sales orders are blocked by incomplete customer data."

Bad: "Use it when data quality is a concern."

3. Real work situations

Use concrete examples from enterprise, SAP, data, integration, or operations work. Two to four examples. Include enough detail that a reader recognizes their own situation.

Each example should include: the symptom, the system or process, the stakeholder, and the business consequence.

4. Inputs required

List documents, systems, logs, data samples, stakeholders, decisions, diagrams, tickets, or examples needed before the skill can be applied. Be specific. If an input is optional, label it optional.

5. Questions to ask

Provide strong diagnostic questions. Avoid generic consultant questions like "What are your pain points?" Instead, ask specific questions that reveal structure, ownership, and causality.

Good: "Which field is missing, and which business process fails when it is missing?"

Bad: "What data quality issues are you experiencing?"

6. Working method

Step-by-step workflow. Numbered list. Each step should be actionable. Make it usable tomorrow. A person with moderate domain knowledge should be able to follow the steps and produce output.

Include substeps where needed. Label decision points clearly.

7. Decision rules

Include rules in the form: "If X, then Y." Or: "If condition A, do B. If condition C, do D instead."

Decision rules are the core of a skill. They turn judgment into repeatable logic.

Examples:

  • If ownership is unclear, produce an ownership matrix before proposing automation.
  • If data defects recur, fix upstream validation, not only existing records.
  • If requirements are vague, separate need, assumption, rule, constraint, and acceptance criterion.
  • If only a few records are affected and the rule is clear, correct records through the governed process.
  • If many records are affected, prepare mass correction with validation and approval.

8. Deliverables

List artifacts the skill should produce. Name each artifact. Describe what it contains. Link to templates where available.

9. Templates

Include at least one compact reusable Markdown template directly in the page. The template should be copy-paste ready. Fill-in-the-blank format. Include example values in comments where helpful.

Templates may also reference the Artifact Templates page for longer formats.

10. Quality checklist

Explain how to judge whether the output is good. Use a checklist format. Each item should be verifiable yes/no.

Good: "Every defect has a classified root cause type."

Bad: "The analysis is thorough."

11. Common mistakes

Explain practical mistakes people and agents make when using this skill. Be specific. Include the mistake and the consequence.

Good: "Mistake: treating the symptom as the root cause. Consequence: the defect recurs because the upstream validation was never fixed."

Bad: "Not following the process."

12. Agent instructions

This section is mandatory. It must tell an AI agent exactly how to use the skill.

Include:

  • What context the agent must gather before applying the skill.
  • How to separate facts from assumptions.
  • What artifacts to produce.
  • What to avoid (generic language, fake certainty, skipping steps).
  • How to handle missing information.
  • How to link to Atlas diagnostics if applicable.

13. Related skills

Use valid local links only. Link to other Skill Hub pages that are commonly used together. Two to five links. Do not link every page to everything.

14. Related Atlas pages

Link to existing Atlas pages where useful. Do not invent links. Do not create broken links. Do not over-link. Two to five links. Only link when the Atlas page adds diagnostic or conceptual depth.

15. Verification status and limitations

Be honest. State that this is a public working interpretation, not official framework documentation. Note any known gaps, version dependencies, or areas where the skill is incomplete.

Front matter conventions

All skill pages use this front matter pattern:

---
layout: default
title: "<Skill Name>"
description: "<One-line practical description>"
permalink: /skill-hub/<group>/<slug>/
last_modified_at: YYYY-MM-DD
status: reviewed
verified: true
---

Quality gate

A skill page is acceptable only if it helps a real person or AI agent perform a real task better. A page is not acceptable if it only explains a concept.

Before marking a skill page complete, verify:

  • Does it help someone do work?
  • Does it include concrete situations?
  • Does it include specific questions?
  • Does it include a workflow?
  • Does it include decision rules?
  • Does it include a template?
  • Does it include agent instructions?
  • Does it avoid generic textbook language?
  • Does it avoid fake official framework claims?
  • Are all links valid?