@jakkrichm/create-nexus-devflow 2.0.1 → 2.0.2

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

@@ -1,114 +0,0 @@
----
-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 +0,0 @@
----
-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 +0,0 @@
----
-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`.

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

@@ -1,63 +0,0 @@
----
-name: prp-dev-php
-description: Comprehensive skill for PHP development following the PRP Pure Agentic workflow. Supports CodeIgniter 3 and Yii 2, with MVC patterns and automated validation loops in a Zero-Script environment.
----
-
-# 🐘 PRP Dev – PHP (Pure Agentic)
-
-This Skill empowers feature development on **PHP** conforming to the PRP Framework standards, focusing principally on CodeIgniter 3 (Legacy) and Yii Framework 2 (Modern). It fully addresses MVC operations alongside fundamental security fortifications.
-
-## 🎯 Scope of Work
-Apply this Skill when:
-- **Framework Dev**: Constructing or mending Controllers, Models, and Views.
-- **Legacy Support**: Improving CodeIgniter 3 codebases for better security and structure.
-- **Modern PHP**: Advancing Yii 2 exploiting ActiveRecord and Dependency Injection.
-- **Workflow**: Doing Task-related work pertinent to PHP Apps.
-
----
-
-## 1. 🔍 Framework Detection
-Probe the environment prior to starting work:
-1. **CodeIgniter 3**: Probe for `application/config/config.php` or `system/`.
-2. **Yii 2**: Probe for `vendor/yiisoft/yii2` or `config/web.php`.
-3. **Composer**: Look over `composer.json` for PHP versions and Dependencies.
-
----
-
-## 2. 🏛️ Implementation Patterns
-
-### CodeIgniter 3 (The Singleton Pattern)
-- **Namespacing**: Frequently lacks namespaces (Global usage).
-- **Loading**: Implements `$this->load->model('...')` or `$this->load->view('...')`.
-- **Security**: Compulsory check: `defined('BASEPATH') OR exit('...');` required universally at the top of files.
-
-### Yii Framework 2 (The Component Pattern)
-- **ActiveRecord**: Fulfills Querying through Model Classes (e.g., `User::find()`).
-- **Namespacing**: Extensively integrates PSR-4 Namespacing.
-- **Views**: Incorporates `Html::encode()` alongside `$this->render()`.
-
----
-
-## 🛡️ Security Best Practices
-- **Prepared Statements**: Mandate using the Query Builder or ORM. Raw SQL accepting direct Variables is strictly forbidden.
-- **Input Validation**: Abide by Framework Validation (CI Form Validation / Yii Rules).
-- **Output Escaping**: Obviate XSS attacks by Encoding data before displaying it on HTML.
-
----
-
-## 🔄 PRP Workflow Integration (Zero-Script)
-For each Task, the Agent must adhere to these principles:
-
-### Phase: Planning (/30-Plan)
-- Designate the files for modification and outline Validation procedures (e.g., executing `phpunit`).
-
-### Phase: Implement (/40-Implement)
-- Proceed with subtasks sequentially and capture real progress in `implement.md`.
-- Chronicle implementation and verification-relevant notes in `implement.md` and `verify.md` first.
-
----
-
-## 🧪 Testing & Validation
-- **Unit Testing**: Employ `PHPUnit` or any pre-installed testing framework within the project.
-- **Command Line**: Tests typically run via `./vendor/bin/phpunit` or specialized framework commands.
-- **Manual Check**: Specify manual verification steps in `verify.md`.

package/template/.agents/skills/prp-sa-ba/SKILL.md

@@ -1,52 +0,0 @@
----
-name: prp-sa-ba
-description: Assist SA/BA in this PRP-based Pure Agentic project with requirement analysis, spec refinement, and maintaining INITIAL.md. Use whenever the user is acting as SA/BA, defining tasks, or discussing project overview.
----
-
-# 📋 PRP SA/BA Workflow (Pure Agentic)
-
-This Skill is tailored to assist users playing the role of an **SA/BA/PO** by collecting requirements and setting up specs so that the AI can work precisely thereafter in accordance with Pure Agentic Framework standards.
-
-## 🎯 Scope of Work
-Apply this Skill when:
-- **Requirement Analysis**: Transcribing Raw requirements into an actionable plan.
-- **Spec Refinement**: Formatting or fine-tuning `spec.md` located in the task folder.
-- **Project Indexing**: Operating and updating `INITIAL.md` ensuring it acts as an up-to-date index.
-- **Flow Coordination**: Recommending ensuing actions within the Workflow (Issue -> Spec -> Plan -> Code -> Verify).
-
----
-
-## 1. 📂 Staging to Spec (Phase: New Task)
-Commencing a new task:
-1. **Pickup from Staging**: Monitor for specific files localized inside `devflow/issues/` (Staging Area).
-2. **Standardize**: Exploit Issue data to instigate a task directory under `devflow/runs/{ID}-{slug}/`.
-3. **Core Files**: Lay down standard requisite AI files:
-   - `spec.md`: Elaborate technical nuances coupled with Acceptance Criteria.
-   - `define.md` / `spec.md` metadata sections: informative context relating to categories, priority, and complexity.
-
----
-
-## 2. 🧠 Requirement Refining
-Aid the SA/BA in finalizing needs thoroughly prior to writing any Code:
-- **Dimension 360**: Question elements about Edge Cases, UX, Security, and Technical Impacts.
-- **Measurable Goals**: Tweak Acceptance Criteria causing them to be quantitatively tangible (averting phrases like "make it good").
-- **Metadata Tuning**: Harmonize Complexity and Priority to resonate closely alongside the veritable effort needed.
-
----
-
-## 3. 📑 Maintaining INITIAL.md
-Act as custodian of the "Home Page of Project" warranting it persists as the quintessential Source of Truth invariably:
-- **Indexing**: During the inception or completion of a Task, append a link right into the `Active Specs & Tasks` division.
-- **Stack Status**: Maintain the pertinent Technical Stack information actively updated if modifications transpire.
-- **Allowed Commands**: Audit alongside updating explicit lists highlighting commands currently actionable by the AI.
-
----
-
-## 🔄 Workflow Guidance (Next Steps)
-Advocate relevant commands following the DevFlow 2.0 hierarchy:
-1. **Planning**: Once a spec matures sufficiently, advise executing `/30-Plan {ID}`.
-2. **Implementation**: After the plan is ready, endorse launching `/40-Implement {ID}`.
-3. **Review**: After implementation evidence exists, point the user to `/50-Verify {ID}`, then `/60-Report {ID}`, and finally `/70-Release {ID}` when release execution is still needed.
-
----
-*Note: This skill synergizes most efficiently running alongside the Agent Persona `requirements-engineer`.*

package/template/.agents/skills/red-team-tactics/SKILL.md

@@ -1,199 +0,0 @@
----
-name: red-team-tactics
-description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
-allowed-tools: Read, Glob, Grep
----
-
-# Red Team Tactics
-
-> Adversary simulation principles based on MITRE ATT&CK framework.
-
----
-
-## 1. MITRE ATT&CK Phases
-
-### Attack Lifecycle
-
-```
-RECONNAISSANCE → INITIAL ACCESS → EXECUTION → PERSISTENCE
-       ↓              ↓              ↓            ↓
-   PRIVILEGE ESC → DEFENSE EVASION → CRED ACCESS → DISCOVERY
-       ↓              ↓              ↓            ↓
-LATERAL MOVEMENT → COLLECTION → C2 → EXFILTRATION → IMPACT
-```
-
-### Phase Objectives
-
-| Phase | Objective |
-|-------|-----------|
-| **Recon** | Map attack surface |
-| **Initial Access** | Get first foothold |
-| **Execution** | Run code on target |
-| **Persistence** | Survive reboots |
-| **Privilege Escalation** | Get admin/root |
-| **Defense Evasion** | Avoid detection |
-| **Credential Access** | Harvest credentials |
-| **Discovery** | Map internal network |
-| **Lateral Movement** | Spread to other systems |
-| **Collection** | Gather target data |
-| **C2** | Maintain command channel |
-| **Exfiltration** | Extract data |
-
----
-
-## 2. Reconnaissance Principles
-
-### Passive vs Active
-
-| Type | Trade-off |
-|------|-----------|
-| **Passive** | No target contact, limited info |
-| **Active** | Direct contact, more detection risk |
-
-### Information Targets
-
-| Category | Value |
-|----------|-------|
-| Technology stack | Attack vector selection |
-| Employee info | Social engineering |
-| Network ranges | Scanning scope |
-| Third parties | Supply chain attack |
-
----
-
-## 3. Initial Access Vectors
-
-### Selection Criteria
-
-| Vector | When to Use |
-|--------|-------------|
-| **Phishing** | Human target, email access |
-| **Public exploits** | Vulnerable services exposed |
-| **Valid credentials** | Leaked or cracked |
-| **Supply chain** | Third-party access |
-
----
-
-## 4. Privilege Escalation Principles
-
-### Windows Targets
-
-| Check | Opportunity |
-|-------|-------------|
-| Unquoted service paths | Write to path |
-| Weak service permissions | Modify service |
-| Token privileges | Abuse SeDebug, etc. |
-| Stored credentials | Harvest |
-
-### Linux Targets
-
-| Check | Opportunity |
-|-------|-------------|
-| SUID binaries | Execute as owner |
-| Sudo misconfiguration | Command execution |
-| Kernel vulnerabilities | Kernel exploits |
-| Cron jobs | Writable scripts |
-
----
-
-## 5. Defense Evasion Principles
-
-### Key Techniques
-
-| Technique | Purpose |
-|-----------|---------|
-| LOLBins | Use legitimate tools |
-| Obfuscation | Hide malicious code |
-| Timestomping | Hide file modifications |
-| Log clearing | Remove evidence |
-
-### Operational Security
-
-- Work during business hours
-- Mimic legitimate traffic patterns
-- Use encrypted channels
-- Blend with normal behavior
-
----
-
-## 6. Lateral Movement Principles
-
-### Credential Types
-
-| Type | Use |
-|------|-----|
-| Password | Standard auth |
-| Hash | Pass-the-hash |
-| Ticket | Pass-the-ticket |
-| Certificate | Certificate auth |
-
-### Movement Paths
-
-- Admin shares
-- Remote services (RDP, SSH, WinRM)
-- Exploitation of internal services
-
----
-
-## 7. Active Directory Attacks
-
-### Attack Categories
-
-| Attack | Target |
-|--------|--------|
-| Kerberoasting | Service account passwords |
-| AS-REP Roasting | Accounts without pre-auth |
-| DCSync | Domain credentials |
-| Golden Ticket | Persistent domain access |
-
----
-
-## 8. Reporting Principles
-
-### Attack Narrative
-
-Document the full attack chain:
-1. How initial access was gained
-2. What techniques were used
-3. What objectives were achieved
-4. Where detection failed
-
-### Detection Gaps
-
-For each successful technique:
-- What should have detected it?
-- Why didn't detection work?
-- How to improve detection
-
----
-
-## 9. Ethical Boundaries
-
-### Always
-
-- Stay within scope
-- Minimize impact
-- Report immediately if real threat found
-- Document all actions
-
-### Never
-
-- Destroy production data
-- Cause denial of service (unless scoped)
-- Access beyond proof of concept
-- Retain sensitive data
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Rush to exploitation | Follow methodology |
-| Cause damage | Minimize impact |
-| Skip reporting | Document everything |
-| Ignore scope | Stay within boundaries |
-
----
-
-> **Remember:** Red team simulates attackers to improve defenses, not to cause harm.

package/template/.agents/skills/writing-great-skills/SKILL.md

@@ -1,65 +0,0 @@
----
-name: writing-great-skills
-description: Maintainer reference for writing predictable DevFlow skills. Use when creating, importing, pruning, or refactoring .agent/skills content.
-disable-model-invocation: true
----
-
-# Writing Great Skills
-
-Use this maintainer support skill when editing `.agent/skills`.
-
-A skill exists to make a process predictable. It should make the agent take the same kind of action in the same kind of situation, without bloating context or competing with workflow ownership.
-
-## Invocation
-
-Choose the lowest-load invocation mode:
-
-- Model-invoked skill: use when the agent must discover and apply the skill on its own.
-- User-invoked skill: use when only humans or another explicit router should call it.
-- Router skill: use when many user-invoked skills create cognitive load.
-
-In DevFlow, public workflow surface should stay stable. New skills usually start as support skills, not public companion commands.
-
-## Description Rules
-
-- Front-load the leading word.
-- Include only distinct trigger branches.
-- Remove synonyms that repeat the same trigger.
-- Keep stage ownership out of the description; put lifecycle placement in the body.
-
-## Information Hierarchy
-
-Put material where it belongs:
-
-1. In-skill steps: actions every invocation needs.
-2. In-skill reference: rules frequently needed during execution.
-3. External reference files: details only some branches need.
-
-Use progressive disclosure for long reference material.
-
-## Splitting Rules
-
-Split a skill only when:
-
-- it needs independent model invocation
-- a long step sequence causes premature completion
-- branches are different enough that one file causes confusion
-
-Do not split only because a file is aesthetically long.
-
-## Pruning Rules
-
-- Keep one source of truth for each rule.
-- Delete no-op advice that does not change behavior.
-- Delete stale upstream assumptions when importing.
-- Prefer DevFlow stage names and artifact paths.
-
-## Import Checklist
-
-- [ ] Fits `docs/skill-selection-policy.md`.
-- [ ] Does not create a new mainline stage.
-- [ ] Does not expand public companion commands by accident.
-- [ ] Names owning DevFlow stages.
-- [ ] Describes output location.
-- [ ] Routes contradictions back to the owning stage.
-- [ ] Passes `npm run validate`.