@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.2

package/template/.agents/skills/obsidian-markdown/SKILL.md

@@ -1,205 +0,0 @@
----
-name: obsidian-markdown
-description: Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.
-risk: unknown
-source: "https://github.com/kepano/obsidian-skills"
-date_added: "2026-03-21"
----
-
-# Obsidian Flavored Markdown Skill
-
-Create and edit valid Obsidian Flavored Markdown. Obsidian extends CommonMark and GFM with wikilinks, embeds, callouts, properties, comments, and other syntax. This skill covers only Obsidian-specific extensions -- standard Markdown (headings, bold, italic, lists, quotes, code blocks, tables) is assumed knowledge.
-
-## When to Use
-
-- Use when writing or editing Markdown notes intended for Obsidian.
-- Use when the task involves wikilinks, embeds, callouts, frontmatter properties, or Obsidian-specific syntax.
-- Use when the user wants notes that render correctly inside an Obsidian vault.
-
-## Workflow: Creating an Obsidian Note
-
-1. **Add frontmatter** with properties (title, tags, aliases) at the top of the file. See [PROPERTIES.md](references/PROPERTIES.md) for all property types.
-2. **Write content** using standard Markdown for structure, plus Obsidian-specific syntax below.
-3. **Link related notes** using wikilinks (`[[Note]]`) for internal vault connections, or standard Markdown links for external URLs.
-4. **Embed content** from other notes, images, or PDFs using the `![[embed]]` syntax. See [EMBEDS.md](references/EMBEDS.md) for all embed types.
-5. **Add callouts** for highlighted information using `> [!type]` syntax. See [CALLOUTS.md](references/CALLOUTS.md) for all callout types.
-6. **Verify** the note renders correctly in Obsidian's reading view.
-
-> When choosing between wikilinks and Markdown links: use `[[wikilinks]]` for notes within the vault (Obsidian tracks renames automatically) and plain Markdown links for external URLs only.
-
-## Internal Links (Wikilinks)
-
-```markdown
-[[Note Name]]                          Link to note
-[[Note Name|Display Text]]             Custom display text
-[[Note Name#Heading]]                  Link to heading
-[[Note Name#^block-id]]                Link to block
-[[#Heading in same note]]              Same-note heading link
-```
-
-Define a block ID by appending `^block-id` to any paragraph:
-
-```markdown
-This paragraph can be linked to. ^my-block-id
-```
-
-For lists and quotes, place the block ID on a separate line after the block:
-
-```markdown
-> A quote block
-
-^quote-id
-```
-
-## Embeds
-
-Prefix any wikilink with `!` to embed its content inline:
-
-```markdown
-![[Note Name]]                         Embed full note
-![[Note Name#Heading]]                 Embed section
-![[image.png]]                         Embed image
-![[image.png|300]]                     Embed image with width
-![[document.pdf#page=3]]               Embed PDF page
-```
-
-See [EMBEDS.md](references/EMBEDS.md) for audio, video, search embeds, and external images.
-
-## Callouts
-
-```markdown
-> [!note]
-> Basic callout.
-
-> [!warning] Custom Title
-> Callout with a custom title.
-
-> [!faq]- Collapsed by default
-> Foldable callout (- collapsed, + expanded).
-```
-
-Common types: `note`, `tip`, `warning`, `info`, `example`, `quote`, `bug`, `danger`, `success`, `failure`, `question`, `abstract`, `todo`.
-
-See [CALLOUTS.md](references/CALLOUTS.md) for the full list with aliases, nesting, and custom CSS callouts.
-
-## Properties (Frontmatter)
-
-```yaml
----
-title: My Note
-date: 2024-01-15
-tags:
-  - project
-  - active
-aliases:
-  - Alternative Name
-cssclasses:
-  - custom-class
----
-```
-
-Default properties: `tags` (searchable labels), `aliases` (alternative note names for link suggestions), `cssclasses` (CSS classes for styling).
-
-See [PROPERTIES.md](references/PROPERTIES.md) for all property types, tag syntax rules, and advanced usage.
-
-## Tags
-
-```markdown
-#tag                    Inline tag
-#nested/tag             Nested tag with hierarchy
-```
-
-Tags can contain letters, numbers (not first character), underscores, hyphens, and forward slashes. Tags can also be defined in frontmatter under the `tags` property.
-
-## Comments
-
-```markdown
-This is visible %%but this is hidden%% text.
-
-%%
-This entire block is hidden in reading view.
-%%
-```
-
-## Obsidian-Specific Formatting
-
-```markdown
-==Highlighted text==                   Highlight syntax
-```
-
-## Math (LaTeX)
-
-```markdown
-Inline: $e^{i\pi} + 1 = 0$
-
-Block:
-$$
-\frac{a}{b} = c
-$$
-```
-
-## Diagrams (Mermaid)
-
-````markdown
-```mermaid
-graph TD
-    A[Start] --> B{Decision}
-    B -->|Yes| C[Do this]
-    B -->|No| D[Do that]
-```
-````
-
-To link Mermaid nodes to Obsidian notes, add `class NodeName internal-link;`.
-
-## Footnotes
-
-```markdown
-Text with a footnote[^1].
-
-[^1]: Footnote content.
-
-Inline footnote.^[This is inline.]
-```
-
-## Complete Example
-
-````markdown
----
-title: Project Alpha
-date: 2024-01-15
-tags:
-  - project
-  - active
-status: in-progress
----
-
-# Project Alpha
-
-This project aims to [[improve workflow]] using modern techniques.
-
-> [!important] Key Deadline
-> The first milestone is due on ==January 30th==.
-
-## Tasks
-
-- [x] Initial planning
-- [ ] Development phase
-  - [ ] Backend implementation
-  - [ ] Frontend design
-
-## Notes
-
-The algorithm uses $O(n \log n)$ sorting. See [[Algorithm Notes#Sorting]] for details.
-
-![[Architecture Diagram.png|600]]
-
-Reviewed in [[Meeting Notes 2024-01-10#Decisions]].
-````
-
-## References
-
-- [Obsidian Flavored Markdown](https://help.obsidian.md/obsidian-flavored-markdown)
-- [Internal links](https://help.obsidian.md/links)
-- [Embed files](https://help.obsidian.md/embeds)
-- [Callouts](https://help.obsidian.md/callouts)
-- [Properties](https://help.obsidian.md/properties)

package/template/.agents/skills/obsidian-markdown/references/CALLOUTS.md

@@ -1,58 +0,0 @@
-# Callouts Reference
-
-## Basic Callout
-
-```markdown
-> [!note]
-> This is a note callout.
-
-> [!info] Custom Title
-> This callout has a custom title.
-
-> [!tip] Title Only
-```
-
-## Foldable Callouts
-
-```markdown
-> [!faq]- Collapsed by default
-> This content is hidden until expanded.
-
-> [!faq]+ Expanded by default
-> This content is visible but can be collapsed.
-```
-
-## Nested Callouts
-
-```markdown
-> [!question] Outer callout
-> > [!note] Inner callout
-> > Nested content
-```
-
-## Supported Callout Types
-
-| Type | Aliases | Color / Icon |
-|------|---------|-------------|
-| `note` | - | Blue, pencil |
-| `abstract` | `summary`, `tldr` | Teal, clipboard |
-| `info` | - | Blue, info |
-| `todo` | - | Blue, checkbox |
-| `tip` | `hint`, `important` | Cyan, flame |
-| `success` | `check`, `done` | Green, checkmark |
-| `question` | `help`, `faq` | Yellow, question mark |
-| `warning` | `caution`, `attention` | Orange, warning |
-| `failure` | `fail`, `missing` | Red, X |
-| `danger` | `error` | Red, zap |
-| `bug` | - | Red, bug |
-| `example` | - | Purple, list |
-| `quote` | `cite` | Gray, quote |
-
-## Custom Callouts (CSS)
-
-```css
-.callout[data-callout="custom-type"] {
-  --callout-color: 255, 0, 0;
-  --callout-icon: lucide-alert-circle;
-}
-```

package/template/.agents/skills/obsidian-markdown/references/EMBEDS.md

@@ -1,63 +0,0 @@
-# Embeds Reference
-
-## Embed Notes
-
-```markdown
-![[Note Name]]
-![[Note Name#Heading]]
-![[Note Name#^block-id]]
-```
-
-## Embed Images
-
-```markdown
-![[image.png]]
-![[image.png|640x480]]    Width x Height
-![[image.png|300]]        Width only (maintains aspect ratio)
-```
-
-## External Images
-
-```markdown
-![Alt text](https://example.com/image.png)
-![Alt text|300](https://example.com/image.png)
-```
-
-## Embed Audio
-
-```markdown
-![[audio.mp3]]
-![[audio.ogg]]
-```
-
-## Embed PDF
-
-```markdown
-![[document.pdf]]
-![[document.pdf#page=3]]
-![[document.pdf#height=400]]
-```
-
-## Embed Lists
-
-```markdown
-![[Note#^list-id]]
-```
-
-Where the list has a block ID:
-
-```markdown
-- Item 1
-- Item 2
-- Item 3
-
-^list-id
-```
-
-## Embed Search Results
-
-````markdown
-```query
-tag:#project status:done
-```
-````

package/template/.agents/skills/obsidian-markdown/references/PROPERTIES.md

@@ -1,61 +0,0 @@
-# Properties (Frontmatter) Reference
-
-Properties use YAML frontmatter at the start of a note:
-
-```yaml
----
-title: My Note Title
-date: 2024-01-15
-tags:
-  - project
-  - important
-aliases:
-  - My Note
-  - Alternative Name
-cssclasses:
-  - custom-class
-status: in-progress
-rating: 4.5
-completed: false
-due: 2024-02-01T14:30:00
----
-```
-
-## Property Types
-
-| Type | Example |
-|------|---------|
-| Text | `title: My Title` |
-| Number | `rating: 4.5` |
-| Checkbox | `completed: true` |
-| Date | `date: 2024-01-15` |
-| Date & Time | `due: 2024-01-15T14:30:00` |
-| List | `tags: [one, two]` or YAML list |
-| Links | `related: "[[Other Note]]"` |
-
-## Default Properties
-
-- `tags` - Note tags (searchable, shown in graph view)
-- `aliases` - Alternative names for the note (used in link suggestions)
-- `cssclasses` - CSS classes applied to the note in reading/editing view
-
-## Tags
-
-```markdown
-#tag
-#nested/tag
-#tag-with-dashes
-#tag_with_underscores
-```
-
-Tags can contain: letters (any language), numbers (not first character), underscores `_`, hyphens `-`, forward slashes `/` (for nesting).
-
-In frontmatter:
-
-```yaml
----
-tags:
-  - tag1
-  - nested/tag2
----
-```

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

@@ -1,99 +0,0 @@
----
-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 +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*