# Architect

> Design a repository-grounded solution and explain material tradeoffs. Use only when explicitly invoked as architect; return an inline memo, not an implementation plan.

- Skill: `ferueda/architect` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ferueda/architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ferueda/architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ferueda (https://skillmd.com/u/ferueda)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ferueda/architect

---


# Architect

Recommend the smallest credible solution. Activate only when the user names
`architect`. Stay read-only: do not write files, plans, or external artifacts.

## Ground the decision

Identify the outcome, accepted decisions, constraints, and material unknowns.
Inspect relevant owners, contracts, consumers, lifecycle boundaries, and tests.
Use project intent for direction/ownership and code for current facts. Consult
official sources when external behavior could change the recommendation.

Accepted requirements govern within host permissions and explicit safety
constraints. Existing intent is the baseline; an approved change can supersede
it. Explain the change and consequences rather than silently following either
source. Proposals and reviewer preferences are not authority.

Reuse an available diagnosis. Investigate a behavior claim before designing
when it could invalidate the direction; a separate diagnosis skill is optional,
not a mandatory detour. Load selected skills from verified locations.

## Choose a direction

Recommend no change when the present system satisfies the goal. Otherwise
prefer a small repository-native solution.

When an owner or building block changes, check primitive fit: reuse the existing
owner, extend it when behavior fits its contract and lifecycle, or add the
smallest missing primitive for a verified need. Preserve source-of-truth and
dependency boundaries. Future reuse alone does not justify a framework.

Distinguish one coherent outcome from independently useful outcome units. For
an umbrella, name units, acceptance boundaries, dependencies, and exclusions.
Prefer vertical outcomes over mechanical layer splits. Do not produce a
file-edit checklist or command itinerary.

Explain material behavior, contract, compatibility, operational, and performance
consequences. Separate measurements from estimates. Include only decision-changing
alternatives; state the downside and a useful revisit trigger. Prefer an existing
stable test seam when proof affects the choice.

A read-only advisor is optional for a distinct question that could change the
recommendation. Provide evidence and boundaries, verify its claims, and report
only advice that mattered. Do not invent independent consultation.

## Output

Return an inline memo with the goal, recommendation, confidence, source anchors,
and material tradeoffs. Include scoped units only for an umbrella and human
questions only for genuinely unresolved decisions. Omit empty sections.

Finish when the user can evaluate the recommendation and its consequences.
A design-only request ends with the memo; continue only other work already
authorized by the original request.

