Agent Usage Guide

How to choose a skill

1. Identify the work situation, not the topic. "Data quality problem" is a topic. "Sales orders blocked by missing tax data" is a work situation.
2. Match the situation to a skill group using the Skill Hub index. Data problems map to DAMA/Data skills. Interface problems map to Integration Architecture skills. Stakeholder confusion maps to Business Analysis skills.
3. Open the skill page and read "When to use this skill" and "Real work situations." If the situation matches, use the skill. If not, look at "Related skills."
4. If no skill matches exactly, combine the closest skill with general consulting judgment. Do not default to generic explanation.

How to combine multiple skills

Real enterprise problems span multiple domains. A single incident may require:

• Incident Triage to classify and contain.
• Root Cause Analysis to find the cause.
• Stakeholder Analysis to identify who needs to approve the fix.
• Change Impact Analysis to assess what else breaks if you change the fix.
• Operational Knowledge Capture to record the pattern for next time.

When combining skills:

1. Run each skill in sequence. Do not merge steps from different skills into a single unordered list.
2. Pass the output of one skill as input to the next. For example, the defect classification from Incident Triage feeds into the root cause hypothesis in Root Cause Analysis.
3. Label which skill produced which part of the output.
4. Flag gaps where a skill does not cover the situation.

How to ask for missing context

Agents must not guess. If the user provides an incomplete situation, ask structured questions:

• What system or module is involved? (SAP module, middleware, database, API)
• What is the business process? (order-to-cash, procure-to-pay, record-to-report)
• What is the symptom? (error message, blocked transaction, wrong data, missing data)
• What is the scale? (one record, one customer, one region, all records)
• What has already been tried? (reprocessing, manual correction, config change)
• Who owns the affected data or process?
• Is there a deadline or regulatory constraint?

Do not proceed with advice until you have enough context to choose a skill and follow its working method.

How to separate facts, assumptions, risks, decisions, and open questions

Every agent output must use these labels explicitly:

Never present an assumption as a fact. Never present a risk as a certainty. Never skip open questions.

How to produce artifacts instead of generic explanations

An artifact is a structured, reusable output that a human can act on. Examples:

• A Root Cause Analysis Note with defect, cause, impact, correction, and prevention.
• A Stakeholder Interview Brief with questions, answers, assumptions, and follow-ups.
• An Architecture Decision Record with context, options, decision, and consequences.
• A Data Quality Rule with field, condition, owner, and enforcement mechanism.

Rules for artifact production:

1. Use the template from the skill page or the Artifact Templates page.
2. Fill every field. If a field is unknown, label it "Unknown — needs input from [owner]."
3. Include dates, owners, and next actions.
4. Format the artifact so it can be pasted into a ticket, document, or wiki without rewriting.
5. Do not summarize the artifact in prose afterward. The artifact is the output.

How to link Skill Hub with Atlas diagnostics

Atlas contains SAP-specific diagnostics. Skill Hub contains cross-domain working skills. Use them together:

• When a user describes a SAP symptom, first consult Atlas diagnostics to understand the technical cause.
• Then use Skill Hub skills to structure the response: stakeholder communication, change impact, knowledge capture, decision record.
• Link Atlas pages in the "Related Atlas pages" section of the skill output.
• Do not duplicate Atlas diagnostic content in Skill Hub skill output.

How to avoid fake certainty

Agents must not sound confident about things they cannot verify:

• Use "appears to be" or "based on the information provided" when inferring from limited data.
• State confidence levels: high, medium, low, unknown.
• Flag when a conclusion depends on an unverified assumption.
• Do not invent system behavior. If you do not know how a specific SAP transaction works in this version, say so.
• Do not invent client names, project details, or internal paths.

How to avoid generic framework summaries

Never output text like:

• "Data governance is important because..."
• "Event-driven architecture provides loose coupling..."
• "Requirements elicitation is the process of..."

Instead, output:

• "Here is the ownership matrix for the 6 data domains in scope. Gaps are flagged in red."
• "Here are the 4 events this process should produce, with owners, schemas, and failure modes."
• "Here are the 7 requirements extracted from the stakeholder interview, with assumptions and risks."

How to create useful project outputs

When a user asks for help with a project, deliver:

1. Situation summary — what is known, what is assumed, what is missing.
2. Skill selection — which Skill Hub skills apply and why.
3. Working method execution — follow the skill steps, produce artifacts.
4. Deliverables — the actual artifacts, not a description of them.
5. Quality checklist — did we cover all required fields? Are there gaps?
6. Next actions — who does what by when, with owners.

Agent instruction summary

• Choose skills based on work situations, not topics.
• Ask for missing context before giving advice.
• Separate facts, assumptions, risks, decisions, and open questions.
• Produce artifacts using templates. Do not stop at explanation.
• Link to Atlas diagnostics when the situation is SAP-specific.
• Avoid fake certainty and generic framework language.
• Label confidence levels and flag unverified assumptions.
• End with deliverables, quality check, and next actions.