@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.13

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

@@ -1,87 +0,0 @@
----
-name: workflow-documentation-sync
-description: "[Devflow] 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.

package/template/.claude/skills/9arm-skills/README.md

@@ -1,51 +0,0 @@
----
-name: 9arm-skills
-description: Credited engineering discipline pack adapted from thananon/9arm-skills for Antigravity IDE and Nexus-DevFlow workflows.
-source_pack: 9arm-skills
-credit: thananon/9arm-skills
-upstream: https://github.com/thananon/9arm-skills
-adapted_for: Antigravity IDE / Nexus-DevFlow
----
-
-# 9arm-Skills Discipline Pack
-
-This pack adapts the engineering discipline ideas from `9arm-skills` into the Nexus-DevFlow `.agent` bundle.
-
-`9arm-skills` is used as a credited thinking layer, not as a replacement for Nexus-DevFlow. Users should keep invoking the normal workflows (`Debug`, `PR-Review`, `Insight`, `Agent`, `Help`). The workflow applies the relevant 9arm discipline internally and still writes the usual Nexus reports and artifacts.
-
-## Credit
-
-- Source pack: `9arm-skills`
-- Credit: `thananon/9arm-skills`
-- Upstream: https://github.com/thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-
-## Workflow Mapping
-
-| Nexus-DevFlow Workflow | Applied 9arm Skill | Purpose |
-|---|---|---|
-| `Debug` | `debug-mantra` | Reproduce before fixing, trace the real fail path, falsify hypotheses, and preserve breadcrumbs. |
-| `Insight` | `post-mortem` | Turn validated bug fixes and incidents into durable team knowledge. |
-| `PR-Review` | `scrutinize` | Review intent, smaller alternatives, actual paths, and findings before approving changes. |
-| `Agent code-reviewer` | `scrutinize` | Apply outsider review discipline to specialist code reviews. |
-| `PR`, `/60-Report`, `/70-Release`, `Help` | `management-talk` | Translate engineering details into stakeholder-readable status, impact, owner, and next step. |
-
-## Output Rule
-
-Keep Nexus-DevFlow output formats intact:
-
-- Debug output still goes to `devflow/debug/rca-{slug}.md`.
-- PR review output still uses the PR review report contract.
-- Specialist reports still go to `devflow/reports/`.
-- Lessons still go to `devflow/lessons.md` or task logs.
-
-When a report uses this pack, include a short source discipline note:
-
-```md
-## Source Discipline
-- Source pack: 9arm-skills
-- Applied skill: {skill-name}
-- Credit: thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-```
-

package/template/.claude/skills/9arm-skills/debug-mantra/SKILL.md

@@ -1,86 +0,0 @@
----
-name: 9arm-skills/debug-mantra
-description: Use during debugging and RCA. Requires reproduction, real fail-path tracing, hypothesis falsification, and breadcrumb cross-reference before proposing a fix.
-source_pack: 9arm-skills
-credit: thananon/9arm-skills
-upstream: https://github.com/thananon/9arm-skills
-adapted_for: Antigravity IDE / Nexus-DevFlow
----
-
-# Debug Mantra
-
-## Purpose
-
-Stop the Antigravity IDE agent from guessing during debug work. The agent must prove the bug path before recommending or applying a fix.
-
-This skill is a credited adaptation of `9arm-skills/debug-mantra` for Nexus-DevFlow.
-
-## Mantra
-
-```text
-Reproduce -> Trace fail path -> Falsify hypothesis -> Cross-reference breadcrumbs
-```
-
-## Required Discipline
-
-### 1. Reproduce First
-
-Do not propose a fix until there is a credible reproduction story.
-
-Capture:
-
-- exact symptom
-- expected behavior
-- observed behavior
-- reproduction steps
-- reproduction rate
-- environment or data conditions
-
-If the issue is intermittent, document the conditions and instrumentation needed to catch it instead of pretending it is solved.
-
-### 2. Trace The Real Fail Path
-
-Follow the actual runtime path end-to-end:
-
-- user action or incoming request
-- entrypoint
-- service/module boundaries
-- data reads and writes
-- external calls
-- final failure point
-
-Evidence should cite file paths, line numbers when available, commands, logs, or observed runtime output.
-
-### 3. Falsify Hypotheses
-
-List 2-4 plausible hypotheses and try to disprove them. A hypothesis that was ruled out is useful evidence and should be recorded.
-
-Use this table in RCA notes when helpful:
-
-| Hypothesis | Test / Evidence | Result | Ruled In/Out |
-|---|---|---|---|
-| {Hypothesis} | {Evidence} | {Result} | {Status} |
-
-### 4. Cross-Reference Breadcrumbs
-
-Keep a breadcrumb ledger so the investigation can be audited later:
-
-| Breadcrumb | Source | What It Proves | Follow-up |
-|---|---|---|---|
-| {Observation} | {File / command / log} | {Claim supported} | {Next step} |
-
-## Nexus-DevFlow Output
-
-When used by `Debug`, preserve the existing RCA output contract:
-
-- inspect `.agent/resources/schemas/rca.template.md`
-- write `devflow/debug/rca-{slug}.md`
-- include the normal RCA sections
-- add a short `Source Discipline` note crediting `9arm-skills/debug-mantra`
-
-Do not replace the RCA template with a custom 9arm-only format.
-
-## Hard Stop
-
-If there is no reproduction, no trace, and no falsified hypothesis, the correct output is an investigation plan, not a fix.
-

package/template/.claude/skills/9arm-skills/management-talk/SKILL.md

@@ -1,79 +0,0 @@
----
-name: 9arm-skills/management-talk
-description: Use to translate engineering detail into stakeholder-readable updates, PR summaries, changelog notes, standups, Slack/JIRA comments, or leadership talking points.
-source_pack: 9arm-skills
-credit: thananon/9arm-skills
-upstream: https://github.com/thananon/9arm-skills
-adapted_for: Antigravity IDE / Nexus-DevFlow
----
-
-# Management Talk
-
-## Purpose
-
-Translate engineering-to-engineering detail into decision-ready communication for PMs, leads, release managers, support, and executives.
-
-This skill is a credited adaptation of `9arm-skills/management-talk` for Nexus-DevFlow.
-
-## What To Preserve
-
-Keep:
-
-- current status
-- user or business impact
-- risk
-- owner
-- next step
-- timeline or blocking condition
-- validation status
-
-Remove or compress unless needed:
-
-- internal function names
-- long file paths
-- commit SHAs
-- implementation details that do not affect decisions
-- speculative blame
-
-## Output Shapes
-
-### Status Update
-
-```md
-## Source Discipline
-- Source pack: 9arm-skills
-- Applied skill: management-talk
-- Credit: thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-
-## Current Status
-## Impact
-## Owner
-## Next Step
-## Risk / Blocker
-```
-
-### PR / Release Summary
-
-```md
-## What Changed
-## Why It Matters
-## Validation
-## Risk
-## Rollback / Follow-up
-```
-
-### Incident / Bug Summary
-
-```md
-## What Happened
-## Who Was Affected
-## Current State
-## Fix / Mitigation
-## Prevention
-```
-
-## Nexus-DevFlow Output
-
-Use this skill inside `PR`, `/60-Report`, `/70-Release`, and `Help` when the user needs a human-readable summary. Keep existing Nexus output formats and destinations intact.
-

package/template/.claude/skills/9arm-skills/post-mortem/SKILL.md

@@ -1,71 +0,0 @@
----
-name: 9arm-skills/post-mortem
-description: Use after a bug, outage, or regression has been fixed and validated. Converts the fix into durable engineering knowledge.
-source_pack: 9arm-skills
-credit: thananon/9arm-skills
-upstream: https://github.com/thananon/9arm-skills
-adapted_for: Antigravity IDE / Nexus-DevFlow
----
-
-# Post-Mortem
-
-## Purpose
-
-Convert a resolved issue into team memory. A fix is not complete until the team can explain what broke, why it broke, how it was fixed, how it was validated, and why it slipped through.
-
-This skill is a credited adaptation of `9arm-skills/post-mortem` for Nexus-DevFlow.
-
-## When To Use
-
-Use after:
-
-- `Debug` found a root cause
-- `/40-Implement` applied a fix
-- `/50-Verify` or manual validation proved the fix
-- a production incident, regression, or high-risk bug deserves durable learning
-
-Do not write a confident post-mortem before the fix and validation evidence exist.
-
-## Required Inputs
-
-- reliable reproduction or incident timeline
-- root cause
-- fix summary
-- validation evidence
-- affected user or system impact
-- prevention measure or follow-up
-
-If inputs are missing, list the gaps and request the missing evidence.
-
-## Report Sections
-
-Use these sections inside `devflow/lessons.md`, task logs, or a task-linked report when appropriate:
-
-```md
-## Source Discipline
-- Source pack: 9arm-skills
-- Applied skill: post-mortem
-- Credit: thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-
-## What Broke
-## Impact
-## Reliable Repro / Timeline
-## Root Cause
-## Fix
-## Validation Evidence
-## Why It Slipped Through
-## Prevention / Follow-up
-```
-
-## Nexus-DevFlow Output
-
-Prefer existing destinations:
-
-- task-specific insight: record the final lesson in the active markdown artifacts for that running ID, or in `devflow/lessons.md`
-- project-wide lesson: `devflow/lessons.md` using `.agent/resources/schemas/lessons.template.md`
-- release-facing summary: `/70-Release`
-- stakeholder summary: `management-talk`
-
-Keep the output concise and actionable. Avoid blame.
-

package/template/.claude/skills/9arm-skills/scrutinize/SKILL.md

@@ -1,72 +0,0 @@
----
-name: 9arm-skills/scrutinize
-description: Use for plan, PR, and code review. Starts by challenging whether the change should exist, then checks smaller alternatives and traces actual code paths.
-source_pack: 9arm-skills
-credit: thananon/9arm-skills
-upstream: https://github.com/thananon/9arm-skills
-adapted_for: Antigravity IDE / Nexus-DevFlow
----
-
-# Scrutinize
-
-## Purpose
-
-Review with an outsider perspective before accepting a plan, PR, or code change. The first question is not "is this code correct?" but "should this change exist in this form?"
-
-This skill is a credited adaptation of `9arm-skills/scrutinize` for Nexus-DevFlow.
-
-## Review Sequence
-
-### 1. Intent Check
-
-Clarify:
-
-- what problem the change is solving
-- what user or system behavior should change
-- what is explicitly out of scope
-- whether the change matches the task, spec, or PR description
-
-### 2. Smaller / Safer Alternative
-
-Before reviewing details, ask:
-
-- can this be solved with less code?
-- can this reuse an existing pattern?
-- can the risk be split into smaller changes?
-- is any dependency, abstraction, migration, or API surface unnecessary?
-
-### 3. Trace The Actual Path
-
-Do not review only the diff. Follow the end-to-end path that will execute after the change:
-
-- entrypoint
-- existing callers
-- changed module
-- downstream effects
-- persistence or external boundaries
-- error path and fallback behavior
-
-### 4. Findings First
-
-Report actionable findings first, ordered by severity. Avoid style-only comments unless style hides real risk.
-
-## Nexus-DevFlow Output
-
-When used by `PR-Review`, preserve `.agent/resources/schemas/pr_review.template.md` and add scrutiny context without replacing the required sections.
-
-Recommended extra sections:
-
-```md
-## Source Discipline
-- Source pack: 9arm-skills
-- Applied skill: scrutinize
-- Credit: thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-
-## Intent Check
-## Smaller Alternative Considered
-## Actual Path Trace
-```
-
-For `Agent code-reviewer`, save substantial reports under `devflow/reports/` unless the invoking workflow has a more specific destination.
-