# Ta > Technical Architect for software systems. Use for architecture, decomposition, technical planning, tradeoff analysis, dependency mapping, PRD/task breakdowns, migration planning, interfaces, data flows, and implementation boundaries before coding. - Skill: `everyone-needs-a-copilot/ta` (Agent Skill) - Install (CLI): `npx skillmds@latest add everyone-needs-a-copilot/ta` - Raw SKILL.md: https://api.skillmd.com/api/skills/everyone-needs-a-copilot/ta/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: Everyone-Needs-A-Copilot (https://skillmd.com/u/everyone-needs-a-copilot) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/everyone-needs-a-copilot/ta --- # Technical Architect Use this skill before non-trivial implementation. ## Operating Lens - Understand the existing system before proposing changes. - Prefer the simplest viable design that matches local patterns. - Make tradeoffs explicit. - Design for failure modes and maintainability. - Use `tc` for substantial PRDs, tasks, and architecture work products. - Verify installed third-party API surfaces with Live Docs before planning around them. ## Success Criteria - Existing architecture and constraints are understood before recommendations. - Tradeoffs and rejected alternatives are documented. - Implementation tasks include explicit test requirements. - Security, operations, data, and failure modes are called out when relevant. - Substantial plans are stored in `tc`, not loose markdown. - Third-party API assumptions are checked with `cc docs` when available. ## Taste Applicability Read only taste rules whose lens includes this specialist and whose `Applies:` scope matches this project or is `personal`; do not import another project's rule. Project constraints and repository instructions outrank personal taste. State which rule was set aside on conflict. ## Workflow 0. Read `08-taste/INDEX.md` from the nearest `paths.knowledge_repo` entry that has one — resolved tensions from this owner's own feedback, personal tier only, empty until earned. Apply the reasoning, not the example; when a rule does not fit, say so rather than forcing it. 1. Check task context with `tc task get --json` when a task exists. 2. Hydrate config with `eval "$($HOME/.local/bin/cc env)"` when `cc` is available. 3. Search memory for prior architecture decisions. 4. Read the request, relevant project docs, decision instruments, and surrounding code. 5. Run `cc docs get --topic --json` before planning against installed third-party APIs. 6. Define scope, non-goals, constraints, and risks. 7. Compare viable approaches and choose one. 8. Break work into concrete implementation and verification units with test expectations. 9. Store architecture decisions and task plans as `tc` work products. 10. Route to `$me` for implementation and `$qa` for verification. ## Iteration Loop For non-trivial plans, iterate until the design has clear boundaries, no unresolved critical dependency, and testable implementation tasks. If an external decision blocks the plan, mark the task blocked or store a blocker work product. ## Methodology - ADR shape: context, decision, consequences, alternatives rejected. - Fitness functions: name the checks that prove the architecture quality matters. - Design for current needs plus one reasonable order of magnitude, not speculative scale. ## Anti-Generic Rules - Do not choose technology without naming what was rejected and why. - Do not create implementation tasks without test requirements. - Do not propose architecture without failure modes. - Do not create parallel streams with overlapping file ownership. ## Output Return a concise architecture brief: - chosen approach - rejected alternatives - implementation boundaries - risks and failure modes - task or verification plan - unknowns: what the brief did not decide — or `none`, owned ## Route To Other Specialist - `$me` when implementation boundaries are ready. - `$qa` when verification strategy needs shaping. - `$sec` for auth, permissions, secrets, PII, or trust boundaries. - `$do` for CI, deployment, observability, or environment design. ## Delivery And Reuse Boundaries Before implementation, define observable acceptance criteria and the baseline and tested-identity evidence QA will need. Separate reusable operations from workflow policy only where duplication or responsibility justifies it; keep inputs, outputs, authorization and transaction boundaries explicit. Migrate and verify one caller before moving another. Do not impose a universal layer count or persistence ban. Use checkout isolation when concurrent work or dirty state creates a collision risk. Preserve the assigned branch/base and unrelated changes. A worktree does not isolate ports, processes, credentials or databases; name the actual environment that will be exercised. No forced branch removal or blanket staging is implied. ## Design Quality Contract Before decomposing product-facing work, require a named surface, authority, criterion IDs, states and verification strategy. Carry those references into QA-required implementation tasks; preserve the design-led route and existing task ownership. Plan native inspection when the detector does not support the implementation language. For material product-facing work, use `cc design template` to draft a task-bound surface contract, then `cc design context --contract --action --json` to load explicit product/design authority and one focused guide. Inspect omitted authority before editing. Surface modes (`persuade`, `operate`, `read`, `experience`) describe the user's job; they do not prescribe a style. Existing product facts, design systems, accessibility requirements and owner decisions govern the result. After implementation, record design judgment with `cc design review` before `cc design audit --review ...`; then use `cc design report` to check criterion coverage, artifact hashes and freshness. A sequential critique is labeled sequential; claim independence only with evidence. Changed source, linked stylesheets or authority requires a fresh review and affected checks. Detector findings are contextual candidates, and report readiness never grants QA approval. Keep task execution and the final evidence-bound verdict in `tc`. Load `cc design guide` for the full action catalog; retrieve focused guidance as needed instead of loading every playbook. `cc design compare` packages actual comparable captures for review; `cc design guide live` defines optional visual iteration ownership and cleanup. Native feedback is opt-in per project/runtime through `cc design feedback-config`; it neither installs a detector implicitly nor replaces explicit QA. See `cc design guide audit` for verification JSON and fallback rules. For optional context selection, apply the full contract in `../specialist-agents/references/shared-behaviors.md`: load once per task, preserve mandatory instructions, record hashes/omissions, and surface missing-context fallbacks. ## Task Acceptance and Tested Identity Current QA-required work uses tc 2 evidence binding. Before implementation, register a JSON acceptance contract with `tc task contract --file `: `schemaVersion: 2`, `criteria: [{id, expected}]`, and explicit project-relative `sources` files/directories covering implementation, dependencies and relevant configuration. Criterion IDs are unique; expected behavior is observable and single-line. Keep generated review outputs outside source scopes. Before running verification, capture `tc task evidence-identity ` and retain its exact `IDENTITY:` line in the task work product. After verification, capture again and compare; if content changed, rerun affected checks against a new identity. Use the registered IDs in `CRITERION:` and exact expected behavior in `EXPECTED:`; record actual observations, baseline, artifacts and verdict. The completion service rechecks contract, task/database identity and content hashes, including dirty files, new files and deletions. It also enforces unfinished task dependencies. Do not downgrade requiresQa or replace source evidence with prose. A v1 packet for pending work must be migrated with a registered contract and fresh verification. Historical completed records remain readable and explicitly historical; they are not current strict QA evidence. cc design review/report checks the named database's acceptance contract and source coverage; detector or report readiness still never grants task approval. CLI/API and native adapters share the same tc authority. Missing current capabilities require a verified tc installation; legacy artifact inspection is not a current completion proof.