Click to enlarge Provider runtime overview
The provider keeps auth, skills, scripts, and downstream execution inside one explicit boundary.
Integrations start with providers.
Providers are AtlasClaw's integration boundary. Each provider packages the target-system contract, one or more skills, implementation scripts, and the context needed to keep the integration understandable.
Runtime architecture
See how a provider carries runtime execution.
This diagram shows how a provider carries auth, skills, scripts, and downstream system execution.
Click to enlarge Provider runtime overview
Close preview The provider keeps auth, skills, scripts, and downstream execution inside one explicit boundary.
Package structure
Provider package shape.
providers/<provider-name>/
├── PROVIDER.md
├── README.md
└── skills/
├── <skill-a>/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── <skill-b>/ Key rules
Keep boundaries explicit and scripts narrow.
- The provider owns how AtlasClaw identity becomes provider-native target-system auth.
- Skills stay human-readable while still binding to concrete entrypoints.
- Provider-qualified naming avoids collisions across integrations.
- Scripts should stay narrow, predictable, and safe with secrets and error mapping.
Naming
Provider-qualified skills.
Provider prefixes prevent skill collisions across systems.
{
"providers_root": "../atlasclaw-providers/providers",
"webhook": {
"systems": [
{
"allowed_skills": ["jira:jira-issue"]
}
]
}
} Examples