@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.14

package/template/.agents/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`

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

@@ -0,0 +1,73 @@
+---
+name: complete
+description: "[Devflow] Fast-Track Complete stage in DevFlow (Blueprint Mode) - perform final safety pass, record release digest in spec.md, git merge, and close run without auto HTML generation."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Fast-Track: Complete (Blueprint Mode)
+
+$ARGUMENTS
+
+Final delivery, safety pass, and run closure stage in Fast-Track. Validates verification status, records the Release Digest into `spec.md`, performs git merge, and marks the run as completed **without auto-generating HTML reports**.
+
+## Invocations & Aliases
+
+- `/complete`: Complete current active run
+- `/complete {running-id}`: Complete specified running ID
+- `$complete`: Codex CLI invocation
+
+## Fast-Track Mainline Workflow
+
+```text
+/spec ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Validate Delivery Pre-conditions
+1. Identify active Running ID from `devflow/context/current-stage.md` or argument.
+2. Read `devflow/runs/{RUNNING_ID}/spec.md`.
+3. Confirm:
+   - All checklist items in `## 3. Implementation Checklist` are marked `- [x]`.
+   - `## 5. Verification Evidence` contains passing verification results.
+
+### 2. Final Safety Pass & Changelog
+1. Verify working directory hygiene (no accidental leftover test files or debug statements).
+2. Update `CHANGELOG.md` with release summary under the current version if applicable.
+
+### 3. Update Living Spec (`spec.md`)
+Append or update `## 6. Release & Handoff` in `spec.md` in **Thai (`th`)**:
+
+```markdown
+## 6. Release & Handoff
+- **Release Digest**: สรุปสิ่งที่ส่งมอบในรอบนี้
+- **Git Branch**: `{branch_name}`
+- **Merge Status**: Merged into `main` (Commit `{commit_hash}`)
+- **Artifact Contract**: Fast-Track Single Living Spec completed.
+```
+Update header status in `spec.md`: `> **Status**: Completed`.
+
+### 4. Policy on HTML Reports (Strict Rule)
+> [!IMPORTANT]
+> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `report.html` หรือ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้โดยเด็ดขาด!
+> หากผู้ใช้ต้องการดู HTML Dashboard สวยงาม ให้แจ้งผู้ใช้ว่าสามารถเรียกคำสั่งแยกได้: `/report:html`
+
+### 5. Git Merge & Branch Cleanup
+1. Commit all modified tracking files (including `spec.md` and `current-stage.md`).
+2. Merge feature branch into target base branch (`main` / `master`).
+
+### 6. Close Active Run
+Update `devflow/context/current-stage.md`:
+- `Active Running ID`: `None (Idle)`
+- `Current Stage`: `Idle (Ready for new /spec, /feature, /fix, or /00-discover)`
+- `Last Completed Run`: `{RUNNING_ID} ({YYYY-MM-DD})`
+- `Last Updated`: `{YYYY-MM-DD}`
+
+### 7. Output Completion Report
+Report to the user:
+- Run successfully completed and merged
+- Living Spec path: `devflow/runs/{RUNNING_ID}/spec.md`
+- Standalone HTML command tip: `/report:html` (if HTML view is desired)
+- Workspace is now Idle and ready for the next task.

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

@@ -3,129 +3,68 @@ name: debug
 description: "[Devflow] Root cause investigation and diagnostic loop before or during implementation without editing code. Use when encountering broken behavior, test failures, or bugs."
 ---
 
----
-description: Root cause analysis and debugging. Transitional compatibility path for the Debug companion command in DevFlow 2.0.
----
-
-# Debug - Root Cause Analysis
-
-## Issue: $ARGUMENTS
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Debug` is a companion command, not a numbered mainline workflow. Its investigative depth should remain comparable to the original debug workflow.
-
-## Purpose
-
-Use `Debug` to find the actual origin of an issue, not just the visible symptom.
-
-Use it when:
-
-- implementation work is blocked by a defect
-- verification reveals a failure that needs root-cause analysis
-- the team needs RCA before deciding the next implementation step
+# Debug & Root Cause Analysis (RCA)
 
-Preferred DevFlow 2.0 pairing:
+## Overview
 
-- from `00-discover` when a new request begins with a failure whose root cause is unknown
-- from `40-implement`
-- from `50-verify`
+This is the comprehensive debugging master skill for Nexus-DevFlow. It guides systematic root-cause investigation without blindly editing code. The goal is to find the actual origin of an issue, not merely suppress visible symptoms.
 
-When invoked with a Discovery ID, link the RCA report to that discovery and return to `00-discover {discovery_id}` for the delivery decision. Do not allocate a Running ID for an unapproved fix during Debug.
-
-## Source Discipline
-
-Apply the local skill pack at `.agents/skills/9arm-skills/debug-mantra/SKILL.md`.
-
-- Source pack: `9arm-skills`
-- Credit: `thananon/9arm-skills`
-- Upstream: https://github.com/thananon/9arm-skills
-- Mantra: `Reproduce -> Trace fail path -> Falsify hypothesis -> Cross-reference breadcrumbs`
+**The Debug Mantra (9arm Pattern)**:
+```text
+Reproduce ➔ Trace Fail Path ➔ Falsify Hypotheses ➔ Cross-reference Breadcrumbs ➔ RCA Proof
+```
 
 ---
 
-## Internal Process
-
-You are doing Root Cause Analysis, not just symptom triage. Keep the richer original debugging discipline and map the next step back into DevFlow 2.0.
-
-### Phase 1: Reproduce And Classify
-
-- restate the symptom clearly
-- capture expected vs actual behavior
-- determine whether the issue is reproducible
-- do not recommend a fix before the reproduction story is credible
+## 1. The 4-Phase Diagnostic Loop
 
-### Phase 2: Isolate And Hypothesize
+### Phase 1: Reproduce & Classify
+- Restate the observed symptom vs. expected behavior with exact steps.
+- Create a minimal reproduction script, test case, or curl command.
+- Rule: **Do not propose a code fix before the reproduction story is verified.**
 
-- identify likely components, recent changes, or conditions
-- generate 2-4 hypotheses ordered by likelihood
-- define what evidence would falsify each hypothesis
+### Phase 2: Isolate & Hypothesize
+- Generate 2–4 distinct hypotheses ranked by probability.
+- Formulate specific criteria and evidence that would *falsify* each hypothesis.
 
-### Phase 3: Investigate With Evidence
+### Phase 3: Non-Destructive Investigation
+- Trace code execution paths end-to-end (stack traces, logs, variable states, async boundaries).
+- Inspect recent commits or configuration changes that touch the affected boundary.
+- Test hypotheses methodically using tests and logging without altering business logic.
 
-- trace the real fail path end-to-end
-- test hypotheses methodically
-- record evidence with file:line or command output
-- maintain a breadcrumb trail of observations and conclusions
+### Phase 4: Root Cause Conclusion (RCA)
+- State precisely *why* the bug occurred (underlying invariant violation).
+- Define the minimal, robust architectural fix direction.
+- Propose regression prevention measures (unit test, type guard, linter rule).
 
-### Phase 4: Conclude With RCA
-
-- name the root cause
-- explain why it is the root cause
-- describe the fix direction
-- capture prevention or follow-up measures
-
-This command supports the active stage. It does not replace the mainline stage itself.
-
-## Output Format
-
-Save the RCA report to `devflow/debug/rca-{slug}.md`.
-
-Before generating the report:
+---
 
-1. Inspect `.agent/resources/schemas/rca.template.md`
-2. Preserve its required headings and structure
-3. Replace placeholder text with concrete evidence
-4. Re-check the output against `rca.template.md`, ensure required headings remain, and remove all placeholders before completion
+## 2. Output Format (RCA Report)
 
-Present the summary in this shape:
+Save substantial RCA investigations under:
+```text
+devflow/debug/rca-{slug}.md
+```
 
+Structure:
 ```markdown
 ## Debug Summary
 
-1. **Symptom**: [What is happening]
-2. **Evidence**: [error log, file, line, failing command]
-3. **Investigation Path**: [what was tested and what happened]
-4. **Root Cause**: [why this happened]
-5. **Fix Direction**: [what should be changed]
-6. **Prevention**: [how to avoid recurrence]
+1. **Symptom**: [What is happening vs expected]
+2. **Evidence**: [Error logs, stack trace, file:line references]
+3. **Investigation Path**: [Hypotheses tested and falsification proof]
+4. **Root Cause**: [The exact mechanism causing the failure]
+5. **Fix Direction**: [Recommended scoped change]
+6. **Regression Guard**: [Reproduction test to add before fixing]
 ```
 
-## Examples
-
-```text
-Debug flaky login redirect
-Debug failing migration in CI
-Debug why webhook verification breaks in staging
-Debug unexpected duplicate records
-```
+---
 
 ## Relationship To DevFlow 2.0
 
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `00-discover`, `40-implement`, `50-verify`, `Issue-Triage`, production failure analysis
-- Typical handoff targets: `00-discover {discovery_id}` for discovery-owned RCA, `40-implement`, `50-verify`, `Insight`, `Wiki`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/rca.template.md`
-- Related commands: `40-implement`, `50-verify`, `Test`, `Insight`, `Wiki`, `Agent`
-
-## Next Workflow Recommendation
-
-- Default: return to `00-discover {discovery_id}` when the failure entered through discovery; otherwise return to `40-implement` when a tracked fix already exists
-- Alternate: `30-plan` if the fix needs planning changes
-- Alternate: `50-verify` when the issue is resolved and needs re-checking
-
+- **Classification**: Companion command & Investigation lane
+- **Mainline integration**:
+  - During `00-discover`: Unclear failure intake before allocation
+  - During `40-implement`: Hard test failure or unexpected runtime exception
+  - During `50-verify`: Defect found during QA inspection
+- **Handoff**: `test` (write repro test), `40-implement` (execute fix), `50-verify` (re-check)

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

@@ -1,91 +1,63 @@
----name: deploy
-
-description: "[Devflow] Production deployment pre-flight checks, smoke validation, and deployment execution."
 ---
-# ๐Ÿš€ Phase 52: Production Deployment (Auto-Deploy)
+name: deploy
+description: "[Devflow] Production deployment pre-flight checks, launch readiness, smoke validation, and deployment execution."
+---
 
-## Usage: `Deploy [subcommand]`
+# Production Deployment & Launch Readiness
 
-Perform pre-flight checks, deployment execution, and verification for production releases.
+## Overview
 
-Primary behavior now lives in:
+This is the comprehensive deployment master skill for Nexus-DevFlow. It handles pre-flight validation, multi-platform deployment execution (Vercel, Render, Railway, Fly.io, Docker), health checks, smoke verification, and safe rollback readiness.
 
 ```text
-.agents/skills/release-git-operations/SKILL.md
+Pre-Flight Checks ➔ Build & Smoke Test ➔ Deployment Execution ➔ Health Verification ➔ Release Logging
 ```
 
-Treat this workflow file as a compatibility wrapper around that skill in `deploy` mode.
-
 ---
 
-## ๐Ÿ› ๏ธ Sub-commands
+## 1. Pre-Flight Verification Checklist
 
-- `Deploy`            - Interactive deployment wizard
-- `Deploy check`      - Run pre-deployment checks only
-- `Deploy preview`    - Deploy to preview/staging
-- `Deploy production` - Deploy to production
-- `Deploy rollback`   - Rollback to previous version
+Before initiating any deployment, verify:
+1. **Code & Quality**: Zero syntax/type errors, linters clean, unit & integration tests passing (`npm test`).
+2. **Security**: No secrets in source code, environment variables documented in `.env.example`, `npm audit` checked.
+3. **Database & Migrations**: Schema migrations verified backwards-compatible and applied.
+4. **Performance & Assets**: Production bundles compiled, assets compressed, Core Web Vitals considered.
+5. **Observability**: Healthcheck endpoint (`/api/health`) responsive, error tracking configured.
 
 ---
 
-## ๐Ÿšฆ Internal Process
+## 2. Platform Deployment Matrix
 
-### Phase 1: Pre-Flight Checks
-Before any deployment, the AI MUST verify the following Checklist:
-1. **Code Quality**: No syntax errors, Linters passing, Tests passing.
-2. **Security**: No hardcoded secrets, Environment variables documented, Dependencies audited.
-3. **Performance**: Bundle size acceptable, Images optimized, No N+1 queries.
-4. **Accessibility**: Keyboard nav works, screen reader compatible, contrast adequate.
-5. **Infrastructure**: Env vars set, migrations ready, monitoring configured.
-6. **Documentation**: README / ADRs / CHANGELOG updated.
+| Target Platform | Deploy Method / Command | Verification Method |
+| :--- | :--- | :--- |
+| **Vercel** | `vercel --prod` or Git push | Inspect deployment URL & build logs |
+| **Render / Railway** | `railway up` or Git integration | Check service status & container logs |
+| **Fly.io** | `fly deploy` | Check `fly status` and HTTP response |
+| **Docker / VPS** | `docker compose up -d --build` | Check container health & PM2 logs |
 
-*You MUST run appropriate validation commands to systematically audit the codebase before giving the green light.*
+---
 
-### Phase 2: Deployment Execution
-Determine the project's platform (Vercel, Railway, Docker, Fly.io, etc.) and execute the appropriate build & deploy commands.
-- Vercel: `vercel --prod`
-- Railway: `railway up`
-- Docker: `docker compose up -d`
-- Fly.io: `fly deploy`
+## 3. Post-Deployment Smoke Verification & Health Check
 
-### Phase 3: Health Check, Verify & Report
-- **Template Verification**: **MANDATORY:** Before final deployment, inspect `.agent/resources/schemas/deploy_report.template.md`, preserve its required layout, and replace placeholder text with concrete environment, commands, checks, rollback notes, and deployment result.
-- Save the final deployment and pre-flight check report to `devflow/reports/{date}-deploy-report-{timestamp}.md` (where `{date}` is today's date in `YYYY-MM-DD` format and `{timestamp}` is a clean date/time slug).
-- Verify that the deployed application is responding (HTTP 200 OK) and all services (Database, API) are healthy.
+1. Send an HTTP request to the deployed domain: verify HTTP 200 OK.
+2. Test critical paths (Authentication, API endpoints, core database transactions).
+3. Confirm telemetry and error log stream are free of unhandled exceptions.
 
 ---
 
-## ๐Ÿ“ Output Formats
+## 4. Rollback Readiness
 
-### Successful Deploy
-Generate a summary indicating:
-- **Summary**: Version, Environment, Duration, Platform
-- **URLs**: Production, Dashboard
-- **Report Location**: Confirm the deploy checklist and validation report has been written to the specified workspace path.
-- **What Changed**: Bullet points of new features or fixes
-- **Health Check**: Status of API and Database
+Always have an immediate rollback plan before triggering production releases:
+- Pin the previous stable build artifact, Docker image tag, or Git commit hash.
+- If post-deployment smoke tests fail, trigger rollback immediately:
+  ```text
+  deploy rollback
+  ```
 
-### Failed Deploy
-Generate an Error summary detailing:
-- **Error**: Step where it failed (e.g., Build failed at TypeScript compilation)
-- **Details**: Exact error snippet
-- **Resolution**: Step-by-step fix recommendation
-- **Rollback Available**: Suggest running `Deploy rollback` if needed.
+---
 
 ## Relationship To DevFlow 2.0
 
-- Classification: Companion command
-- Mainline status: Release support command, not a numbered stage
-- Typical entry points: `70-release` after the report is aligned and packaging is ready to execute
-- Typical handoff targets: `60-report`, `Changelog`, `Wiki`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agents/skills/shipping-and-launch/SKILL.md`
-- `.agents/skills/deployment-procedures/SKILL.md`
-- `.agent/resources/schemas/deploy_report.template.md`
-- Related commands: `70-release`, `Commit`, `PR`, `Changelog`, `60-report`
-
-
+- **Classification**: Companion command & Delivery support
+- **Mainline integration**: Invoked after `70-release` when ready to deploy.
+- **Handoff**: `60-report`, `changelog`, `rollback`