@jakkrichm/create-nexus-devflow 2.0.20 → 2.0.22

package/template/.agents/skills/behavioral-modes/SKILL.md

@@ -1,242 +0,0 @@
----
-name: behavioral-modes
-description: "[Devflow] AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type."
-allowed-tools: Read, Glob, Grep
----
-
-# Behavioral Modes - Adaptive AI Operating Modes
-
-## Purpose
-This skill defines distinct behavioral modes that optimize AI performance for specific tasks. Modes change how the AI approaches problems, communicates, and prioritizes.
-
----
-
-## Available Modes
-
-### 1. 🧠 BRAINSTORM Mode
-
-**When to use:** Early project planning, feature ideation, architecture decisions
-
-**Behavior:**
-- Ask clarifying questions before assumptions
-- Offer multiple alternatives (at least 3)
-- Think divergently - explore unconventional solutions
-- No code yet - focus on ideas and options
-- Use visual diagrams (mermaid) to explain concepts
-
-**Output style:**
-```
-"Let's explore this together. Here are some approaches:
-
-Option A: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-Option B: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-What resonates with you? Or should we explore a different direction?"
-```
-
----
-
-### 2. ⚡ IMPLEMENT Mode
-
-**When to use:** Writing code, building features, executing plans
-
-**Behavior:**
-- **CRITICAL: Use `clean-code` skill standards** - concise, direct, no verbose explanations
-- Fast execution - minimize questions
-- Use established patterns and best practices
-- Write complete, production-ready code
-- Include error handling and edge cases
-- **NO tutorial-style explanations** - just code
-- **NO unnecessary comments** - let code self-document
-- **NO over-engineering** - solve the problem directly
-- **NO RUSHING** - Quality > Speed. Read ALL references before coding.
-
-**Output style:**
-```
-[Code block]
-
-[Brief summary, max 1-2 sentences]
-```
-
-**NOT:**
-```
-"Building [feature]...
-
-✓ Created [file1]
-✓ Created [file2]
-✓ Updated [file3]
-
-[long explanation]
-
-Run `npm run dev` to test."
-```
-
----
-
-### 3. 🔍 DEBUG Mode
-
-**When to use:** Fixing bugs, troubleshooting errors, investigating issues
-
-**Behavior:**
-- Ask for error messages and reproduction steps
-- Think systematically - check logs, trace data flow
-- Form hypothesis → test → verify
-- Explain the root cause, not just the fix
-- Prevent future occurrences
-
-**Output style:**
-```
-"Investigating...
-
-🔍 Symptom: [what's happening]
-🎯 Root cause: [why it's happening]
-✅ Fix: [the solution]
-🛡️ Prevention: [how to avoid in future]
-```
-
----
-
-### 4. 📋 REVIEW Mode
-
-**When to use:** Code review, architecture review, security audit
-
-**Behavior:**
-- Be thorough but constructive
-- Categorize by severity (Critical/High/Medium/Low)
-- Explain the "why" behind suggestions
-- Offer improved code examples
-- Acknowledge what's done well
-
-**Output style:**
-```
-## Code Review: [file/feature]
-
-### 🔴 Critical
-- [issue with explanation]
-
-### 🟠 Improvements
-- [suggestion with example]
-
-### 🟢 Good
-- [positive observation]
-```
-
----
-
-### 5. 📚 TEACH Mode
-
-**When to use:** Explaining concepts, documentation, onboarding
-
-**Behavior:**
-- Explain from fundamentals
-- Use analogies and examples
-- Progress from simple to complex
-- Include practical exercises
-- Check understanding
-
-**Output style:**
-```
-## Understanding [Concept]
-
-### What is it?
-[Simple explanation with analogy]
-
-### How it works
-[Technical explanation with diagram]
-
-### Example
-[Code example with comments]
-
-### Try it yourself
-[Exercise or task]
-```
-
----
-
-### 6. 🚀 SHIP Mode
-
-**When to use:** Production deployment, final polish, release preparation
-
-**Behavior:**
-- Focus on stability over features
-- Check for missing error handling
-- Verify environment configs
-- Run all tests
-- Create deployment checklist
-
-**Output style:**
-```
-## Pre-Ship Checklist
-
-### ✅ Code Quality
-- [ ] No TypeScript errors
-- [ ] ESLint passing
-- [ ] All tests passing
-
-### ✅ Security
-- [ ] No exposed secrets
-- [ ] Input validation complete
-
-### ✅ Performance
-- [ ] Bundle size acceptable
-- [ ] No console.logs
-
-### 🚀 Ready to deploy
-```
-
----
-
-## Mode Detection
-
-The AI should automatically detect the appropriate mode based on:
-
-| Trigger | Mode |
-|---------|------|
-| "what if", "ideas", "options" | BRAINSTORM |
-| "build", "create", "add" | IMPLEMENT |
-| "not working", "error", "bug" | DEBUG |
-| "review", "check", "audit" | REVIEW |
-| "explain", "how does", "learn" | TEACH |
-| "deploy", "release", "production" | SHIP |
-
----
-
-## Multi-Agent Collaboration Patterns (2025)
-
-Modern architectures optimized for agent-to-agent collaboration:
-
-### 1. 🔭 EXPLORE Mode
-**Role:** Discovery and Analysis (Explorer Agent)
-**Behavior:** Socratic questioning, deep-dive code reading, dependency mapping.
-**Output:** `discovery-report.json`, architectural visualization.
-
-### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
-Cyclic mode transitions for high-complexity tasks:
-1. **Planner:** Decomposes the task into atomic steps (`task.md`).
-2. **Executor:** Performs the actual coding (`IMPLEMENT`).
-3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
-
-### 3. 🧠 MENTAL MODEL SYNC
-Behavior for creating and loading "Mental Model" summaries to preserve context between sessions.
-
----
-
-## Combining Modes
-
----
-
-## Manual Mode Switching
-
-Users can explicitly request a mode:
-
-```
-/brainstorm new feature ideas
-/implement the user profile page
-/debug why login fails
-/review this pull request
-```

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

@@ -1,168 +0,0 @@
----name: brainstorm
-
-description: "[Devflow] Structured divergent and convergent ideation for features and ideas without allocating running IDs."
----
-
-# Brainstorm - Structured Idea Exploration
-
-$ARGUMENTS
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Brainstorm` is a companion command, not a numbered mainline workflow. The operational behavior remains intentionally rich so the user experience does not regress.
-
-## Purpose
-
-Use `Brainstorm` for structured idea exploration before committing to a direction.
-
-Use it when:
-
-- the request is still vague
-- there are multiple possible directions
-- the team needs to compare options before locking the work
-- Discover or Define would benefit from explicit option comparison
-
-Preferred DevFlow 2.0 pairing:
-
-- from `00-discover` when the request is still fuzzy
-- from `10-define` when the direction is still unstable
-
-When invoked with a Discovery ID, link the brainstorming report to that discovery and return to `00-discover {discovery_id}` for synthesis. Do not allocate a Running ID or jump directly from a discovery-owned brainstorm into Define.
-
-## Behavior
-
-When `Brainstorm` is triggered:
-
-1. Understand the goal
-   - What problem are we solving?
-   - Who is the user or stakeholder?
-   - What constraints matter?
-2. Generate options
-   - Provide at least 3 materially different approaches
-   - Include pros and cons for each
-   - Consider both safe and unconventional paths when useful
-3. Compare and recommend
-   - Summarize the tradeoffs
-   - Give a recommendation with reasoning
-4. Keep it exploratory
-   - Do not pretend certainty where it does not exist
-   - Do not turn this into implementation planning too early
-
-Apply prompt ideation addons when useful:
-
-- `ideation_code_improvements`
-- `ideation_code_quality`
-- `ideation_documentation`
-- `ideation_performance`
-- `ideation_security`
-- `ideation_ui_ux`
-
-In DevFlow 2.0, do not treat `Brainstorm` as a required linear state before `10-Define`. It supports the mainline; it does not replace it.
-
-## Output Format
-
-Return a brief summary in chat, and save the full brainstorming report under `devflow/research/brainstorm-{topic}.md`.
-
-Before generating the report:
-
-1. Inspect `.agent/resources/schemas/brainstorm.template.md`
-2. Preserve its required headings and structure
-3. Replace all placeholders with concrete content
-4. Re-check the output against `brainstorm.template.md`, ensure required headings remain, and remove all placeholders before completion
-
-Use this structure:
-
-```markdown
-## ๐Ÿง  Brainstorm: [Topic]
-
-### Context
-[Brief problem statement]
-
----
-
-### Option A: [Name]
-[Description]
-
-โœ… **Pros:**
-- [benefit 1]
-- [benefit 2]
-
-โŒ **Cons:**
-- [drawback 1]
-
-๐Ÿ“Š **Effort:** Low | Medium | High
-
----
-
-### Option B: [Name]
-[Description]
-
-โœ… **Pros:**
-- [benefit 1]
-
-โŒ **Cons:**
-- [drawback 1]
-- [drawback 2]
-
-๐Ÿ“Š **Effort:** Low | Medium | High
-
----
-
-### Option C: [Name]
-[Description]
-
-โœ… **Pros:**
-- [benefit 1]
-
-โŒ **Cons:**
-- [drawback 1]
-
-๐Ÿ“Š **Effort:** Low | Medium | High
-
----
-
-## ๐Ÿ’ก Recommendation
-
-**Option [X]** because [reasoning].
-
-## Next Suggested Actions
-- [Action 1]
-- [Action 2]
-```
-
-## Examples
-
-```text
-Brainstorm authentication system
-Brainstorm state management for complex form
-Brainstorm database schema for social app
-Brainstorm caching strategy
-```
-
-## Key Principles
-
-- No code unless the user explicitly changes mode
-- Honest tradeoffs over fake confidence
-- Multiple viable paths before recommending one
-- Persistent output saved to disk
-- Mainline remains: `00-discover -> 10-define -> 20-spec -> 30-plan -> 40-execute -> 50-verify -> 60-report -> 70-release`
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `00-discover`, `10-define`
-- Typical handoff targets: `00-discover {discovery_id}` for discovery-owned work, or the active numbered stage for run-owned work
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/brainstorm.template.md`
-- Related commands: `00-discover`, `10-define`, `Research`, `PRD`, `20-spec`
-
-## Next Workflow Recommendation
-
-- Default: return to `00-discover {discovery_id}` when Discover requested the work; otherwise return to the stage that requested it
-- Alternate: `Research` when facts are still missing
-- Alternate: `10-define` or `20-spec` only when the work was not opened from a pending discovery
-

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

@@ -1,109 +0,0 @@
----name: changelog
-
-description: "[Devflow] Update CHANGELOG.md automatically from specs, git commits, and stage report history."
----
-# 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/codebase-design/DEEPENING.md

@@ -1,24 +0,0 @@
-# Deepening
-
-Use this reference when a cluster of shallow modules may need to become one deeper module.
-
-## Dependency Categories
-
-| Category | Meaning | Testing strategy |
-| :--- | :--- | :--- |
-| In-process | Pure computation or in-memory state | Test through the new interface directly. |
-| Local-substitutable | Dependency has a local test stand-in | Test the deep module with the local stand-in. |
-| Remote but owned | Internal service across a network boundary | Define a port at the seam; use production and in-memory adapters. |
-| True external | Third-party service you do not control | Inject a port and use a mock adapter at the system boundary. |
-
-## Seam Discipline
-
-- One adapter means a hypothetical seam; two adapters means a real one.
-- A deep module may have internal seams, but callers should not need to know them.
-- Do not add ports only to make tests easier when the real design does not vary there.
-
-## Testing Strategy
-
-- Replace tests of shallow internals with tests at the deepened module's interface.
-- Assert observable behavior through the interface.
-- Keep tests resilient to internal refactors.

package/template/.agents/skills/codebase-design/DESIGN-IT-TWICE.md

@@ -1,28 +0,0 @@
-# Design It Twice
-
-Use this reference when a stage needs alternative module or interface designs before committing to one.
-
-## Process
-
-1. Frame the problem space.
-   - Name constraints.
-   - Name dependencies and classify them with `DEEPENING.md`.
-   - Sketch only enough code to make the constraints concrete.
-
-2. Produce at least three different designs.
-   - Minimal interface: 1-3 entry points.
-   - Flexible interface: supports more use cases and extension.
-   - Common-case interface: makes the dominant caller trivial.
-   - Ports-and-adapters interface: use only when cross-seam dependencies justify it.
-
-3. Compare designs.
-   - Interface depth.
-   - Locality of future change.
-   - Seam placement.
-   - Test surface.
-   - Adapter strategy.
-
-4. Recommend one design.
-   - Be opinionated.
-   - Mention any useful hybrid.
-   - Record rejected alternatives only when future readers would otherwise re-open the same debate.

package/template/.agents/skills/codebase-design/SKILL.md

@@ -1,58 +0,0 @@
----
-name: codebase-design
-description: "[Devflow] Shared vocabulary for designing deep modules. Use when a DevFlow stage needs module/interface design, seam placement, testability review, or architecture simplification."
----
-
-# Codebase Design
-
-Use this support skill when `20-spec`, `30-plan`, `40-execute`, or `50-verify` needs better module shape.
-
-Design deep modules: a lot of behavior behind a small interface, placed at a clean seam, and testable through that interface. The aim is leverage for callers, locality for maintainers, and behavior-focused tests.
-
-## DevFlow Placement
-
-- `20-spec`: use when requirements depend on a stable module or interface contract.
-- `30-plan`: use when planning needs file-level architecture, seams, or dependency strategy.
-- `40-execute`: use when implementation reveals shallow modules or awkward test seams.
-- `50-verify`: use when review finds code that is hard to test, hard to change, or too spread out.
-
-## Vocabulary
-
-Use these words consistently:
-
-- **Module**: anything with an interface and an implementation.
-- **Interface**: everything a caller must know to use the module correctly, including invariants, ordering constraints, error modes, configuration, and performance characteristics.
-- **Implementation**: what sits inside the module.
-- **Depth**: leverage at the interface. A module is deep when a large amount of behavior sits behind a small interface.
-- **Seam**: a place where behavior can change without editing the caller.
-- **Adapter**: a concrete thing that satisfies an interface at a seam.
-- **Leverage**: capability callers get per unit of interface they learn.
-- **Locality**: how much change, debugging, and verification concentrate in one place.
-
-## Principles
-
-- Depth is a property of the interface, not line count.
-- The interface is the test surface.
-- One adapter means a hypothetical seam; two adapters means a real one.
-- Do not expose internal seams through the public interface just because tests use them.
-- If deleting a module removes no complexity, it is probably a pass-through.
-
-## Process
-
-1. Identify the module, callers, and behavior the active stage is trying to stabilize.
-2. Name the current interface, implementation, seams, and adapters.
-3. Ask whether the interface is smaller than the behavior it unlocks.
-4. Classify dependencies using `DEEPENING.md` when a module needs restructuring.
-5. Use `DESIGN-IT-TWICE.md` when multiple viable interface shapes exist.
-6. Record the result in the owning stage artifact. Use ADRs only for hard-to-reverse decisions.
-
-## Output
-
-Return:
-
-- current module/interface shape
-- proposed seam or interface change
-- dependency strategy
-- test surface
-- risks and rejected alternatives
-- recommended owning DevFlow stage

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

@@ -1,59 +0,0 @@
----
-name: commit
-description: "[Devflow] Smart Commit (Git Orchestration) - Stage files intelligently, write conventional imperative commit messages, and manage trunk-based versioning."
----
-
-# Smart Commit & Git Workflow Versioning
-
-## Overview
-
-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.
-
----
-
-## 1. Commit Discipline & The Conventional Commits Standard
-
-Each commit should represent one atomic, self-contained change:
-
-```text
-<type>(<scope>): <short imperative summary>
-
-[optional detailed body explaining WHY, not WHAT]
-```
-
-### 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
-
-### 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.
-
----
-
-## 2. Trunk-Based Branching & Safety
-
-- **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.
-
----
-
-## 3. Execution Flow
-
-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-execute` (checkpoint commits), `70-release` (final release commit).
-- **Handoff**: `pr`, `merge`, `70-release`