npx claudepluginhub sethgammon/citadel --plugin citadelThis skill uses the workspace's default tool permissions.
- Before adding a new database, cache, or queue to a project
Performs 12-Factor App compliance analysis on any codebase. Use when evaluating application architecture, auditing SaaS applications, or reviewing cloud-native applications.
Runs 7-phase analysis of TypeScript codebases using typegraph-mcp tools like ts_dependency_tree and ts_import_cycles, producing architectural report for onboarding or overviews.
Audits git repositories for engineering practices with SARIF evidence, 4-level confidence ratings, and OpenSSF scoring to evaluate health and code quality.
Share bugs, ideas, or general feedback.
Do not use when:
/architect)/research)Scan the project for infrastructure configuration files. Check each category:
Container orchestration:
docker-compose.yml, docker-compose.*.ymlDockerfile, *.dockerfilek8s/, kubernetes/, helm/, charts/Environment and secrets:
.env, .env.*, .env.example, .env.local*.env files in config directoriesDatabase and ORM:
prisma/schema.prismadrizzle.config.ts, drizzle/ormconfig.*, data-source.ts.sequelizerc, config/database.*knexfile.*alembic.ini, alembic/settings.py (DATABASES section)config/database.ymlpgx, gorm, sqlx in go.modMessage queues and event streaming:
ioredis, redis in package.json/requirements.txt/go.modamqplib, pika, amqp importskafkajs, confluent-kafka, sarama importsnats, nats.go imports@aws-sdk/client-sqs, boto3 sqs referencesCache:
memcached, pylibmc importsSearch:
@elastic/elasticsearch, elasticsearch-pyObject storage:
@aws-sdk/client-s3, boto3 s3 referencesExternal APIs:
NEXT_PUBLIC_* or VITE_* env vars pointing to external servicesCI/CD:
.github/workflows/, .gitlab-ci.yml, Jenkinsfile, bitbucket-pipelines.ymlFor each discovered item, record:
For each discovered system, trace how the application connects:
new Client(), createPool())Build a connection graph:
App --> [pool: 10] --> PostgreSQL (primary store)
App --> [ioredis] --> Redis (cache + pub/sub)
App --> [SDK] --> Stripe (payments)
Based on what's connected and how it's used, identify:
Access patterns:
Missing layers (flag only when evidence supports the need):
| Signal | Likely Missing | Evidence Required |
|---|---|---|
| Repeated identical DB queries in hot paths | Cache layer (Redis/Memcached) | Same query in 3+ request handlers |
setTimeout/setInterval for deferred work | Job queue (Bull/BullMQ/Celery) | Processing that doesn't need to block the response |
Full-text search via LIKE '%term%' | Search engine (Elasticsearch/Meilisearch) | Text search on >10K rows |
| Large file uploads stored in DB or local disk | Object storage (S3/MinIO) | Binary columns or fs.writeFile for user content |
| Analytics queries on production tables | Analytics DB (Snowflake/BigQuery/ClickHouse) | Aggregation queries mixed with OLTP |
| Multiple services sharing one DB | Event bus or API gateway | 2+ repos writing to same schema |
| No connection pooling | Connection pooler (PgBouncer) | Direct connections in serverless/high-concurrency |
Do not flag something as missing unless the evidence is in the code.
Output the infrastructure manifest to .planning/infra-manifest.md:
# Infrastructure Manifest
> Generated: {ISO date}
> Project: {project name from package.json or repo name}
## Current Systems
### {System Name} -- {Role}
- **Type**: {database|cache|queue|search|storage|auth|payments|...}
- **Product**: {PostgreSQL 15|Redis 7|Stripe SDK|...}
- **Config**: `{file path}`
- **Connection**: {method -- pooled, direct, SDK, ORM}
- **Used by**: {modules/services that import the client}
(repeat for each system)
## Connection Graph
{ASCII diagram of connections -- use /ascii-diagram conventions}
## Access Patterns
- {Pattern 1}: {evidence}
- {Pattern 2}: {evidence}
## Opportunities
### {Opportunity Title}
- **Signal**: {what in the code suggests this}
- **System**: {what would address it -- e.g., "Redis as cache layer"}
- **Impact**: {what improves -- latency, scalability, separation of concerns}
- **Effort**: low | medium | high
(repeat for each opportunity)
## Multi-Repo Considerations
{If the project references other repos, APIs, or shared databases, note them here.
This section feeds directly into /workspace if the user wants to act on opportunities
that span repos.}
Present a summary to the user:
/workspace)src/, lib/, config/ for
connection patterns. Note the absence of externalized config as a finding..planning/ does not exist: Create it before writing the manifest.Disclosure: "Auditing infrastructure configuration. No files modified."
Reversibility: green — read-only audit; only writes .planning/infra-manifest.md; undo with rm .planning/infra-manifest.md.
Trust gates:
.planning/infra-manifest.md---HANDOFF---
- Scanned {N} config files, found {M} external systems
- Key systems: {list top 3-4}
- Top opportunity: {highest-signal opportunity}
- Multi-repo scope: {yes/no -- if yes, suggest /workspace}
- Reversibility: green — delete .planning/infra-manifest.md to undo
---