@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

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

@@ -1,109 +1,109 @@
 ---name: changelog
-
-description: Update CHANGELOG.md - Automatically gather changes from specs, git history, or current state to update the project changelog.
----
-# Phase 53: Update Changelog
-
-This command automates the process of maintaining the `CHANGELOG.md` file by analyzing task specifications, git diffs, and the current project state.
-
-Primary behavior now lives in:
-
-```text
-.agents/skills/release-git-operations/SKILL.md
-```
-
-Treat this workflow file as a compatibility wrapper around that skill in `changelog` mode.
-
-## Usage
-
-Run the command by typing:
-```
-Changelog
-```
-
-## Objectives
-
-1.  **Change Detection**: Identify new features, fixes, and changes since the last recorded version in `CHANGELOG.md`.
-2.  **Automated Versioning**: Analyze the impact of changes to automatically select the next version number (Major, Minor, or Patch) based on Semantic Versioning (SemVer) principles.
-3.  **Source Analysis**:
-    *   Scan `devflow/` for `20-spec.md` files of active or recently completed tasks.
-    *   Check `git status` and `git diff` for uncommitted/staged changes.
-    *   Check `git log` if git is initialized to see history since the last tag or version entry.
-3.  **Automatic Formatting**: Generate a standardized changelog entry following the [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format.
-4.  **Consistency**: Ensure the `CHANGELOG.md` reflects the actual work done in the repository.
-
-## Process
-
-### 1. Version Detection & Setup
-1.  **Read Current Changelog**: Extract the latest version and date from `CHANGELOG.md`.
-2.  **Analyze & Determine Next Version**: 
-    *   Analyze the collected changes to decide the increment based on **Semantic Versioning (SemVer)**:
-        - **Major (+1.0.0)**: Use if there are breaking changes, [DELETE] operations on core modules, or major architectural shifts.
-        - **Minor (0.+1.0)**: Use if new features ([NEW]) or significant compatible additions are found.
-        - **Patch (0.0.+1)**: Use for bug fixes ([FIXED]), small tweaks ([MODIFY]), or documentation updates.
-    *   Auto-propose the version based on the highest impact category found.
-3.  **Get Current Date**: Use the current system date (YYYY-MM-DD).
-
-### 2. Information Gathering
-1.  **Scan devflow/**:
-    *   Find all `20-spec.md` files in subdirectories of `devflow/`.
-    *   Extract the `Goal` or `Requirements` sections to identify high-level features/fixes.
-2.  **Git Analysis** (if available):
-    *   Run `git status` to see current work in progress.
-    *   Run `git diff` to understand technical changes and impact.
-    *   Look for "BREAKING CHANGE" in git commit messages.
-3.  **Categorization & Impact Assessment**: Group findings and assess impact:
-    *   `Added` โ†’ Usually Minor.
-    *   `Changed` โ†’ Minor or Patch (Major if breaking).
-    *   `Fixed` โ†’ Patch.
-    *   `Removed` โ†’ Major (if public API/Core).
-    *   `Security` โ†’ Patch or Minor.
-
-### 3. Update CHANGELOG.md
-1.  **Template Verification**: Before generating a new changelog block, inspect `.agent/resources/schemas/changelog_entry.template.md`, use its headings, and manually apply the same no-placeholder gate to the inserted changelog block.
-2.  **Generate Entry**: Format the gathered information into a Markdown block.
-3.  **Insertion**: Use `replace_file_content` to insert the new version block at the top of the version list (usually after the header and description).
-4.  **Validation**: Ensure the file remains readable and correctly formatted.
-
-## Benefits
-- **Automation**: Reduces the manual effort of tracking changes.
-- **Accuracy**: Ensures all tasks documented in `devflow/` are captured.
-- **Standardization**: Maintains a consistent look and feel for project history.
-
-## System Prompt / Persona
-- **Release Engineer**: Focuses on clear, concise, and accurate documentation of software changes.
-- **Technical Writer**: Ensures the changelog is readable for both humans and machines.
-
-## Insight Addon
-
-When recent work includes useful lessons, apply the `insight_extractor` pattern before writing the changelog:
-
-- Extract reusable patterns, gotchas, and file insights from task artifacts and git diff.
-- Keep lessons actionable and concise.
-- Include only user-facing changes in `CHANGELOG.md`; keep internal gotchas in `devflow/lessons.md` or task logs.
-
-## Management-Talk Addon
-
-When changelog input is too implementation-heavy, apply `.agents/skills/9arm-skills/management-talk/SKILL.md` as a credited communication lens:
-
-- Source pack: `9arm-skills`
-- Credit: `thananon/9arm-skills`
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-- Preserve user-facing impact, validation, risk, and follow-up.
-- Remove low-value internal details such as function names, long file paths, and commit SHAs unless they are needed for release decisions.
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Release communication support, not a numbered stage
-- Typical entry points: `/70-Release`, `Deploy`, `PR`
-- Typical handoff targets: `/60-Report`, `Wiki`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agent/resources/schemas/changelog_entry.template.md`
-- Related commands: `/70-Release`, `Deploy`, `PR`, `/60-Report`, `Wiki`
-
-
+
+description: Update CHANGELOG.md - Automatically gather changes from specs, git history, or current state to update the project changelog.
+---
+# Phase 53: Update Changelog
+
+This command automates the process of maintaining the `CHANGELOG.md` file by analyzing task specifications, git diffs, and the current project state.
+
+Primary behavior now lives in:
+
+```text
+.agents/skills/release-git-operations/SKILL.md
+```
+
+Treat this workflow file as a compatibility wrapper around that skill in `changelog` mode.
+
+## Usage
+
+Run the command by typing:
+```
+Changelog
+```
+
+## Objectives
+
+1.  **Change Detection**: Identify new features, fixes, and changes since the last recorded version in `CHANGELOG.md`.
+2.  **Automated Versioning**: Analyze the impact of changes to automatically select the next version number (Major, Minor, or Patch) based on Semantic Versioning (SemVer) principles.
+3.  **Source Analysis**:
+    *   Scan `devflow/` for `20-spec.md` files of active or recently completed tasks.
+    *   Check `git status` and `git diff` for uncommitted/staged changes.
+    *   Check `git log` if git is initialized to see history since the last tag or version entry.
+3.  **Automatic Formatting**: Generate a standardized changelog entry following the [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format.
+4.  **Consistency**: Ensure the `CHANGELOG.md` reflects the actual work done in the repository.
+
+## Process
+
+### 1. Version Detection & Setup
+1.  **Read Current Changelog**: Extract the latest version and date from `CHANGELOG.md`.
+2.  **Analyze & Determine Next Version**: 
+    *   Analyze the collected changes to decide the increment based on **Semantic Versioning (SemVer)**:
+        - **Major (+1.0.0)**: Use if there are breaking changes, [DELETE] operations on core modules, or major architectural shifts.
+        - **Minor (0.+1.0)**: Use if new features ([NEW]) or significant compatible additions are found.
+        - **Patch (0.0.+1)**: Use for bug fixes ([FIXED]), small tweaks ([MODIFY]), or documentation updates.
+    *   Auto-propose the version based on the highest impact category found.
+3.  **Get Current Date**: Use the current system date (YYYY-MM-DD).
+
+### 2. Information Gathering
+1.  **Scan devflow/**:
+    *   Find all `20-spec.md` files in subdirectories of `devflow/`.
+    *   Extract the `Goal` or `Requirements` sections to identify high-level features/fixes.
+2.  **Git Analysis** (if available):
+    *   Run `git status` to see current work in progress.
+    *   Run `git diff` to understand technical changes and impact.
+    *   Look for "BREAKING CHANGE" in git commit messages.
+3.  **Categorization & Impact Assessment**: Group findings and assess impact:
+    *   `Added` โ†’ Usually Minor.
+    *   `Changed` โ†’ Minor or Patch (Major if breaking).
+    *   `Fixed` โ†’ Patch.
+    *   `Removed` โ†’ Major (if public API/Core).
+    *   `Security` โ†’ Patch or Minor.
+
+### 3. Update CHANGELOG.md
+1.  **Template Verification**: Before generating a new changelog block, inspect `.agent/resources/schemas/changelog_entry.template.md`, use its headings, and manually apply the same no-placeholder gate to the inserted changelog block.
+2.  **Generate Entry**: Format the gathered information into a Markdown block.
+3.  **Insertion**: Use `replace_file_content` to insert the new version block at the top of the version list (usually after the header and description).
+4.  **Validation**: Ensure the file remains readable and correctly formatted.
+
+## Benefits
+- **Automation**: Reduces the manual effort of tracking changes.
+- **Accuracy**: Ensures all tasks documented in `devflow/` are captured.
+- **Standardization**: Maintains a consistent look and feel for project history.
+
+## System Prompt / Persona
+- **Release Engineer**: Focuses on clear, concise, and accurate documentation of software changes.
+- **Technical Writer**: Ensures the changelog is readable for both humans and machines.
+
+## Insight Addon
+
+When recent work includes useful lessons, apply the `insight_extractor` pattern before writing the changelog:
+
+- Extract reusable patterns, gotchas, and file insights from task artifacts and git diff.
+- Keep lessons actionable and concise.
+- Include only user-facing changes in `CHANGELOG.md`; keep internal gotchas in `devflow/lessons.md` or task logs.
+
+## Management-Talk Addon
+
+When changelog input is too implementation-heavy, apply `.agents/skills/9arm-skills/management-talk/SKILL.md` as a credited communication lens:
+
+- Source pack: `9arm-skills`
+- Credit: `thananon/9arm-skills`
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+- Preserve user-facing impact, validation, risk, and follow-up.
+- Remove low-value internal details such as function names, long file paths, and commit SHAs unless they are needed for release decisions.
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Release communication support, not a numbered stage
+- Typical entry points: `/70-Release`, `Deploy`, `PR`
+- Typical handoff targets: `/60-Report`, `Wiki`
+
+## Sources
+
+- `AGENTS.md`
+- `.agents/skills/release-git-operations/SKILL.md`
+- `.agent/resources/schemas/changelog_entry.template.md`
+- Related commands: `/70-Release`, `Deploy`, `PR`, `/60-Report`, `Wiki`
+
+

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

@@ -1,117 +1,117 @@
 ---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
+
+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