Sruja Architecture Skill

Deterministic, evidence-first workflow for generating and maintaining repo.sruja (or architecture.sruja). The skill guides the AI to write valid architecture from real code evidence; no DSL expertise required.

Quick Start

1. Evidence — Prefer .sruja/author_evidence.json when present and recent; else run sruja sync -r . (do not ask the user to run it). Use .sruja/context.json only for the small fields needed for synthesis (communities, suggested_questions, architecture_digest) and avoid loading .sruja/graph.json unless the user explicitly asks for deep dependency debugging.
2. Synthesis (Mandatory) — Propose a domain architecture map from evidence. Communities are import-graph hints, not containers; merge/split/rename into domain boundaries.
3. Questions — Ask 2–5 targeted questions only when evidence is ambiguous (boundaries, externals, datastores, deployment, runtime/data flows).
4. Output (Never write truth by default) — Write either (a) .sruja/proposals/<id>.json (preferred, incremental) or (b) repo.sruja.working (greenfield / big bang). Do not write repo.sruja until the user explicitly says to promote.
5. Promote + Validate — For proposals: sruja propose approve <id> then sruja lint repo.sruja. For working DSL: user promotes by renaming/copying to repo.sruja then sruja lint.
6. Refine — Run sruja drift -r . and iterate; keep unknowns as open questions instead of guessing.
7. Impact (Optional) — Before refactoring code, run sruja impact <target> -r . --depth 3.

Workflow checklist: [ ] Evidence gathered → [ ] Synthesis done → [ ] Questions (if needed) → [ ] Proposal/working DSL written → [ ] Promotion path used → [ ] sruja lint passed → [ ] Open questions listed

Core Principles