Axodus Backend Architecture

Design backend APIs, services, persistence, and observability with security.

Security Scan

This is an instruction-only skill that provides backend architecture design guidance; its files, requirements, and instructions are consistent with that purpose and it does not request credentials or install software.

Purpose & Capability

The skill's stated purpose (design backend APIs, services, persistence, observability, and security) matches the SKILL.md and backend-architecture.md content. Minor provenance inconsistencies exist: the registry entry you provided calls it "Axodus Backend Architecture" and lists a different owner ID, while the packaged files identify the skill as 'backend-architecture' authored by 'RedHat Dev' and include _meta.json with ownerId 'redhat-agent-001'. This is likely a metadata mismatch rather than functional incoherence, but you should verify the publisher before trusting it.

Instruction Scope

The SKILL.md contains purely design instructions and templates (API surface, security model, persistence, observability, validation). It does not instruct the agent to read local files, access environment variables, call arbitrary endpoints, or exfiltrate data.

Install Mechanism

There is no install spec and no code files—this is instruction-only. Nothing is downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. The instructions do not reference any secrets or external credentials.

Persistence & Privilege

The skill is not flagged 'always: true' and does not request persistent system presence or modify other skills. Autonomous invocation is allowed by platform default but there is no sign this skill needs elevated privileges.

Assessment

This skill is an instruction-only architecture helper and appears coherent and low-risk. Before installing or using it: 1) verify the publisher/source (there is a mismatch between the registry owner ID and the SKILL.md/_meta author fields), 2) avoid pasting any real credentials, secrets, or internal configuration into prompts when interacting with the skill, and 3) if you need an auditable provenance, ask the publisher for a homepage or canonical repo and confirm licensing. If those checks are satisfactory, the skill's scope and requirements look appropriate for its stated purpose.

SKILL: backend-architecture

Purpose

Design backend systems with clear boundaries: API contracts, services, persistence, observability, and security controls.

When to Use

• Building a new backend or major subsystem.
• Introducing a new API surface (REST/WebSocket).
• You need a concrete module/service layout and DB model.

Inputs

• requirements (required, string|object): endpoints, behaviors, SLAs, compliance needs.
• constraints (optional, string[]): security, latency, cost, runtime, stack limits.
• data_entities (optional, string[]): core domain objects.
• integration_points (optional, string[]): external services/APIs.

Steps

1. Define API surface:
   • endpoints/events
   • request/response schema
   • error model (codes/messages)
2. Define security model:
   • authentication method
   • authorization rules
   • rate limits and abuse controls
3. Define service/module boundaries:
   • controllers/handlers
   • domain services
   • repositories/adapters
4. Define persistence:
   • schema/tables/collections
   • migrations
   • idempotency model (if needed)
5. Define observability:
   • structured logs
   • request ids
   • audit trail for sensitive actions
6. Define validation plan (tests + CI hooks).

Validation

• Every endpoint has authz rules or an explicit “public” justification.
• Inputs are validated; outputs are consistent with schema.
• Failure modes are explicit (timeouts, retries, fallbacks).

Output

Architecture spec (example schema):

api:
  - method: POST
    path: /v1/...
    auth: required
services: ["..."]
data_model: ["..."]
observability: ["logs", "metrics (optional)"]
validation: ["unit tests", "integration tests"]

Safety Rules

• Do not design systems that require storing secrets in source control.
• Avoid introducing new dependencies unless justified.
• Default to safe failure modes (no partial writes without idempotency).

Example

Requirement: “Webhook ingestion with replay protection.” Output: includes idempotency key storage, signature verification, and audit logging.