ddd13e6422
Group G — markdown tech-debt cleanup (post-audit 2026-05-02).
- 36 SKILL.md files: added "## When to use" section. Was missing across the
catalog; orchestrator routing by keyword could not auto-dispatch.
- 20 code-implementer agent .md files: added Output Footer block prescribing
RULE 0.16 STATUS-TRUTH MARKER schema in agent's final report. Previously only
code-implementer-rust.md had it; other 27 language/role variants were silent
about the marker, breaking RULE 0.16 §3 status-truth aggregation for non-Rust
batches.
- skills/site-create/: added phase-5-preview.md and phase-6-deploy.md skeleton
files. SKILL.md table-of-contents referenced 7 phases; only 5 existed on disk.
- skills/{ai-animation,rag-pipeline}/skill.md: added migration banner comment
noting they should be SKILL.md (canonical filename). Case-rename via git is a
separate orchestrator task (macOS APFS is case-insensitive; Linux deploy needs
explicit rename).
- 3 deprecated skills (site-builder, competitor-analysis, design-inspiration):
added concrete removed-after dates (was vague "before v2").
- docs/CONVERGENCE-PLAN.md:129: TBD on _blocks/evidence-grading.md duplicate
resolved (file exists, not duplicated).
- docs/DNA-INDEX.md: count edits made then overwritten by auto-encyclopedia-refresh
hook during agent run. The .kei-registry-ignore files in test fixtures (Group F)
are the structural fix; kei-registry walker implementation is the follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
119 lines
3.8 KiB
Markdown
119 lines
3.8 KiB
Markdown
---
|
|
name: architecture
|
|
description: Multi-agent architectural analysis following the Holographic Development Chain. Use when user asks to design architecture, plan implementation, analyze system structure, or says "архитектура", "план", "спроектируй", "как лучше сделать".
|
|
argument-hint: <system or feature description>
|
|
---
|
|
|
|
# Holographic Architecture Analysis
|
|
|
|
## When to use
|
|
|
|
- Designing the architecture for a new system or feature ("архитектура", "план", "спроектируй").
|
|
- Analysing an existing codebase structure for patterns, antipatterns, and dependency issues.
|
|
- Making a cross-cutting architectural decision that spans multiple modules or services.
|
|
|
|
Task: $ARGUMENTS
|
|
|
|
## Phase 0: Load Architecture Rules
|
|
|
|
BEFORE any analysis, read the rules database:
|
|
1. `~/.claude/skills/architecture-rules/references/checklist.md` — pre-implementation checklist
|
|
2. `~/.claude/skills/architecture-rules/references/patterns.md` — pattern selection guide
|
|
3. `~/.claude/skills/architecture-rules/references/antipatterns.md` — what to detect and avoid
|
|
4. `~/.claude/skills/architecture-rules/references/stack-compat.md` — technology compatibility
|
|
5. `~/.claude/skills/architecture-rules/references/duplication.md` — duplication thresholds
|
|
|
|
Apply these rules throughout ALL subsequent phases.
|
|
|
|
## Phase 1: Base Agents (Parallel)
|
|
|
|
Launch 3 agents simultaneously:
|
|
|
|
### Agent 1: Architect
|
|
Analyze structure, dependencies, patterns. If codebase exists — use Explore agent to map:
|
|
- Directory structure and module boundaries
|
|
- Data flow and control flow
|
|
- Existing patterns and conventions
|
|
- Integration points and APIs
|
|
- Return list of 5-10 key files to read
|
|
|
|
### Agent 2: Critic
|
|
Search for problems, vulnerabilities, anti-patterns:
|
|
- OWASP top 10 relevant issues
|
|
- Performance bottlenecks
|
|
- Scalability concerns
|
|
- Technical debt indicators
|
|
- Over-engineering or missing abstractions
|
|
- Return specific file:line references
|
|
|
|
### Agent 3: Validator
|
|
Verify facts and check for hallucinations:
|
|
- Do the proposed technologies actually work together?
|
|
- Are version compatibilities correct?
|
|
- Do the APIs referenced actually exist?
|
|
- Cross-check with official documentation
|
|
- Return verified facts vs unverified assumptions
|
|
|
|
## Phase 2: Arbitration
|
|
|
|
After all 3 agents return:
|
|
1. Read all key files identified by Architect
|
|
2. Compare findings — where do agents agree/disagree?
|
|
3. Resolve conflicts — pick best path with reasoning
|
|
4. Rate confidence: X% for the chosen approach
|
|
|
|
Present as:
|
|
```
|
|
## Arbitration Result
|
|
|
|
### Agents Agree On:
|
|
- [Point] — all 3 confirm
|
|
|
|
### Disagreements:
|
|
- [Point] — Architect says X, Critic says Y
|
|
- Resolution: [chosen path + why]
|
|
|
|
### Confidence: X%
|
|
```
|
|
|
|
## Phase 3: Design Options (2-3 Parallel Agents)
|
|
|
|
Launch architecture design agents with different philosophies:
|
|
|
|
### Option A: Minimal Changes
|
|
Smallest possible change, maximum reuse of existing code
|
|
|
|
### Option B: Clean Architecture
|
|
Optimal maintainability, elegant abstractions, proper separation
|
|
|
|
### Option C: Pragmatic Balance
|
|
Speed + quality trade-off, ship fast but don't accumulate debt
|
|
|
|
## Phase 4: Present & Recommend
|
|
|
|
For each option show:
|
|
- Component diagram (text-based)
|
|
- Files to create/modify
|
|
- Data flow
|
|
- Implementation phases (ordered steps)
|
|
- Estimated complexity
|
|
- Trade-offs
|
|
|
|
**Your recommendation** with reasoning and confidence %.
|
|
|
|
## Phase 5: Implementation Blueprint
|
|
|
|
After user picks an option:
|
|
1. Detailed file-by-file changes
|
|
2. Build sequence (what first, what depends on what)
|
|
3. Test strategy
|
|
4. Checkpoint plan (when to verify)
|
|
|
|
## Rules
|
|
- Architecture FIRST, code SECOND
|
|
- Find root cause, not symptoms
|
|
- Simple > clever
|
|
- 3 repeating lines > premature abstraction
|
|
- Dead code = delete, don't comment
|
|
- Each logic in separate file — defragmentation
|
|
- Checkpoints after each phase
|