identify-deployment-arch

Analyze the current project to identify deployment architecture — where code runs, what services it depends on, where state lives. Use at the start of a backup-planning engagement, before deciding what to protect.

Ir para a instalação

Repositório: danielrosehill/Claude-Backup-Planner-Plugin
Última atividade na origem: 20 de abril de 2026 às 14:32
Idioma detectado do SKILL.md: inglês
Estrelas: 0
Forks: 0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/danielrosehill/Claude-Backup-Planner-Plugin --skill identify-deployment-arch

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

save-backup-infra

Capture the user's available backup infrastructure (S3/B2/R2 buckets, rsync.net, NAS, external drives, existing restic repos, etc.) to persistent memory so it can be reused across projects without re-asking. Use when the user mentions backup destinations, or before evaluating backup options.

2026-04-27

document-backup-strategy

Write the authoritative backup strategy document for the project — the approved option from evaluation, spelled out with schedules, retention, responsibilities, and monitoring. Use after the user has approved an option.

2026-04-20

evaluate-backup-options

Recommend the best-fit backup strategy for the project given its data inventory and the user's available infrastructure. Produces a ranked options brief with trade-offs. Use after architecture and inventory are mapped.

2026-04-20

Ver todas deste repositório

Identify Deployment Architecture

Before a sensible backup strategy can be designed, you must understand what the system actually looks like in production. This skill produces a short architecture map that the later skills consume.

Steps

Inventory the runtime surface. Read README.md, docker-compose.yml, Dockerfile, *.tf, k8s/, fly.toml, vercel.json, render.yaml, Procfile, package.json (scripts + deps), pyproject.toml, requirements.txt, wrangler.toml, serverless.yml, and any CI config. Note the deployment target(s): VPS, container host, serverless, PaaS, on-prem, hybrid.

Identify persistent state. For each service, classify storage:

Database (Postgres, MySQL, SQLite, Mongo, Redis-with-persistence, etc.) — note version and whether managed or self-hosted.
Object storage (S3, R2, B2, GCS, Azure Blob).
Block/file storage (volumes, NFS, bind mounts).
External SaaS (auth providers, CMS, analytics) that hold canonical data.

Identify configuration and secrets. .env files, secret managers, CI/CD secret stores, TLS certs, SSH keys bound to the deployment.

Map data flow. Briefly note: where user-facing writes land, what's derived vs canonical, what's ephemeral (caches, queues, build artefacts).

Ask the user to confirm anything ambiguous — especially whether the deployment is single-region / multi-region, and whether any storage is already replicated by the provider.

Output

Write findings to backup-plan/01-architecture.md in the project. Use this structure:

# Deployment Architecture ## Runtime - <service>: <where it runs>, <how it's deployed> ## Persistent State - <store>: <type>, <location>, <provider-level durability> ## Configuration & Secrets - <source> ## Data Flow Notes - <canonical vs derived, ephemeral exclusions>

Keep it tight — one page. This document is input to identify-data-to-protect.