@kienha/anti-chaotic 1.0.2 → 1.0.6

package/.agent/skills/frontend-developer/references/react.md

@@ -1,91 +0,0 @@
-# Tech Stack: React & Next.js (Expert Guide)
-
-> **RESEARCH FIRST**: Before implementing, use `mcp_context7_query-docs` or `web_search` to verify you are using the latest version of Next.js features and React hooks patterns.
-
-You are an expert in React's internal mechanisms (Fiber, Reconciliation). You don't just "use hooks"; you understand _closure traps_ and _dependency arrays_.
-
-## 🌟 Core Philosophy
-
-- **UI = f(state)**: The UI is a pure projection of the application state.
-- **Unidirectional Data Flow**: Props go down, events go up.
-- **Escape Hatches are Dangerous**: Refs and `useEffect` are escape hatches. Use them only when you cannot derive behavior from rendering.
-
-## 🏗 Advanced Patterns
-
-### 1. Compound Components
-
-Avoid prop drilling and giant configuration objects.
-
-```tsx
-// Bad: <Select options={[{...}]} onChange={...} />
-
-// Good:
-<Select onValueChange={setValue}>
-  <SelectTrigger>{value}</SelectTrigger>
-  <SelectContent>
-    <SelectItem value="apple">Apple</SelectItem>
-    <SelectItem value="banana">Banana</SelectItem>
-  </SelectContent>
-</Select>
-```
-
-### 2. Custom Hooks as Logic Layer
-
-Extract _all_ logic into custom hooks. Keep components focused on _rendering_.
-
-```tsx
-// Component
-function UserProfile() {
-  const { user, loading, error } = useUserProfile(id);
-  // ... render ...
-}
-
-// Hook
-function useUserProfile(id: string) {
-  // ... query, transformation, side effects ...
-  return { user, loading, error };
-}
-```
-
-### 3. Server Components (RSC) vs Client Components
-
-- **Default to Server Components**: Fetch data, access DB, keep secrets.
-- **"Client Boundary" at the Leaves**: Add `'use client'` only when you need interactivity (onClick, useState, useEffect).
-- **Pattern**: Pass Server Component data as _props_ to Client Components.
-
-## 📦 State Management Strategy
-
-1.  **Server State**: **React Query (TanStack Query)** or **SWR**.
-    - _Never_ put API data in `useState` unless you are transforming it heavily for UI state.
-    - Use `staleTime` and `gcTime` aggressively.
-2.  **Global UI State**: **Zustand** (preferred) or Context API.
-    - Context is for _Dependency Injection_ (Themes, Auth, Toast).
-    - Zustand is for _Data Stores_ (Cart, Multi-step Form Data).
-3.  **Local State**: `useState` / `useReducer`.
-4.  **Form State**: **React Hook Form**.
-    - Uncontrolled components for performance (no re-render on every keystroke).
-    - **Zod** for schema validation.
-
-## 🚀 Performance Optimization
-
-1.  **Referential Stability**:
-    - Objects/Arrays declared in render body = new reference every render.
-    - `useMemo` for derived objects/arrays passed as props.
-    - `useCallback` for functions passed as props to memoized children.
-2.  **Virtualization**:
-    - Rendering lists > 50 items? Use `react-window` or `tanstack-virtual`.
-3.  **Code Splitting**:
-    - `lazy()` and `<Suspense>` for heavy route components or heavy libraries (charts, maps).
-
-## 🛡 Anti-Patterns to Avoid
-
-1.  **Prop Drilling**: Passing props through 5 layers. -> Use Composition or Context.
-2.  **Effect Chaining**: `useEffect` triggering state change, triggering another `useEffect`. -> Combine logic or derive state.
-3.  **Stale Closures**: Forgetting dependencies in `useEffect` or `useCallback`.
-4.  **"God Components"**: Components with > 200 lines or > 5 hook calls.
-
-## 🧪 Testing (React Testing Library)
-
-- **Priority**: `screen.findByRole('button', { name: /save/i })`
-- **User Event**: Use `userEvent.type()` instead of `fireEvent.change()`.
-- **Wrappers**: Create a custom `render` function that wraps components in all Providers (Auth, QueryClient, Theme).

package/.agent/skills/rules-workflows/assets/example-workflow.md

@@ -1,37 +0,0 @@
----
-description: Standard workflow for deploying to staging environment
----
-
-# Deploy to Staging
-
-This workflow guides through deploying the application to staging.
-
-## Step 1: Run Tests
-
-Ensure all tests pass before deployment:
-
-```bash
-npm run test
-```
-
-## Step 2: Build Application
-
-Build the production bundle:
-
-```bash
-npm run build
-```
-
-## Step 3: Deploy to Staging
-
-Deploy the built application:
-
-```bash
-npm run deploy:staging
-```
-
-## Step 4: Verify Deployment
-
-- Check the staging URL is accessible
-- Verify key functionality works
-- Review logs for any errors

package/.agent/skills/rules-workflows/assets/templates/rule-project-context.md

@@ -1,26 +0,0 @@
----
-trigger: always_on
----
-
-# Project Context & Insights
-
-## Domain Overview
-
-[Describe the business domain, e.g., "E-commerce platform for vintage watches"]
-
-## Key Architecture Decisions
-
-- **Frontend**: [e.g., Next.js 14, Tailwind, Shadcn]
-- **Backend**: [e.g., Supabase, Edge Functions]
-- **State Management**: [e.g., Zustand]
-
-## Coding Standards (Strict)
-
-- [Rule 1: e.g., "All components must be functional"]
-- [Rule 2: e.g., "Use Zod for all validations"]
-- [Rule 3: e.g., "No console.log in production"]
-
-## Workflow Preferences
-
-- **Testing**: [e.g., "Write tests before code"]
-- **Commits**: [e.g., "Conventional Commits format"]

package/.agent/skills/rules-workflows/assets/templates/workflow-agile-feature.md

@@ -1,62 +0,0 @@
----
-description: End-to-end Agile feature implementation workflow
----
-
-# Agile Feature Implementation
-
-## Step 1: Requirements Analysis
-
-**Role: Product Manager**
-
-Analyze the user's request.
-
-1.  Identify the core problem and user goal.
-2.  Define success criteria.
-3.  List key constraints (tech stack, performance, etc.).
-4.  Generate a list of user stories or acceptance criteria.
-
-If requirements are vague, STOP and ask the user for clarification.
-
-## Step 2: Technical Specification
-
-**Role: Lead Architect**
-
-Create a technical design for the feature.
-
-1.  Propose the architecture changes.
-2.  Identify necessary file changes (New/Modified/Deleted).
-3.  Define API contracts or data models.
-4.  Assess security and performance implications.
-
-## Step 3: Implementation Strategy
-
-**Role: Sequential Thinking**
-
-Plan the coding steps.
-
-1.  Break down the implementation into small, testable chunks.
-2.  Identify dependencies between steps.
-3.  Plan for edge cases and error handling.
-4.  **Output**: A step-by-step implementation plan in `task.md`.
-
-## Step 4: Coding & TDD
-
-**Role: Developer (Backend/Frontend)**
-
-Execute the plan.
-
-1.  Create/Update tests first (if TDD is followed).
-2.  Implement the code for one chunk.
-3.  Run tests to verify.
-4.  Repeat until feature is complete.
-
-## Step 5: Verification & QA
-
-**Role: QA Tester**
-
-Verify the implementation.
-
-1.  Run the full test suite.
-2.  Perform manual verification steps (if strictly necessary).
-3.  Check against the original acceptance criteria.
-4.  Generate a final `walkthrough.md` report.

package/.agent/workflows/generate-docs-from-codebase.md

@@ -1,335 +0,0 @@
----
-description: Generate comprehensive documentation from existing codebase (Architecture, API, Specs).
----
-
-# Workflow: Generate Documentation from Codebase
-
-Use this workflow to automatically generate structured documentation from an existing codebase. This workflow follows the project's **documentation rule** (`documentation.md`) to ensure proper folder structure and knowledge graph linking.
-
-## Prerequisites
-
-- The `docs/` folder structure should exist (or will be created based on `documentation.md` rule).
-- Agent should understand the project's tech stack.
-
----
-
-## Step 1: Codebase Discovery & Analysis
-
-**Goal**: Understand the project structure, tech stack, and architecture.
-
-// turbo
-
-1. **Read Configuration Files**:
-   - `package.json` / `pyproject.toml` / `go.mod` (dependencies & scripts)
-   - `tsconfig.json` / `drizzle.config.ts` / `vite.config.ts` (build config)
-   - `.env.example` (environment variables)
-
-2. **Analyze Folder Structure**:
-   - Run `list_dir` on root, `app/` or `src/`, `db/` or `schema/`
-   - Identify patterns: routes, components, services, models
-
-3. **Identify Key Components**:
-   - Entry points (`main.ts`, `index.ts`, `app/root.tsx`)
-   - API routes (`app/routes/api/`, `app/api/`)
-   - Database schemas (`app/db/schema/`, `prisma/schema.prisma`)
-   - Shared utilities and types
-
-**Output**: Mental map of the codebase structure.
-
----
-
-## Step 2: Determine Documentation Scope
-
-**Goal**: Decide which documentation types to generate based on analysis.
-
-// turbo
-
-Ask the user which documentation to generate (or generate all by default):
-
-| Doc Type                | Target Folder                  | Description                              |
-| ----------------------- | ------------------------------ | ---------------------------------------- |
-| **System Architecture** | `docs/030-Specs/Architecture/` | C4 diagrams, component relationships     |
-| **API Documentation**   | `docs/030-Specs/API/`          | Endpoint specs, request/response schemas |
-| **Database Schema**     | `docs/030-Specs/Schema/`       | Entity descriptions, relationships       |
-| **Component Reference** | `docs/030-Specs/Components/`   | Frontend component documentation         |
-| **Technical Overview**  | `docs/030-Specs/`              | High-level technical summary             |
-
-**Output**: List of documentation targets to generate.
-
----
-
-## Step 3: Generate System Architecture Documentation
-
-**Role**: Lead Architect (use `lead-architect` skill if complex)
-
-// turbo
-
-1. **Create Architecture Overview**:
-   - File: `docs/030-Specs/Architecture/System-Context.md`
-   - Include: Technology stack, deployment targets, external integrations
-   - Generate: C4 Context Diagram (Mermaid)
-
-2. **Create Component Diagram**:
-   - File: `docs/030-Specs/Architecture/Component-View.md`
-   - Include: Major components and their interactions
-   - Generate: C4 Component Diagram (Mermaid)
-
-3. **Document Data Flow**:
-   - File: `docs/030-Specs/Architecture/Data-Flow.md`
-   - Include: Request lifecycle, data transformation points
-
-**Template**:
-
-```markdown
----
-id: ARCH-001
-type: architecture
-status: generated
-created: { DATE }
-tags: [architecture, c4, system-design]
----
-
-# System Architecture Overview
-
-## Context Diagram
-
-\`\`\`mermaid
-C4Context
-title System Context Diagram
-Person(user, "User", "End user of the system")
-System(app, "Application", "The main application")
-System_Ext(db, "Database", "Data persistence")
-\`\`\`
-
-## Technology Stack
-
-- **Frontend**: {framework}
-- **Backend**: {runtime}
-- **Database**: {database}
-- **Hosting**: {platform}
-
-## Key Architectural Decisions
-
-1. ...
-```
-
----
-
-## Step 4: Generate API Documentation
-
-**Goal**: Document all API endpoints with request/response schemas.
-
-// turbo
-
-1. **Scan API Routes**:
-   - Find all route handlers in `app/routes/api/` or equivalent
-   - Extract: method, path, parameters, response types
-
-2. **Generate Endpoint Docs**:
-   - Create one file per major API resource
-   - Location: `docs/030-Specs/API/`
-   - Naming: `Endpoint-{Resource}-{Action}.md`
-
-3. **Create API Index**:
-   - File: `docs/030-Specs/API/API-Standards.md`
-   - Include: Base URL, authentication, common patterns
-
-**Template**:
-
-```markdown
----
-id: API-{NUMBER}
-type: api-spec
-status: generated
-created: { DATE }
-tags: [api, { resource }]
----
-
-# API: {Resource Name}
-
-## Endpoints
-
-### `{METHOD} {PATH}`
-
-**Description**: {what this endpoint does}
-
-**Authentication**: Required / Public
-
-**Request**:
-\`\`\`typescript
-// Request body type
-interface Request {
-field: type;
-}
-\`\`\`
-
-**Response**:
-\`\`\`typescript
-// Response type
-interface Response {
-data: type;
-}
-\`\`\`
-
-**Example**:
-\`\`\`bash
-curl -X {METHOD} {BASE_URL}{PATH} \
- -H "Authorization: Bearer $TOKEN" \
- -d '{"field": "value"}'
-\`\`\`
-```
-
----
-
-## Step 5: Generate Database Schema Documentation
-
-**Goal**: Document database entities and relationships.
-
-// turbo
-
-1. **Scan Schema Definitions**:
-   - Drizzle: `app/db/schema/*.ts`
-   - Prisma: `prisma/schema.prisma`
-   - Raw SQL: `migrations/`
-
-2. **Generate Entity Docs**:
-   - Location: `docs/030-Specs/Schema/`
-   - Naming: `DB-Entity-{TableName}.md`
-
-3. **Create ERD**:
-   - File: `docs/030-Specs/Schema/ERD.md`
-   - Generate: Mermaid ER Diagram
-
-**Template**:
-
-```markdown
----
-id: DB-{NUMBER}
-type: schema
-status: generated
-created: { DATE }
-tags: [database, { table_name }]
----
-
-# Entity: {TableName}
-
-## Description
-
-{Purpose of this table}
-
-## Schema
-
-| Column | Type | Nullable | Default           | Description |
-| ------ | ---- | -------- | ----------------- | ----------- |
-| id     | uuid | No       | gen_random_uuid() | Primary key |
-| ...    | ...  | ...      | ...               | ...         |
-
-## Relationships
-
-- **belongs_to**: [[DB-Entity-{Parent}]]
-- **has_many**: [[DB-Entity-{Child}]]
-
-## Indexes
-
-- `idx_{table}_{column}` - {purpose}
-```
-
----
-
-## Step 6: Generate MOC (Map of Content) Files
-
-**Goal**: Create index files for navigation.
-
-// turbo
-
-1. **Create Specs MOC**:
-   - File: `docs/030-Specs/Specs-MOC.md`
-   - Link to all generated specs
-
-2. **Update Main Index**:
-   - File: `docs/000-Index.md`
-   - Add links to new documentation
-
-**Template**:
-
-```markdown
----
-id: MOC-030
-type: moc
-status: active
-created: { DATE }
----
-
-# Specifications (Map of Content)
-
-## Architecture
-
-- [[System-Context]] - High-level system overview
-- [[Component-View]] - Internal component structure
-- [[Data-Flow]] - Request/response lifecycle
-
-## API
-
-- [[API-Standards]] - API conventions and authentication
-- [[Endpoint-Users]] - User management endpoints
-- ...
-
-## Database Schema
-
-- [[ERD]] - Entity relationship diagram
-- [[DB-Entity-User]] - User table schema
-- ...
-```
-
----
-
-## Step 7: Validation & Linking
-
-**Goal**: Ensure generated documentation is complete and properly linked.
-
-// turbo
-
-1. **Check Frontmatter**: All files must have YAML frontmatter with required fields.
-2. **Verify Links**: All `[[Wiki-links]]` should point to existing files.
-3. **Cross-Reference**: Technical specs should link to related requirements if they exist.
-
-**Validation Checklist**:
-
-- [ ] All docs have `id`, `type`, `status`, `created` in frontmatter
-- [ ] MOC files link to all related documents
-- [ ] Mermaid diagrams render correctly
-- [ ] No broken wiki-links
-
----
-
-## Step 8: Summary & Next Steps
-
-// turbo
-
-1. **Report Generated Files**: List all created documentation files.
-2. **Suggest Improvements**:
-   - Missing documentation areas
-   - Outdated sections that need manual review
-3. **Recommend Follow-ups**:
-   - Run `/ui-ux-design-from-doc` if design docs are needed
-   - Run `/requirement-analysis` for new features
-
-**Output Example**:
-
-```
-✅ Documentation generated successfully!
-
-📁 Files Created:
-- docs/030-Specs/Architecture/System-Context.md
-- docs/030-Specs/Architecture/Component-View.md
-- docs/030-Specs/API/API-Standards.md
-- docs/030-Specs/API/Endpoint-Users.md
-- docs/030-Specs/Schema/ERD.md
-- docs/030-Specs/Schema/DB-Entity-User.md
-- docs/030-Specs/Specs-MOC.md
-
-🔗 Next Steps:
-- Review generated docs for accuracy
-- Add missing business context to architecture docs
-- Link specs to existing requirements
-```