@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

package/template/.agents/skills/wiki/SKILL.md

@@ -1,149 +1,149 @@
 ---name: wiki
-
-description: DevFlow Wiki - Ingest, query, lint, and promote compiled project or framework knowledge.
----
-# Wiki
-
-In DevFlow 2.0, `Wiki` is a companion command, not a numbered mainline workflow. Its operational behavior remains detailed because wiki compilation is still an active workflow capability.
-
-## Purpose
-
-Use `Wiki` to compile reusable knowledge from verified DevFlow artifacts into a structured Markdown wiki without replacing source artifacts.
-
-## Usage
-
-```text
-Wiki project ingest {source}
-Wiki framework ingest {source}
-Wiki query {framework|project|all} "{question}"
-Wiki lint
-Wiki promote project-to-framework {page}
-```
-
-## When To Use
-
-Use `Wiki` when:
-
-- verified knowledge should be preserved
-- framework or project conventions should be documented
-- a final report should be promoted into durable knowledge
-- review, debug, research, or release output contains reusable patterns
-
-Preferred DevFlow 2.0 pairing:
-
-- after `/50-Verify`
-- after `/70-Release`
-- after `/60-Report`
-- after meaningful `Debug` or review output
-
-## Process
-
-`Wiki` turns verified specs, verify reports, RCA reports, PR reviews, research, release notes, and final reports into durable linked pages.
-
-It supports two namespaces:
-
-- `framework`: knowledge about Nexus-DevFlow itself
-- `project`: knowledge about the project that uses Nexus-DevFlow
-
-Rules:
-
-1. The wiki is compiled knowledge, not source of truth
-2. Ingest only reusable knowledge
-3. Prefer small, focused updates over broad rewrites
-4. Always include source references
-5. Do not promote unresolved hypotheses as settled project knowledge
-
-## Canonical Layout
-
-```text
-devflow/wiki/
-|-- framework/
-|   |-- index.md
-|   |-- agents/
-|   |-- commands/
-|   |-- decisions/
-|   |-- gotchas/
-|   |-- token-context/
-|   `-- workflows/
-`-- project/
-    |-- index.md
-    |-- architecture/
-    |-- decisions/
-    |-- domain/
-    |-- gotchas/
-    |-- patterns/
-    |-- tasks/
-    |-- token-context/
-    `-- _drafts/
-```
-
-## Process Detail
-
-### 1. Classify Scope
-
-Choose the namespace before editing:
-
-- use `framework` for DevFlow workflow, agent, command, install, token/context, or framework design knowledge
-- use `project` for target project architecture, domain, patterns, decisions, gotchas, and task lessons
-- use `promote project-to-framework` only after confirming the lesson applies beyond one project
-
-### 2. Load Source Evidence
-
-Read the source path or range:
-
-- `devflow/runs/{ID}-*/`
-- `devflow/debug/*.md`
-- `devflow/reports/*.md`
-- `devflow/research/*.md`
-- `devflow/lessons.md`
-- git diff or commit range when explicit source artifacts are missing
-
-### 3. Draft Or Update Pages
-
-Prefer the smallest page set:
-
-- create or update one concept page when possible
-- add backlinks to related pages with `[[wikilinks]]`
-- include a `Sources` section with paths, commits, or reports
-- put uncertain or unreviewed pages under `_drafts/`
-- avoid broad rewrites of unrelated wiki pages
-
-### 4. Lint Before Reporting Complete
-
-For `lint`, inspect wiki pages for:
-
-- missing `Sources`
-- broken local links or stale paths
-- duplicate concept pages
-- orphan pages without incoming links
-- framework/project namespace leakage
-
-## Output
-
-Return:
-
-- pages created or updated
-- source artifacts used
-- unresolved questions or stale-risk notes
-- lint result if run
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Knowledge system command, not a numbered stage
-- Typical entry points: after `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`
-- Typical handoff targets: return to the originating stage or finish as documentation-only work
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/wiki_page.template.md`
-- `.agent/resources/schemas/wiki_project_index.template.md`
-- Related commands: `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`, `Help`
-
-## Next Workflow Recommendation
-
-- **Primary**: return to the stage or artifact flow that produced the reusable knowledge
-- **Why**: `Wiki` compiles lessons after the source work is already validated
-- **Common routes**: `/60-Report`, `/70-Release`, or `/50-Verify`
-
+
+description: DevFlow Wiki - Ingest, query, lint, and promote compiled project or framework knowledge.
+---
+# Wiki
+
+In DevFlow 2.0, `Wiki` is a companion command, not a numbered mainline workflow. Its operational behavior remains detailed because wiki compilation is still an active workflow capability.
+
+## Purpose
+
+Use `Wiki` to compile reusable knowledge from verified DevFlow artifacts into a structured Markdown wiki without replacing source artifacts.
+
+## Usage
+
+```text
+Wiki project ingest {source}
+Wiki framework ingest {source}
+Wiki query {framework|project|all} "{question}"
+Wiki lint
+Wiki promote project-to-framework {page}
+```
+
+## When To Use
+
+Use `Wiki` when:
+
+- verified knowledge should be preserved
+- framework or project conventions should be documented
+- a final report should be promoted into durable knowledge
+- review, debug, research, or release output contains reusable patterns
+
+Preferred DevFlow 2.0 pairing:
+
+- after `/50-Verify`
+- after `/70-Release`
+- after `/60-Report`
+- after meaningful `Debug` or review output
+
+## Process
+
+`Wiki` turns verified specs, verify reports, RCA reports, PR reviews, research, release notes, and final reports into durable linked pages.
+
+It supports two namespaces:
+
+- `framework`: knowledge about Nexus-DevFlow itself
+- `project`: knowledge about the project that uses Nexus-DevFlow
+
+Rules:
+
+1. The wiki is compiled knowledge, not source of truth
+2. Ingest only reusable knowledge
+3. Prefer small, focused updates over broad rewrites
+4. Always include source references
+5. Do not promote unresolved hypotheses as settled project knowledge
+
+## Canonical Layout
+
+```text
+devflow/wiki/
+|-- framework/
+|   |-- index.md
+|   |-- agents/
+|   |-- commands/
+|   |-- decisions/
+|   |-- gotchas/
+|   |-- token-context/
+|   `-- workflows/
+`-- project/
+    |-- index.md
+    |-- architecture/
+    |-- decisions/
+    |-- domain/
+    |-- gotchas/
+    |-- patterns/
+    |-- tasks/
+    |-- token-context/
+    `-- _drafts/
+```
+
+## Process Detail
+
+### 1. Classify Scope
+
+Choose the namespace before editing:
+
+- use `framework` for DevFlow workflow, agent, command, install, token/context, or framework design knowledge
+- use `project` for target project architecture, domain, patterns, decisions, gotchas, and task lessons
+- use `promote project-to-framework` only after confirming the lesson applies beyond one project
+
+### 2. Load Source Evidence
+
+Read the source path or range:
+
+- `devflow/runs/{ID}-*/`
+- `devflow/debug/*.md`
+- `devflow/reports/*.md`
+- `devflow/research/*.md`
+- `devflow/lessons.md`
+- git diff or commit range when explicit source artifacts are missing
+
+### 3. Draft Or Update Pages
+
+Prefer the smallest page set:
+
+- create or update one concept page when possible
+- add backlinks to related pages with `[[wikilinks]]`
+- include a `Sources` section with paths, commits, or reports
+- put uncertain or unreviewed pages under `_drafts/`
+- avoid broad rewrites of unrelated wiki pages
+
+### 4. Lint Before Reporting Complete
+
+For `lint`, inspect wiki pages for:
+
+- missing `Sources`
+- broken local links or stale paths
+- duplicate concept pages
+- orphan pages without incoming links
+- framework/project namespace leakage
+
+## Output
+
+Return:
+
+- pages created or updated
+- source artifacts used
+- unresolved questions or stale-risk notes
+- lint result if run
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Knowledge system command, not a numbered stage
+- Typical entry points: after `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`
+- Typical handoff targets: return to the originating stage or finish as documentation-only work
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/wiki_page.template.md`
+- `.agent/resources/schemas/wiki_project_index.template.md`
+- Related commands: `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`, `Help`
+
+## Next Workflow Recommendation
+
+- **Primary**: return to the stage or artifact flow that produced the reusable knowledge
+- **Why**: `Wiki` compiles lessons after the source work is already validated
+- **Common routes**: `/60-Report`, `/70-Release`, or `/50-Verify`
+

package/template/.agents/skills/workflow-documentation-sync/SKILL.md

@@ -1,87 +1,87 @@
----
-name: workflow-documentation-sync
-description: Enforces the synchronization and comprehensive update of documentation, manuals, usage guides, and examples whenever a new workflow is introduced or modified in the project. Use when introducing new workflows or changing existing ones.
----
-
-# Workflow Documentation Sync
-
-## Overview
-This skill ensures that whenever a DevFlow 2.0 workflow or companion command is introduced or modified, all associated documents, user guides, manuals, and usage examples are thoroughly and systematically updated. This prevents outdated context and ensures humans and AI agents have an accurate, uniform understanding of the available tools.
-
-## When to Use
-- When creating a new workflow file under `.agents/skills/*.md`.
-- When modifying the inputs, outputs, processes, or rules of an existing workflow.
-- When deprecating or removing a workflow.
-
-Do NOT use when modifying source code logic that doesn't impact workflow interface, arguments, or overall process.
-
----
-
-## 🏗️ Core Process
-
-### Step 1: Identify Documentation Targets
-Whenever a workflow is added or modified, compile the list of documents that must be synchronized:
-1. **User Guide / Manual**: [**`USAGE.md`**](file:///d:/nexus-devflow/USAGE.md) (The main IDE user manual).
-2. **Workflow Index**: `.agents/skills/README.md` (if present) or any registry that lists command interfaces.
-3. **Template/Example files**: Any scratch templates, templates, or example files that demonstrate workflow inputs.
-
-### Step 2: Extract Workflow Metadata
-Identify the exact interface changes:
-- What is the **Command trigger**? (e.g., `/70-Release` or `Brainstorm`)
-- What are the **Arguments**? (e.g., Target Branch, default main)
-- What is the **Process flow**? (Pre-flight -> Execution -> Cleanup)
-- What are the **Mandatory Rules**? (e.g., Enforced branch checks)
-
-### Step 3: Comprehensive Updates
-Update all target files systematically:
-1. **Update USAGE.md**: Locate the quick command index and detail sections. Inject the new workflow command, its purpose, argument syntax, full execution steps, and real-world examples.
-2. **Update Workflow Index**: Add the new workflow to the lists of available command surfaces.
-3. **Create Examples**: If the workflow uses complex parameters or stage artifacts, ensure clean, tested examples are placed in the task workspace or referenced guides.
-
-### Step 4: Verify Alignment
-Ensure that:
-- The command prefix is consistent across all documents.
-- Any manual steps described in the guide match the automation logic of the workflow file.
-- Outdated versions or deleted arguments are removed from all documents.
-
----
-
-## 🛠️ Documentation Template for USAGE.md
-
-When injecting a new workflow into `USAGE.md`, use the following structure:
-
-```markdown
-### 🔀 /{Workflow-Name} - {Workflow-Title}
-- **วัตถุประสงค์**: {Brief description of what it does in Thai}
-- **วิธีใช้งาน**:
-  ```powershell
-  /{Workflow-Name} [Arguments]
-  ```
-- **ขั้นตอนการทำงาน (Process)**:
-  1. {Step 1}
-  2. {Step 2}
-- **กฎเกณฑ์และ Gotchas (Rules & Gotchas)**:
-  - {Mandatory rules or things to watch out for}
-- **ตัวอย่างการใช้งาน (Example)**:
-  - `/{Workflow-Name} {Example-Arguments}`
-```
-
----
-
-## 🚫 Common Rationalizations
-
-| Rationalization | Reality |
-|:---|:---|
-| "I'll update USAGE.md in the next task." | Undocumented workflows are forgotten workflows. Doc drift starts with a single missed update. |
-| "The prompt in the workflow file is self-documenting." | Workflow prompts are optimized for AI. Humans need clean, Thai-friendly usage instructions with clear examples. |
-| "The workflow is too simple to need examples." | Even simple workflows (like Merge or PR) have edge cases (e.g., force delete warnings) that must be documented. |
-
----
-
-## ✅ Verification Checklist
-
-- [ ] Every new/modified workflow has been mapped to `USAGE.md`.
-- [ ] Argument parameters in the markdown guide perfectly match the actual `.md` workflow trigger.
-- [ ] Real-world, copy-pasteable execution examples are provided.
-- [ ] Deprecated or old workflow definitions have been removed or clearly marked as legacy to prevent hallucination.
-- [ ] Verification command output or terminal execution proof is recorded.
+---
+name: workflow-documentation-sync
+description: Enforces the synchronization and comprehensive update of documentation, manuals, usage guides, and examples whenever a new workflow is introduced or modified in the project. Use when introducing new workflows or changing existing ones.
+---
+
+# Workflow Documentation Sync
+
+## Overview
+This skill ensures that whenever a DevFlow 2.0 workflow or companion command is introduced or modified, all associated documents, user guides, manuals, and usage examples are thoroughly and systematically updated. This prevents outdated context and ensures humans and AI agents have an accurate, uniform understanding of the available tools.
+
+## When to Use
+- When creating a new workflow file under `.agents/skills/*.md`.
+- When modifying the inputs, outputs, processes, or rules of an existing workflow.
+- When deprecating or removing a workflow.
+
+Do NOT use when modifying source code logic that doesn't impact workflow interface, arguments, or overall process.
+
+---
+
+## 🏗️ Core Process
+
+### Step 1: Identify Documentation Targets
+Whenever a workflow is added or modified, compile the list of documents that must be synchronized:
+1. **User Guide / Manual**: [**`USAGE.md`**](file:///d:/nexus-devflow/USAGE.md) (The main IDE user manual).
+2. **Workflow Index**: `.agents/skills/README.md` (if present) or any registry that lists command interfaces.
+3. **Template/Example files**: Any scratch templates, templates, or example files that demonstrate workflow inputs.
+
+### Step 2: Extract Workflow Metadata
+Identify the exact interface changes:
+- What is the **Command trigger**? (e.g., `/70-Release` or `Brainstorm`)
+- What are the **Arguments**? (e.g., Target Branch, default main)
+- What is the **Process flow**? (Pre-flight -> Execution -> Cleanup)
+- What are the **Mandatory Rules**? (e.g., Enforced branch checks)
+
+### Step 3: Comprehensive Updates
+Update all target files systematically:
+1. **Update USAGE.md**: Locate the quick command index and detail sections. Inject the new workflow command, its purpose, argument syntax, full execution steps, and real-world examples.
+2. **Update Workflow Index**: Add the new workflow to the lists of available command surfaces.
+3. **Create Examples**: If the workflow uses complex parameters or stage artifacts, ensure clean, tested examples are placed in the task workspace or referenced guides.
+
+### Step 4: Verify Alignment
+Ensure that:
+- The command prefix is consistent across all documents.
+- Any manual steps described in the guide match the automation logic of the workflow file.
+- Outdated versions or deleted arguments are removed from all documents.
+
+---
+
+## 🛠️ Documentation Template for USAGE.md
+
+When injecting a new workflow into `USAGE.md`, use the following structure:
+
+```markdown
+### 🔀 /{Workflow-Name} - {Workflow-Title}
+- **วัตถุประสงค์**: {Brief description of what it does in Thai}
+- **วิธีใช้งาน**:
+  ```powershell
+  /{Workflow-Name} [Arguments]
+  ```
+- **ขั้นตอนการทำงาน (Process)**:
+  1. {Step 1}
+  2. {Step 2}
+- **กฎเกณฑ์และ Gotchas (Rules & Gotchas)**:
+  - {Mandatory rules or things to watch out for}
+- **ตัวอย่างการใช้งาน (Example)**:
+  - `/{Workflow-Name} {Example-Arguments}`
+```
+
+---
+
+## 🚫 Common Rationalizations
+
+| Rationalization | Reality |
+|:---|:---|
+| "I'll update USAGE.md in the next task." | Undocumented workflows are forgotten workflows. Doc drift starts with a single missed update. |
+| "The prompt in the workflow file is self-documenting." | Workflow prompts are optimized for AI. Humans need clean, Thai-friendly usage instructions with clear examples. |
+| "The workflow is too simple to need examples." | Even simple workflows (like Merge or PR) have edge cases (e.g., force delete warnings) that must be documented. |
+
+---
+
+## ✅ Verification Checklist
+
+- [ ] Every new/modified workflow has been mapped to `USAGE.md`.
+- [ ] Argument parameters in the markdown guide perfectly match the actual `.md` workflow trigger.
+- [ ] Real-world, copy-pasteable execution examples are provided.
+- [ ] Deprecated or old workflow definitions have been removed or clearly marked as legacy to prevent hallucination.
+- [ ] Verification command output or terminal execution proof is recorded.