@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

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

@@ -3,125 +3,125 @@ name: prd
 description: PRD workflow
 ---
 
----
-description: Strategic PRD Generator (Orchestration) - Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
----
-# Phase 12: Strategic PRD Generator (Orchestration)
-
-## Feature Idea: $ARGUMENTS
-
-Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
-
+---
+description: Strategic PRD Generator (Orchestration) - Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
+---
+# Phase 12: Strategic PRD Generator (Orchestration)
+
+## Feature Idea: $ARGUMENTS
+
+Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
+
 In DevFlow 2.0, this is a supporting workflow, not part of the numbered mainline state path. Use it when the idea is still too product-shaped for `/10-Define` or `/20-Spec` to proceed cleanly.
 Use `to-prd` when existing conversation, discovery, or codebase context is already sufficient and the job is synthesis rather than another interview.
 When invoked from `/00-Discover`, link the PRD to the Discovery ID and return to `/00-Discover {discovery_id}` for the final `Proceed`, `Defer`, or `Reject` decision. PRD does not create Running IDs.
-
----
-
-## Internal Process
-
-You are an orchestrator. Your goal is to call the specialized PRD Architect agent and preserve the quality of discovery, framing, and scope decisions before the work enters the mainline execution flow.
-
-### Phase 1: Interactive Discovery
-**Call Agent**: `prp-core-prd-architect`
-
-- Provide the feature idea if one exists.
-- If no idea is provided, the agent should initiate discovery through targeted questions or structured prompting.
-- Support the agent in grounding the PRD around:
-  - **Who**: primary persona, context, environment, and trigger moment.
-  - **What**: the core problem or desired outcome.
-  - **Why**: limitations of the current process, product, or alternative solutions.
-  - **Success**: measurable outcomes, user signals, or business impact.
-
-### Phase 2: Grounding And Feasibility
-
-- Facilitate research into technical feasibility, domain context, and operational constraints.
-- Ensure the agent checks internal codebase or platform patterns when the idea must fit an existing system.
-- Apply `Research` or the relevant research agent/skill when the PRD mentions:
-  - external APIs
-  - SDKs
-  - databases
-  - cloud services
-  - auth providers
-  - payments
-  - browser or device dependencies
-- Apply competitor or market analysis only when differentiation, market positioning, or user pain points materially affect scope decisions.
-
-### Phase 3: Scope Definition
-
-- Review the agent's prioritization carefully.
-- Confirm:
-  - MVP definition
-  - non-goals
-  - explicit assumptions
-  - open questions
-  - risks that should remain visible before delivery planning
-- Do not let the PRD silently drift into implementation detail that belongs in `/20-Spec` or `/30-Plan`.
-
-### Phase 4: Output Generation
-
-- **MANDATORY:** Before generating the PRD, inspect `.agent/resources/schemas/prd.template.md` and use its required headings and table structure.
-- Before reporting completion, run:
-
-Review `{prd_path}` against `prd.template.md`, keep the required headings, and remove placeholder text before completion.
-
-- Replace any placeholder or template text with concrete product details, assumptions, risks, metrics, and open questions.
-- Save the PRD to:
-
-```text
-devflow/prds/{date}-{slug}.prd.md
-```
-
-- Verify the document includes:
-  - problem statement
-  - target user or actor
-  - key hypotheses
-  - success measures
-  - scope boundaries
-  - implementation phases at a product level, not task granularity
-
-### Phase 5: Map Into DevFlow 2.0
-
+
+---
+
+## Internal Process
+
+You are an orchestrator. Your goal is to call the specialized PRD Architect agent and preserve the quality of discovery, framing, and scope decisions before the work enters the mainline execution flow.
+
+### Phase 1: Interactive Discovery
+**Call Agent**: `prp-core-prd-architect`
+
+- Provide the feature idea if one exists.
+- If no idea is provided, the agent should initiate discovery through targeted questions or structured prompting.
+- Support the agent in grounding the PRD around:
+  - **Who**: primary persona, context, environment, and trigger moment.
+  - **What**: the core problem or desired outcome.
+  - **Why**: limitations of the current process, product, or alternative solutions.
+  - **Success**: measurable outcomes, user signals, or business impact.
+
+### Phase 2: Grounding And Feasibility
+
+- Facilitate research into technical feasibility, domain context, and operational constraints.
+- Ensure the agent checks internal codebase or platform patterns when the idea must fit an existing system.
+- Apply `Research` or the relevant research agent/skill when the PRD mentions:
+  - external APIs
+  - SDKs
+  - databases
+  - cloud services
+  - auth providers
+  - payments
+  - browser or device dependencies
+- Apply competitor or market analysis only when differentiation, market positioning, or user pain points materially affect scope decisions.
+
+### Phase 3: Scope Definition
+
+- Review the agent's prioritization carefully.
+- Confirm:
+  - MVP definition
+  - non-goals
+  - explicit assumptions
+  - open questions
+  - risks that should remain visible before delivery planning
+- Do not let the PRD silently drift into implementation detail that belongs in `/20-Spec` or `/30-Plan`.
+
+### Phase 4: Output Generation
+
+- **MANDATORY:** Before generating the PRD, inspect `.agent/resources/schemas/prd.template.md` and use its required headings and table structure.
+- Before reporting completion, run:
+
+Review `{prd_path}` against `prd.template.md`, keep the required headings, and remove placeholder text before completion.
+
+- Replace any placeholder or template text with concrete product details, assumptions, risks, metrics, and open questions.
+- Save the PRD to:
+
+```text
+devflow/prds/{date}-{slug}.prd.md
+```
+
+- Verify the document includes:
+  - problem statement
+  - target user or actor
+  - key hypotheses
+  - success measures
+  - scope boundaries
+  - implementation phases at a product level, not task granularity
+
+### Phase 5: Map Into DevFlow 2.0
+
 Convert the PRD into explicit next steps for the Timeline flow:
 
 - `/00-Discover {discovery_id}` when the PRD belongs to an active discovery
 - `/10-Define` when product framing was created outside Discover and delivery has already been approved
-- `/20-Spec` when the delivery contract is ready to be locked
-- `/30-Plan {ID}` only after the spec is execution-ready
-
-The user should still approve the transition into execution work. Do not treat PRD generation as automatic task creation.
-
----
-
-## Output
-
-Return:
-
-- where the PRD was saved
-- the short product thesis
-- major scope boundaries
-- the biggest open questions
-- the exact recommended next DevFlow 2.0 command
-
----
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: product framing before implementation-ready scope exists
+- `/20-Spec` when the delivery contract is ready to be locked
+- `/30-Plan {ID}` only after the spec is execution-ready
+
+The user should still approve the transition into execution work. Do not treat PRD generation as automatic task creation.
+
+---
+
+## Output
+
+Return:
+
+- where the PRD was saved
+- the short product thesis
+- major scope boundaries
+- the biggest open questions
+- the exact recommended next DevFlow 2.0 command
+
+---
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: product framing before implementation-ready scope exists
 - Typical handoff targets: `/00-Discover {discovery_id}`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/prd.template.md`
-- Related commands: `Brainstorm`, `Research`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
-- Support skills: `to-prd`, `grill-with-docs`, `domain-modeling`
-
-## Next Workflow Recommendation
-
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/prd.template.md`
+- Related commands: `Brainstorm`, `Research`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
+- Support skills: `to-prd`, `grill-with-docs`, `domain-modeling`
+
+## Next Workflow Recommendation
+
 - **Primary**: `/00-Discover {discovery_id}` when invoked from discovery; otherwise `/10-Define`
 - **Why**: PRD shapes product intent, while Discover owns the delivery decision and Define owns Running ID creation.
-- **Alternative**: `Research` when technical feasibility or external dependencies are still unresolved.
-
+- **Alternative**: `Research` when technical feasibility or external dependencies are still unresolved.
+

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

@@ -3,119 +3,119 @@ name: preview
 description: Preview workflow
 ---
 
----
-description: Preview management and temporary runtime checks. Transitional compatibility path for the Preview companion command in DevFlow 2.0.
----
-
-# Preview Management
-
-## Usage
-
-```text
-Preview
-Preview start
-Preview stop
-Preview restart
-Preview check
-```
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Preview` is a companion command, not a numbered mainline workflow.
-
-Primary behavior now lives in:
-
-```text
-.agents/skills/preview-local-check/SKILL.md
-```
-
-Treat this workflow file as a compatibility wrapper around that skill.
-
-Manage the local preview development server or temporary runtime check.
-
-Use it when:
-
-- the team wants a quick visual or runtime check before formal verification
-- implementation needs a local smoke check
-- a temporary render helps clarify what changed
-- a human reviewer needs something concrete to inspect before giving feedback
-
-Preferred DevFlow 2.0 pairing:
-
-- from `/40-Implement`
-- from `/50-Verify`
-
----
-
-## Sub-commands
-
-- `Preview` - show current preview status
-- `Preview start` - start the server
-- `Preview stop` - stop the server
-- `Preview restart` - restart the server
-- `Preview check` - run a health check
-
----
-
-## Internal Process
-
-`Preview` manages the local preview workflow using the `preview-local-check` skill plus any available preview automation or equivalent project-local commands.
-
-When handling preview operations:
-
-1. detect the correct project or server command path
-2. report the current state clearly
-3. handle port conflicts gracefully
-4. keep the action scoped to preview management, not broader deployment
-5. distinguish between preview success and full verification success
-
-Commands should use the nearest equivalent project-local preview command for the project, such as `npm run dev`, `npm run preview`, framework-specific local servers, or other runtime helpers that already exist in the target project.
-
-### Resolving Port Conflicts
-
-If the port is in use, offer options:
-
-1. start on a different port
-2. terminate the process on the existing port
-3. specify a custom port
-
-### Status Format
-
-When displaying status, clearly state:
-
-- URL
-- project path
-- app type
-- health status
-- notes about blockers, missing dependencies, or startup warnings
-
-Example summary:
-
-```markdown
-## Preview Status
-
-- **URL**: `http://localhost:3000`
-- **Project Path**: `[absolute path]`
-- **App Type**: `Next.js | FastAPI | Odoo | PHP | Other`
-- **Health Status**: `OK | Warning | Failed`
-- **Notes**: [port conflict, startup issue, missing dependency, or none]
-```
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `/40-Implement`, `/50-Verify`, UI or runtime checking
-- Typical handoff targets: `/50-Verify`, `Debug`, `/40-Implement`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/preview-local-check/SKILL.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `Debug`
-
-## Next Workflow Recommendation
-
-- **Primary**: `/50-Verify` when preview confirms the change is ready for formal checks
-- **Alternative**: `/40-Implement` when preview exposed implementation work
-
+---
+description: Preview management and temporary runtime checks. Transitional compatibility path for the Preview companion command in DevFlow 2.0.
+---
+
+# Preview Management
+
+## Usage
+
+```text
+Preview
+Preview start
+Preview stop
+Preview restart
+Preview check
+```
+
+This file keeps its old numeric path for migration compatibility.
+
+In DevFlow 2.0, `Preview` is a companion command, not a numbered mainline workflow.
+
+Primary behavior now lives in:
+
+```text
+.agents/skills/preview-local-check/SKILL.md
+```
+
+Treat this workflow file as a compatibility wrapper around that skill.
+
+Manage the local preview development server or temporary runtime check.
+
+Use it when:
+
+- the team wants a quick visual or runtime check before formal verification
+- implementation needs a local smoke check
+- a temporary render helps clarify what changed
+- a human reviewer needs something concrete to inspect before giving feedback
+
+Preferred DevFlow 2.0 pairing:
+
+- from `/40-Implement`
+- from `/50-Verify`
+
+---
+
+## Sub-commands
+
+- `Preview` - show current preview status
+- `Preview start` - start the server
+- `Preview stop` - stop the server
+- `Preview restart` - restart the server
+- `Preview check` - run a health check
+
+---
+
+## Internal Process
+
+`Preview` manages the local preview workflow using the `preview-local-check` skill plus any available preview automation or equivalent project-local commands.
+
+When handling preview operations:
+
+1. detect the correct project or server command path
+2. report the current state clearly
+3. handle port conflicts gracefully
+4. keep the action scoped to preview management, not broader deployment
+5. distinguish between preview success and full verification success
+
+Commands should use the nearest equivalent project-local preview command for the project, such as `npm run dev`, `npm run preview`, framework-specific local servers, or other runtime helpers that already exist in the target project.
+
+### Resolving Port Conflicts
+
+If the port is in use, offer options:
+
+1. start on a different port
+2. terminate the process on the existing port
+3. specify a custom port
+
+### Status Format
+
+When displaying status, clearly state:
+
+- URL
+- project path
+- app type
+- health status
+- notes about blockers, missing dependencies, or startup warnings
+
+Example summary:
+
+```markdown
+## Preview Status
+
+- **URL**: `http://localhost:3000`
+- **Project Path**: `[absolute path]`
+- **App Type**: `Next.js | FastAPI | Odoo | PHP | Other`
+- **Health Status**: `OK | Warning | Failed`
+- **Notes**: [port conflict, startup issue, missing dependency, or none]
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: `/40-Implement`, `/50-Verify`, UI or runtime checking
+- Typical handoff targets: `/50-Verify`, `Debug`, `/40-Implement`
+
+## Sources
+
+- `AGENTS.md`
+- `.agents/skills/preview-local-check/SKILL.md`
+- Related commands: `/40-Implement`, `/50-Verify`, `Debug`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/50-Verify` when preview confirms the change is ready for formal checks
+- **Alternative**: `/40-Implement` when preview exposed implementation work
+

package/template/.agents/skills/preview-local-check/SKILL.md

@@ -1,59 +1,59 @@
----
-name: preview-local-check
-description: Manage local preview, smoke-check, and temporary runtime verification before formal verification. Use when implementation needs a quick visual or runtime check, when a reviewer needs a local URL, or when a change should be inspected before /50-Verify.
----
-
-# Preview Local Check
-
-## Overview
-
-This skill handles preview management and lightweight runtime checks without pretending that preview success is the same as full verification success.
-
-Use it to:
-
-- start or stop a local preview server
-- report preview health and URL
-- run a quick smoke check before formal verification
-- give humans a concrete local artifact to inspect
-
-## When to Use
-
-- During `/40-Implement` when a quick runtime check is useful
-- During `/50-Verify` when the change needs visual or interactive confirmation
-- When a reviewer asks for a local preview URL
-
-Do not use this skill as a replacement for test evidence, verification evidence, or release readiness.
-
-## Process
-
-### 1. Detect Preview Path
-
-- identify the correct project-local preview command
-- detect the likely app type and default port
-- separate preview management from deployment logic
-
-### 2. Manage State
-
-- support `status`, `start`, `stop`, `restart`, and `check`
-- report port conflicts clearly
-- offer a safe alternate port when possible
-
-### 3. Report Health
-
-Always report:
-
-- URL
-- project path
-- app type
-- health status
-- blockers or warnings
-
-### 4. Route Back
-
-- return to `/50-Verify` when preview confirms the change is ready for formal checks
-- return to `/40-Implement` when preview reveals implementation issues
-- use `Debug` when the preview failure needs RCA
-
-## Output
-
-Return a concise preview status or action summary. When useful, save notes into the current stage artifact rather than inventing a separate contract.
+---
+name: preview-local-check
+description: Manage local preview, smoke-check, and temporary runtime verification before formal verification. Use when implementation needs a quick visual or runtime check, when a reviewer needs a local URL, or when a change should be inspected before /50-Verify.
+---
+
+# Preview Local Check
+
+## Overview
+
+This skill handles preview management and lightweight runtime checks without pretending that preview success is the same as full verification success.
+
+Use it to:
+
+- start or stop a local preview server
+- report preview health and URL
+- run a quick smoke check before formal verification
+- give humans a concrete local artifact to inspect
+
+## When to Use
+
+- During `/40-Implement` when a quick runtime check is useful
+- During `/50-Verify` when the change needs visual or interactive confirmation
+- When a reviewer asks for a local preview URL
+
+Do not use this skill as a replacement for test evidence, verification evidence, or release readiness.
+
+## Process
+
+### 1. Detect Preview Path
+
+- identify the correct project-local preview command
+- detect the likely app type and default port
+- separate preview management from deployment logic
+
+### 2. Manage State
+
+- support `status`, `start`, `stop`, `restart`, and `check`
+- report port conflicts clearly
+- offer a safe alternate port when possible
+
+### 3. Report Health
+
+Always report:
+
+- URL
+- project path
+- app type
+- health status
+- blockers or warnings
+
+### 4. Route Back
+
+- return to `/50-Verify` when preview confirms the change is ready for formal checks
+- return to `/40-Implement` when preview reveals implementation issues
+- use `Debug` when the preview failure needs RCA
+
+## Output
+
+Return a concise preview status or action summary. When useful, save notes into the current stage artifact rather than inventing a separate contract.