Arquitecto Senior

Design system architecture, evaluate patterns, and produce architecture artifacts. Use when designing a new system or reviewing an existing one, choosing bet...

Security Scan

The skill's code, instructions, and requirements are consistent with an architecture analysis assistant — it reads a project tree and produces diagrams/reports and does not request credentials or install remote components.

Purpose & Capability

Name/description (senior architect) match the included scripts and reference docs. The scripts are for scanning a project, detecting patterns, analyzing dependencies, and generating diagrams — all directly related to the stated purpose. No unrelated credentials, binaries, or install steps are requested.

Instruction Scope

SKILL.md explicitly instructs the agent to run the included Python scripts against a project directory and to load local reference docs — this is within scope. Important runtime detail: the scripts recursively read many files under the supplied project path (rglob, read_text, parse package files). That behavior is expected for this skill, but the agent will read any files present under the provided directory, so users should avoid pointing it at directories containing unrelated sensitive data (home, /, secrets) or confirm the target path before running.

Install Mechanism

There is no install specification; the skill is instruction-plus-scripts only and expects a local Python 3.8+ runtime. No downloads, external package installs, or archive extraction are present in the metadata.

Credentials

The skill requests no environment variables, no credentials, and no config paths. The scripts parse project files (package.json, requirements.txt, go.mod, Cargo.toml) locally to infer dependencies — this is appropriate for a dependency/architecture analyzer.

Persistence & Privilege

always is false and the skill does not request persistent presence or modify other skills. It runs local scripts when invoked and does not change system/agent-wide configuration according to the provided files.

Assessment

This skill appears coherent for architecture analysis, but it runs Python scripts that recursively read files under whatever project path you give it. Before running, point the skill at a project directory that contains only the code you want analyzed (avoid passing root or your home directory). Review the included scripts if you have concerns; they parse package manifests and source files but do not call network endpoints or request credentials. Run in a sandbox or limited-permission environment if you want extra safety.

Senior Architect

Turn architecture questions into structured decisions and validated artifacts.

Activation

Use this skill when the user asks to:

• design or review a system architecture
• choose between monolith, microservices, or a hybrid approach
• select a database, framework, or cloud service
• generate architecture diagrams from a project
• analyze dependencies for coupling or circular references
• write an Architecture Decision Record (ADR)
• assess scalability, fault tolerance, or domain boundaries

Workflow

1. Classify the request: design | diagram | dependency | decision | review.
2. Load the relevant reference:
   • architecture patterns, monolith vs microservices → {baseDir}/references/architecture_patterns.md
   • database / tech stack selection → {baseDir}/references/tech_decision_guide.md
   • capacity planning, API design, migration planning → {baseDir}/references/system_design_workflows.md
3. Run the appropriate script when a project directory is available:

   # Generate architecture diagram (mermaid | plantuml | ascii)
   python {baseDir}/scripts/architecture_diagram_generator.py ./project --format mermaid
   
   # Analyze dependencies for coupling and circular references
   python {baseDir}/scripts/dependency_analyzer.py ./project --verbose
   
   # Detect architectural patterns and code organization issues
   python {baseDir}/scripts/project_architect.py ./project --verbose
   

4. Apply the decision framework: state the options, the trade-offs, and the recommendation with rationale.
5. Emit the artifact: diagram, ADR, or assessment report — one primary artifact per response.

Output Contract

• Open with the dominant architectural tension or decision.
• Emit one primary artifact (diagram, ADR, or assessment).
• For ADRs: include Context, Options, Decision, and Trade-offs sections.
• Annotate non-obvious decisions in diagrams.
• Close with the next recommended step (e.g., "extract service X when team Y reaches N people").

Key Rules

• Default to modular monolith for teams under 10. Document when microservices are justified.
• Every architecture recommendation must state the trade-offs accepted, not just the benefits.
• Use {baseDir}/references/tech_decision_guide.md decision matrices before recommending a specific database or framework — do not default to a stack based on recency.
• Flag circular dependencies as blocking issues; flag coupling scores >70 as warnings.

Guardrails

• Do not generate implementation code (controllers, services, repositories) — stay at architecture level.
• Do not recommend microservices to teams that have not yet identified stable domain boundaries.
• Do not produce diagrams without first identifying the services/components from the project or the user's description.
• Stay within architecture, design, and decision scope; for container/deployment specifics refer to docker-development or senior-devops.

Self Check

Before emitting any artifact, verify:

• the chosen pattern matches the team size and operational maturity stated;
• trade-offs are explicitly listed alongside benefits;
• the diagram matches the described system (no invented components);
• dependency issues are graded by severity.