agentleFS
Sign inStart free
ChariereFiedlerChariereFiedler/ronce-racine/skills/audit-architecture/SKILL.md

audit-architecture

Skill9 starsChanged 24 days agoMITView on GitHub

Audit Architecture, Scalability & Availability. Use when auditing ADRs, interface contracts, coupling, scalability, resilience patterns, SLA/RPO/RTO, high availability, or incident management. Triggers on "audit architecture", "audit archi", "audit scalabilité", "audit scalability", "audit disponibilité", "audit availability", "audit résilience", "audit resilience", "audit incidents".

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    ME when: audit targeted at this domain only

    line 16
  2. Distinctive:

    audit-industrialisation: instead when: a global multi-domain audit - it orchestrates every audit (ME included) and produces a consolidated …

    line 17
  3. Very specific:

    Read the matching reference/<section>.md file.

    line 51
  4. Distinctive:

    Backend / API: - every question applies with the standard grid.

    line 73

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Audit Architecture, Scalability & Availability

The project variant (<repo>/.claude/skills/) wins if it exists: it tools this generic protocol with scripts, datasets and CI gates specific to the repo.

When ME and not audit-industrialisation

  • ME when: audit targeted at this domain only
  • audit-industrialisation instead when: a global multi-domain audit - it orchestrates every audit (ME included) and produces a consolidated report

For a full project audit, use audit-industrialisation rather than invoking each skill separately.

Overview

Audit a project's architectural maturity: documented decisions, API stability, coupling, resilience patterns, scalability, availability, operational support and incident management. Produces a maturity score (0-4) per question.

74 questions split across 7 sections:

SectionDomainQuestions
ARArchitecture, Specification & Deployment11
SCTechnical scalability7
PAFault and interruption tolerance15
RERecovery after a problem13
DIAvailability & SLA11
SUSupport & Operability8
IMIncident management9

The detailed grids (statements, criticality, conditions, verification commands, levels 0-4) live in reference/ - one file per section.

Score calculation

  • Each scored question is assigned a level from 0 to 4.
  • Questions marked N/A are excluded from the calculation.
  • Global score = sum of levels / number of scored questions (excluding N/A).
  • Formula: score = Σ(levels) / count(scored questions)
  • Example: 50 questions scored out of 74, sum = 120 → score = 120/50 = 2.4/4

Audit protocol

  1. Detect the project type: backend/API, frontend SPA/PWA, fullstack, library/SDK. Adjust the N/A questions per type (see Variants below).
  2. For each section (AR, SC, PA, RE, DI, SU, IM in this order):
    • Read the matching reference/<section>.md file.
    • For each question: run the listed verification commands.
    • Assign a level 0-4 (or N/A) in light of the grids, with justification and confidence level.
    • Handle the conditional questions (e.g. AR-01a is only evaluated if AR-01 >= 2): if the condition is not met, mark N/A.
  3. Mark N/A the questions that do not apply to the project type.
  4. Compute the global score excluding N/A.
  5. Produce the report via audit-report.

Variants by project type

Frontend SPA/PWA - adapt:

  • SC-01 to SC-07: PWA offline, service worker, bundle size, CDN, lazy loading. No HPA/K8s.
  • PA-01: error boundaries (React/Vue), offline fallback, service worker cache, retry on API calls.
  • PA-06: service worker lifecycle, graceful update.
  • PA-12: offline fallback, stale-while-revalidate, IndexedDB cache.
  • PA-18 to PA-21: usually N/A (no frontend DB).
  • RE-01: retry safety of client-side API calls.
  • DI-01 to DI-09: CDN availability, service worker health, connectivity detection.
  • IM-01 to IM-09: error tracking (Sentry), performance monitoring (Web Vitals).

Library / SDK - usually N/A: SC-01 to SC-07, PA-05 to PA-09, PA-12, PA-18 to PA-21, RE-05 to RE-08a, DI-01 to DI-09, SU-01 to SU-03, IM-01 to IM-09. Focus on AR-01 (ADR), AR-02 (tech debt), AR-07 (backward compatibility), AR-08 (deprecation), AR-09 (semver), PA-01/PA-03 (retry guidance in the docs).

Backend / API - every question applies with the standard grid.

Grids by section

SectionFileDescriptionQuestions
ARreference/ar-architecture.mdADR, technical debt, multi-level docs, progressive deployment, feature flags, rollback, compatibility, deprecation, semver11
SCreference/sc-scalabilite.mdCapacity planning, load testing, auto-scaling, queues/brokers, QoS, partitioning, specialized workers7
PAreference/pa-pannes.mdAPI error handling, retry, circuit breaker, pause, safe shutdown, recovery, isolation, degraded mode, API watch, DB backup/migration15
REreference/re-recuperation.mdIdempotency, idempotency key, replay, data rollback, RTO/RPO, restart/recovery tests, recovery validation, reconciliation13
DIreference/di-disponibilite.mdRPO/RTO, target availability, SLOs/error budget, SLI dashboards, alerts, SLA export, status page, synthetic monitoring11
SUreference/su-support.mdRunbooks, L1/L2/L3 escalation, RACI, install scripts, setup time, onboarding8
IMreference/im-incidents.mdP1-P4 classification, on-call, MTTD, MTTR, communication, incident commander, blameless post-mortem, metrics, automation9

Exit condition

  • All 7 sections have been covered (each reference/<section>.md read).
  • Every question is scored 0-4 or marked N/A (conditional questions included).
  • Every level rests on evidence from running the verification commands.
  • Global score computed excluding N/A per the formula.
  • Report produced via audit-report (summary, per-question detail, strengths/weaknesses, MUST/SHOULD/COULD recommendations, non-auditable items).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free