DEV Community

Vishwa Santhosh
Vishwa Santhosh

Posted on

From Tribal Knowledge to a Reusable Skill: SAP-on-AWS Pre-Sales with Claude

#ai #claude #aws #sap

Every infrastructure team eventually develops the same problem.

Someone asks:

How should we design HA and DR for this SAP workload?

Someone else asks:

What AWS instance family should we consider?

Then:

What assumptions should go into the RFP?

Then:

Can you rewrite this into a customer-facing proposal?

The answers usually exist.

The problem is that they exist in five different places:

Architect's experience
        +
Previous proposals
        +
Architecture diagrams
        +
Internal standards
        +
People's memory
Enter fullscreen mode Exit fullscreen mode

That is what people often call tribal knowledge.

Generative AI can help turn that knowledge into something reusable.

But a giant system prompt is not the solution.

A better approach is to package the workflow as a Claude Skill.

Anthropic's current Skills model lets you create a Skill bundle containing a SKILL.md plus supporting scripts and resources. Custom Skills can then be loaded into the Claude API through the container parameter.

This article shows how I would structure a Skill for SAP-on-AWS infrastructure pre-sales.

What problem are we actually solving?

Consider a typical SAP infrastructure RFP.

The customer provides:

SAP system
Database size
Expected users
Availability requirement
RTO
RPO
Growth rate
Operating system
AWS region
Security requirements
Migration timeline
Enter fullscreen mode Exit fullscreen mode

The infrastructure architect needs to turn that into decisions around:

Compute
Storage
Networking
High availability
Disaster recovery
Backup
Security
Monitoring
Operations
Migration
Support scope
Enter fullscreen mode Exit fullscreen mode

The repetitive part isn't necessarily the final architecture decision.

It is everything surrounding the decision.

For example:

Question
   ↓
Interpret requirements
   ↓
Identify assumptions
   ↓
Check architecture patterns
   ↓
Apply sizing rules
   ↓
Identify missing information
   ↓
Draft response
   ↓
Architect review
Enter fullscreen mode Exit fullscreen mode

That workflow is a good candidate for a Skill.

What is a Skill?

At a high level, think of a Skill as a reusable package of instructions, knowledge and supporting code.

A simple Skill might look like:

sap-aws-presales/
├── SKILL.md
├── references/
│   ├── ha-dr-patterns.md
│   ├── aws-sap-patterns.md
│   ├── rfp-style-guide.md
│   └── assumptions.md
└── scripts/
    └── sizing_sanity_check.py
Enter fullscreen mode Exit fullscreen mode

The important file is:

SKILL.md
Enter fullscreen mode Exit fullscreen mode

Anthropic's current API documentation requires SKILL.md at the top level of the Skill bundle, with YAML frontmatter containing name and description. Supporting resources can be included alongside it.

The Skill can then be uploaded to the workspace and loaded into a Messages API request.

Why not put everything into the system prompt?

Imagine putting all of this into one system prompt:

Here are 50 pages of SAP architecture guidance...

Here are our proposal-writing standards...

Here are our AWS assumptions...

Here are 30 previous RFP responses...
Enter fullscreen mode Exit fullscreen mode

That creates several problems.

Context bloat

The model receives information that may not be relevant to every request.

Maintenance

Updating one architecture standard means changing the prompt.

Reuse

Another workflow may need the same knowledge.

Separation of concerns

Instructions, reference knowledge and executable validation logic become mixed together.

Skills provide a cleaner boundary.

Progressive loading is the important idea

Anthropic's Skills architecture separates discovery from loading.

Claude initially sees Skill metadata such as the name and description. When a Skill is relevant, its files can be loaded into the execution environment. The documentation describes this as a metadata-discovery and file-loading process.

That makes this:

User request
     │
     ▼
Skill metadata
     │
 Is this relevant?
     │
    yes
     ▼
Load Skill
     │
     ├── SKILL.md
     ├── references
     └── scripts
Enter fullscreen mode Exit fullscreen mode

much more attractive than putting every piece of domain knowledge into every conversation.

Designing the Skill

I would start with four layers.

1. Workflow instructions

SKILL.md

This tells Claude:

  • when the Skill applies
  • what process to follow
  • what information to request
  • how to structure the response
  • when to use scripts
  • what assumptions must be disclosed

2. Architecture references

For example:

references/ha-dr-patterns.md
Enter fullscreen mode Exit fullscreen mode

This could contain approved patterns for:

  • HANA System Replication
  • Multi-AZ architecture
  • DR patterns
  • backup strategies
  • replication considerations

3. Proposal style 

references/rfp-style-guide.md
Enter fullscreen mode Exit fullscreen mode

This defines:

  • tone
  • terminology
  • proposal structure
  • assumption format
  • customer-facing language

4. Validation scripts 

scripts/sizing_sanity_check.py
Enter fullscreen mode Exit fullscreen mode

This handles deterministic checks that should not depend on model reasoning.

That distinction is important.

Use the model for:

reasoning
interpretation
drafting
comparison
Enter fullscreen mode Exit fullscreen mode

Use code for:

validation
arithmetic
threshold checks
format validation
Enter fullscreen mode Exit fullscreen mode

A first SKILL.md

Here is a minimal starting point:

---
name: sap-aws-presales
description: >
  Helps draft and review SAP S/4HANA on AWS infrastructure
  pre-sales responses, including architecture assumptions,
  HA/DR considerations, sizing inputs, migration scope,
  operational responsibilities, and RFP response structure.
---
Enter fullscreen mode Exit fullscreen mode

Then the body could say:

# SAP on AWS Pre-Sales

## When to use this Skill

Use this Skill when the user is:

- responding to an SAP infrastructure RFP
- preparing an SAP-on-AWS architecture proposal
- reviewing HA/DR requirements
- documenting infrastructure assumptions
- preparing migration or managed-services scope

Do not invent customer requirements.

If a required input is missing, explicitly identify it as
an assumption or ask for clarification.

## Workflow

1. Extract customer requirements.
2. Separate confirmed facts from assumptions.
3. Identify missing sizing inputs.
4. Review the relevant architecture references.
5. Run deterministic validation scripts where applicable.
6. Draft the response.
7. Identify risks and open questions.
8. Present the final recommendation with assumptions.

## Response structure

Use:

1. Requirement interpretation
2. Proposed architecture
3. Sizing considerations
4. HA/DR approach
5. Security and networking
6. Migration considerations
7. Managed-services scope
8. Assumptions
9. Open questions
Enter fullscreen mode Exit fullscreen mode

This is already much more useful than:

You are an SAP architect.
Give good answers.
Enter fullscreen mode Exit fullscreen mode

The description matters more than people think

The Skill description determines when it is relevant.

Compare these two.

Weak 

description: >
  Helps with SAP and AWS.
Enter fullscreen mode Exit fullscreen mode

That's too broad.

Better 

description: >
  Helps draft and review SAP S/4HANA on AWS infrastructure
  pre-sales responses, including HA/DR architecture,
  sizing assumptions, migration scope, networking,
  security, and managed-services responsibilities.
  Use when responding to SAP infrastructure RFPs,
  proposals, architecture questionnaires, or pre-sales
  design requests.
Enter fullscreen mode Exit fullscreen mode

The second description gives the system much more information about the Skill's intended domain.

I would test it with prompts such as:

Prepare an SAP on AWS HA/DR response for this RFP.
Enter fullscreen mode Exit fullscreen mode 
Review the infrastructure assumptions in this SAP proposal.
Enter fullscreen mode Exit fullscreen mode 
Draft the AWS architecture section for an SAP migration proposal.
Enter fullscreen mode Exit fullscreen mode

And unrelated prompts:

Write a Python web scraper.
Enter fullscreen mode Exit fullscreen mode 
Explain Kubernetes networking.
Enter fullscreen mode Exit fullscreen mode

The goal isn't to make the Skill trigger as often as possible.

The goal is to make it trigger when it should.

References should contain knowledge, not instructions

This is another design principle I find useful.

Instead of putting this into a reference document:

Always answer in exactly seven paragraphs...
Enter fullscreen mode Exit fullscreen mode

put reusable domain knowledge there.

For example:

references/ha-dr-patterns.md
Enter fullscreen mode Exit fullscreen mode

might contain:

# SAP HA/DR Patterns

## HANA System Replication

Describe:

- primary and secondary roles
- synchronization mode
- failover considerations
- application integration
- operational dependencies

## Availability Zones

Evaluate:

- AZ placement
- network latency
- storage architecture
- failure domains

## Disaster Recovery

Capture:

- RPO
- RTO
- replication mechanism
- recovery orchestration
- testing frequency
Enter fullscreen mode Exit fullscreen mode

The Skill instructions can tell Claude when to consult the document.

The document itself provides the knowledge.

Don't let the model do arithmetic that code can verify

Suppose an RFP contains:

Current database size: 8 TB
Annual growth: 20%
Retention: 3 years
Enter fullscreen mode Exit fullscreen mode

A model can calculate this.

But I would still prefer a deterministic sanity-check script.

For example:

def project_storage(current_tb, growth_rate, years):
    value = current_tb

    for _ in range(years):
        value *= 1 + growth_rate

    return value


def validate_storage(current_tb, growth_rate, years):
    if current_tb <= 0:
        raise ValueError("Current storage must be positive")

    if not 0 <= growth_rate <= 1:
        raise ValueError("Growth rate must be between 0 and 1")

    if years < 0:
        raise ValueError("Years cannot be negative")

    return project_storage(current_tb, growth_rate, years)
Enter fullscreen mode Exit fullscreen mode

The model can then reason about the result:

Current:
8 TB

Projected:
≈13.82 TB after three years at 20% annual growth.

Architecture implication:
Storage headroom should account for projected growth,
operational overhead and backup requirements.
Enter fullscreen mode Exit fullscreen mode

The code performs the arithmetic.

The model interprets it.

That's a much healthier division of labor.

Uploading the Skill

The Skills API provides a dedicated endpoint for creating a Skill.

A Python example is conceptually:

import anthropic
from anthropic.lib import files_from_dir

client = anthropic.Anthropic()

skill = client.skills.create(
    files=files_from_dir("sap-aws-presales"),
    display_name="SAP AWS Pre-Sales"
)

print(skill.id)
Enter fullscreen mode Exit fullscreen mode

The current API accepts the Skill files and requires the bundle to contain SKILL.md. Custom Skills also support versioning.

The resulting Skill has an identifier similar to:

skill_01AbCdEfGhIjKlMnOpQrStUv
Enter fullscreen mode Exit fullscreen mode

Keep that identifier in your application configuration rather than hard-coding it throughout your codebase.

Loading the Skill in a Claude request

The current Messages API uses the container parameter:

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,

    container={
        "skills": [
            {
                "type": "custom",
                "skill_id": "skill_01AbCdEfGhIjKlMnOpQrStUv",
                "version": "latest"
            }
        ]
    },

    tools=[
        {
            "type": "code_execution_20250825",
            "name": "code_execution"
        }
    ],

    messages=[
        {
            "role": "user",
            "content": """
            Review this SAP infrastructure requirement and
            prepare a first-pass AWS architecture response.
            """
        }
    ]
)
Enter fullscreen mode Exit fullscreen mode

Anthropic's current documentation shows custom Skills being loaded through container.skills with:

type
skill_id
version
Enter fullscreen mode Exit fullscreen mode

and notes that Skills use the code execution environment.

What about customer documents?

This is where the Files API becomes useful.

Instead of uploading the same RFP document repeatedly, you can upload it once and reference the resulting file_id in subsequent Messages API calls.

The Files API is designed around a create-once, use-many-times workflow.

Conceptually:

RFP PDF
   │
   ▼
Files API
   │
   ▼
file_123
   │
   ├──────────► Claude request 1
   │
   ├──────────► Claude request 2
   │
   └──────────► Claude request 3
Enter fullscreen mode Exit fullscreen mode

That is especially useful when the same source document is involved in multiple analysis steps.

One important security consideration from the current documentation: uploaded Files are workspace-scoped, not scoped to an individual end user or conversation. Applications should therefore treat file_id values as server-side references and not blindly accept user-supplied file IDs.

Version the Skill

This is important for enterprise workflows.

Suppose your original Skill is:

v1
Enter fullscreen mode Exit fullscreen mode

Then you update:

HA/DR reference
RFP wording
sizing logic
Enter fullscreen mode Exit fullscreen mode

Don't silently change the behavior of every existing workflow.

Create a new Skill version.

Anthropic's current Skills API supports versions, and custom Skill versions are complete snapshots rather than deltas.

That gives you:

sap-aws-presales
       │
       ├── version A
       │
       ├── version B
       │
       └── version C
Enter fullscreen mode Exit fullscreen mode

For a production workflow, I would pin a version during evaluation and only move to latest after validation.

Evaluating the Skill

This is where many AI projects become subjective.

Someone tries the Skill once and says:

Looks better.

That's not enough.

Create a fixed evaluation set.

For example:

Question 01 — HA architecture
Question 02 — DR architecture
Question 03 — HANA sizing
Question 04 — storage
Question 05 — networking
Question 06 — migration
Question 07 — backup
Question 08 — security
Question 09 — AMS scope
Question 10 — assumptions
Enter fullscreen mode Exit fullscreen mode

Run every question twice:

Baseline Claude
       vs
Claude + SAP Skill
Enter fullscreen mode Exit fullscreen mode

Then score:

Category Score
Technical correctness 0–5
Requirement coverage 0–5
Structure 0–5
Assumption clarity 0–5
Unsupported claims 0–5
Customer readiness 0–5

Don't invent the results.

Actually run the evaluation and publish the numbers.

That's much more credible than saying:

The Skill improved accuracy by 37%.

unless you can demonstrate where that number came from.

Hallucination testing is particularly important

SAP infrastructure is not a domain where plausible-sounding answers are good enough.

A response might sound perfectly reasonable while quietly inventing:

instance capabilities
storage characteristics
supported configurations
licensing assumptions
RTO/RPO guarantees
AWS service behavior
SAP support requirements
Enter fullscreen mode Exit fullscreen mode

So I would explicitly test for hallucinations.

Give the model incomplete information:

Database size: 4 TB
RPO: 15 minutes
RTO: 2 hours

No other information provided.
Enter fullscreen mode Exit fullscreen mode

Then check whether it:

Good 

The following information is still required:
- workload profile
- peak CPU
- memory requirement
- growth rate
- AWS region
...
Enter fullscreen mode Exit fullscreen mode

Bad 

The workload requires r6i.4xlarge.
Enter fullscreen mode Exit fullscreen mode

without enough evidence.

The Skill should encourage the first behavior.

The architect remains in the loop

This is probably the most important limitation.

A Skill does not turn Claude into an SAP solution architect.

It gives the model:

repeatable instructions
+
domain references
+
validation tools
+
workflow structure
Enter fullscreen mode Exit fullscreen mode

It does not remove uncertainty.

A sensible workflow is:

RFP
 │
 ▼
Claude + Skill
 │
 ▼
Draft architecture
 │
 ▼
Validation
 │
 ▼
Human architect
 │
 ▼
Approved proposal
 │
 ▼
Customer
Enter fullscreen mode Exit fullscreen mode

The human should remain responsible for decisions involving:

  • production sizing
  • SAP supportability
  • licensing
  • security
  • availability guarantees
  • DR commitments
  • contractual scope

The Skill is an accelerator.

Not an authority.

What I would put in the repository

A practical starting repository could look like:

sap-aws-presales/
│
├── SKILL.md
│
├── references/
│   ├── aws-sap-patterns.md
│   ├── ha-dr-patterns.md
│   ├── networking-patterns.md
│   ├── migration-patterns.md
│   ├── managed-services-scope.md
│   ├── assumptions.md
│   └── rfp-style-guide.md
│
└── scripts/
    ├── sizing_sanity_check.py
    ├── storage_projection.py
    └── validate_rpo_rto.py
Enter fullscreen mode Exit fullscreen mode

This separation is intentional.

SKILL.md
    ↓
How to think/work

references/
    ↓
What to know

scripts/
    ↓
What to calculate/validate
Enter fullscreen mode Exit fullscreen mode

That's a much cleaner architecture than one enormous prompt.

The same pattern works outside SAP

SAP is just a good example because infrastructure pre-sales contains a lot of structured knowledge.

The same design could be used for:

Azure Landing Zone proposals
AWS migration assessments
Security architecture reviews
Network design questionnaires
DevOps implementation proposals
Cloud cost assessments
Database migration planning
Managed-services RFPs
Enter fullscreen mode Exit fullscreen mode

The general pattern is:

Domain expertise
      +
Reusable workflow
      +
Reference material
      +
Deterministic validation
      =
Reusable Skill
Enter fullscreen mode Exit fullscreen mode

That is the real opportunity.

A template you can reuse

For another domain, start with:

my-domain-skill/
│
├── SKILL.md
│
├── references/
│   ├── domain-architecture.md
│   ├── standards.md
│   └── response-style.md
│
└── scripts/
    └── validation.py
Enter fullscreen mode Exit fullscreen mode

And make SKILL.md answer five questions:

1. When should this Skill activate?

2. What process should Claude follow?

3. Which references should it consult?

4. Which calculations should be delegated to code?

5. What should the final response look like?
Enter fullscreen mode Exit fullscreen mode

If those five questions are answered clearly, you already have the foundation of a useful domain Skill.

From tribal knowledge to an engineering asset

The most valuable part of this approach isn't actually Claude.

It's the process of extracting knowledge that previously lived inside people's heads.

Instead of:

"Ask the architect. They know how we usually do this."
Enter fullscreen mode Exit fullscreen mode

you can begin creating:

Architecture pattern
       ↓
Documented assumption
       ↓
Reusable reference
       ↓
Validation script
       ↓
Skill
       ↓
Repeatable workflow
Enter fullscreen mode Exit fullscreen mode

That makes the knowledge easier to review, update and reuse.

And unlike a giant prompt, the pieces can evolve independently.

Final takeaway

I wouldn't use a Claude Skill to make an AI pretend to be an architect.

I'd use it to make an experienced architect's workflow repeatable.

The distinction matters.

A good SAP-on-AWS Skill should help Claude:

  • identify missing requirements
  • distinguish facts from assumptions
  • apply documented architecture patterns
  • perform deterministic sanity checks
  • produce consistent RFP responses
  • surface risks and open questions
  • prepare a strong first draft

Then an architect reviews the result.

That's a much more realistic goal for enterprise AI.

The long-term value isn't:

"Claude knows SAP now."

It's:

"Our SAP infrastructure knowledge has been turned into a reusable, testable and versioned workflow."

And that idea is useful far beyond SAP.

Top comments (0)