@kienha/anti-chaotic 1.0.2 → 1.0.5

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

@@ -1,67 +0,0 @@
-# React & Next.js Architecture
-
-**Status**: Definitive Guide
-**Stack**: React 18+, Next.js App Router (14+)
-
-## 🏗 Architecture: "Server-Centric" Design
-
-### 1. The Separation: Server vs. Client
-
-- **Default to Server Components (RSC)**: All components are Server by default.
-- **Client Components**: Only use `'use client'` when you need:
-  - Event listeners (`onClick`, `onChange`)
-  - Hooks (`useState`, `useEffect`)
-  - Browser-only APIs
-
-### 2. File Structure (Feature-Sliced)
-
-```
-app/
-├── layout.tsx         # Root layout
-├── page.tsx           # Home
-├── (auth)/            # Route Group (doesn't affect URL)
-│   ├── login/
-│   │   └── page.tsx
-├── _components/       # Shared UI
-└── features/          # Feature Modules
-    ├── cart/
-    │   ├── components/
-    │   ├── hooks/
-    │   └── actions.ts # Server Actions
-```
-
-## ⚡ Performance Patterns
-
-### 1. Data Fetching
-
-- **No `useEffect`**: Fetch data directly in Server Components using `async/await`.
-- **Deduplication**: `fetch` is auto-memoized.
-- **Waterfalls**: Use `Promise.all` for parallel fetching, or use `<Suspense>` for streaming.
-
-```tsx
-// ✅ GOOD: Streaming
-export default async function Page() {
-  return (
-    <Suspense fallback={<Skeleton />}>
-      <UserFeed /> {/* Fetches its own data */}
-    </Suspense>
-  );
-}
-```
-
-### 2. Server Actions instead of API Routes
-
-- Colocate mutations with the feature code.
-- Use `useFormStatus` for pending states.
-- Use `useOptimistic` for instant UI updates.
-
-### 3. Image Optimization
-
-- Required usage of `next/image`.
-- **sizes**: mandatory prop for responsive images. `sizes="(max-width: 768px) 100vw, 50vw"`.
-
-## 🧪 Testing
-
-- **Unit**: Vitest/Jest for logic.
-- **Integration**: React Testing Library for Client Components.
-- **E2E**: Playwright for full flows.

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
-```

package/.agent/workflows/workflow-rule-from-codebase.md

@@ -1,43 +0,0 @@
----
-description: Analyze the current codebase to generate a project context rule file.
----
-
-# Workflow: Generate Rule from Codebase
-
-Use this workflow to "learn" the project's existing patterns, stack, and conventions by scanning the codebase. This is useful when joining an existing project.
-
-## Step 1: Discovery Scan
-
-1.  **Read Configuration**: Check `package.json`, `tsconfig.json`, `drizzle.config.ts`, `wrangler.toml`, etc.
-2.  **Analyze Structure**: Run `list_dir` on root and `app/` or `src/` to understand the architecture.
-3.  **Sample Code**: Read 2-3 representative files (e.g., a component, an API route, a schema definition) to understand coding style (naming, exports, type usage).
-
-## Step 2: Synthesize Observations
-
-Identify key facts:
-
-- **Tech Stack**: Frameworks, ORMs, UI Libraries.
-- **Conventions**: File naming (kebab vs camel), Component structure, Data fetching patterns.
-- **Directories**: Where does code live? (e.g., `app/routes` vs `src/pages`).
-
-## Step 3: Create Project Rules
-
-Create a file named `.agent/rules/project-rules.md`.
-
-**Content Structure**:
-
-1.  **Project Overview**: One line summary.
-2.  **Tech Stack**: Bullet points of major tools.
-3.  **Key Conventions**: detailed "Do's and Don'ts".
-4.  **Architecture**: Brief explanation of folder structure.
-
-// turbo
-
-## Step 4: Write the File
-
-Use `write_to_file` to create `.agent/rules/project-rules.md`. If it exists, overwrite it with the fresh analysis.
-
-## Step 5: Validation
-
-1.  Check if the new rule aligns with `package.json` dependencies.
-2.  Notify the user that project context has been refreshed.

package/.agent/workflows/workflow-rule-from-feedback.md

@@ -1,38 +0,0 @@
----
-description: Create or update a project rule based on specific user feedback or corrections.
----
-
-# Workflow: Extract Rule from Feedback
-
-Use this workflow when the user provides explicit feedback about how they want the agent to behave, code preferences, or structural constraints (e.g., "Don't use library X", "Always name files Y").
-
-## Step 1: Analyze Feedback & Existing Rules
-
-1.  **Analyze the User's Request**: Identifying the constraint or preference. Is it a global preference or specific to a file type?
-2.  **Check Existing Rules**: Look in `.agent/rules/` to see if a conflicting or similar rule already exists.
-    - If it contradicts an existing rule, you will need to UPDATE the old rule.
-    - If it's new, you will CREATE a new rule.
-
-## Step 2: Determine Target Rule File
-
-Decide where this rule belongs:
-
-- **Default**: Update `.agent/rules/project-rules.md`. This is the central source of truth.
-- **Exception**: If the rule is extremely complex or requires a very specific glob pattern (e.g., specific to only `.css` files), create a dedicated file.
-
-## Step 3: Update Project Content
-
-1.  **Read**: Read `.agent/rules/project-rules.md`.
-2.  **Append/Update**: Add the new rule to the "Key Conventions" or "User Preferences" section.
-    - Format: `- **[Rule Name]**: [Description]`.
-3.  **Conflict Check**: Ensure it doesn't contradict existing lines.
-
-## Step 4: Write the File
-
-1.  Use `replace_file_content` (or `write_to_file` if creating new) to save the changes.
-2.  **Validation**: Ensure the file format remains valid markdown.
-
-## Step 5: Confirmation
-
-1.  Notify the user that the rule has been learned.
-2.  (Optional) If this feedback was given during a task, ask if you should re-run the previous step with the new rule applied.