atlasclaw-providers AGENTS.md

AGENTS.md - AtlasClaw Providers Guidelines

Repository Overview

This repository owns concrete integrations. If a document or implementation depends on a target system's auth model, fields, workflow semantics, webhook payloads, or provider-specific UI text, it belongs here rather than in atlasclaw core.

This repository is organized into a few top-level modules:

• providers/: concrete provider packages such as SmartCMP-Provider and jira
• skills/: shared reusable skills, templates, and helper tooling that are not tied to a single provider
• docs/: repository-level architecture notes, design plans, and supporting assets
• .agentdocs/: optional AI-only working notes and memory files used during execution

Most provider work happens under a provider package with a layout similar to:

providers/<provider-name>/
|-- PROVIDER.md
|-- README.md
|-- skills/
|   `-- <skill-name>/
|       |-- SKILL.md
|       |-- scripts/
|       |-- references/
|       `-- test/              # optional, skill-scoped tests
|-- docs/                      # optional, provider-specific plans or design notes
`-- test/                      # optional, provider-level tests

Directory responsibilities:

• PROVIDER.md: provider contract, configuration shape, and authentication model
• README.md: human-readable provider overview
• skills/<skill-name>/SKILL.md: skill metadata, usage guidance, and tool entrypoints
• skills/<skill-name>/scripts/: executable integration logic and helpers
• skills/<skill-name>/references/: API mappings, workflows, and examples kept close to the skill
• docs/ and test/: provider-specific design notes and verification coverage

Core/runtime contracts, loading behavior, and provider-agnostic rules stay in atlasclaw. Concrete provider behavior and examples stay here.

Code Style Guidelines

• Comments must be in English
• Prefer wide lines suitable for large screens; avoid over-wrapping
• Do not split simple logic into many tiny methods unless reuse justifies it
• Avoid breaking short code across many lines
• Keep validation pragmatic: validate external input, persistence integrity, and core trading invariants, but do not add layers of redundant defensive checks that do not improve correctness