@jakkrichm/create-nexus-devflow 2.0.11 → 2.0.13

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

@@ -3,77 +3,68 @@ name: simplify
 description: "[Devflow] Code simplification and refactoring for clarity and maintainability without altering runtime behavior."
 ---
 
----
-description: Simplify code for clarity and maintainability while preserving behavior.
----
-
-# Simplify - Code Simplification And Refactoring
+# Code Simplification & Refactoring
 
-Invoke the `code-simplification` skill.
+## Overview
 
-Primary behavior already lives in:
-
-```text
-.agents/skills/code-simplification/SKILL.md
-```
+This is the comprehensive code simplification master skill for Nexus-DevFlow. It reduces cognitive load, cleans up unnecessary abstractions, flattens deep nesting, and removes dead code while **preserving 100% exact runtime behavior**.
 
-Treat this workflow file as a wrapper around that skill.
+**Core Rule**: Every simplification must pass: *"Would a new team member understand this faster than the original, without any behavioral regression?"*
 
-Use this workflow when the code works but has grown harder to read, harder to change, or more general than necessary.
+---
 
-In DevFlow 2.0, `Simplify` is a supporting implementation workflow. It usually pairs with `40-implement` and should end in `50-verify`.
+## 1. The Five Principles of Simplification
 
-## Process
+1. **Preserve Behavior Exactly**: Same inputs, outputs, error conditions, side effects, and ordering.
+2. **Follow Project Conventions**: Consistency with neighboring files beats personal style preferences.
+3. **Delete Dead & Unused Code**: Remove abandoned helpers, dead branch paths, and leftover debugging code.
+4. **Flatten Control Flow**: Replace nested conditionals and callback pyramids with guard clauses and early returns.
+5. **Eliminate Speculative Generalization**: Replace single-use abstractions with clear, direct implementations.
 
-1. Read project instructions and study local conventions.
-2. Identify the target code: recent changes unless a broader scope is specified.
-3. Understand purpose, callers, edge cases, and test coverage before touching it.
-4. Scan for simplification opportunities:
-   - deep nesting to guard clauses or extracted helpers
-   - long functions to responsibility-based splits
-   - nested ternaries to clearer control flow
-   - vague names to descriptive names
-   - duplicated logic to shared helpers
-   - dead code to removal after confirmation
-   - speculative abstraction to simpler concrete flow
-5. Inspect `.agent/resources/schemas/refactoring.template.md` before generating a report.
-6. Apply each simplification incrementally and run verification after each meaningful change.
-7. Save the refactoring report to:
+---
 
-```text
-devflow/reports/{date}-refactoring-{slug}.md
+## 2. High-Impact Simplification Techniques
+
+### A. Guard Clauses Over Nested Conditionals
+```typescript
+// Before: Deep indentation
+function processOrder(order) {
+  if (order) {
+    if (order.isValid) {
+      if (order.isPaid) {
+        return fulfill(order);
+      }
+    }
+  }
+}
+
+// After: Early returns
+function processOrder(order) {
+  if (!order || !order.isValid) return;
+  if (!order.isPaid) return;
+  return fulfill(order);
+}
 ```
 
-8. Verify tests pass, the build succeeds, and the diff stays behavior-preserving.
-
-If tests fail after a simplification, revert that specific change and reconsider.
+### B. Inline Single-Use Helpers & Dead Shims
+If a helper function is only called once and adds indirection without semantic clarity, inline it directly.
 
-## Output
+### C. Remove Dead Code & Leftover Comments
+Delete commented-out code blocks, `// removed` notes, and unused variables (`_unused`). Version control (Git) remembers the history.
 
-Return:
-
-- what was simplified
-- what was intentionally left alone
-- validation evidence
-- remaining risks or debt
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `40-implement`, `50-verify`, `PR-Review`, `Agent`
-- Typical handoff targets: `40-implement`, `50-verify`, `PR-Review`
+---
 
-## Sources
+## 3. Verification & Safety Loop
 
-- `AGENTS.md`
-- `.agents/skills/code-simplification/SKILL.md`
-- `.agent/resources/schemas/refactoring.template.md`
-- Related commands: `40-implement`, `50-verify`, `PR-Review`, `Agent`
+1. Run unit tests before touching code (`npm test` -> GREEN).
+2. Apply one small refactoring step at a time.
+3. Rerun tests immediately after each step. If tests break, revert and reconsider.
+4. Verify overall build and linter checks.
 
-## Next Workflow Recommendation
+---
 
-- **Primary**: `50-verify`
-- **Why**: simplification should finish with explicit proof that behavior did not regress
-- **Alternative**: `40-implement` when simplification exposed a deeper implementation change rather than a pure refactor
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Refactoring support
+- **Mainline integration**: Used during `40-implement` (Refactor step of TDD) or `50-verify`.
+- **Handoff**: `50-verify` (proves zero regressions).

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

@@ -1,82 +1,94 @@
 ---
 name: test
-description: "[Devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
+description: "[Devflow] Test-driven development, test generation, test execution, and coverage analysis across unit, integration, and smoke test suites."
 ---
 
----
-description: Test Generation and Execution - Generates missing tests, runs existing test suites, or checks test coverage for the project.
----
-# ๐Ÿงช Test Generation and Execution
-
-## Usage: `/13-Test [target]`
+# Test-Driven Development, Generation & Execution
 
-Generates missing tests, runs existing test suites, or checks test coverage for the project.
+## Overview
 
-Primary behavior now lives in:
+This is the comprehensive testing master skill for Nexus-DevFlow. It drives development with tests (TDD), handles test generation, execution, coverage analysis, and bug reproduction. Tests are proof — "seems right" is not done.
 
 ```text
-.agents/skills/test-execution-and-coverage/SKILL.md
+    RED                GREEN              REFACTOR
+ Write a test    Write minimal code    Clean up the
+ that fails  ──→  to make it pass  ──→  implementation  ──→  (repeat)
+      │                  │                    │
+      ▼                  ▼                    ▼
+   Test FAILS        Test PASSES         Tests still PASS
 ```
 
-Treat this workflow file as a compatibility wrapper around that skill.
+## Usage & Sub-Commands
+
+- `/test`                - Run all project test suites
+- `/test [file/feature]` - Generate tests for a specific target
+- `/test coverage`       - Show test coverage report
+- `/test watch`          - Run tests in watch mode
 
 ---
 
-## ๐Ÿ› ๏ธ Sub-commands
+## 1. The TDD Cycle
+
+### Step 1: RED — Write a Failing Test
+Write the test first. It must fail. A test that passes immediately proves nothing.
+
+### Step 2: GREEN — Make It Pass
+Write the minimum code to make the test pass. Avoid premature over-engineering.
 
-- `/13-Test`                - Run all tests
-- `/13-Test [file/feature]` - Generate tests for a specific target
-- `/13-Test coverage`       - Show test coverage report
-- `/13-Test watch`          - Run tests in watch mode
+### Step 3: REFACTOR — Clean Up
+Improve code readability, naming, structure, and eliminate duplication while keeping tests green.
 
 ---
 
-## ๐Ÿšฆ Internal Process
+## 2. The Prove-It Pattern (Bug Reproduction)
 
-### Scenario A: Generate Tests
-If the user requests tests for a target:
-1. **Analyze**: Identify functions, edge cases, and external dependencies.
-2. **Template Verification**: **MANDATORY:** Before generating the test plan, inspect `.agent/resources/schemas/test_report.template.md`, preserve its required layout, and replace placeholder text with concrete coverage, command output, failures, and gaps.
-3. **Generate Cases**: Develop Happy path, Error cases, Edge cases.
-4. **Write**: Implement the tests using the project's testing framework (Pytest, Jest, Vitest, etc.). Follow the `Arrange-Act-Assert` pattern and mock external dependencies.
-5. **Save Test Report**: Save the test plan and results to `devflow/reports/{date}-test-report-{target}.md` (where `{date}` is today's date in `YYYY-MM-DD` format and `{target}` is a slugified version of the file or feature name).
+When fixing any defect, **do not attempt a fix without proving the bug exists first**:
 
-### Scenario B: Execute Tests
-Use the project's native command (e.g., `npm test`, `pytest`) to run the tests and format the output clearly for the user. Highlight any failed tests with expected vs received values. Save the execution summary report matching the template to `devflow/reports/{date}-test-report-run.md` (where `{date}` is today's date in `YYYY-MM-DD` format).
+```text
+Bug report arrives ➔ Write reproduction test (FAILS) ➔ Implement fix ➔ Test PASSES ➔ Guard regression
+```
 
 ---
 
-## ๐Ÿ›ก๏ธ Key Principles
-- **Test behavior, not implementation.**
-- **One assertion per test** (when practical).
-- **Descriptive test names.**
-- **Arrange-Act-Assert pattern.**
-- **Save Report**: Always save the test plan or results to disk for persistent logging.
+## 3. The Test Pyramid & Resource Sizes
 
-## ๐Ÿ“ Output Formats
+| Level | Size | Target % | Scope & Characteristics |
+| :--- | :--- | :--- | :--- |
+| **Unit** | Small | ~80% | Pure logic, in-memory, single process, milliseconds each |
+| **Integration** | Medium | ~15% | API boundaries, database interaction, component seams |
+| **E2E** | Large | ~5% | Critical user journeys, full workflows, browser automation |
 
-### For Test Generation
-Generate a summary indicating:
-- **Test Plan**: Table of Test Case, Type, Coverage (Happy path, error case, validation)
-- **Generated Tests**: File path and the code block
-- **Report Location**: Confirm the report has been written to the specified workspace path.
-- **Run command**: e.g. `npm test`
+---
 
-### For Test Execution
-Display an organized output listing Passed/Failed files, and explicitly show the expectation vs received outcome for failed assertions.
+## 4. Key Testing Principles & Best Practices
 
-## Relationship To DevFlow 2.0
+1. **Test behavior, not implementation details**: Assert on output and state changes, not private method call sequences.
+2. **DAMP over DRY in tests**: Descriptive and meaningful test setup beats overly abstract shared helpers.
+3. **Arrange-Act-Assert**: Distinct setup, action, and verification phases in every test case.
+4. **Prefer real implementations & fakes over heavy mocks**: Mock only at boundaries where real dependencies are slow or non-deterministic.
+5. **One assertion concept per test**: Isolate test failure reasons clearly.
 
-- Classification: Companion command
-- Mainline status: Verification support command, not a numbered stage
-- Typical entry points: `40-implement`, `50-verify`, `Debug`
-- Typical handoff targets: `50-verify`, `Debug`, `QA-Orchestrate`
+---
+
+## 5. Browser Testing & Runtime Verification
+
+For browser and UI features, unit tests alone are insufficient:
+- **Console**: Zero errors and unhandled exceptions in production code.
+- **Network**: Accurate status codes, payload shapes, and CORS handling.
+- **DOM & Styles**: Verified layout rendering, accessibility tree, and responsive behaviors.
+
+---
+
+## 6. Test Generation & Persistent Execution Reports
 
-## Sources
+When generating or logging test runs during `40-implement` or `50-verify`:
+- Save summary reports to `devflow/reports/{date}-test-report-{slug}.md`
+- Include: Target, Test Cases (Happy Path, Error, Edge Cases), Pass/Fail statistics, and gaps/risks.
 
-- `AGENTS.md`
-- `.agents/skills/test-execution-and-coverage/SKILL.md`
-- `.agent/resources/schemas/test_report.template.md`
-- Related commands: `40-implement`, `50-verify`, `Debug`, `QA-Orchestrate`
+---
 
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Engineering standard
+- **Mainline stages**: `30-plan` (TDD decisions), `40-implement` (TDD execution), `50-verify` (QA gate)
+- **Handoff**: `50-verify`, `Debug`, `autopilot`

package/template/.claude/skills/70-release/SKILL.md

@@ -77,6 +77,8 @@ Before packaging, merging, or releasing:
    - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
 3. **Archive Resolved Findings**:
    - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
+4. **Append to Master History Ledger**:
+   - บันทึก Entry ใหม่ลงใน `devflow/history/HISTORY.md` พร้อมระบุ Running ID, Title, วันที่, Git Commit Hash / Tag, สถานะ (`Released`), และลิงก์ไปยังรายงานสรุป `60-report.md`
 
 ### 1. Load Verified Context
 

package/template/.claude/skills/ci/SKILL.md

@@ -1,70 +1,36 @@
 ---
 name: ci
-description: "[Devflow] Set up automated GitHub Actions CI workflow (.github/workflows/verify.yml) aligned with project verify command."
+description: "[Devflow] CI/CD pipeline automation and GitHub Actions setup (.github/workflows/verify.yml). Automates quality gates, typechecks, tests, and build checks."
 ---
 
-# ci - Automated GitHub Actions Pipeline Setup
+# CI/CD Pipeline Automation & Quality Gates
 
-Where this sits in the workflow:
+## Overview
+
+This is the CI/CD and automation master skill for Nexus-DevFlow. It automates quality gates so that no change reaches production without passing static analysis, typechecking, tests, security audits, and builds.
 
 ```text
-onboard or adopt  ->  [ci]  ->  Verify locally  ->  GitHub Actions runs Verify on PR & Push
-(project setup)         (setup)    (same command)     (automated checks)
+PR / Push ➔ Lint & Typecheck ➔ Unit & Integration Tests ➔ Build Verification ➔ Security Audit
 ```
 
-This skill connects local verification with automated GitHub checks using **one shared Verify recipe**:
-
-- **Verify is the recipe**: Runs the project's real checks (typecheck, tests, build) defined in `AGENTS.md`.
-- **GitHub Actions is the worker**: Executes the same recipe automatically on pull requests and pushes.
-- **Branch Protection / Ruleset is the gate**: Optionally requires the check to pass before merging.
-
-This skill configures the workflow file. It **never pushes to remote, changes remote repository rulesets, or publishes releases** without explicit permission.
-
-## Input
-
-No argument is required. A preferred package manager or branch name can be optionally provided.
-
-## Step 1 - Inspect Project Setup (Read-Only)
-
-Inspect the repository without modifying files:
-
-1. **Commands in `AGENTS.md`**: Look for existing `Verify`, `Test`, `Build`, and `Dev` commands.
-2. **Project Manifests**: `package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc.
-3. **Lockfiles & Package Manager**: `pnpm-lock.yaml` (pnpm), `package-lock.json` (npm), `yarn.lock` (yarn), `bun.lockb` (bun), `poetry.lock` (poetry), `Cargo.lock` (cargo).
-4. **Runtime Versions**: `.node-version`, `.nvmrc`, `package.json` engines, `.python-version`.
-5. **Existing Workflows**: Inspect `.github/workflows/` to check if a CI workflow already exists.
-6. **Git Default Branch**: Detect `main` or `master`.
-
-If a healthy and matching workflow already exists, report that CI is already in place and stop.
-
-## Step 2 - Define The Single Verify Command
-
-Build one combined Verify command from actual checks that exist in the project, in this standard order:
-
-1. **Typecheck** (e.g. `tsc --noEmit`, `mypy`, `pyright`, `go vet`)
-2. **Tests** (e.g. `npm test`, `pytest`, `go test ./...`, `cargo test`) - only if real tests exist
-3. **Build** (e.g. `npm run build`, `cargo build`)
-
-For JavaScript/TypeScript projects, ensure a `verify` or `check` script exists in `package.json` (or combine existing scripts: e.g. `npm run check:static && npm test && npm run build`).
-
-Record the exact command in the Commands section of `AGENTS.md`:
+---
 
-```markdown
-## Commands
-- Verify: `npm run check` (or detected verify command)
-```
+## 1. Shift-Left Quality Gate Pipeline
 
-## Step 3 - Generate `.github/workflows/verify.yml`
+1. **Static Analysis & Typecheck**: `tsc --noEmit`, `eslint`, `biome` (Catches syntax & type flaws in seconds).
+2. **Automated Tests**: Unit & Integration tests (`npm test`, `pytest`, `go test`).
+3. **Build Integrity**: `npm run build` (Ensures bundle compiles cleanly without warnings).
+4. **Security Hygiene**: `npm audit --audit-level=high` (Flags vulnerable dependencies).
 
-Create `.github/workflows/verify.yml` with security and stability best practices:
+---
 
-- **Trigger**: Pull requests to default branch + Pushes to default branch.
-- **Permissions**: Set least privilege `permissions: contents: read`.
-- **Concurrency**: Cancel in-progress runs on the same PR branch.
-- **Lockfile-Safe Install**: Use `npm ci`, `pnpm install --frozen-lockfile`, `yarn install --immutable`, or `cargo --locked`.
-- **Exact Verify Step**: Run the exact Verify command from `AGENTS.md`.
+## 2. GitHub Actions Setup (`.github/workflows/verify.yml`)
 
-### Standard GitHub Actions Template (Node.js Example):
+When setting up or updating CI:
+- **Trigger**: Pull requests and pushes to `main` / `master`.
+- **Permissions**: Enforce least privilege (`permissions: contents: read`).
+- **Concurrency**: Cancel stale in-progress runs on the same PR.
+- **Deterministic Install**: Use `npm ci` or `--frozen-lockfile`.
 
 ```yaml
 name: Verify
@@ -90,7 +56,7 @@ jobs:
       - name: Checkout Code
         uses: actions/checkout@v4
 
-      - name: Setup Runtime
+      - name: Setup Node
         uses: actions/setup-node@v4
         with:
           node-version: 20
@@ -103,29 +69,10 @@ jobs:
         run: npm run check
 ```
 
-## Step 4 - Verify Locally
-
-Execute the Verify command locally to confirm that it succeeds on clean code before recommending it:
-
-```bash
-npm run check
-```
-
-If local verification fails, report the failing check and assist in resolving it before claiming CI readiness.
-
-## Step 5 - Summary & Handoff
-
-Output a concise summary:
-
-- **Verify Command**: Documented command in `AGENTS.md`.
-- **Workflow File**: `.github/workflows/verify.yml` (created/updated).
-- **Trigger Events**: `pull_request` & `push`.
-- **Local Test**: Result of local execution.
-- **Next Steps**: Advise user to commit and push the workflow to activate GitHub Actions.
+---
 
-## Rules
+## Relationship To DevFlow 2.0
 
-- **Preserve Existing CI**: Never overwrite existing custom workflows without explicit user consent.
-- **No Dummy Tests**: Do not invent fake test commands or install unrequested test runners.
-- **Least Privilege Security**: Always specify `permissions: contents: read`.
-- **No Auto-Push**: Stop at local file creation; do not push to remote automatically.
+- **Classification**: Companion command & Automated testing infrastructure
+- **Mainline integration**: Invoked via `/ci` during `onboard` or `adopt`.
+- **Handoff**: `50-verify`, `70-release`

package/template/.claude/skills/commit/SKILL.md

@@ -1,63 +1,59 @@
----name: commit
-
-description: "[Devflow] Smart Commit (Git Orchestration) - Stage files intelligently and write a concise, imperative commit message according to project standards."
 ---
-# ๐Ÿ’พ Smart Commit (Git Orchestration)
+name: commit
+description: "[Devflow] Smart Commit (Git Orchestration) - Stage files intelligently, write conventional imperative commit messages, and manage trunk-based versioning."
+---
 
-## Target: $ARGUMENTS
+# Smart Commit & Git Workflow Versioning
 
-Stage files intelligently and write a concise, imperative commit message according to project standards.
+## Overview
 
-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 `commit` mode.
+This is the Git orchestration and versioning master skill for Nexus-DevFlow. It enforces atomic commits, conventional commit formatting, intelligent staging, and safe trunk-based workflows. Commits are save points, branches are sandboxes, and Git history is durable documentation.
 
 ---
 
-## ๐Ÿ› ๏ธ Internal Process
+## 1. Commit Discipline & The Conventional Commits Standard
+
+Each commit should represent one atomic, self-contained change:
 
-You are an orchestrator. Your goal is to call the specialized Git Committer agent to perform a high-quality commit.
+```text
+<type>(<scope>): <short imperative summary>
 
-### Phase 1: Assessment & Staging
-**Call Agent**: `prp-core-git-committer`
-- Provide the target description (e.g., "all", "backend only", "staged").
-- The agent will:
-  - Check the current Git status and branch.
-  - **MANDATORY BRANCH RULE:** Use the user's current branch as-is. Do not create, switch, or checkout a branch automatically. Only create or switch branches when the user explicitly asks for that exact branch action in the current request.
-  - If the current branch appears risky for the intended commit (for example `main`/`master` or a protected branch), warn the user and ask whether they want to continue on the current branch or explicitly create/switch to another branch.
-  - Interpret your description to stage the correct files.
-  - Review the staged changes to understand the context.
+[optional detailed body explaining WHY, not WHAT]
+```
 
-### Phase 2: Message Generation & Commit
-- Ensure the agent generates an imperative commit message (e.g., `feat: Add user auth`).
-- The agent will execute the commit and capture the result.
+### Commit Types:
+- `feat`: A new user-facing feature or capability
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `test`: Adding missing tests or correcting existing tests
+- `chore`: Maintenance, build tasks, package updates
 
-### Phase 3: Result Summary
-- Verify the agent reports:
-  - Commit Hash.
-  - Final Commit Message.
-  - Statistics (Files changed, additions, deletions).
+### Formatting Rules:
+- Use the imperative mood: `"feat(auth): add password reset flow"` (NOT `"added"` or `"adds"`).
+- Never mix formatting/refactoring with behavioral feature changes in the same commit.
 
 ---
 
-๐Ÿ“Œ **Next Step**: Run `PR` to create a Pull Request.
+## 2. Trunk-Based Branching & Safety
 
-## Relationship To DevFlow 2.0
+- **Keep `main` deployable**: Feature branches (`feature/{slug}-{running-id}`) must be short-lived.
+- **Never commit directly to `main` without review**: Use feature/fix branches during development.
+- **Small, verified increments**: Test and verify before committing each checkpoint.
 
-- Classification: Companion command
-- Mainline status: Release support command, not a numbered stage
-- Typical entry points: `70-release` after the report is aligned and release execution is ready
-- Typical handoff targets: `PR`, `Deploy`, `70-release`
+---
 
-## Sources
+## 3. Execution Flow
 
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `70-release`, `PR`, `Deploy`, `Merge`
+1. Check `git status` and verify current branch.
+2. Stage relevant files explicitly (`git add <files>` — avoid blindly running `git add .` if untracked temporary files exist).
+3. Generate concise conventional commit message.
+4. Execute `git commit` and capture commit hash.
 
+---
+
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Version control support
+- **Mainline integration**: Used during `40-implement` (checkpoint commits), `70-release` (final release commit).
+- **Handoff**: `pr`, `merge`, `70-release`