@jakkrichm/create-nexus-devflow 2.0.19 → 2.0.21

package/template/.agents/skills/powershell-windows/SKILL.md

@@ -1,167 +0,0 @@
----
-name: powershell-windows
-description: "[Devflow] PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling."
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# PowerShell Windows Patterns
-
-> Critical patterns and pitfalls for Windows PowerShell.
-
----
-
-## 1. Operator Syntax Rules
-
-### CRITICAL: Parentheses Required
-
-| ❌ Wrong | ✅ Correct |
-|----------|-----------|
-| `if (Test-Path "a" -or Test-Path "b")` | `if ((Test-Path "a") -or (Test-Path "b"))` |
-| `if (Get-Item $x -and $y -eq 5)` | `if ((Get-Item $x) -and ($y -eq 5))` |
-
-**Rule:** Each cmdlet call MUST be in parentheses when using logical operators.
-
----
-
-## 2. Unicode/Emoji Restriction
-
-### CRITICAL: No Unicode in Scripts
-
-| Purpose | ❌ Don't Use | ✅ Use |
-|---------|-------------|--------|
-| Success | ✅ ✓ | [OK] [+] |
-| Error | ❌ ✗ 🔴 | [!] [X] |
-| Warning | ⚠️ 🟡 | [*] [WARN] |
-| Info | ℹ️ 🔵 | [i] [INFO] |
-| Progress | ⏳ | [...] |
-
-**Rule:** Use ASCII characters only in PowerShell scripts.
-
----
-
-## 3. Null Check Patterns
-
-### Always Check Before Access
-
-| ❌ Wrong | ✅ Correct |
-|----------|-----------|
-| `$array.Count -gt 0` | `$array -and $array.Count -gt 0` |
-| `$text.Length` | `if ($text) { $text.Length }` |
-
----
-
-## 4. String Interpolation
-
-### Complex Expressions
-
-| ❌ Wrong | ✅ Correct |
-|----------|-----------|
-| `"Value: $($obj.prop.sub)"` | Store in variable first |
-
-**Pattern:**
-```
-$value = $obj.prop.sub
-Write-Output "Value: $value"
-```
-
----
-
-## 5. Error Handling
-
-### ErrorActionPreference
-
-| Value | Use |
-|-------|-----|
-| Stop | Development (fail fast) |
-| Continue | Production scripts |
-| SilentlyContinue | When errors expected |
-
-### Try/Catch Pattern
-
-- Don't return inside try block
-- Use finally for cleanup
-- Return after try/catch
-
----
-
-## 6. File Paths
-
-### Windows Path Rules
-
-| Pattern | Use |
-|---------|-----|
-| Literal path | `C:\Users\User\file.txt` |
-| Variable path | `Join-Path $env:USERPROFILE "file.txt"` |
-| Relative | `Join-Path $ScriptDir "data"` |
-
-**Rule:** Use Join-Path for cross-platform safety.
-
----
-
-## 7. Array Operations
-
-### Correct Patterns
-
-| Operation | Syntax |
-|-----------|--------|
-| Empty array | `$array = @()` |
-| Add item | `$array += $item` |
-| ArrayList add | `$list.Add($item) | Out-Null` |
-
----
-
-## 8. JSON Operations
-
-### CRITICAL: Depth Parameter
-
-| ❌ Wrong | ✅ Correct |
-|----------|-----------|
-| `ConvertTo-Json` | `ConvertTo-Json -Depth 10` |
-
-**Rule:** Always specify `-Depth` for nested objects.
-
-### File Operations
-
-| Operation | Pattern |
-|-----------|---------|
-| Read | `Get-Content "file.json" -Raw | ConvertFrom-Json` |
-| Write | `$data | ConvertTo-Json -Depth 10 | Out-File "file.json" -Encoding UTF8` |
-
----
-
-## 9. Common Errors
-
-| Error Message | Cause | Fix |
-|---------------|-------|-----|
-| "parameter 'or'" | Missing parentheses | Wrap cmdlets in () |
-| "Unexpected token" | Unicode character | Use ASCII only |
-| "Cannot find property" | Null object | Check null first |
-| "Cannot convert" | Type mismatch | Use .ToString() |
-
----
-
-## 10. Script Template
-
-```powershell
-# Strict mode
-Set-StrictMode -Version Latest
-$ErrorActionPreference = "Continue"
-
-# Paths
-$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path
-
-# Main
-try {
-    # Logic here
-    Write-Output "[OK] Done"
-    exit 0
-}
-catch {
-    Write-Warning "Error: $_"
-    exit 1
-}
-```
-
----
-
-> **Remember:** PowerShell has unique syntax rules. Parentheses, ASCII-only, and null checks are non-negotiable.

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

@@ -1,93 +0,0 @@
----name: pr
-
-description: "[Devflow] Pull Request creation with automated change summaries, verification evidence, and linked stage artifacts."
----
-# Create Pull Request (Git Orchestration)
-
-## Base Branch: $ARGUMENTS (default: main)
-
-Create a well-formatted pull request from the current branch with a clear summary of changes and linked artifacts.
-
-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 `pr` mode.
-
-In DevFlow 2.0, this is a release-adjacent workflow. It usually follows `60-report` and pairs naturally with `70-release` once the final summary is aligned.
-
----
-
-## Internal Process
-
-You are an orchestrator. Your goal is to call the specialized Git PR Maker agent and preserve the quality of the original PR workflow: clean preflight checks, strong summary construction, repository-template fidelity, and explicit next steps.
-
-### Phase 1: Pre-flight Validation
-**Call Agent**: `prp-core-git-pr-maker`
-
-- Provide the base branch.
-- Ensure the branch is not `main` or `master`.
-- Check for unpushed commits.
-- Verify the working directory is clean enough for PR submission.
-- Confirm the implementation has already passed the expected verification gate. If it has not, route back to `50-verify` first.
-
-### Phase 2: Context And Template
-
-- Search for PR templates in the repository, such as `.github/`.
-- Analyze commit history, diff, and linked task artifacts.
-- Prefer markdown-first stage artifacts as the source narrative:
-  - `20-spec.md`
-  - `30-plan.md`
-  - `40-execute.md`
-  - `50-verify.md`
-  - `60-report.md` when the final summary already exists
-  - `70-release.md` when release execution notes already exist
-- Automatically identify and link referenced issues when supported by repository conventions.
-- When the PR body needs stakeholder-readable language, apply `.agents/skills/9arm-skills/management-talk/SKILL.md` as a credited communication lens while preserving the repository PR template.
-- Apply GitHub prompt addons when useful:
-  - `pr_template_filler` for PR body structure
-  - `pr_reviewer`, `pr_quality_agent`, `pr_logic_agent`, `pr_security_agent`, `pr_structural` for review perspectives
-  - `pr_finding_validator` to confirm findings are actionable
-  - `pr_followup_*` to convert review comments into focused fixes
-  - `issue_analyzer`, `issue_triager`, `duplicate_detector`, `spam_detector` for issue-linked context
-
-### Phase 3: Push And Submission
-
-- Push the branch to the remote repository.
-- Use GitHub CLI or the repository-standard submission flow to create the PR with the generated body.
-- Preserve any repository policy on draft PRs, labels, reviewers, or linked issue syntax.
-
-### Phase 4: Final Summary
-
-Verify that the workflow returns:
-
-- PR number
-- PR URL
-- base and head branches
-- draft or ready status
-- any follow-up actions still expected from the user
-
----
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Release support command, not a numbered stage
-- Typical entry points: `70-release`, `Commit`
-- Typical handoff targets: `PR-Review`, `PR-Followup`, `Merge`, `70-release`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `Commit`, `PR-Review`, `PR-Followup`, `Merge`, `60-report`, `70-release`
-
-## Next Workflow Recommendation
-
-- **Primary**: `70-release`
-- **Why**: after PR creation, release execution and handoff details should stay consistent with the approved report.
-- **Alternative**: `PR-Review` for structured review before broader sharing, or `60-report` when the final communication summary still needs to be refreshed first.
-

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

@@ -1,127 +0,0 @@
----
-name: prd
-description: "[Devflow] Product Requirements Document drafting, user story mapping, and feature scoping before delivery commitment."
----
-
----
-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
-
-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
-- 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
-
-- **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.
-

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

@@ -1,42 +0,0 @@
----
-name: preview
-description: "[Devflow] Local preview server management, smoke-check, and temporary runtime inspection before formal verification."
----
-
-# Preview Management & Local Runtime Inspection
-
-## Overview
-
-This is the preview master skill for Nexus-DevFlow. It manages local development/preview servers (`npm run dev`, `npm run preview`, `vite`, `next dev`), handles port conflicts, and executes smoke checks before formal verification.
-
-## Usage & Sub-Commands
-
-- `/preview`         - Inspect current preview status and health
-- `/preview start`   - Start the local preview/dev server
-- `/preview stop`    - Stop the running server process
-- `/preview restart` - Restart the preview server
-- `/preview check`   - Perform runtime smoke check against `http://localhost:<port>`
-
----
-
-## 1. Process & Runtime Management
-
-1. **Detect Framework & Command**: Identify the project runtime (`npm run dev`, `vite preview`, `pnpm start`, `python -m http.server`).
-2. **Handle Port Conflicts**: Check if the standard port (3000, 5173, 8080) is occupied; auto-select fallback port or terminate stale background processes.
-3. **Health & Smoke Check**: Query local endpoint via HTTP GET to verify HTTP 200 OK and asset loading.
-4. **Report Status**:
-   ```markdown
-   ## Preview Status
-   - **URL**: `http://localhost:3000`
-   - **App Type**: Next.js / Vite / Node.js
-   - **Health Status**: `OK` (200 OK)
-   - **Console / Network**: Zero fatal runtime errors
-   ```
-
----
-
-## Relationship To DevFlow 2.0
-
-- **Classification**: Companion command & Runtime support
-- **Mainline stages**: `40-execute` (interactive visual check), `50-verify` (smoke test check)
-- **Handoff**: `50-verify`