원클릭으로
validate-config
// Validate config hygiene — docker-compose env vars vs .env.example vs code references vs architecture docs. Flags missing, stale, or undocumented configuration.
// Validate config hygiene — docker-compose env vars vs .env.example vs code references vs architecture docs. Flags missing, stale, or undocumented configuration.
| name | validate-config |
| description | Validate config hygiene — docker-compose env vars vs .env.example vs code references vs architecture docs. Flags missing, stale, or undocumented configuration. |
| allowed-tools | ["Read","Grep","Glob","Bash"] |
| user-invocable | true |
Check that configuration is consistent across all surfaces: docker-compose files, .env.example, backend code that reads env vars, and documentation. Report gaps where a variable is referenced but not documented, or documented but unused. No changes are made — read-only analysis.
| Source | Location | Read | Write | Description |
|---|---|---|---|---|
| Docker Compose (local) | docker-compose.yml | R | Local service definitions | |
| Docker Compose (prod) | docker-compose.prod.yml | R | Production service definitions | |
| Env example | .env.example | R | Documented env vars | |
| Backend config | src/backend/config.py | R | Centralized config constants | |
| Backend code | src/backend/ | R | os.environ / os.getenv usage | |
| MCP server code | src/mcp-server/src/ | R | process.env usage | |
| Frontend code | src/frontend/ | R | VITE_ env var usage | |
| Architecture docs | docs/memory/architecture.md | R | Documented config |
Read .env.example and extract all variable names and their placeholder values.
Build a set: documented_vars
Read docker-compose.yml and docker-compose.prod.yml. Extract:
environment: entries (both KEY=value and KEY: value forms)${VAR} and ${VAR:-default} referencesBuild a map: var_name -> [services that use it]
Grep src/backend/ for:
os.environ.get("VAR" and os.environ["VAR"]os.getenv("VAR"config.VAR patterns where config.py reads from envRead src/backend/config.py specifically and extract all env var references.
Build a set: backend_vars
Grep src/mcp-server/src/ for:
process.env.VARprocess.env["VAR"]Build a set: mcp_vars
Grep src/frontend/ for:
import.meta.env.VITE_Build a set: frontend_vars
6a. Used but undocumented:
For each var in backend_vars + mcp_vars + frontend_vars + docker_compose_vars:
.env.examplePATH, HOME, NODE_ENV)6b. Documented but unused:
For each var in .env.example:
6c. Docker-compose vs .env.example:
For each ${VAR} in docker-compose files:
.env.example provides a value6d. Local vs production divergence:
Compare docker-compose.yml and docker-compose.prod.yml:
Grep src/backend/ for patterns that should be env vars:
localhost, 127.0.0.1, service names from docker-compose)Flag as informational — not all are violations, but worth reviewing.
Output a summary:
## Config Validation Report
### Env Var Coverage
| Var | .env.example | docker-compose | Backend | MCP | Frontend | Status |
|-----|-------------|----------------|---------|-----|----------|--------|
| ADMIN_PASSWORD | Y | Y | Y | - | - | OK |
| NEW_VAR | - | - | Y | - | - | UNDOCUMENTED |
| OLD_VAR | Y | - | - | - | - | UNUSED |
...
### Issues
#### Used but Undocumented (add to .env.example)
- `VAR_NAME` — used in `src/backend/config.py:42`
#### Documented but Unused (remove from .env.example)
- `OLD_VAR` — not referenced anywhere in code
#### Docker Compose Missing from .env.example
- `${VAR}` in docker-compose.yml service `backend` — no .env.example entry
#### Local vs Production Divergence
- `VAR` in docker-compose.yml but not docker-compose.prod.yml
#### Hardcoded Config (informational)
- `src/backend/services/foo.py:88` — hardcoded URL `http://some-service:3000`
**Result: X issues found (Y must-fix, Z informational)**
If any critical (P0-P1) config issues were found, create or update a GitHub issue.
P0-P1 criteria (critical — cause startup failures or security issues):
${VAR} with no .env.example entry (deployment fails)Check: Count "must-fix" issues from the report.
If must-fix issues > 0, find or create a tracking issue:
Dedupe guard — check for an existing open Config Validation issue before creating:
EXISTING=$(gh issue list --repo abilityai/trinity \
--label "automated" --state open \
--search "\"Config Validation\" in:title" \
--json number --jq '.[0].number')
Branch on $EXISTING. The two paths are mutually exclusive — execute exactly one.
Path A — $EXISTING is non-empty (open issue found): COMMENT, then STOP.
gh issue comment "$EXISTING" --repo abilityai/trinity --body "Re-run on $(date -u +%Y-%m-%d): [N] critical config issues still present.
### Updated Critical Findings (P0-P1)
[List each must-fix finding with var name, where it's used, and what's missing]
### Recommended Actions
1. [Prioritized fix — typically add to .env.example or remove dead config]
---
*Generated by scheduled /validate-config run*"
After commenting, DO NOT execute Path B. The skill workflow ends here for this run.
Path B — $EXISTING is empty (no open issue found): CREATE a new issue.
Only run this block when Path A did not run.
gh issue create \
--repo abilityai/trinity \
--title "Config Validation: [N] critical config issues found ($(date -u +%Y-%m-%d))" \
--body "## Automated Config Validation Report
**Date**: $(date -u +%Y-%m-%d)
**Result**: [N] critical config issues require attention
### Critical Findings (P0-P1)
[List each must-fix finding with var name, where it's used, and what's missing]
### Recommended Actions
1. [Prioritized fix — typically add to .env.example or remove dead config]
### Tracking Notes
- Future runs will comment on this issue rather than open a new one.
- Close this issue once all critical config issues are resolved.
---
*Generated by scheduled /validate-config run*" \
--label "type-bug,priority-p1,automated"
Concurrency caveat: best-effort, not atomic. Two simultaneous runners could both create issues; the next run will comment on the first one found. Close any duplicate manually.
If no must-fix issues (only informational like unused vars), skip issue creation — report only.
automated, priority-p1)Generate and update user documentation from code, feature flows, and recent changes into docs/user-docs/
Detect drift between architecture.md and the actual code. Validates 15 architectural invariants and flags stale doc claims with suggested edits.
Validate database schema consistency — DDL in schema.py vs migrations.py vs architecture.md. Flags drift between the three sources of truth.
Chief Security Officer audit — infrastructure-first security scan with secrets archaeology, dependency supply chain, CI/CD pipeline, LLM/AI security, OWASP Top 10, STRIDE threat modeling, and active verification. Two modes — daily (8/10 confidence gate) and comprehensive (2/10 bar).
Run the Playwright frontend e2e suite against a live Trinity stack, analyze failures, and update visual regression snapshots. Use after UI changes, before merging a PR with the `ui` label, or when the `frontend-e2e` CI workflow fails.
Validate a pull request against the Trinity development methodology and generate a merge decision report.