@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.2

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

package/template/.claude/skills/check-for-updates/SKILL.md

@@ -1,117 +0,0 @@
----name: check-for-updates
-
-description: Install, upgrade, or verify Nexus-DevFlow setup for this machine or project using SETUP-BY-AI.md as the source of truth.
-argument-hint: [optional: target project path, provider/tool, or update intent]
----
-
-# Check For Updates
-
-`Check-For-Updates` is a public companion command for Nexus-DevFlow install, upgrade, and setup verification work.
-
-It is not a numbered mainline stage.
-
-## Mission
-
-Install or upgrade Nexus-DevFlow 2.0 for this machine or target project.
-
-First read `SETUP-BY-AI.md` from the Nexus-DevFlow repository and use it as the operational source of truth.
-
-Detect:
-
-- framework root
-- package version
-- provider or tool
-- target project
-- whether the current setup is using `Codex global`, `Central clone + link`, or `Manual copy / overwrite`
-
-Keep `.workspaces` project-local.
-
-Do not overwrite user instruction files blindly.
-
-After install or upgrade, run `roadmap:validate`, `validate`, and `validate:all` where relevant, then report files changed, installed version, framework root, chosen route, and any manual approval steps.
-
-Repository reference:
-
-```text
-https://github.com/Jakkrich/nexus-devflow
-```
-
-## When To Use
-
-Use this command when:
-
-- the user wants to install Nexus-DevFlow into Codex or another AI tool
-- the user wants to install Nexus-DevFlow into a target project
-- the user wants to upgrade an existing Nexus-DevFlow install
-- the user wants to check whether the current machine or project is on the expected framework version
-- the user needs routing across optional Codex global setup, `Central clone + link`, or `Manual copy / overwrite`
-
-## Operating Rules
-
-- `SETUP-BY-AI.md` is the operational source of truth
-- prefer the safest route that matches the user request and existing environment
-- for project-local setup, prefer `Central clone + link`
-- use `Manual copy / overwrite` only when linking is unsuitable or explicitly rejected
-- treat `AI install` as guided execution of one of the supported routes, not as a separate bundle layout
-- preserve user-authored instructions outside managed Nexus-DevFlow content
-- do not link, copy, or share `.workspaces` from the framework repo into another project
-- if the framework repo is dirty, do not pull automatically; report the dirty files and ask before proceeding with a pull-based update
-- do not claim success until the relevant validation commands pass
-
-## Execution Flow
-
-1. Read `SETUP-BY-AI.md`.
-2. Detect the framework root and confirm the framework files listed there exist.
-3. Detect the installed or target version from `package.json`.
-4. Detect the provider or tool context.
-5. Detect the target project and keep its `.workspaces` local to that project.
-6. Detect the current route already in use, if any:
-   - optional `Codex global`
-   - `Central clone + link`
-   - `Manual copy / overwrite`
-7. Choose the route:
-   - optional `Codex global` only when explicitly requested
-   - `Central clone + link` for project-local setup by default
-   - `Manual copy / overwrite` only when linking is not suitable
-8. If upgrading and the user wants latest, inspect git cleanliness before any pull-based update.
-9. Apply the relevant install or upgrade commands.
-10. Run validation:
-   - `npm.cmd run roadmap:validate`
-   - `npm.cmd run validate`
-   - `npm.cmd run validate:all`
-   - plus provider-specific checks such as `npm.cmd run codex:check-global` when applicable
-11. Report the outcome in the final setup result format.
-
-## Final Report Format
-
-```text
-Nexus-DevFlow setup result
-- Mode:
-- Framework root:
-- Framework version:
-- Target project:
-- Provider:
-- Files changed:
-- Validation:
-- Warnings or manual steps:
-```
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: before using DevFlow on a new machine, before linking or copying into a target project, after pulling framework changes, or during provider setup maintenance
-- Typical handoff targets: `Help`, `/00-Discover`, or the user's requested active task after setup is verified
-
-## Sources
-
-- `SETUP-BY-AI.md`
-- `SETUP.md`
-- `AGENTS.md`
-- `package.json`
-- `docs/install-update-troubleshooting.md`
-
-## Next Workflow Recommendation
-
-- Default: return to the user's requested work after setup is verified
-- Common routes: `Help` for routing, `/00-Discover` for new work, or `/50-Verify` when setup validation exposes framework issues