@jakkrichm/create-nexus-devflow 2.0.19 → 2.0.21

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

package/template/.claude/skills/competitor-analysis/SKILL.md

@@ -1,66 +0,0 @@
----
-name: competitor-analysis
-description: "[Devflow] Research competitors, market alternatives, user pain points, and differentiation opportunities. Use when product framing, roadmap decisions, or strategic positioning need source-backed external context."
----
-
-# Competitor Analysis
-
-## Overview
-
-This skill gathers market context and converts it into usable product insight for PRD, Define, Spec, or Roadmap work.
-
-## When to Use
-
-- The team needs to understand competitors or substitutes
-- Product framing needs real external context
-- Roadmap decisions need evidence about gaps or opportunities
-- A feature idea needs differentiation, not just implementation detail
-
-## Process
-
-### 1. Load Product Context
-
-- read the user request, PRD, Define, Spec, or Roadmap context
-- identify target users, use case, and known alternatives
-
-### 2. Gather Evidence
-
-- find direct and indirect competitors
-- inspect public docs, reviews, forums, comparisons, issue trackers, and discussion surfaces when available
-- cite sources and separate evidence from inference
-
-### 3. Analyze Opportunities
-
-For each competitor or market segment, summarize:
-
-- positioning
-- strengths
-- recurring pain points
-- opportunity for the current project
-
-### 4. Produce Reusable Output
-
-If the result is reusable, write it under:
-
-```text
-devflow/research/{date}-{slug}-competitor-analysis.md
-```
-
-Use `.agent/resources/schemas/competitor_analysis.template.md` when saving a reusable report.
-
-### 5. Route Back
-
-- `PRD` for product framing
-- `10-define` for scope and decision shaping
-- `Roadmap` for prioritization
-- `20-spec` when a selected opportunity becomes actionable
-
-## Output
-
-Return:
-
-- competitors researched
-- market gaps
-- evidence-backed opportunities
-- source links
-- recommended return stage or command