@kienha/anti-chaotic 1.0.5 → 1.0.7

package/.agent/skills/rules-workflows/SKILL.md

@@ -16,172 +16,39 @@ This skill empowers the Agent to act as an **Autonomous Process Orchestrator**,
 
 Before creating any rule or workflow, the Agent MUST:
 
-1.  **Analyze the Goal**: What is the user trying to achieve? (e.g., "Add a feature", "Fix a bug").
-2.  **Orchestrate Capabilities**: Identify which _other_ skills (Frontend, Backend, QA) needed to execute the plan.
+1.  **Analyze the Goal**: What is the user trying to achieve?
+2.  **Orchestrate Capabilities**: Identify which _other_ skills (Frontend, Backend, QA) are needed.
+3.  **Separate Concerns**:
+    - **Workflows** = Process (Steps, Sequences)
+    - **Skills** = Knowledge (Standards, Implementation)
 
-### Design Principle: Separation of Concerns
+## 📚 Reference Library
 
-- **Workflows are Processes**: They define the sequence of steps (Step 1 -> Step 2).
-- **Workflows are NOT Knowledge**: They should NOT contain hardcoded rules (e.g., WCAG 2.1 ratios, specific library versions).
-- **Delegation**: Workflows must **delegate** to Skills/Roles for execution standards.
-  - ❌ Bad: `Step 3: Check accessibility using 4.5:1 contrast ratio.`
-  - ✅ Good: `Step 3: Verify accessibility compliance using [designer] skill.`
+This skill relies on specialized guides located in the `references/` directory. **You MUST consult these files for specific tasks.**
 
-## 📚 Resource Library
-
-### Guides & Templates (`references/`)
-
-- `rules-guide.md`: **Rule Creation Guide**. Contains templates for Always-On, Glob, Manual, and Model Decision rules.
-- `workflows-guide.md`: **Workflow Creation Guide**. Contains the standard Feature Implementation workflow template.
-
-### Workflows (`../../workflows/`)
-
-- `workflow-rule-from-feedback.md`: **Learn from User**. Use to enable persistent memory of user preferences.
-- `workflow-rule-from-codebase.md`: **Learn from Project**. Use to standardize behavior on existing codebases.
-
-### References (`references/`)
-
-- `orchestration-patterns.md`: **Skill Chaining**. Guides on how to sequence skills (e.g., PM -> Architect -> Dev).
+| Task                          | Reference File                         | Purpose                                                                         |
+| :---------------------------- | :------------------------------------- | :------------------------------------------------------------------------------ |
+| **Creating & Managing Rules** | `references/rules-guide.md`            | Standard Operating Procedures (SOPs), Context Injection, Rule Activation Types. |
+| **Building Workflows**        | `references/workflows-guide.md`        | High-Performance Workflow Design, "Turbo" Execution, Checkpoints.               |
+| **Orchestrating Skills**      | `references/orchestration-patterns.md` | Skill Chaining Patterns (e.g., Spec-First, TDD), Conflict Resolution.           |
 
 ---
 
-## 1. Rules: Shaping Context
-
-Rules are persistent instructions that guide _how_ the Agent thinks and acts. Workspace rules live in the `.agent/rules` folder.
-
-### Rule Activation Types
-
-At the rule level, you can define **how** a rule should be activated:
-
-| Type               | Trigger Value    | Description                                                          |
-| ------------------ | ---------------- | -------------------------------------------------------------------- |
-| **Manual**         | `manual`         | Activated via `@mention` in Agent's input box                        |
-| **Always On**      | `always_on`      | Always applied to every interaction                                  |
-| **Model Decision** | `model_decision` | Model decides based on natural language `description` in frontmatter |
-| **Glob**           | `glob`           | Applied to files matching the `glob` pattern (e.g., `src/**/*.tsx`)  |
-
-### Examples
-
-Refer to `references/rules-guide.md` for a comprehensive list of rule pattern examples and templates.
-
-### Creation Process
-
-1.  **Ask**: "What specific behaviors or constraints must be enforced?"
-2.  **Choose Activation Type**: Select the appropriate trigger based on when the rule should apply
-3.  **Draft**: Refer to templates in `references/rules-guide.md`.
-4.  **Refine**: Ensure rules are actionable (e.g., "Use Zod for input" vs "Write good code")
-
-### Best Practices
-
-- **Global vs Workspace**: Use valid paths (`~/.gemini/` for global, `.agent/rules/` for workspace)
-- **Activation Selection**:
-  - Use `always_on` for critical project constraints
-  - Use `glob` for file-type specific rules
-  - Use `model_decision` for context-aware rules with clear description
-  - Use `manual` for intensive operations (@mention to activate)
-- **Fail on Error**: Rule syntax is strict. A bad rule can break the Agent. Validate always.
-
----
-
-## 2. Workflows: Automating Process
-
-Workflows are structured "recipes" for complex tasks.
-
-### usage: The Agile Way
-
-Instead of generic "write code", use structured flows:
-
-> User: "Implement the login feature"
-
-**Agent Response (Internal Monologue):**
-
-1.  _Trigger_: `workflow-agile-feature.md`.
-2.  _Step 1 (PM)_: Analyze requirements for "Login".
-3.  _Step 2 (Arch)_: Design Auth schema in Supabase.
-4.  _Step 3 (Dev)_: Implement components.
-5.  _Step 4 (QA)_: Verify login flow.
+## 1. Orchestration Strategy
 
-### Creation Process
+**👉 For best practices on sequencing skills, refer to `references/orchestration-patterns.md`**.
 
-1.  **Map the Process**: Identify the roles and steps involved.
-2.  **Select Pattern**: Consult `references/orchestration-patterns.md`.
-3.  **Draft**: Refer to the template in `references/workflows-guide.md`.
+Key principles:
 
-## Workflow Design Standards
-
-Follow the "Feature Implementation" pattern (see `references/workflows-guide.md` for full template details):
-
-### 1. Header & Prereqs
-
-- **Description**: Clear, action-oriented.
-- **Rules**: Mandatory reference to global rules (e.g., `documentation.md`).
-- **Tool Guidelines**: A table defining _which_ tools (Antigravity native or MCP) to use, _when_, and with _what queries_.
-
-```markdown
-## Tool Usage Guidelines
-
-| Tool | When to Use | Example Query |
-| ---- | ----------- | ------------- |
-| ...  | ...         | ...           |
-```
-
-### 2. Step Structure
-
-Each step should be structured for maximum context and autonomy:
-
-1.  **Turbo Annotation**: `// turbo` if the step involves safe, auto-runnable commands.
-2.  **Tool Context**: `> 💡 **Tip**: ...` block to guide specific tool usage for this step.
-3.  **Skill Actions**: key functionality delegated to skills via `**Invoke [skill-name] skill**`.
-4.  **Artifacts**: Explicitly name output files.
-5.  **Checkpoints**: Explicit `**WAIT**` states for user confirmation.
-
-**Example Step:**
-
-```markdown
-## Step 1: Analyze Requirements
-
-// turbo
-
-> 💡 **Tip**: Use `sequential-thinking` (if available) or `read_file` to parse requirements.
-
-1. **Invoke [product-manager] skill** to refine the request.
-2. Create `requirements.md` artifact.
-3. **WAIT** for user confirmation.
-```
-
-### 3. Summary
-
-- **Quick Reference**: A table at the bottom tracking Step -> Skill -> Output.
+1.  **Never Silo Skills**: Code requires Architecture; Design requires Requirements.
+2.  **Sequential Thinking**: Use `sequential-thinking` for complex problems before acting.
+3.  **Process vs. Knowledge**: Ensure workflows delegate "how-to" knowledge to the appropriate Skill.
 
 ---
 
-## 3. Orchestration & Autonomy Rules
-
-### Rule 1: Cross-Skill Collaboration
-
-- **Never** silo skills. A "Code" task usually requires "Architect" input first.
-- **Always** check `reference/orchestration-patterns.md` for the correct sequence.
-
-### Rule 2: Sequential Thinking
-
-- **Mandatory** for: Debugging, Architecture Design, and Requirement Analysis.
-- **Usage**: Break down problems step-by-step _before_ writing code.
-
-### Rule 3: Strict Validation
-
-- Verify all generated rules/workflows against the official documentation.
-- If a workflow fails, **stop**, analyze step-by-step, and propose a fix.
-
-### Rule 4: Process vs Knowledge Separation
-
-- **Strict Enforcement**: When designing, Skills MUST contain Knowledge (Standards, Templates) and Workflows MUST contain Process (Steps, Sequences).
-- **No Overlap**: Never hardcode standards in a workflow. Never bury a lifecycle process in a skill.
-
-## 4. Self-Correction & Learning
-
-The Agent can now modify its own rules (Meta-Programming).
+## 2. Self-Correction & Learning
 
-### When to use
+The Agent can modify its own rules (Meta-Programming).
 
-- **User Correction**: "Don't do X anymore" -> Trigger `workflow-rule-from-feedback`.
-- **New Project**: "Read this codebase" -> Trigger `workflow-rule-from-codebase`.
+- **User Correction**: "Don't do X anymore" -> Trigger `workflow-rule-from-feedback.md`.
+- **New Project**: "Read this codebase" -> Trigger `workflow-rule-from-codebase.md`.

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

@@ -7,7 +7,7 @@ description: [End-to-end feature implementation workflow]
 Orchestrates feature implementation from specification to deployment.
 
 > [!IMPORTANT]
-> **MANDATORY**: Read `.agent/rules/documentation.md` before creating any document.
+> **MANDATORY**: Read `.agent/rules/documents.md` before creating any document.
 
 ---
 

package/.agent/skills/rules-workflows/references/orchestration-patterns.md

@@ -30,19 +30,17 @@ These patterns guide how to combine multiple specialized skills to solve complex
 1.  **Designer**: creating the look & feel, animations, and component structure.
 2.  **Dev**: Translates the design into React/CSS code.
 
-32:
-33: ## 4. The "Delegation" Pattern (Process vs Knowledge)
-34:
-35: **Best for**: Enforcing standards within workflows.
-36: **Sequence**: `Workflow` (Process) -> `Skill` (Knowledge).
-37:
-38: **Rule**: Workflows define _when_ to do something. Skills define _how_ to do it.
-39:
-40: - ❌ **Bad Workflow**: "Step 4: Check that contrast is 4.5:1." (Hardcoded)
-41: - ✅ **Good Workflow**: "Step 4: Verify accessibility using [designer] skill." (Delegated)
-42:
-43: ## 5. The "Reasoning" Bridge
-44:
+## 4. The "Delegation" Pattern (Process vs Knowledge)
+
+**Best for**: Enforcing standards within workflows.
+**Sequence**: `Workflow` (Process) -> `Skill` (Knowledge).
+
+**Rule**: Workflows define _when_ to do something. Skills define _how_ to do it.
+
+- ❌ **Bad Workflow**: "Step 4: Check that contrast is 4.5:1." (Hardcoded)
+- ✅ **Good Workflow**: "Step 4: Verify accessibility using [designer] skill." (Delegated)
+
+## 5. The "Reasoning" Bridge
 
 **Best for**: Ambiguity, complex debugging.
 **Approach**: Break down the problem step-by-step before switching skills.

package/.agent/skills/rules-workflows/references/rules-guide.md

@@ -1,60 +1,118 @@
-# Rules Creation Guide
+# High-Performance Rule Governance
 
-## Overview
+> "Rules are the automated guardrails that ensure consistency without micromanagement."
 
-Workspace rules live in the `.agent/rules` folder of your workspace or git root. Rules are persistent instructions that guide _how_ the Agent thinks and acts.
+This guide establishes the framework for defining, enforcing, and managing Agent behavior standards across the organization.
 
-## Creating Rules via UI
+## 1. The Core Philosophy
 
-1. Open **Customizations** panel via "..." dropdown in agent panel
-2. Navigate to **Rules** panel
-3. Select **+ Global** (cross-workspace) or **+ Workspace** (project-specific)
+In a high-functioning AI-driven organization, Rules serve two critical functions:
 
----
+1.  **Context Injection**: Instantly downloading "Senior Engineer" context into the Agent's specific session.
+2.  **Operational Guardrails**: Preventing known anti-patterns (e.g., "Never commit secrets", "Always use strict TS").
+
+| Level                 | Purpose                                | Example                    |
+| :-------------------- | :------------------------------------- | :------------------------- |
+| **L1: Critical**      | Security & Compliance (Non-negotiable) | `security-policy.md`       |
+| **L2: Architectural** | Tech Stack Standards                   | `nextjs-best-practices.md` |
+| **L3: Stylistic**     | Team preferences                       | `naming-conventions.md`    |
+
+## 2. Activation Strategy (Context Management)
+
+The key to a responsive Agent is _Selective Activation_. Loading 100 rules confuses the context. Use activation types strategically.
+
+### A. The "Always On" (Global Constitution)
+
+**Use sparingly.** Only for rules that apply to _every_ single keystroke.
+
+- **Triggers**: `always_on`
+- **Use Case**: Safety checks, Tone of Voice, Core Documentation links.
+- **Cost**: Consumes context window on every turn.
+
+### B. The "Just-in-Time" (Context-Aware)
+
+**The Gold Standard.** Rules that activate only when relevant.
+
+- **Triggers**: `model_decision` (based on description) or `glob` (based on files).
+- **Use Case**:
+  - If user asks about "Auth" -> Load `auth-guidelines.md`.
+  - If editing `.tsx` files -> Load `react-component-standards.md`.
+
+### C. The "Surgical" (Manual Override)
+
+**For heavy-duty tasks.**
+
+- **Triggers**: `manual`
+- **Use Case**: "Refactor this legacy code." -> User explicitly calls `@refactoring-rules`.
 
-## Rule Activation Types
+## 3. Designing Effective Rules
 
-At the rule level, you can define **how** a rule should be activated:
+A rule is a **Directive**, not a suggestion.
 
-| Type               | Description                                                                                                                     |
-| ------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
-| **Manual**         | The rule is manually activated via `@mention` in Agent's input box                                                              |
-| **Always On**      | The rule is always applied to every interaction                                                                                 |
-| **Model Decision** | Based on a natural language description of the rule, the model decides whether to apply the rule                                |
-| **Glob**           | Based on the glob pattern you define (e.g., `.js`, `src/**/*.ts`), the rule will be applied to all files that match the pattern |
+### ❌ Weak Rule
 
-### When to Use Each Type
+> "Try to write good variable names and maybe use TypeScript if you can."
 
-- **Manual**: For intensive operations like deep code reviews, refactoring strategies, or specialized analysis that shouldn't run automatically
-- **Always On**: For critical project constraints, coding standards, and domain knowledge that must be enforced on every interaction
-- **Model Decision**: For context-aware rules that should only apply when relevant (e.g., security guidelines only when working with auth)
-- **Glob**: For file-type-specific standards (e.g., React component standards for `.tsx` files)
+### ✅ Strong Rule
 
+> **Constraint**: All variables MUST follow `camelCase`.
+> **Requirement**: TypeScript `strict` mode is MANDATORY. `any` type is strictly FORBIDDEN.
+
+## 4. Governance & Lifecycle
+
+Avoid "Rule Bloat" (Bureaucracy).
+
+1.  **Consolidate**: Don't have `button-rules.md` and `input-rules.md`. Have `ui-components.md`.
+2.  **Review**: If the Agent frequently ignores a rule, it is likely too vague or conflicting. Clarify or Delete it.
+3.  **Hierarchy**: Workspace Rules override Global Rules. Specific Rules override General Rules.
+
+## 5. Standard Rule Template
+
+Use this structure to create enforceable, high-clarity rules.
+
+```markdown
+---
+description:
+  [When should this apply? e.g., "Applied when editing Database Schema"]
+globs: ["prisma/schema.prisma"]
 ---
 
-## Rule File Templates
+# [Rule Name, e.g., Database Schema Standards]
+
+## 1. Executive Summary
+
+All database changes must preserve backward compatibility and follow 3NF normalization.
+
+## 2. Critical Constraints (The "Musts")
+
+- 🔴 **NEVER** delete columns in a migration. Mark as `@deprecated` instead.
+- 🔴 **NEVER** use `autoincrement()` for publicly exposed IDs. Use `uuid()`.
+
+## 3. Code Patterns (The "How")
+
+### Naming
 
-Templates are available in the `../assets/` directory:
+- Tables: `snake_case` (plural), e.g., `users`, `order_items`.
+- Foreign Keys: `noun_id`, e.g., `user_id`.
 
-- **Always-On Rule**: `../assets/rule-always-on.md`
-- **Model-Decision Rule**: `../assets/rule-model-decision.md`
-- **Glob-Pattern Rule**: `../assets/rule-glob.md`
-- **Manual Rule**: `../assets/rule-manual.md`
+### Example
 
-Use these templates as a starting point for creating new rules.
+✅ **Good**:
+model User {
+id String @id @default(uuid())
+}
 
-## Best Practices
+❌ **Bad**:
+model User {
+id Int @id @default(autoincrement())
+}
+```
 
-1. **Keep rules focused** - One concern per rule file
-2. **Use descriptive names** - Rule filename becomes its identifier
-3. **Leverage glob patterns** - Auto-apply rules to relevant files
-4. **Reference external files** - Use `@filename` to include context
-5. **Stay under 12,000 chars** - Split into multiple files if needed
+## 6. Advanced Context Injection
 
-## @ Mentions Syntax
+You can "hydrate" rules with dynamic context using `@` references.
 
-Reference files in rules:
+- **`@/docs/api-spec.md`**: "Enforce the API contract defined in this file."
+- **`@../shared/types.ts`**: "Use these exact types."
 
-- `@schema.prisma` - Relative to rules file
-- `@/docs/api.md` - Absolute from workspace root
-- `@../shared/types.ts` - Relative path traversal
+This allows the rule to remain static (the _policy_) while referencing dynamic content (the _data_).

package/.agent/skills/rules-workflows/references/workflows-guide.md

@@ -1,46 +1,123 @@
-# Workflows Creation Guide
+# Building High-Performance Workflows
 
-## Creating Workflows via UI
+> "Workflows are the operating system of your delivery pipeline."
 
-1. Open **Customizations** panel via "..." dropdown in agent panel
-2. Navigate to **Workflows** panel
-3. Click **+ Global** or **+ Workspace** to create workflow
+This guide is designed for Project Managers, COOs, and Architects to codify operational excellence into executable Agent processes.
 
-## Workflow File Template
+## 1. The Core Philosophy
 
-A basic workflow template is available in `../assets/workflow-basic.md`.
+Effective workflows shift the Agent from "Ad-hoc Assistant" to "Autonomous Operator".
 
-This template serves as a comprehensive guide for structuring workflows, including tool usage, step definitions, and referencing other skills.
+| Ad-hoc Request          | Systematized Workflow                                             |
+| :---------------------- | :---------------------------------------------------------------- |
+| "Help me test this."    | **Run `/qa-feature`**: Analyze -> Test Plan -> Execute -> Report. |
+| "Deploy this."          | **Run `/deploy`**: Lint -> Build -> Test -> Staging -> Prod.      |
+| **High Cognitive Load** | **Zero Cognitive Load**                                           |
 
-## Calling Other Workflows
+## 2. Anatomy of an Effective Workflow
 
-Chain workflows together:
+A workflow is not just a list of steps. It is a **Contract of Execution**.
+
+### Key Components
+
+1.  **The Trigger**: Explicit starting condition (User request, file change, manual invocation).
+2.  **The Context**: Loading necessary rules (`rules/documents.md`) and skills (`[product-manager]`).
+3.  **The Process**: Sequential steps with explicit hand-offs.
+4.  **The Verification**: Mandatory checkpoints to prevent error propagation.
+
+## 3. Designing for Efficiency (The "COO Mindset")
+
+To build workflows that work at scale, apply these principles:
+
+### A. Principle of Delegation (Process vs. Skill)
+
+**Never hardcode specific technical knowledge in a workflow.**
+
+- ❌ **Fragile**: "Step 1: Run `npm install react@18`."
+- ✅ **Robust**: "Step 1: Install dependencies using standard practices defined in `[frontend-developer]` skill."
+
+### B. Principle of "Turbo" execution
+
+**Optimize for speed where safety allows.**
+Use the `// turbo` annotation for steps that are read-only or safe to retry. This allows the Agent to execute without stopping for approval.
+
+- **Use for**: Reading files, generating docs, running local tests.
+- **Avoid for**: Deleting files, pushing to production, external API calls with costs.
+
+### C. Principle of "Stop-the-Line" (Checkpoints)
+
+**Fail early, fail loudly.**
+Insert `**WAIT**` steps after critical actions (e.g., after Requirement Analysis, before Deployment). This is your quality gate.
+
+## 4. Structural Template
+
+Use this structure for all production-grade workflows:
+
+```markdown
+---
+description:
+  [Action-oriented description, e.g., "End-to-end Feature Implementation"]
+---
+
+# [Workflow Name]
+
+## 1. Initialization
+
+1. Load Global Rules: `documents.md`.
+2. Analyze Context: Identify touched files.
+
+## 2. Phase I: Definition (The "PM" Phase)
+
+> 💡 **Tip**: Clarify before coding.
+
+1. Invoke **[product-manager]** to refine requirements.
+   // turbo
+2. Create `docs/specs/feature-x.md`.
+3. **WAIT** for user approval.
+
+## 3. Phase II: Execution (The "Dev" Phase)
+
+1. Read `docs/specs/feature-x.md`.
+2. Invoke **[lead-architect]** to update `implementation-plan.md`.
+3. Invoke **[backend-developer]** for API changes.
+4. Invoke **[frontend-developer]** for UI changes.
+
+## 4. Phase III: Verification (The "QA" Phase)
+
+1. Invoke **[qa-tester]** to run test suite.
+2. Verify all tests pass.
+```
+
+## 5. Advanced Orchestration Patterns
+
+### Chaining Workflows
+
+Don't build monoliths. Compose small, focused workflows.
 
 ```markdown
-## Step 4: Deploy
+## Step 5: Deployment
 
 Call /deploy-staging
 ```
 
-## Agent-Generated Workflows
+### Dynamic Branching (via Logic)
 
-After performing a task manually, ask agent to formalize it:
+Workflows are linear, but the _Agent_ is dynamic. Use logic in steps:
 
-> "Create a workflow from our conversation about deploying to production"
+```markdown
+## Step 2: Determine Path
 
-## Workflow Design Principles
+IF requirements are unclear:
 
-When creating new workflows, strictly follow **"Workflow = Process"**:
+- Call [business-analysis]
+  ELSE:
+- Proceed to Step 3
+```
 
-1.  **Sequence over Standards**: Define _what_ to do and _when_, but delegate _how_ to Skills.
-2.  **Refer to roles**: Use "As [Role]" or "Call [Skill]" instead of hardcoding instructions.
-3.  **Dynamic References**:
-    - ❌ `Ensure indentation is 2 spaces.` (Hardcoded knowledge)
-    - ✅ `Format code according to project standards defined in [frontend-developer] skill.` (Dynamic reference)
+## 6. Maintenance & KPI
 
-## Best Practices
+Treat workflows like products.
 
-1. **Clear step names** - Describe the action in step title
-2. **Atomic steps** - One logical action per step
-3. **Include verification** - Add steps to confirm success
-4. **Document prerequisites** - State what's needed before running
+- **Review**: Does the workflow still match how the team works?
+- **Optimize**: Are we stopping too often? (Add `// turbo`). Are we breaking things? (Add Checkpoints).
+- **Refactor**: If a workflow steps become too complex, extract them into a dedicated Skill or a Sub-workflow.

package/.agent/workflows/bootstrap.md

@@ -0,0 +1,96 @@
+---
+description: Sets up project structure, installs dependencies, and configures environment based on architectural specs.
+---
+
+# Bootstrap Workflow
+
+> [!IMPORTANT]
+> **Prerequisite**: Ensure SDD exists in `docs/030-Specs/Architecture/`.
+
+---
+
+## MCP Usage Guidelines
+
+| MCP Tool                          | When to Use                        |
+| :-------------------------------- | :--------------------------------- |
+| `mcp_context7_resolve-library-id` | Find correct package names         |
+| `mcp_context7_query-docs`         | Research installation/config steps |
+
+---
+
+## Step 1: Framework Initialization & Structure
+
+// turbo
+
+1. **Invoke `[lead-architect]` skill** to:
+   - Define the project root structure (Monorepo vs Polyrepo)
+   - Initialize the base project (e.g., `git init`, `npx create-next-app`)
+   - Create the directory skeleton based on SDD
+2. **WAIT** for initialization
+
+---
+
+## Step 2: Maintenance & Quality Engineering Tools
+
+// turbo
+
+> 💡 **Role**: DevOps Engineer ensures the "Development Experience" (DX) is solid.
+
+1. **Invoke `[devops-engineer]` skill** to install & configure:
+   - **Quality Tools**: ESLint, Prettier, TypeScript config
+   - **Git Hooks**: Husky, Lint-staged, Commitlint
+   - **CI/CD**: Github Actions (basic build/test)
+2. Verify: Run `npm run lint` and ensure hooks fire on commit.
+
+---
+
+## Step 3: Frontend Setup
+
+// turbo
+
+> 💡 **Role**: Frontend Developer manages the UI/Client side.
+
+1. **Invoke `[frontend-developer]` skill** to:
+   - **UI Ecosystem**: Install TailwindCSS, Radix/Shadcn, Framer Motion
+   - **State Manager**: Zustand/Jotai/Redux
+   - **Structure**: Setup `src/components`, `src/hooks`, `src/pages` (or `app`)
+   - **Assets**: Configure font loaders, image optimization
+2. **WAIT** for installation
+
+---
+
+## Step 4: Backend Setup
+
+// turbo
+
+> 💡 **Role**: Backend Developer manages the Data/Server side.
+
+1. **Invoke `[backend-developer]` skill** to:
+   - **Database**: Setup Prisma/Drizzle/Supabase client
+   - **API**: Configure API routes/Server Actions
+   - **Validation**: Install Zod/Valibot
+   - **Environment**: Create `.env.example` and validate `.env` keys
+2. **WAIT** for installation
+
+---
+
+## Step 5: Final Validation
+
+// turbo
+
+1. **Invoke `[devops-engineer]` skill** to:
+   - Run full build `npm run build`
+   - Test Type-checking `tsc --noEmit`
+2. **Invoke `[product-manager]`** to update Roadmap status to "In Progress"
+
+---
+
+## Quick Reference
+
+| Step | Skill              | Action                      |
+| :--- | :----------------- | :-------------------------- |
+| 1    | lead-architect     | Init Framework & Structure  |
+| 2    | devops-engineer    | Husky, Linter, CI/CD        |
+| 3    | frontend-developer | Tailwind, Components, State |
+| 4    | backend-developer  | DB, API, Env                |
+| 5    | devops-engineer    | Final Build Check           |