code-ai-installer 4.0.0 → 4.0.1-b

package/domains/development/locales/en/.agents/skills/current-state-analysis/SKILL.md

@@ -1,172 +1,256 @@
----
-name: current-state-analysis
-description: Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.
-type: discretionary
-domain: development
-owners:
-  - architect
-gates:
-  - ARCH
-tech: []
-topic:
-  - architecture
-triggers:
-  - codebase analysis
-  - current architecture
-  - tech debt
-  - bottlenecks
-  - repo review
-  - current state
-related:
-  - system-design-checklist
-  - architecture-doc
-  - architecture-doc-reference
-  - architecture-compliance-review
-  - lava-flow-legacy-detection
-  - adr-log
-  - adr-log-reference
-  - threat-model-baseline
-  - security-baseline-dev
-  - observability-plan
-  - observability-logging
-budget_lines: 265
-schema_version: 1
----
-
-
-# Skill: Current State Analysis
-
-How to audit a repository before making major architectural decisions or refactoring.
-
-**Sections:**
-1. [When to use](#1-when-to-use)
-2. [Workflow](#2-workflow)
-3. [Analysis Areas](#3-analysis-areas)
-4. [Output Template](#4-output)
-
----
-
-## 1. When to use
-
-The Architect or Senior Full Stack agent uses this skill:
-- **During Discovery:** When taking over an existing repository.
-- **Before major refactoring:** To understand the baseline.
-- **Before system design:** To identify constraints and existing patterns that shouldn't be duplicated.
-
----
-
-## 2. Workflow
-
-```
-1. Get the repository structure (find_by_name, ls)
-2. Identify the technology stack (package.json, go.mod, dockerfile)
-3. For each analysis area (Architecture, Data, UI, DX):
-   a. Sample 3-5 representative files
-   b. Look for consistency (e.g., are there 3 ways to fetch data?)
-   c. Identify red flags (hardcoded secrets, missing auth, god objects)
-4. Synthesize the findings into the Analysis Report
-5. Propose immediate remediation steps (if requested)
-```
-
----
-
-## 3. Analysis Areas
-
-### 3.1 Architecture & Structure
-
-Check how the code is organized.
-
-| What to look for | Tooling / Pattern | Good | Bad |
-|------------------|-------------------|------|-----|
-| **Module boundaries** | `find_by_name`, structure | By feature (`features/products`) or layer (`src/controllers`) | Flat `src/` with 50 files, or `misc/` folder |
-| **Data flow** | `grep "fetch("` or `grep "axios"` | Through explicit services/API clients | Directly from UI components |
-| **State management** | `package.json`, React Context | Zustand, RTK Query, or well-scoped Context | Prop drilling 5 levels deep, redundant global state |
-| **Routing** | React Router / Next.js app dir | Centralized, lazy loaded where needed | Scattered `<Route>` definitions, no 404 handling |
-
-### 3.2 Code Quality & Consistency
-
-Check if the team is writing code the same way.
-
-| What to look for | Tooling / Pattern | Good | Bad |
-|------------------|-------------------|------|-----|
-| **Linting/Formatting**| `package.json` (ESLint, Biome, Prettier) | Strict CI checks, `biome.json` | Missing, or lots of `eslint-disable` |
-| **Naming Conventions**| Sampling files | `camelCase` for vars, `PascalCase` for React | Mixed `snake_case` and `camelCase` in JS |
-| **Component Size** | File sizes | < 200 lines, focused | 1000+ line God Components |
-| **Testing** | `__tests__` or `*.test.ts` | High coverage on business logic | No tests, or only empty generated tests |
-
-### 3.3 Security & Resiliency
-
-Check for obvious vulnerabilities and fragility.
-
-| What to look for | Tooling / Pattern | Good | Bad |
-|------------------|-------------------|------|-----|
-| **Secrets** | `grep "API_KEY"` or `grep "password"` | Environment variables (`process.env`) | Hardcoded tokens in source code |
-| **Authentication** | Middleware/HOCs | Centralized auth check / protected routes | Ad-hoc checks, leaked sensitive data |
-| **Error Handling** | `try/catch`, Error Boundaries | Global error boundary, unified API error format | Unhandled promise rejections, blank screens |
-| **Dependencies** | `npm audit`, `package.json` | Up-to-date, minimal external deps | Known vulnerabilities, 5 different date libraries |
-
-### 3.4 UI & Performance
-
-Check how the frontend is built and how it performs.
-
-| What to look for | Tooling / Pattern | Good | Bad |
-|------------------|-------------------|------|-----|
-| **Styling Strategy** | CSS Modules, Tailwind, WDS | Consistent use of one strategy | Mixed inline styles, global CSS, and Tailwind |
-| **Rendering** | Over-fetching, hydration | Memoization where needed, optimized images | 10MB bundle, `useEffect` infinite loops |
-| **Accessibility (a11y)**| `aria-`, semantic HTML | `<button>`, native focus, correct contrast | `onClick` on `<div>` without keyboard support |
-
----
-
-## 4. Output Template
-
-```markdown
-# Current State Analysis: <Project/Module Name>
-
-**Date:** YYYY-MM-DD
-**Analyst:** <Agent Role>
-
-## 1. Executive Summary
-<2-3 sentences summarizing the overall health and major findings.>
-
-## 2. Tech Stack & Architecture
-- **Frontend:** React 18, Vite, Zustand
-- **Backend:** Node.js, Express (if monolithic repo)
-- **Styling:** CSS Modules
-- **Pattern:** Layered architecture (Controllers -> Services)
-
-## 3. Findings
-
-### 3.1 Architecture & Consistency
-- ✅ **Good:** Routing is centralized in `src/routes.tsx`.
-- ⚠️ **Warning:** Two different data fetching patterns found (raw `fetch` vs custom `apiClient`). Need to unify.
-- 🔴 **Red Flag:** `Dashboard.jsx` is 850 lines long and handles rendering, data fetching, and complex logic (God Object).
-
-### 3.2 Security & Error Handling
-- ✅ **Good:** Passwords are never sent to the client.
-- 🔴 **Red Flag:** Production API keys found hardcoded in `src/config/keys.js`. (Requires immediate rotation and .env extraction).
-- ⚠️ **Warning:** Missing global React Error Boundary. Unhandled exceptions crash the whole tree.
-
-### 3.3 UI & Code Quality
-- ✅ **Good:** ESLint is configured and running strictly.
-- ⚠️ **Warning:** Minimal unit test coverage (only 3 tests exist).
-
-## 4. Recommendations & Tech Debt
-
-**Immediate Remediation (P0):**
-1. Extract secrets from `src/config/keys.js` to `.env`.
-2. Refactor `Dashboard.jsx` into smaller pure components.
-
-**Short-term Tech Debt (P1):**
-1. Unify data fetching to use `apiClient` exclusively.
-2. Implement global Error Boundary.
-
-**Long-term Strategy (P2):**
-1. Introduce Vitest for unit testing critical services.
-```
-
----
-
-## See also
-- `$architecture-doc` — Use the analysis to propose the new architecture.
-- `$system-design-checklist` — To ensure no areas are missed during redesign.
-- `$security-review-baseline` — For deeper security audits.
+---
+name: current-state-analysis
+description: Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.
+type: discretionary
+domain: development
+owners:
+  - architect
+gates:
+  - ARCH
+tech: []
+topic:
+  - architecture
+triggers:
+  - codebase analysis
+  - current architecture
+  - tech debt
+  - bottlenecks
+  - repo review
+  - current state
+related:
+  - system-design-checklist
+  - architecture-doc
+  - architecture-doc-reference
+  - architecture-compliance-review
+  - lava-flow-legacy-detection
+  - adr-log
+  - adr-log-reference
+  - threat-model-baseline
+  - security-baseline-dev
+  - observability-plan
+  - observability-logging
+budget_lines: 265
+schema_version: 1
+---
+
+
+# Skill: Current State Analysis
+
+A systematic audit of existing code before starting a new task.
+
+**Sections:**
+1. [When to use](#1-when-to-use)
+2. [Audit workflow](#2-workflow)
+3. [What to look for (checklist)](#3-what-to-look-for)
+4. [Severity levels](#4-severity)
+5. [Output Template](#5-output-template)
+6. [Example analysis](#6-example)
+
+---
+
+## 1. When to use
+
+- The project already exists / there is a repository with code
+- Before the ARCH gate (new feature, refactoring, migration)
+- There is legacy or partially implemented functionality
+- The team wants to understand the current state before planning
+
+---
+
+## 2. Workflow
+
+```
+1. Structure overview (5 min)
+   ├── list_dir → root, src/, packages/
+   ├── package.json → deps, scripts, engines
+   ├── Docker files → services, ports, volumes
+   └── Config files → .env.example, tsconfig, biome, vitest
+
+2. Pattern identification (10 min)
+   ├── FE: framework, state management, routing, styling
+   ├── BE: framework, layers (router/controller/service/repo), middleware
+   ├── Data: ORM/ODM, schema strategy, migrations
+   └── Infra: CI/CD, Docker, reverse proxy, certs
+
+3. Finding bottlenecks (10 min)
+   ├── grep_search → console.log, TODO, FIXME, HACK, XXX
+   ├── grep_search → hardcoded secrets, passwords, API keys
+   ├── grep_search → any, eslint-disable, @ts-ignore
+   ├── find_by_name → *.test.*, *.spec.* (coverage)
+   └── Manual check → N+1, god objects, tight coupling
+
+4. Recording findings (5 min)
+   └── Fill in the Output Template (section 5)
+
+5. Forming recommendations
+   └── Quick wins (< 1h) vs Strategic (> 1 sprint)
+```
+
+---
+
+## 3. What to look for
+
+### Structure and conventions
+
+| What to check | How | Red flag |
+|--------------|-----|----------|
+| Layers (FE/BE) | `list_dir` src/ | No clear separation |
+| Naming | Files, variables, exports | Mixed styles (camelCase + snake_case) |
+| JSDoc | `grep_search` `@param` | No function documentation |
+| Imports | Absolute vs relative | `../../../` — deep nesting |
+| Config | `.env.example`, schema validation | No env var validation |
+
+### Technical debt
+
+| What to look for | Grep pattern | Severity |
+|-----------|-------------|----------|
+| `console.log` in production | `console.log` (excluding tests) | P1 |
+| TODO/FIXME | `TODO\|FIXME\|HACK\|XXX` | P1-P2 |
+| Hardcoded secrets | `password.*=\|secret.*=\|apiKey.*=` | 🔴 P0 |
+| Disabled linting | `eslint-disable\|@ts-ignore\|biome-ignore` | P1 |
+| `any` types | `:\s*any\b` (in .ts files) | P1 |
+| Missing error handling | `catch\s*\(\s*\)` (empty catch) | P1 |
+| Outdated deps | `npm outdated` / `npm audit` | P1-P2 |
+| Dead code | Unused exports, unreachable branches | P2 |
+
+### Performance
+
+| What to look for | Where | Red flag |
+|-----------|-----|----------|
+| N+1 queries | Loops with DB calls inside | 🔴 P0 |
+| Missing indexes | Schema definitions | P0-P1 |
+| No `.lean()` | Mongoose queries in API responses | P1 |
+| No `.select()` | Full document fetch for list endpoints | P1 |
+| `skip()` pagination | Large collections | P1 |
+| Sync heavy ops | Main thread blocking | P0 |
+
+### Security
+
+| What to look for | How | Severity |
+|-----------|-----|----------|
+| NoSQL injection | `Model.find(req.query)` | 🔴 P0 |
+| XSS | `dangerouslySetInnerHTML` without sanitize | 🔴 P0 |
+| Secrets in code | `grep_search` API keys, tokens | 🔴 P0 |
+| No Helmet | Express without `helmet()` | P1 |
+| No CORS whitelist | `cors({ origin: '*' })` | P1 |
+| No rate limiting | Public endpoints without throttle | P1 |
+
+---
+
+## 4. Severity
+
+| Level | Description | Action |
+|-------|---------|----------|
+| 🔴 **P0** | Blocker: security vulnerability, data loss risk, broken core flow | Fix before release |
+| 🟠 **P1** | Important: tech debt, missing validation, no tests, performance risk | Schedule in the current sprint |
+| 🟡 **P2** | Improvement: code style, naming, dead code, minor optimizations | Backlog |
+
+---
+
+## 5. Output Template
+
+```markdown
+# Current State Analysis: <project-name>
+
+**Date:** YYYY-MM-DD
+**Analyst:** Architect Agent
+**Scope:** <what was analyzed>
+
+## Summary
+<1-2 paragraphs: what this project is, key technologies, current status>
+
+## Stack
+| Layer | Technology | Version |
+|-------|-----------|---------|
+| Frontend | React | 18.x |
+| Backend | Express | 4.x |
+| Database | MongoDB + Mongoose | 7.x |
+| Infra | Docker + Caddy | ... |
+
+## Conventions (detected patterns)
+- **Naming:** camelCase for files, PascalCase for components
+- **Layers:** router → controller → service → repository
+- **State:** Zustand / context
+- **Styling:** CSS Modules / Tailwind
+- **Testing:** Vitest + RTL
+
+## Technical Debt
+
+| # | Finding | Severity | Location | Recommendation |
+|---|---------|----------|----------|----------------|
+| 1 | No input validation on API endpoints | 🔴 P0 | `api/routes/*.js` | Add Zod schemas |
+| 2 | console.log in production code | 🟠 P1 | 12 files | Replace with pino logger |
+| 3 | No JSDoc on service functions | 🟡 P2 | `api/services/` | Add JSDoc blocks |
+
+## Scalability Limits
+- <specific bottlenecks: no indexes, sync ops, no cache, etc.>
+
+## Security Notes
+- <hardcoded secrets, no CORS, injection risks, etc.>
+
+## Recommendations
+
+### Quick Wins (< 1 hour each)
+1. Add Helmet middleware
+2. Add .env validation (Zod)
+3. Replace console.log with pino
+
+### Strategic (requires planning)
+1. ARCH-xx: Implement input validation layer
+2. ARCH-xx: Add integration tests for critical paths
+3. ARCH-xx: Set up CI pipeline
+
+## Next Actions
+- [ ] ARCH-01: <description>
+- [ ] ARCH-02: <description>
+```
+
+---
+
+## 6. Example analysis (excerpt)
+
+```markdown
+# Current State Analysis: SaaS Admin Panel
+
+**Date:** 2025-12-01
+**Scope:** Full repository audit
+
+## Summary
+SaaS application with Admin Dashboard (React 18 + Vite) and API (Express 4).
+Public content served via API to end-users.
+Monorepo with Docker Compose + Caddy gateway.
+
+## Technical Debt
+
+| # | Finding | Severity | Location | Recommendation |
+|---|---------|----------|----------|----------------|
+| 1 | Content payload hardcoded in template | 🔴 P0 | `public/content-renderer.js` | Fetch from API |
+| 2 | No error boundaries in React | 🟠 P1 | Dashboard components | Add ErrorBoundary wrapper |
+| 3 | Mixed import styles (CJS + ESM) | 🟡 P2 | API server files | Migrate to ESM |
+
+## Scalability Limits
+- No DB indexes on `settings.ownerId` (collection scan on every request)
+- Public endpoint fetches config on every page load (no caching)
+
+## Quick Wins
+1. Add compound index `{ ownerId: 1 }` on settings collection
+2. Add `Cache-Control` header to public content endpoint
+3. Add Helmet to Express app
+```
+
+---
+
+## Deliverables
+
+| Artifact | Format | Where to store |
+|---------|--------|---------------|
+| Current State Analysis | Markdown (output template above) | `docs/architecture/current-state-analysis.md` |
+| Tech Debt backlog | ARCH-xx items | `docs/architecture/tech-debt.md` or backlog tasks |
+
+---
+
+## See also
+- `$system-design-checklist` — checklist for a new design
+- `$architecture-doc` — full Architecture Document
+- `$security-baseline-dev` — detailed security check
+- `$observability-logging` — observability

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/SKILL.md

@@ -31,7 +31,8 @@ triggers:
   - minimal change
   - LLM working rules
   - check assumptions
-related: []
+related:
+  - mcp-integration
 budget_lines: 380
 schema_version: 1
 license: MIT

package/domains/development/locales/en/.agents/skills/lava-flow-legacy-detection/SKILL.md

@@ -44,7 +44,7 @@ schema_version: 1
 
 The "lava flow" anti-pattern (Brown et al., *AntiPatterns*, 1998) — a hardened mass of code that flowed unchecked into production. Nobody remembers why it's there, deleting feels risky (no tests), rewriting is expensive. Every release thickens the layer.
 
-> **When to apply:** ARCH (current-state analysis), DEV (before touching an old module), REV (PR review in a mature codebase). Reference skill — MCP hints via PreToolUse on mentions of legacy/brownfield/"why is this code here".
+> **When to apply:** ARCH (current-state analysis), DEV (before touching an old module), REV (PR review in a mature codebase). Reference skill — activation via frontmatter triggers; see § MCP integration below for cross-gate consumption.
 
 **Sections:**
 1. [Signs of lava flow](#1-signs)
@@ -181,3 +181,17 @@ Apply before refactoring a module or when first onboarding into a legacy repo.
 - `$design-patterns-reference` — what to use INSTEAD of the removed lava
 - `$code-review-checklist` — for reviewing the deletion PRs
 - `$system-design-checklist` — so the new code doesn't become next year's lava
+
+---
+
+## MCP integration (cross-gate activation)
+
+Reference skill with cross-gate consumption:
+
+- **ARCH (primary)** — `architect` uses it during current-state analysis before proposing refactoring
+- **DEV (secondary)** — `senior_full_stack` consults before touching an old module
+- **REV (secondary)** — `reviewer` applies during PR review in a mature codebase
+
+Activation via frontmatter triggers (`legacy code`, `dead code`, `lava flow`, `unremoved feature flag`, `brownfield refactoring`, etc.). See `$mcp-integration` for general MCP flow, gate ritual and recording discipline.
+
+Section IDs (`LF-01..LF-25`) are stable anchors: cite them inline in ARCH/REV artifacts instead of copying content. Keeps the audit trail compact and provides a backlink to the canonical source.