code-ai-installer 1.1.4 → 1.1.6

package/locales/en/.agents/architecture_doc/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: architecture_doc
+description: Architectural document on PRD+UX: modules, flows, data, integrations, errors, testability, bottlenecks, growth plan and implementation plan.
+---
+
+# Skill: Architecture Document
+
+## Goal
+Make the architecture implementable, testable, and ready for growth.
+
+## Inputs
+-PRD
+- UX Spec (flows/screens/states)
+- Stack/deployment restrictions
+- (if available) Current State Analysis
+
+## Output (structure)
+
+## 1) Overview
+- What are we building (1 paragraph)
+- Context and limitations
+- Assumptions
+
+## 2) System Context
+- Actors
+- External integrations
+- System boundaries
+
+## 3) High-level Architecture Diagram (text)
+- FE → BE → DB/Cache/External
+- Basic outlines of data and responsibilities
+
+## 4) Modules / Components
+For each component/module:
+- responsibility
+- public interfaces
+- dependencies
+- testing boundaries (unit vs integration)
+- consistency rules (patterns/conventions)
+
+## 5) Flow Mapping (from UX Spec)
+- Flow → endpoints → services → repos → entities
+- Where and why loading/empty/error states occur
+- Error strategy on the UI (what to show to the user)
+
+## 6) Integration Patterns
+- Synchronous calls (HTTP)
+- Asynchronous operations (events/queues) - if justified
+- Idempotency for risky operations
+
+## 7) Error Handling Strategy
+- Unified error format (machine-readable code)
+- 401/403/404/409/422/5xx policy
+- Secure messages (no leaks)
+
+## 8) Testing Strategy
+- Boundaries of unit tests
+- Integration tests (API/DB/integration contracts)
+- A set of “must-have” scenarios for PRD/UX
+- (optional) e2e / visual checks - if the design requires
+
+## 9) Scalability Bottlenecks (anticipation)
+- potential bottlenecks (DB hot spots, N+1, stateful sessions, heavy endpoints)
+- measures: indexes, caching, background tasks, CDN, sharding (if ever needed)
+
+## 10) Growth Plan
+Describe the thresholds and what changes:
+- 10K users: The current architecture is sufficient, but you need to monitor metrics and optimize database queries.
+- 100K users: Implementation of Redis clustering and use of CDN for static resources
+- 1M users: Transition to microservice architecture, dividing databases into reading and writing (Read/Write splitting)
+- 10M users: Event-driven architecture, distributed caching, multi-region deployment
+
+## 11) Implementation Plan
+- Epics/subsystems
+- Vertical slices MVP (minimum 1–3)
+- Dependencies and order
+
+## Quality (checklist)
+- Any UX flow can be traced through modules/API/data
+- Module boundaries reduce cohesion
+- Testability is built in
+- Observability/deployment is not forgotten
+
+## Red Flags
+- Big Ball of Mud: Lack of clear architecture
+- Golden Hammer: Use the same solution for any task
+- Premature Optimization: Optimization at too early stages
+- Not Invented Here: Refusal of ready-made solutions
+- Analysis Paralysis: Too much planning with little implementation
+- Magic: Strange, undocumented behavior
+- Tight Coupling: Too much dependence of components on each other
+- God Object: One class or component that does everything

package/locales/en/.agents/board/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: board
+description: Project Board management: creating tasks with ID, statuses ☐/⏳/☑/⚠️, updates after each step, visible checklist in every message from the conductor.
+---
+
+# Skill: Project Board (conductor's checklist)
+
+## Goal
+Provide transparent progress control: who is doing what, what is being blocked, what’s next.
+
+## When to use
+- Immediately after kickoff
+- After every response from any agent
+- When new requirements/bugs/comments appear
+
+## ID Rules
+- Prefixes: `PM-xx`, `UX-xx`, `ARCH-xx`, `DEV-xx`, `REV-xx`, `TEST-xx`
+- Numbering: 01, 02, 03…
+- One task = one verifiable result (artifact/verification).
+
+## Statuses
+- `☐` not started
+- `⏳` at work
+- `☑` ready (there is an artifact + check)
+- `⚠️` blocked (required: reason + withdrawal owner)
+
+## Algorithm
+1) Create a primary Project Board: 1–3 tasks per role for the next iteration.
+2) Update statuses at every step:
+   - if the agent started - `⏳`
+   - if you submitted an artifact and it is accepted - `☑`
+   - if input/solution is needed - `⚠️`
+3) With `⚠️` add the line “Blocker” to the report and the specific next step.
+4) In each conductor’s message, display the Project Board as the first block.
+
+## Board template (copy as is)
+###Project Board
+- [ ] (PM-01) ... — Owner: PM — Status: ☐/⏳/☑/⚠️
+- [ ] (UX-01) ... — Owner: UX — Status: ☐/⏳/☑/⚠️
+- [ ] (ARCH-01) ... — Owner: ARCH — Status: ☐/⏳/☑/⚠️
+- [ ] (DEV-01) ... — Owner: DEV — Status: ☐/⏳/☑/⚠️
+- [ ] (REV-01) ... — Owner: REV — Status: ☐/⏳/☑/⚠️
+- [ ] (TEST-01) ... — Owner: TEST — Status: ☐/⏳/☑/⚠️

package/locales/en/.agents/cloud_infrastructure_security/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: cloud_infrastructure_security
+description: Security review of cloud/infra/CI/CD: IAM, secrets manager, network, logging/monitoring, supply chain, CDN/WAF, backup/DR.
+---
+
+#Skill: Cloud & Infrastructure Security
+
+## When to activate
+- Deploy to AWS/Vercel/Railway/Cloudflare, etc.
+- IAM policies/roles
+- CI/CD pipelines
+- IaC (Terraform/CloudFormation)
+- Secrets management in the cloud
+- CDN/WAF/edge security
+- Backup/Recovery/DR
+
+## Cloud Security Checklist
+1) IAM & Access Control
+- least privilege, no wildcard
+- MFA for privileged accounts
+- no root usage in prod
+- regular access review
+
+2) Secrets Management
+- platform secrets manager
+- rotation for DB credentials (if applicable)
+- audit of access to secrets
+- prohibition of leaks in logs/errors
+
+3) Network Security
+- DB is not public
+- SSH/RDP only via VPN/bastion
+- security groups/NACL least privilege
+- flow logs (if available)
+
+4) Logging & Monitoring
+- audit of admin actions
+- log retention (for example 90+ days if necessary)
+- alerts for anomalies/failed auth
+
+5) CI/CD Pipeline Security
+- OIDC instead of long-lived credentials
+- secret scanning
+- dependency audit
+- image scanning (if containers)
+- branch protection / required reviews
+
+6) CDN/WAF (Cloudflare and analogues)
+- WAF managed rules (OWASP)
+- rate limiting/bot protection
+- security headers
+- strict TLS
+
+7) Backup & Disaster Recovery
+- automated backups + retention
+- PITR (if necessary)
+- periodic recovery testing
+- documented RPO/RTO
+
+## Pre-Deployment Checklist (short)
+IAM / Secrets / Network / Logging / Monitoring / CI/CD / WAF / Encryption / Backups / Runbooks / Incident plan
+
+## Exit
+- Findings P0/P1/P2 + specific fixes/settings
+- What to add to CI and what checks are required
+
+## See also
+- Examples and anti-examples: $review_reference_snippets

package/locales/en/.agents/code_review_checklist/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: code_review_checklist
+description: Universal review checklist: code quality, readability, testability, security, contracts, DoD.
+---
+
+# Skill: Code Review Checklist
+
+## Goal
+Quickly evaluate PR for completeness and compliance with standards.
+
+## Checklist
+### Code Quality
+- [ ] Clear names, small functions/modules
+- [ ] No duplication without reason
+- [ ] No “magic” (unobvious side effects)
+- [ ] Boundaries of layers/modules are respected
+
+### Architecture
+- [ ] Corresponds to Architecture Doc / ADR
+- [ ] No Tight Coupling / God Object / Big Ball of Mud
+- [ ] New solutions are recorded by ADR if necessary
+
+### API & Data
+- [ ] Contracts are met (schemas, codes, errors)
+- [ ] Validation at the border
+- [ ] Data/migration model is consistent
+
+###Tests
+- [ ] Unit + Integration tests added/updated
+- [ ] Covered happy + edge + error paths
+- [ ] No flakes/dependencies of tests on each other
+
+###Security
+- [ ] AuthZ on the server
+- [ ] No secrets in code/logs
+- [ ] Safe errors (no stack/SQL/PII)
+- [ ] Dependency hygiene
+
+### Observability & Ops
+- [ ] request_id/trace_id correlation (if applicable)
+- [ ] Logs are structured, without PII/secrets
+- [ ] Startup/check instructions present
+
+## Exit
+- PASS: ...
+- MISSING: ...
+- Findings P0/P1/P2

package/locales/en/.agents/current_state_analysis/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: current_state_analysis
+description: Analysis of the current repository architecture: conventions, patterns, technical debt, scaling bottlenecks, security risks and consistency.
+---
+
+#Skill: Current State Analysis
+
+## Goal
+Understand the current system so that new solutions do not break conventions and actually reduce technical debt.
+
+## When to use
+- The project already exists / there is a repository with code
+- There are legacy or partially implemented features
+
+## Exit (Deliverables)
+- Current Architecture Summary
+- Patterns & Conventions
+- Technical Debt (top 5–15)
+- Scalability limitations
+- Security baseline issues (if visible)
+- Recommendations (quick wins + strategic)
+
+## Algorithm
+1) Overview of the repo structure (folders, layers, boundaries)
+2) Define key patterns (FE/BE/data) and style
+3) Find bottlenecks:
+   - statefulness
+   - N+1/slow queries
+   - strong connectivity
+   - no caching (if needed)
+   - lack of observability
+4) Record technical debt and risks
+5) Suggest a fix plan: quick wins vs later
+
+## Response format
+### Summary
+### Deliverables
+### Findings
+- Patterns/Conventions
+- Tech Debt
+- Scalability Limits
+- Security Notes
+### Recommendations
+### Next Actions (IDs: ARCH-xx)

package/locales/en/.agents/data_model/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: data_model
+description: Data model and storage strategy: normalization/denormalization, indexes, transactions, cache, (optional) event sourcing/eventual consistency - with trade-offs and binding to UX flows.
+---
+
+# Skill: Data Model
+
+## Goal
+Support product scenarios and prepare the base for growth.
+
+## Exit
+## 1) Entities
+For each entity:
+- fields (type/required)
+- restrictions (unique/not null/range)
+- communications
+- indexes for UX queries
+
+## 2) Data patterns (conscious choice)
+- Default normalization
+- Denormalization for read perf (if really needed)
+- Cache layers (Redis) - if there are hot reads
+- Eventual consistency - if there are distributed parts
+- Event sourcing - only if you need a strict audit/replay
+
+For each selected pattern: Pros/Cons/Alternatives (ADR if necessary).
+
+## 3) Migrations strategy
+- versioning
+- reversibility (if necessary)
+- Seeds/fixtures
+
+## 4) Transaction boundaries
+- where transactions are needed
+- competition and integrity (constraints/locking)
+
+## 5) Query patterns
+- typical requests for screens
+- risks of N+1 / heavy joins
+- optimizations: indexes, prefetch, denormalization (if necessary)

package/locales/en/.agents/dependency_supply_chain_review/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: dependency_supply_chain_review
+description: Dependency review: minimization, updates, vulnerability audit, licenses, banning of unsafe packages.
+---
+
+#Skill: Dependency & Supply Chain Review
+
+## Check
+- New dependencies are really needed (no unnecessary ones)
+- Versions are not outdated/vulnerable (according to available reports/project audit)
+- Lockfile updated correctly
+- No “questionable” packages for critical functions
+- Licenses are acceptable (if the project requires)
+
+## Exit
+- List of suspicious/unnecessary packages
+- Recommendations: delete/replace/fix version
+
+## See also
+- Examples and anti-examples: $review_reference_snippets

package/locales/en/.agents/deployment_ci_plan/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: deployment_ci_plan
+description: Deployment and CI plan: environments, configs, secrets, migrations, CI checks (tests/lint/security), release and rollback strategy.
+---
+
+# Skill: Deployment & CI Plan
+
+## Goal
+Make a reproducible build/test/deploy process.
+
+## Add (Operations)
+- Monitoring/alerting (minimum)
+- Backup & recovery (if there is a database)
+- Rollback plan (required)
+
+## Inputs
+- Deployment restrictions (Vercel/Docker/AWS/etc)
+- Stack
+- Security requirements (secrets)
+
+## Output (structure)
+## 1) Environments
+-local
+- staging (if any)
+- production
+
+## 2) Config & Secrets
+- env vars list
+- where we store secrets (secret storage)
+- log policy (do not print secrets)
+
+## 3) CI pipeline (minimum)
+- install
+- lint/format (if available)
+- unit tests
+- integration tests
+- (optional) dependency audit
+
+## 4) DB migrations (if there is a database)
+- when and how migrations are applied
+- rollback strategy (if needed)
+
+## 5) Release strategy
+- versioning
+- feature flags (if needed)
+-rollback plan
+
+## DoD link
+- release is not allowed without green CI
+- migrations applied and tested
+- smoke test passed after deployment

package/locales/en/.agents/design_intake/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: design_intake
+description: Find and analyze provided design materials (files/links), determine the “source of truth” for the UI and extract verifiable rules (screens, components, tokens, states).
+---
+
+# Skill: Design Intake (collection of design sources)
+
+## Goal
+Capture which design artifacts are the source of truth and extract testable rules from them for UX Spec and development.
+
+## When to use
+- Design files (PDF/PNG/SVG/FIG, etc.) have been added to the repository
+- The user provided a link to Figma/other layouts
+- Before preparing the UX Spec or before the final UI verification
+
+## Inputs
+- Paths to files in the repository (if any)
+- Links (if available, for example Figma)
+- PRD/UX Spec (if already exist)
+
+## Search for design artifacts (heuristics)
+Check availability (if the repository is available):
+- Folders: `design/`, `docs/design/`, `assets/design/`, `.figma/`, `ui/`
+- Files: `*.fig`, `*.pdf`, `*.png`, `*.jpg`, `*.jpeg`, `*.svg`
+- Documents: `README.md`, `docs/*` for the presence of the word “Figma” and links
+
+## Algorithm
+1) **Collect sources**:
+   - list of files/folders (paths)
+   - list of links (if given)
+2) **Define the “source of truth”** (Source of Truth):
+   - main page/file for MVP screens
+   - separate pages/sections for components/tokens (if any)
+3) **Extract the specification**:
+   - list of screens and their purpose
+   - screen structure (main sections)
+   - components and options (primary/secondary, sizes, states)
+   - states: loading/empty/error/success (if reflected)
+   - key content rules (errors, tips, button texts)
+4) **Gather a Design Reference Map**:
+   - Screen → where described (file/page/frame)
+   - Component → where described
+5) **Create a “Design Rules Summary”**:
+   - 5–20 rules that can be checked (without subjectivity)
+
+## Exit (Deliverables)
+###Design Sources
+- Files:
+- Links:
+
+###Source of Truth
+- Screens:
+- Components:
+- Tokens/Guidelines:
+
+### Design Reference Map
+- Screens:
+- Components:
+
+### Design Rules Summary
+- Rule 1:
+- Rule 2:
+...
+
+## Response format
+### Summary
+### Deliverables (Design Sources + Reference Map + Rules)
+###Decisions
+###Risks/Blockers
+### Open Questions
+### Next Actions (IDs: UX-xx)

package/locales/en/.agents/design_parity_review/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: design_parity_review
+description: Compare design artifacts with the UX Spec or with the implemented UI. Issue a Design Parity Report with P0/P1/P2 priorities and specific recommendations.
+---
+
+# Skill: Design Parity Review (design verification)
+
+## Goal
+Check the compliance of the UX Spec and/or implemented UI with the provided design materials and record any discrepancies.
+
+## When to use
+- After preparing the UX Spec (Design ↔ UX Spec)
+- After implementing the UI (Design ↔ Implemented UI)
+- Before closing the release increment (as part of the DoD if there is a design)
+
+## Inputs
+- Design Reference Map and Rules (from `$design_intake`)
+- UX Spec (if we check the spec)
+- UI implementation (if we check the code):
+  - links/routes, how to reproduce states
+  - screenshots/videos/Storybook (if available)
+  - e2e/visual results (if available)
+
+## Check modes
+### Mode A: Design ↔ UX Spec (no code yet)
+Check each screen:
+- composition of sections and their order
+- main actions/CTAs
+- forms: fields, mandatory, validation, error texts
+- states: loading/empty/error/success
+- matching components with inventory/guides
+Output: list of edits to UX Spec + questions/conflicts.
+
+### Mode B: Design ↔ Implemented UI (UI has already been implemented)
+Check for each key screen and status:
+- layout/hierarchy (what is located where, what is visible first)
+- availability and options for components (buttons, inputs, tables, modals)
+- texts/labels/placeholders/error messages (if the design specifies them)
+- UI status (loading/empty/error/success)
+- basic a11y (keyboard/focus/labels/ARIA) by `$a11y_baseline`
+
+## Classification of discrepancies
+- **P0 (Blocker)**: breaks critical flow, is misleading, violates accessibility, leads to errors/data loss, contradicts PRD.
+- **P1 (Important)**: breaks consistency, degrades UX, but does not block use.
+- **P2 (Nice-to-have)**: cosmetics/polish.
+
+## Output: Design Parity Report (required structure)
+### ✅ Matches
+- ...
+
+### ⚠️ Discrepancies
+#### P0 (Blockers)
+- [ ] <what's wrong> - Screen/Component: ... - Expected: ... - Actual: ... - Fix: ...
+
+#### P1 (Important)
+- [ ] ...
+
+#### P2 (Nice-to-have)
+- [ ] ...
+
+### Recommendations for correction
+- DEV-xx: ...
+- UX-xx: ...
+
+### Conflicts (if any)
+- Conflict: <design vs PRD/architecture> → solution options
+
+## Response format
+### Summary
+### Deliverables (Design Parity Report)
+### Findings (P0/P1/P2)
+###Risks/Blockers
+### Next Actions (IDs: UX-xx / DEV-xx)

package/locales/en/.agents/design_systems/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: design_systems
+description: Integration of design systems: shadcn/ui, mantine, Wix Design System; compliance with UI inventory/UX spec and common components.
+---
+
+# Skill: Design Systems Integration
+
+## Goal
+Assemble the UI from ready-made, consistent components and do not “draw a bicycle”.
+
+## Rules
+- Prefer shadcn/ui for new projects (if the stack is suitable)
+- Mantine - if chosen by the project/there are reasons
+- Wix Design System - for the Wix ecosystem (if specified)
+- Components must support states from the UX Spec (loading/empty/error/disabled)