Design and plan software architecture for new features or refactoring. Use when asked to architect a solution, design a feature, create TDD, plan implementation, or make architectural decisions.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Design and plan software architecture for new features or refactoring. Use when asked to architect a solution, design a feature, create TDD, plan implementation, or make architectural decisions.
allowed-tools
Read, Grep, Glob, Task, Skill
Architect Skill
Design software architecture for the personal_assistant project following established patterns and principles.
In PRD the user will add "!IMPORTANT!" for items you must address. Always evaluate this section and propose 1 to 2 solutions to the highlighted issue.
Architecture Principles
This project follows Domain Driven Design and Onion Architecture:
The project uses SQL Server (not PostgreSQL). All raw SQL scripts in TDDs must use SQL Server syntax:
INT IDENTITY(1,1) for auto-increment (not SERIAL)
DATETIME2 for timestamps (not TIMESTAMPTZ)
BIT for booleans (not BOOLEAN)
UNIQUEIDENTIFIER for GUIDs (not UUID)
NVARCHAR for Unicode strings
Square brackets [TableName] for identifiers (not double quotes)
CONSTRAINT [FK_Name] FOREIGN KEY syntax for foreign keys
Backwards Compatibility
All backend changes must be 100% backwards compatible for drops (memories) and access to drops (which users have access to drops they or others created).
Design Process
For every request, always create an md file and save it to directory docs/tdd.
Most times you will be referrencing PRDs in docs/prd. You can ask /product-manager to create a prd if you don't have enough requirements to do a quality design.
1. Understand Requirements
Clarify the feature/change scope
Identify affected domains
Determine integration points with existing code
2. Identify Components
For Backend Features:
Which controllers need modification/creation?
What services handle the business logic?
What repositories are needed for data access?
What domain models represent the data?
What request/response models are needed?
For Frontend Features:
!IMPORTANT! - use fyli-fe-v2 project. fyli-fe is deprecated and only used for reference.
Which views/pages are affected?
What components need creation/modification?
What composables provide shared logic?
What Pinia stores manage state?
What service layer handles API calls?
Use docs/FRONTEND_STYLE_GUIDE.md for all style decisions.
Request the /designer to review proposed frontend changes.
3. Design Patterns to Apply
Factory Pattern - Use instead of if/else chains or switch statements:
// Good: Factory pattern via dictionary or DI registrationvar handlerFactory = new Dictionary<string, INotificationHandler>
{
["email"] = new EmailHandler(),
["sms"] = new SmsHandler(),
["push"] = new PushHandler()
};
var handler = handlerFactory[type];
// Avoid: Switch statementsswitch (type)
{
case"email": ...
case"sms": ...
}
This project uses EF Core Code-First migrations. Never write raw SQL for schema changes. To add/modify tables:
Create/update POCO entity class in cimplur-core/Memento/Domain/Entities/
Add FK and index configuration in StreamContext.cs → OnModelCreating
Add DbSet<T> property to StreamContext.cs
Generate migration: cd cimplur-core/Memento && dotnet ef migrations add <Name>
When documenting schema in TDDs, show the POCO entity, the OnModelCreating configuration, and the DbSet line.
Raw SQL MUST be included as a reference comment.
Always create the raw sql for each migration and save it in the TDD. That is the way the code gets to production (we don't use EF migrations in production).
Database Schema
Do not use jsonb fields if it can be avoided.
API Endpoints
New or modified endpoints
Frontend Components
Vue components and their responsibilities
Testing Plan
What tests are needed and at what level. Always add tests for both frontend and backend changes.
Implementation Order
Recommended sequence for building the feature
Review
After creating the TDD, use the Skill tool to invoke /code-review (e.g., Skill: code-review) to review the TDD and get feedback. Do NOT use the Task tool with subagent_type "code-review" — code-review is a skill, not a subagent type. Display feedback to the user to decide if to address.
Archiving
When a TDD is complete (all phases built and reviewed), move the corresponding PRD from docs/prd/ to docs/prd/archive/.
Project-Specific Considerations
Calendar Integration: Consider Google Calendar and Outlook APIs
