code-ai-installer 1.1.4 → 1.1.5

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)