@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

package/template/.agents/skills/prompt-addons/SKILL.md

@@ -1,99 +1,99 @@
----
-name: prompt-addons
-description: Routes external prompt families into DevFlow 2.0 workflows, specialist agents, or thin skill aliases. Use when deciding whether a prompt-inspired behavior should become a mainline workflow, a companion command, a reusable skill, or remain legacy-only.
----
-
-# Prompt Addons
-
-Use this skill when adapting outside prompt patterns into the DevFlow 2.0 system.
-
-## Core Rule
-
-Adapt intent, not old output contracts.
-
-DevFlow 2.0 uses a stage-based, markdown-first model:
-
-1. Mainline workflow stays minimal and ordered
-2. Companion commands exist for non-mainline help
-3. Specialist agents and skills handle reusable methods
-4. JSON-first orchestration is legacy and should not define new architecture
-
-## Mainline Routing
-
-| Need | Route to |
-| :--- | :--- |
-| Explore problem space | `/00-Discover` |
-| Clarify goal, scope, decisions | `/10-Define` |
-| Lock delivery contract | `/20-Spec` |
-| Break into execution plan | `/30-Plan` |
-| Build the change | `/40-Implement` |
-| Validate quality and evidence | `/50-Verify` |
-| Package release-ready outcome | `/70-Release` |
-| Summarize the full run | `/60-Report` |
-
-## Companion Command Routing
-
-| Command | Use when | Typical stage pairing |
-| :--- | :--- | :--- |
-| `Brainstorm` | โจทย์ยังไม่นิ่ง ต้องคิดทางเลือกก่อน lock | Discover, Define |
-| `Research` | ต้องหาหลักฐานหรือข้อมูลเพิ่ม | Discover, Define, Spec, Verify |
-| `Debug` | งานผิดปกติ ต้องหา root cause | Implement, Verify |
-| `Preview` | ต้องตรวจชิ้นงานระหว่างทาง | Implement, Verify |
-| `Wiki` | ต้องสกัดความรู้ reusable | Verify, Release, Report |
-| `Help` | ผู้ใช้ไม่แน่ใจว่าจะเริ่มตรงไหน | ก่อนเข้า stage หรือระหว่างทาง |
-
-## Classification Rule
-
-ก่อนสร้าง workflow ใหม่ ให้จัดประเภทก่อน:
-
-1. ถ้า intent เปลี่ยน stage ของงาน ให้ route เข้าสู่ mainline stage ที่มีอยู่
-2. ถ้าเป็นวิธีทำงานที่ใช้ซ้ำหลาย stage ให้เป็น skill
-3. ถ้าเป็นความเชี่ยวชาญเฉพาะด้าน ให้เป็น agent
-4. ถ้าเป็นแค่ตัวช่วยคิดหรือหาหลักฐานระหว่างทาง ให้เป็น companion command
-5. ถ้าอิง dashboard/json orchestration เดิมเป็นหลัก ให้คงไว้เป็น legacy หรือ migration note
-
-## Prompt Family Routing
-
-| Family | DevFlow 2.0 route | Keep as |
-| :--- | :--- | :--- |
-| Spec | `/10-Define`, `/20-Spec`, `/30-Plan` | workflow + `requirements-engineer` |
-| Complexity | `/10-Define`, `/30-Plan` | workflow content, not standalone mainline |
-| Roadmap | Discover/Define adjacent | skill or optional workflow outside core line |
-| Ideation | `Brainstorm`, `Research` | companion command |
-| Competitor | `Research` during Discover/Define | companion command or research skill |
-| Insight | `Wiki`, `/60-Report` | companion command + report content |
-| Coder | `/40-Implement` | workflow + specialist agents |
-| QA | `/50-Verify` | workflow + QA/test skills |
-| Follow-up | `/10-Define` or `/30-Plan` ของรอบใหม่ | stage reuse, not separate numbered mainline |
-| GitHub review | `/50-Verify`, `/70-Release` | workflow/agent support |
-| MCP tool validation | `/50-Verify` | tool-specific verification skill |
-
-## Borderline Rules
-
-| Idea | Route | Keep as | Rule |
-| :--- | :--- | :--- | :--- |
-| Validation fixer | `/50-Verify` แล้วค่อยย้อน `/40-Implement` ถ้าต้องแก้โค้ด | thin skill/process note | ให้ verification ชี้ failure ก่อนเสมอ |
-| Documentation ideation | `Brainstorm`, `Wiki`, `/60-Report` | skill-backed support | ไม่ต้องเปิด mainline ใหม่ |
-| Performance ideation | `/50-Verify` หรือ `/40-Implement` เมื่อมีหลักฐาน | specialist skill/agent | ต้องมี measurement |
-| Security ideation | `/50-Verify` หรือ `Debug` เมื่อมี incident symptom | specialist skill/agent | treat as finding-first |
-| Follow-up planning | `/10-Define` -> `/20-Spec` -> `/30-Plan` ของรอบใหม่ | mainline reuse | ไม่แยก workflow หมายเลขใหม่ |
-| Legacy dashboard orchestration | legacy note only | migration-only | ไม่ใช้เป็นแบบตั้งต้นของ DevFlow 2.0 |
-
-## Follow-Up Planning
-
-เมื่อผู้ใช้ต้องการต่อยอดงานเดิม:
-
-1. อ่าน stage artifacts ที่มีอยู่ของ running ID เดิม
-2. ระบุให้ชัดว่าอะไร lock แล้ว และอะไรจะเพิ่มใหม่
-3. เริ่มรอบใหม่จาก `/10-Define` ถ้าโจทย์เปลี่ยน หรือ `/30-Plan` ถ้า spec ยังใช้ได้
-4. ใช้ไฟล์ `.md` ของ stage ใหม่เป็นหลักในการบันทึกบริบท
-
-## Output Principle
-
-เมื่อ prompt family ถูกแปลงเข้าระบบ:
-
-1. อย่า copy contract เดิมเข้ามาตรง ๆ
-2. แปลงให้สอดคล้องกับ numbering rule ของ DevFlow 2.0
-3. อย่าทำให้ผู้ใช้ต้องเดาเลขย้อนกลับ
-4. ให้ mainline มีเฉพาะ state ของงาน
-5. ให้ความสามารถเสริมไปอยู่ใน skill, agent, หรือ companion command ตามความเหมาะสม
+---
+name: prompt-addons
+description: Routes external prompt families into DevFlow 2.0 workflows, specialist agents, or thin skill aliases. Use when deciding whether a prompt-inspired behavior should become a mainline workflow, a companion command, a reusable skill, or remain legacy-only.
+---
+
+# Prompt Addons
+
+Use this skill when adapting outside prompt patterns into the DevFlow 2.0 system.
+
+## Core Rule
+
+Adapt intent, not old output contracts.
+
+DevFlow 2.0 uses a stage-based, markdown-first model:
+
+1. Mainline workflow stays minimal and ordered
+2. Companion commands exist for non-mainline help
+3. Specialist agents and skills handle reusable methods
+4. JSON-first orchestration is legacy and should not define new architecture
+
+## Mainline Routing
+
+| Need | Route to |
+| :--- | :--- |
+| Explore problem space | `/00-Discover` |
+| Clarify goal, scope, decisions | `/10-Define` |
+| Lock delivery contract | `/20-Spec` |
+| Break into execution plan | `/30-Plan` |
+| Build the change | `/40-Implement` |
+| Validate quality and evidence | `/50-Verify` |
+| Package release-ready outcome | `/70-Release` |
+| Summarize the full run | `/60-Report` |
+
+## Companion Command Routing
+
+| Command | Use when | Typical stage pairing |
+| :--- | :--- | :--- |
+| `Brainstorm` | โจทย์ยังไม่นิ่ง ต้องคิดทางเลือกก่อน lock | Discover, Define |
+| `Research` | ต้องหาหลักฐานหรือข้อมูลเพิ่ม | Discover, Define, Spec, Verify |
+| `Debug` | งานผิดปกติ ต้องหา root cause | Implement, Verify |
+| `Preview` | ต้องตรวจชิ้นงานระหว่างทาง | Implement, Verify |
+| `Wiki` | ต้องสกัดความรู้ reusable | Verify, Release, Report |
+| `Help` | ผู้ใช้ไม่แน่ใจว่าจะเริ่มตรงไหน | ก่อนเข้า stage หรือระหว่างทาง |
+
+## Classification Rule
+
+ก่อนสร้าง workflow ใหม่ ให้จัดประเภทก่อน:
+
+1. ถ้า intent เปลี่ยน stage ของงาน ให้ route เข้าสู่ mainline stage ที่มีอยู่
+2. ถ้าเป็นวิธีทำงานที่ใช้ซ้ำหลาย stage ให้เป็น skill
+3. ถ้าเป็นความเชี่ยวชาญเฉพาะด้าน ให้เป็น agent
+4. ถ้าเป็นแค่ตัวช่วยคิดหรือหาหลักฐานระหว่างทาง ให้เป็น companion command
+5. ถ้าอิง dashboard/json orchestration เดิมเป็นหลัก ให้คงไว้เป็น legacy หรือ migration note
+
+## Prompt Family Routing
+
+| Family | DevFlow 2.0 route | Keep as |
+| :--- | :--- | :--- |
+| Spec | `/10-Define`, `/20-Spec`, `/30-Plan` | workflow + `requirements-engineer` |
+| Complexity | `/10-Define`, `/30-Plan` | workflow content, not standalone mainline |
+| Roadmap | Discover/Define adjacent | skill or optional workflow outside core line |
+| Ideation | `Brainstorm`, `Research` | companion command |
+| Competitor | `Research` during Discover/Define | companion command or research skill |
+| Insight | `Wiki`, `/60-Report` | companion command + report content |
+| Coder | `/40-Implement` | workflow + specialist agents |
+| QA | `/50-Verify` | workflow + QA/test skills |
+| Follow-up | `/10-Define` or `/30-Plan` ของรอบใหม่ | stage reuse, not separate numbered mainline |
+| GitHub review | `/50-Verify`, `/70-Release` | workflow/agent support |
+| MCP tool validation | `/50-Verify` | tool-specific verification skill |
+
+## Borderline Rules
+
+| Idea | Route | Keep as | Rule |
+| :--- | :--- | :--- | :--- |
+| Validation fixer | `/50-Verify` แล้วค่อยย้อน `/40-Implement` ถ้าต้องแก้โค้ด | thin skill/process note | ให้ verification ชี้ failure ก่อนเสมอ |
+| Documentation ideation | `Brainstorm`, `Wiki`, `/60-Report` | skill-backed support | ไม่ต้องเปิด mainline ใหม่ |
+| Performance ideation | `/50-Verify` หรือ `/40-Implement` เมื่อมีหลักฐาน | specialist skill/agent | ต้องมี measurement |
+| Security ideation | `/50-Verify` หรือ `Debug` เมื่อมี incident symptom | specialist skill/agent | treat as finding-first |
+| Follow-up planning | `/10-Define` -> `/20-Spec` -> `/30-Plan` ของรอบใหม่ | mainline reuse | ไม่แยก workflow หมายเลขใหม่ |
+| Legacy dashboard orchestration | legacy note only | migration-only | ไม่ใช้เป็นแบบตั้งต้นของ DevFlow 2.0 |
+
+## Follow-Up Planning
+
+เมื่อผู้ใช้ต้องการต่อยอดงานเดิม:
+
+1. อ่าน stage artifacts ที่มีอยู่ของ running ID เดิม
+2. ระบุให้ชัดว่าอะไร lock แล้ว และอะไรจะเพิ่มใหม่
+3. เริ่มรอบใหม่จาก `/10-Define` ถ้าโจทย์เปลี่ยน หรือ `/30-Plan` ถ้า spec ยังใช้ได้
+4. ใช้ไฟล์ `.md` ของ stage ใหม่เป็นหลักในการบันทึกบริบท
+
+## Output Principle
+
+เมื่อ prompt family ถูกแปลงเข้าระบบ:
+
+1. อย่า copy contract เดิมเข้ามาตรง ๆ
+2. แปลงให้สอดคล้องกับ numbering rule ของ DevFlow 2.0
+3. อย่าทำให้ผู้ใช้ต้องเดาเลขย้อนกลับ
+4. ให้ mainline มีเฉพาะ state ของงาน
+5. ให้ความสามารถเสริมไปอยู่ใน skill, agent, หรือ companion command ตามความเหมาะสม

package/template/.agents/skills/prp-dev-fastapi/SKILL.md

@@ -1,114 +1,114 @@
----
-name: prp-dev-fastapi
-description: Comprehensive skill for FastAPI development following the PRP Pure Agentic workflow. Includes project templates, async/await patterns, Pydantic validation, repository/service architecture, and automated validation loops. Use when designing, implementation, or refactoring FastAPI applications.
----
-
-# 🚀 PRP Dev – FastAPI (Pure Agentic)
-
-This Skill operates to assist the AI Agent in systematically developing features for **FastAPI** following the PRP Framework standards, focusing on Architectural correctness, clean code, and automated Validation Loops.
-
-## 🎯 Scope of Work
-Apply this Skill when:
-- **Design**: Designing the API structure or Database Schema.
-- **Implementation**: Writing FastAPI code, Pydantic Models, or the Service Layer.
-- **Refactor**: Revamping legacy code for better organization or full Async compatibility.
-- **Workflow**: When engaging in tasks related to Backend APIs (spanning from planning to Verify).
-
----
-
-## 1. 🔍 Platform & Stack Detection
-Always ascertain the environment prior to starting work:
-1. **Indicators**: Locate `FastAPI` in `main.py`, `requirements.txt`, or through `@app.get()` decorators.
-2. **Database/ORM**: Identify the utilization of `SQLAlchemy` (Async/Sync), `SQLModel`, or `Tortoise`.
-3. **Pydantic**: Confirm whether Version 1.x or 2.x is used (to guarantee proper Syntax).
-4. **Project Type**: Examine if the structure is Monolithic (Small) or Modular (Production-Ready).
-
----
-
-## 2. 🏗️ Architecture & Organization
-Adhere to a Production-Ready architecture (strive to avoid files exceeding 500 lines):
-
-```text
-app/
-├── api/                    # API route handlers
-├── core/                   # config, security, database setup
-├── models/                 # Database models (ORM)
-├── schemas/                # Pydantic schemas (Request/Response)
-├── services/               # Business logic layer
-├── repositories/           # Data access layer (CRUD)
-├── utils/                  # Utility functions
-└── main.py                 # Application entry
-```
-
-### Naming Conventions
-- **Files**: `snake_case` (e.g., `auth_service.py`)
-- **Classes**: `PascalCase` (e.g., `UserUpdate`)
-- **Functions**: `snake_case` (e.g., `get_active_users`)
-- **Endpoints**: `kebab-case` (e.g., `/api/v1/user-profiles`)
-
----
-
-## 3. 🛡️ Implementation Patterns (Best Practices)
-
-### 3.1 Async All The Way
-- Employ `async def` consistently for Endpoints.
-- Utilize `await` for all I/O operations (Database, API Call, File System).
-- **Prohibited**: Using Blocking code inside an Async function (e.g., `time.sleep`, `requests.get`). Employ `asyncio.sleep` or `httpx` instead.
-
-### 3.2 Dependency Injection (FastAPI `Depends`)
-Use `Depends` for managing Shared resources:
-```python
-@router.post("/", response_model=Item)
-async def create_item(
-    item_in: ItemCreate,
-    db: AsyncSession = Depends(get_db),
-    current_user: User = Depends(get_current_user)
-):
-    return await service.create(db, obj_in=item_in, user=current_user)
-```
-
-### 3.3 CRUD Repository Pattern
-Segregate Data management Logic from Business Logic:
-```python
-# repositories/base.py
-class BaseRepository(Generic[ModelType, CreateSchema, UpdateSchema]):
-    async def get(self, db: AsyncSession, id: Any) -> Optional[ModelType]:
-        result = await db.execute(select(self.model).where(self.model.id == id))
-        return result.scalars().first()
-```
-
----
-
-## 4. 🔄 PRP Workflow Integration (Pure Agentic)
-For each Task, the Agent must adhere to these principles:
-
-### Phase: Planning (/30-Plan)
-- Designate the files to be created/modified in the `File & Directory Index`.
-- Formulate a comprehensive `Validation Loop`:
-    - **Step 1**: Lint & Type Check (`ruff`, `mypy`)
-    - **Step 2**: Unit Test (`pytest`)
-    - **Step 3**: Integration Test (Start the server and `curl` or use `httpx`)
-
-### Phase: Implement (/40-Implement)
-- Proceed with subtasks sequentially and update `implement.md` as the primary progress record.
-- When producing a new Endpoint, consistently generate the corresponding Pydantic Schema and Test simultaneously.
-
-### Phase: Verify (/50-Verify)
-- Execute all commands outlined in the `Validation Loop`.
-- Should an Error emerge, the AI must diagnose and rectify it promptly (Fix-Forward).
-
----
-
-## 🧪 Testing & Validation
-- **Framework**: Utilize `pytest` alongside `pytest-asyncio`.
-- **Mocking**: Adopt `unittest.mock` or `pytest-mock` for External services.
-- **Async Client**: Use `httpx.AsyncClient` to dispatch Requests to FastAPI.
-- **Evidence**: Document passed outcomes in `verify.md` as the primary verification record.
-
----
-
-## ⚡ Quick Reference: Common Gotchas
-- **Pydantic v2**: Employ `model_dump()` instead of `dict()` and `model_validate()` rather than `from_orm()`.
-- **SQLAlchemy Async**: Necessitates the `postgresql+asyncpg://` schema and requires `await session.commit()`.
-- **FastAPI Middleware**: Be cautious regarding the insertion sequence of Middleware (CORS should commonly be near the end or customized based on Auth requirements).
-- **Token Efficiency**: Should a file grow excessively long, propose Module Splitting as early as the Planning phase.
+---
+name: prp-dev-fastapi
+description: Comprehensive skill for FastAPI development following the PRP Pure Agentic workflow. Includes project templates, async/await patterns, Pydantic validation, repository/service architecture, and automated validation loops. Use when designing, implementation, or refactoring FastAPI applications.
+---
+
+# 🚀 PRP Dev – FastAPI (Pure Agentic)
+
+This Skill operates to assist the AI Agent in systematically developing features for **FastAPI** following the PRP Framework standards, focusing on Architectural correctness, clean code, and automated Validation Loops.
+
+## 🎯 Scope of Work
+Apply this Skill when:
+- **Design**: Designing the API structure or Database Schema.
+- **Implementation**: Writing FastAPI code, Pydantic Models, or the Service Layer.
+- **Refactor**: Revamping legacy code for better organization or full Async compatibility.
+- **Workflow**: When engaging in tasks related to Backend APIs (spanning from planning to Verify).
+
+---
+
+## 1. 🔍 Platform & Stack Detection
+Always ascertain the environment prior to starting work:
+1. **Indicators**: Locate `FastAPI` in `main.py`, `requirements.txt`, or through `@app.get()` decorators.
+2. **Database/ORM**: Identify the utilization of `SQLAlchemy` (Async/Sync), `SQLModel`, or `Tortoise`.
+3. **Pydantic**: Confirm whether Version 1.x or 2.x is used (to guarantee proper Syntax).
+4. **Project Type**: Examine if the structure is Monolithic (Small) or Modular (Production-Ready).
+
+---
+
+## 2. 🏗️ Architecture & Organization
+Adhere to a Production-Ready architecture (strive to avoid files exceeding 500 lines):
+
+```text
+app/
+├── api/                    # API route handlers
+├── core/                   # config, security, database setup
+├── models/                 # Database models (ORM)
+├── schemas/                # Pydantic schemas (Request/Response)
+├── services/               # Business logic layer
+├── repositories/           # Data access layer (CRUD)
+├── utils/                  # Utility functions
+└── main.py                 # Application entry
+```
+
+### Naming Conventions
+- **Files**: `snake_case` (e.g., `auth_service.py`)
+- **Classes**: `PascalCase` (e.g., `UserUpdate`)
+- **Functions**: `snake_case` (e.g., `get_active_users`)
+- **Endpoints**: `kebab-case` (e.g., `/api/v1/user-profiles`)
+
+---
+
+## 3. 🛡️ Implementation Patterns (Best Practices)
+
+### 3.1 Async All The Way
+- Employ `async def` consistently for Endpoints.
+- Utilize `await` for all I/O operations (Database, API Call, File System).
+- **Prohibited**: Using Blocking code inside an Async function (e.g., `time.sleep`, `requests.get`). Employ `asyncio.sleep` or `httpx` instead.
+
+### 3.2 Dependency Injection (FastAPI `Depends`)
+Use `Depends` for managing Shared resources:
+```python
+@router.post("/", response_model=Item)
+async def create_item(
+    item_in: ItemCreate,
+    db: AsyncSession = Depends(get_db),
+    current_user: User = Depends(get_current_user)
+):
+    return await service.create(db, obj_in=item_in, user=current_user)
+```
+
+### 3.3 CRUD Repository Pattern
+Segregate Data management Logic from Business Logic:
+```python
+# repositories/base.py
+class BaseRepository(Generic[ModelType, CreateSchema, UpdateSchema]):
+    async def get(self, db: AsyncSession, id: Any) -> Optional[ModelType]:
+        result = await db.execute(select(self.model).where(self.model.id == id))
+        return result.scalars().first()
+```
+
+---
+
+## 4. 🔄 PRP Workflow Integration (Pure Agentic)
+For each Task, the Agent must adhere to these principles:
+
+### Phase: Planning (/30-Plan)
+- Designate the files to be created/modified in the `File & Directory Index`.
+- Formulate a comprehensive `Validation Loop`:
+    - **Step 1**: Lint & Type Check (`ruff`, `mypy`)
+    - **Step 2**: Unit Test (`pytest`)
+    - **Step 3**: Integration Test (Start the server and `curl` or use `httpx`)
+
+### Phase: Implement (/40-Implement)
+- Proceed with subtasks sequentially and update `implement.md` as the primary progress record.
+- When producing a new Endpoint, consistently generate the corresponding Pydantic Schema and Test simultaneously.
+
+### Phase: Verify (/50-Verify)
+- Execute all commands outlined in the `Validation Loop`.
+- Should an Error emerge, the AI must diagnose and rectify it promptly (Fix-Forward).
+
+---
+
+## 🧪 Testing & Validation
+- **Framework**: Utilize `pytest` alongside `pytest-asyncio`.
+- **Mocking**: Adopt `unittest.mock` or `pytest-mock` for External services.
+- **Async Client**: Use `httpx.AsyncClient` to dispatch Requests to FastAPI.
+- **Evidence**: Document passed outcomes in `verify.md` as the primary verification record.
+
+---
+
+## ⚡ Quick Reference: Common Gotchas
+- **Pydantic v2**: Employ `model_dump()` instead of `dict()` and `model_validate()` rather than `from_orm()`.
+- **SQLAlchemy Async**: Necessitates the `postgresql+asyncpg://` schema and requires `await session.commit()`.
+- **FastAPI Middleware**: Be cautious regarding the insertion sequence of Middleware (CORS should commonly be near the end or customized based on Auth requirements).
+- **Token Efficiency**: Should a file grow excessively long, propose Module Splitting as early as the Planning phase.

package/template/.agents/skills/prp-dev-multiplatform/SKILL.md

@@ -1,36 +1,36 @@
----
-name: prp-dev-multiplatform
-description: Intelligent platform router for PRP development. Automatically detects whether the project is FastAPI, Odoo, or PHP and provides guidance on which specific skill to use.
----
-
-# 🚦 PRP Dev – Platform Router (Pure Agentic)
-
-This Skill functions as an **"Intelligent Receptionist"**, helping detect the technology powering your current project and directing other AIs (or myself) to adopt the appropriate specialized Skill for the job.
-
-## 🔍 Platform Detection Logic
-
-When kick-starting a new task or if the environment is ambiguous, I will scan the files as follows:
-
-### 1. 🐍 FastAPI
-- **Check**: `main.py`, `app.py` featuring `from fastapi import FastAPI`, or a `requirements.txt` file listing `fastapi`.
-- **Recommended Skill**: `prp-dev-fastapi`
-
-### 2. 📦 Odoo (ERP)
-- **Check**: The `addons/` folder, `__manifest__.py` (for versions 13+), or `__openerp__.py` (for version 8).
-- **Recommended Skill**: `prp-dev-odoo`
-
-### 3. 🐘 PHP (CI/Yii)
-- **Check**: The `application/` folder (CodeIgniter) or the `vendor/yiisoft/` folder (Yii).
-- **Recommended Skill**: `prp-dev-php`
-
----
-
-## 🛠️ Action Flow
-
-Upon detecting a Platform:
-1. **Notification**: I will inform you of the detected Stack (e.g., "Detected: Odoo 13 module").
-2. **Mode Switch**: I will instantly harness the knowledge from the relevant specialized Skill to plan (`/30-Plan`) and write code (`/40-Implement`).
-3. **Fallback**: If an unrecognized Stack is spotted, I will ask you for details or default to the standard **Generic Python/JS** pattern.
-
----
-*Developed for Nexus-DevFlow — Hybrid Development Support*
+---
+name: prp-dev-multiplatform
+description: Intelligent platform router for PRP development. Automatically detects whether the project is FastAPI, Odoo, or PHP and provides guidance on which specific skill to use.
+---
+
+# 🚦 PRP Dev – Platform Router (Pure Agentic)
+
+This Skill functions as an **"Intelligent Receptionist"**, helping detect the technology powering your current project and directing other AIs (or myself) to adopt the appropriate specialized Skill for the job.
+
+## 🔍 Platform Detection Logic
+
+When kick-starting a new task or if the environment is ambiguous, I will scan the files as follows:
+
+### 1. 🐍 FastAPI
+- **Check**: `main.py`, `app.py` featuring `from fastapi import FastAPI`, or a `requirements.txt` file listing `fastapi`.
+- **Recommended Skill**: `prp-dev-fastapi`
+
+### 2. 📦 Odoo (ERP)
+- **Check**: The `addons/` folder, `__manifest__.py` (for versions 13+), or `__openerp__.py` (for version 8).
+- **Recommended Skill**: `prp-dev-odoo`
+
+### 3. 🐘 PHP (CI/Yii)
+- **Check**: The `application/` folder (CodeIgniter) or the `vendor/yiisoft/` folder (Yii).
+- **Recommended Skill**: `prp-dev-php`
+
+---
+
+## 🛠️ Action Flow
+
+Upon detecting a Platform:
+1. **Notification**: I will inform you of the detected Stack (e.g., "Detected: Odoo 13 module").
+2. **Mode Switch**: I will instantly harness the knowledge from the relevant specialized Skill to plan (`/30-Plan`) and write code (`/40-Implement`).
+3. **Fallback**: If an unrecognized Stack is spotted, I will ask you for details or default to the standard **Generic Python/JS** pattern.
+
+---
+*Developed for Nexus-DevFlow — Hybrid Development Support*

package/template/.agents/skills/prp-dev-odoo/SKILL.md

@@ -1,71 +1,71 @@
----
-name: prp-dev-odoo
-description: Comprehensive skill for Odoo development following the PRP Pure Agentic workflow. Supports Odoo 8 and Odoo 13+ patterns, model/view/controller architecture, and automated validation in a Zero-Script environment.
----
-
-# 📦 PRP Dev – Odoo (Pure Agentic)
-
-This Skill operates to facilitate feature development on **Odoo** (ERP) in obedience to PRP Framework standards. It encompasses both Legacy (Odoo 8) and Modern (Odoo 13+) versions, enforcing correct Inheritance practices and optimal Security measures.
-
-## 🎯 Scope of Work
-Apply this Skill when:
-- **Module Dev**: Building or revising Odoo Modules (Models, Views, Controllers, Wizards).
-- **Migration/Fix**: Squashing Bugs or ameliorating features within Odoo 8 and 13+.
-- **Security**: Configuring Access Rights (CSV) and Record Rules (XML).
-- **Workflow**: Engaging in Odoo-related tasks throughout its lifecycle.
-
----
-
-## 1. 🔍 Platform & Version Detection
-Check the Odoo environment preceding any actions:
-1. **Odoo 8**: Search for `__openerp__.py` or the `openerp` namespace.
-2. **Odoo 13+**: Search for `__manifest__.py` or the `odoo` namespace.
-3. **Module Structure**: Inspect directories like `addons/` or `models/`, `views/`.
-
----
-
-## 2. 🧱 Implementation Guidelines
-
-### Naming Conventions
-- **Module/Model**: `snake_case` (e.g., `sale_order_line`)
-- **Class**: `PascalCase` (e.g., `SaleOrderLine`)
-- **Fields**: `snake_case`
-
-### Persistence Patterns (Inheritance)
-- **Model**: Leverage `_inherit` to extend an existing model's capability.
-- **View**: Always utilize `<xpath expr="..." position="...">` to adjust existing UI to mitigate conflict.
-
-### Security (Mandatory)
-Every time a new Model is fabricated, it must include:
-1. `security/ir.model.access.csv`: Group-level access rights.
-2. `security/ir.rule.xml`: (If necessary) Record visibility specifications (e.g., visible only to the record owner).
-
----
-
-## 3. 🛡️ Pattern References
-
-| Version | Root Header | Namespace | Decorators |
-|:---|:---|:---|:---|
-| **Odoo 8** | `<openerp>` | `from openerp import ...` | `@api.one`, `@api.multi` |
-| **Odoo 13+** | `<odoo>` | `from odoo import ...` | `@api.model`, `@api.depends` |
-
----
-
-## 🔄 PRP Workflow Integration (Zero-Script)
-For each Task, the Agent must adhere to these principles:
-
-### Phase: Planning (/30-Plan)
-- Designate the files to be created/modified in the `File & Directory Index`.
-- Formulate a `Validation Loop`:
-    - **Step 1**: Lint (flake8/pylint-odoo)
-    - **Step 2**: Odoo Test (`--test-enable` / `--init` module)
-
-### Phase: Implement (/40-Implement)
-- Proceed with subtasks sequentially and record status in `implement.md`.
-- **Gotcha**: Be mindful of Odoo's Caching. Following any Python modifications, inevitably Restart the service and update the Module.
-
----
-
-## 🧪 Testing & Validation
-- **Common Case**: Utilize `TransactionCase` to execute Business Logic Tests.
-- **UI Check**: Propose instructions for verification via a Browser inside `verify.md`.
+---
+name: prp-dev-odoo
+description: Comprehensive skill for Odoo development following the PRP Pure Agentic workflow. Supports Odoo 8 and Odoo 13+ patterns, model/view/controller architecture, and automated validation in a Zero-Script environment.
+---
+
+# 📦 PRP Dev – Odoo (Pure Agentic)
+
+This Skill operates to facilitate feature development on **Odoo** (ERP) in obedience to PRP Framework standards. It encompasses both Legacy (Odoo 8) and Modern (Odoo 13+) versions, enforcing correct Inheritance practices and optimal Security measures.
+
+## 🎯 Scope of Work
+Apply this Skill when:
+- **Module Dev**: Building or revising Odoo Modules (Models, Views, Controllers, Wizards).
+- **Migration/Fix**: Squashing Bugs or ameliorating features within Odoo 8 and 13+.
+- **Security**: Configuring Access Rights (CSV) and Record Rules (XML).
+- **Workflow**: Engaging in Odoo-related tasks throughout its lifecycle.
+
+---
+
+## 1. 🔍 Platform & Version Detection
+Check the Odoo environment preceding any actions:
+1. **Odoo 8**: Search for `__openerp__.py` or the `openerp` namespace.
+2. **Odoo 13+**: Search for `__manifest__.py` or the `odoo` namespace.
+3. **Module Structure**: Inspect directories like `addons/` or `models/`, `views/`.
+
+---
+
+## 2. 🧱 Implementation Guidelines
+
+### Naming Conventions
+- **Module/Model**: `snake_case` (e.g., `sale_order_line`)
+- **Class**: `PascalCase` (e.g., `SaleOrderLine`)
+- **Fields**: `snake_case`
+
+### Persistence Patterns (Inheritance)
+- **Model**: Leverage `_inherit` to extend an existing model's capability.
+- **View**: Always utilize `<xpath expr="..." position="...">` to adjust existing UI to mitigate conflict.
+
+### Security (Mandatory)
+Every time a new Model is fabricated, it must include:
+1. `security/ir.model.access.csv`: Group-level access rights.
+2. `security/ir.rule.xml`: (If necessary) Record visibility specifications (e.g., visible only to the record owner).
+
+---
+
+## 3. 🛡️ Pattern References
+
+| Version | Root Header | Namespace | Decorators |
+|:---|:---|:---|:---|
+| **Odoo 8** | `<openerp>` | `from openerp import ...` | `@api.one`, `@api.multi` |
+| **Odoo 13+** | `<odoo>` | `from odoo import ...` | `@api.model`, `@api.depends` |
+
+---
+
+## 🔄 PRP Workflow Integration (Zero-Script)
+For each Task, the Agent must adhere to these principles:
+
+### Phase: Planning (/30-Plan)
+- Designate the files to be created/modified in the `File & Directory Index`.
+- Formulate a `Validation Loop`:
+    - **Step 1**: Lint (flake8/pylint-odoo)
+    - **Step 2**: Odoo Test (`--test-enable` / `--init` module)
+
+### Phase: Implement (/40-Implement)
+- Proceed with subtasks sequentially and record status in `implement.md`.
+- **Gotcha**: Be mindful of Odoo's Caching. Following any Python modifications, inevitably Restart the service and update the Module.
+
+---
+
+## 🧪 Testing & Validation
+- **Common Case**: Utilize `TransactionCase` to execute Business Logic Tests.
+- **UI Check**: Propose instructions for verification via a Browser inside `verify.md`.