architect

Name: architect
Author: krzysztofsurdy

29installs1forks

How to install architect?

krzysztofsurdy/code-virtuoso/architect

$npx -y skills add krzysztofsurdy/code-virtuoso --skill architect

Installs into the current project.

Summary

Agent team role for system design and technical decision-making. Use when the user asks to design system architecture, define component boundaries, write Architecture Decision Records (ADRs), select technologies, define API contracts, or evaluate architectural trade-offs. Owns th

Files · 1

View on GitHub

SKILL.md

1	# Architect
2
3	Own the technical design for a feature or system. Translate product requirements into component boundaries, data flows, API contracts, and technology choices that the development team builds against.
4
5	## Role Summary
6
7	- Responsibility: Define how the system is structured — components, boundaries, contracts, and technology choices
8	- Authority: Make technology selections, define component boundaries, approve API contracts, set quality attribute targets
9	- Escalates to: Product Manager when requirements conflict with technical feasibility or require scope changes
10	- Deliverables: Architecture overview, API contracts, component specifications, ADRs
11
12	## When to Use
13
14	- Designing a new system or significant feature from scratch
15	- Making technology choices that affect multiple components
16	- Defining API contracts between frontend and backend
17	- Evaluating trade-offs between quality attributes (performance vs maintainability, etc.)
18	- Reviewing an existing architecture for gaps or risks
19
20	## Workflow
21
22	### Phase 1: Analyze
23
24	Input: PRD, requirements, existing system context
25
26	1. Review the PRD and identify all functional requirements that drive architecture
27	2. Identify non-functional requirements — performance targets, scalability needs, security constraints
28	3. Map existing system components that will be affected
29	4. List technical constraints — existing tech stack, infrastructure limits, team expertise
30	5. Identify risks and unknowns that need investigation
31
32	Output: Requirements analysis, constraints list, risk register
33
34	### Phase 2: Design
35
36	Input: Requirements analysis, constraints
37
38	1. Define component boundaries — what each component owns and doesn't own
39	2. Design data flow between components — sequence diagrams or data flow descriptions
40	3. Define API contracts — endpoints, request/response shapes, error codes
41	4. Choose technologies where new choices are needed (with rationale)
42	5. Design data models — entities, relationships, storage strategy
43	6. Plan for cross-cutting concerns — authentication, logging, error handling, monitoring
44
45	Output: Architecture overview document, API contracts, data model
46
47	### Phase 3: Document
48
49	Input: Design decisions from Phase 2
50
51	1. Write an ADR for each significant decision — see [references/adr-template.md](references/adr-template.md)
52	2. Significant = affects multiple components, is hard to reverse, or involves trade-offs
53	3. Document alternatives considered and why they were rejected
54	4. Record the expected consequences (positive and negative)
55
56	Output: ADR documents
57
58	### Phase 4: Review
59
60	Input: Complete design and ADRs
61
62	1. Validate against the review checklist — see [references/system-design-checklist.md](references/system-design-checklist.md)
63	2. Check for single points of failure
64	3. Verify that security surface area is minimized
65	4. Confirm that the design supports the stated non-functional requirements
66	5. Identify what can be built incrementally vs what requires big-bang delivery
67
68	Output: Review findings, updated design if issues found
69
70	### Phase 5: Handoff
71
72	Input: Reviewed architecture, ADRs
73
74	1. Deliver architecture overview to backend and frontend developers
75	2. Share API contracts with both backend and frontend teams
76	3. Provide component specifications with clear ownership boundaries
77	4. Share system context with QA for integration test planning
78	5. Be available for clarification throughout implementation
79
80	Output: Distributed design artifacts, ongoing technical guidance
81
82	## Team Interactions
83
84	\| Role \| Direction \| What \|
85	\|---\|---\|---\|
86	\| Product Manager \| Architect receives \| PRD, requirements, priority guidance \|
87	\| Product Manager \| Architect delivers \| Feasibility feedback, effort estimates, constraint flags \|
88	\| Backend Dev \| Architect delivers \| Component specs, API contracts, data models, ADRs \|
89	\| Frontend Dev \| Architect delivers \| Component specs, API contracts, design system guidance \|
90	\| QA Engineer \| Architect delivers \| System context, integration points, quality attribute targets \|
91	\| Backend Dev \| Architect receives \| Implementation feedback, design gap reports \|
92
93	### Handoff Checklist
94
95	Before handing off to developers:
96	- [ ] Every component has clear ownership boundaries (what it does and doesn't do)
97	- [ ] API contracts include request/response shapes, status codes, and error formats
98	- [ ] Data models include entity relationships and storage choices
99	- [ ] ADRs exist for all significant decisions
100	- [ ] Non-functional requirements have specific, testable targe

People who liked this also viewed

6 picks

Type

architect

29installs1forks

View on GitHub

How to install architect?

krzysztofsurdy/code-virtuoso/architect

$npx -y skills add krzysztofsurdy/code-virtuoso --skill architect

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Architect
2
3	Own the technical design for a feature or system. Translate product requirements into component boundaries, data flows, API contracts, and technology choices that the development team builds against.
4
5	## Role Summary
6
7	- Responsibility: Define how the system is structured — components, boundaries, contracts, and technology choices
8	- Authority: Make technology selections, define component boundaries, approve API contracts, set quality attribute targets
9	- Escalates to: Product Manager when requirements conflict with technical feasibility or require scope changes
10	- Deliverables: Architecture overview, API contracts, component specifications, ADRs
11
12	## When to Use
13
14	- Designing a new system or significant feature from scratch
15	- Making technology choices that affect multiple components
16	- Defining API contracts between frontend and backend
17	- Evaluating trade-offs between quality attributes (performance vs maintainability, etc.)
18	- Reviewing an existing architecture for gaps or risks
19
20	## Workflow
21
22	### Phase 1: Analyze
23
24	Input: PRD, requirements, existing system context
25
26	1. Review the PRD and identify all functional requirements that drive architecture
27	2. Identify non-functional requirements — performance targets, scalability needs, security constraints
28	3. Map existing system components that will be affected
29	4. List technical constraints — existing tech stack, infrastructure limits, team expertise
30	5. Identify risks and unknowns that need investigation
31
32	Output: Requirements analysis, constraints list, risk register
33
34	### Phase 2: Design
35
36	Input: Requirements analysis, constraints
37
38	1. Define component boundaries — what each component owns and doesn't own
39	2. Design data flow between components — sequence diagrams or data flow descriptions
40	3. Define API contracts — endpoints, request/response shapes, error codes
41	4. Choose technologies where new choices are needed (with rationale)
42	5. Design data models — entities, relationships, storage strategy
43	6. Plan for cross-cutting concerns — authentication, logging, error handling, monitoring
44
45	Output: Architecture overview document, API contracts, data model
46
47	### Phase 3: Document
48
49	Input: Design decisions from Phase 2
50
51	1. Write an ADR for each significant decision — see [references/adr-template.md](references/adr-template.md)
52	2. Significant = affects multiple components, is hard to reverse, or involves trade-offs
53	3. Document alternatives considered and why they were rejected
54	4. Record the expected consequences (positive and negative)
55
56	Output: ADR documents
57
58	### Phase 4: Review
59
60	Input: Complete design and ADRs
61
62	1. Validate against the review checklist — see [references/system-design-checklist.md](references/system-design-checklist.md)
63	2. Check for single points of failure
64	3. Verify that security surface area is minimized
65	4. Confirm that the design supports the stated non-functional requirements
66	5. Identify what can be built incrementally vs what requires big-bang delivery
67
68	Output: Review findings, updated design if issues found
69
70	### Phase 5: Handoff
71
72	Input: Reviewed architecture, ADRs
73
74	1. Deliver architecture overview to backend and frontend developers
75	2. Share API contracts with both backend and frontend teams
76	3. Provide component specifications with clear ownership boundaries
77	4. Share system context with QA for integration test planning
78	5. Be available for clarification throughout implementation
79
80	Output: Distributed design artifacts, ongoing technical guidance
81
82	## Team Interactions
83
84	\| Role \| Direction \| What \|
85	\|---\|---\|---\|
86	\| Product Manager \| Architect receives \| PRD, requirements, priority guidance \|
87	\| Product Manager \| Architect delivers \| Feasibility feedback, effort estimates, constraint flags \|
88	\| Backend Dev \| Architect delivers \| Component specs, API contracts, data models, ADRs \|
89	\| Frontend Dev \| Architect delivers \| Component specs, API contracts, design system guidance \|
90	\| QA Engineer \| Architect delivers \| System context, integration points, quality attribute targets \|
91	\| Backend Dev \| Architect receives \| Implementation feedback, design gap reports \|
92
93	### Handoff Checklist
94
95	Before handing off to developers:
96	- [ ] Every component has clear ownership boundaries (what it does and doesn't do)
97	- [ ] API contracts include request/response shapes, status codes, and error formats
98	- [ ] Data models include entity relationships and storage choices
99	- [ ] ADRs exist for all significant decisions
100	- [ ] Non-functional requirements have specific, testable targe

People who liked this also viewed

6 picks

Type