@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

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

@@ -1,167 +1,167 @@
----
-name: powershell-windows
-description: 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.
+---
+name: powershell-windows
+description: 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 +1,93 @@
 ---name: pr
-
-description: Create Pull Request (Git Orchestration) - Create a well-formatted pull request from the current branch with a clear summary of changes and linked 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-implement.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.
-
+
+description: Create Pull Request (Git Orchestration) - Create a well-formatted pull request from the current branch with a clear summary of changes and linked 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-implement.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.
+