@jakkrichm/create-nexus-devflow 2.0.0

package/template/.claude/skills/planning-and-task-breakdown/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: planning-and-task-breakdown
+description: Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
+---
+
+# Planning and Task Breakdown
+
+## Overview
+
+Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.
+
+## Task Breakdown Principles
+
+1. **Small, Focused Tasks**: Each task should take 2-5 minutes of model effort. One clear outcome per task.
+2. **Clear Verification**: Every task must have a "Verify:" section.
+3. **Logical Ordering**: Dependencies must be identified. Critical path first.
+4. **Principle: Keep It SHORT**: Max 5-10 clear tasks. If more, break into multiple plans.
+
+## When to Use
+
+- You have a spec and need to break it into implementable units
+- A task feels too large or vague to start
+- Work needs to be parallelized across multiple agents or sessions
+- You need to communicate scope to a human
+- The implementation order isn't obvious
+
+In DevFlow 2.0, this skill primarily supports `/30-Plan`.
+
+**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
+
+## The Planning Process
+
+### Step 1: Enter Plan Mode
+
+Before writing any code, operate in read-only mode:
+
+- Read the spec and relevant codebase sections
+- Identify existing patterns and conventions
+- Map dependencies between components
+- Note risks and unknowns
+
+**Do NOT write code during planning.** The output is a plan document, not implementation.
+
+### Step 2: Identify the Dependency Graph
+
+Map what depends on what:
+
+```
+Database schema
+    │
+    ├── API models/types
+    │       │
+    │       ├── API endpoints
+    │       │       │
+    │       │       └── Frontend API client
+    │       │               │
+    │       │               └── UI components
+    │       │
+    │       └── Validation logic
+    │
+    └── Seed data / migrations
+```
+
+Implementation order follows the dependency graph bottom-up: build foundations first.
+
+### Step 3: Slice Vertically
+
+Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:
+
+**Bad (horizontal slicing):**
+```
+Task 1: Build entire database schema
+Task 2: Build all API endpoints
+Task 3: Build all UI components
+Task 4: Connect everything
+```
+
+**Good (vertical slicing):**
+```
+Task 1: User can create an account (schema + API + UI for registration)
+Task 2: User can log in (auth schema + API + UI for login)
+Task 3: User can create a task (task schema + API + UI for creation)
+Task 4: User can view task list (query + API + UI for list view)
+```
+
+Each vertical slice delivers working, testable functionality.
+
+### Step 4: Write Tasks
+
+Each task follows this structure:
+
+```markdown
+## Task [N]: [Short descriptive title]
+
+**Description:** One paragraph explaining what this task accomplishes.
+
+**Acceptance criteria:**
+- [ ] [Specific, testable condition]
+- [ ] [Specific, testable condition]
+
+**Verification:**
+- [ ] Tests pass: `npm test -- --grep "feature-name"`
+- [ ] Build succeeds: `npm run build`
+- [ ] Manual check: [description of what to verify]
+
+**Dependencies:** [Task numbers this depends on, or "None"]
+
+**Files likely touched:**
+- `src/path/to/file.ts`
+- `tests/path/to/test.ts`
+
+**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]
+```
+
+### Step 5: Order and Checkpoint
+
+Arrange tasks so that:
+
+1. Dependencies are satisfied (build foundation first)
+2. Each task leaves the system in a working state
+3. Verification checkpoints occur after every 2-3 tasks
+4. High-risk tasks are early (fail fast)
+
+Add explicit checkpoints:
+
+```markdown
+## Checkpoint: After Tasks 1-3
+- [ ] All tests pass
+- [ ] Application builds without errors
+- [ ] Core user flow works end-to-end
+- [ ] Review with human before proceeding
+```
+
+## Task Sizing Guidelines
+
+| Size | Files | Scope | Example |
+|------|-------|-------|---------|
+| **XS** | 1 | Single function or config change | Add a validation rule |
+| **S** | 1-2 | One component or endpoint | Add a new API endpoint |
+| **M** | 3-5 | One feature slice | User registration flow |
+| **L** | 5-8 | Multi-component feature | Search with filtering and pagination |
+| **XL** | 8+ | **Too large — break it down further** | — |
+
+If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.
+
+**When to break a task down further:**
+- It would take more than one focused session (roughly 2+ hours of agent work)
+- You cannot describe the acceptance criteria in 3 or fewer bullet points
+- It touches two or more independent subsystems (e.g., auth and billing)
+- You find yourself writing "and" in the task title (a sign it is two tasks)
+
+## DevFlow 2.0 Stage Contract
+
+In DevFlow 2.0, every plan must remain understandable from markdown alone inside `devflow/runs/{ID}-*/`.
+
+1. **`plan.md`**: The primary planning artifact following the template below.
+2. The markdown plan must still work even if no dashboard or JSON reader is available.
+
+## Plan Document Template
+
+```markdown
+# Implementation Plan: [Feature/Project Name]
+
+## Overview
+[One paragraph summary of what we're building]
+
+## Architecture Decisions
+- [Key decision 1 and rationale]
+- [Key decision 2 and rationale]
+
+## Task List
+
+### Phase 1: Foundation
+- [ ] Task 1: ...
+- [ ] Task 2: ...
+
+### Checkpoint: Foundation
+- [ ] Tests pass, builds clean
+
+### Phase 2: Core Features
+- [ ] Task 3: ...
+- [ ] Task 4: ...
+
+### Checkpoint: Core Features
+- [ ] End-to-end flow works
+
+### Phase 3: Polish
+- [ ] Task 5: ...
+- [ ] Task 6: ...
+
+### Checkpoint: Complete
+- [ ] All acceptance criteria met
+- [ ] Ready for review
+
+## Risks and Mitigations
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| [Risk] | [High/Med/Low] | [Strategy] |
+
+## Open Questions
+- [Question needing human input]
+```
+
+## Parallelization Opportunities
+
+When multiple agents or sessions are available:
+
+- **Safe to parallelize:** Independent feature slices, tests for already-implemented features, documentation
+- **Must be sequential:** Database migrations, shared state changes, dependency chains
+- **Needs coordination:** Features that share an API contract (define the contract first, then parallelize)
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
+| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
+| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
+| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
+
+## Red Flags
+
+- Starting implementation without a written task list
+- Tasks that say "implement the feature" without acceptance criteria
+- No verification steps in the plan
+- All tasks are XL-sized
+- No checkpoints between tasks
+- Dependency order isn't considered
+
+## Verification
+
+Before starting implementation, confirm:
+
+- [ ] Every task has acceptance criteria
+- [ ] Every task has a verification step
+- [ ] Task dependencies are identified and ordered correctly
+- [ ] No task touches more than ~5 files
+- [ ] Checkpoints exist between major phases
+- [ ] The human has reviewed and approved the plan

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

@@ -0,0 +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.

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

@@ -0,0 +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.
+

package/template/.claude/skills/pr-review/SKILL.md

@@ -0,0 +1,143 @@
+---name: pr-review
+
+description: PR Review Addon - Review a pull request using GitHub review prompt patterns and the credited 9arm-skills/scrutinize discipline.
+---
+
+# Phase 55: PR Review Addon
+
+## Target: $ARGUMENTS
+
+Use this workflow when you need a structured PR review without creating or changing the PR. It can review a local diff, a PR URL or number, or a task-linked branch.
+
+In DevFlow 2.0, this remains a supporting review workflow. It should feed corrective work back into `/40-Implement` or clear the path toward `/60-Report` and then `/70-Release`.
+
+Primary behavior now lives in the `pr-review-analysis` skill. Keep this workflow as the compatibility wrapper and user-facing review prompt surface.
+
+## Prompt Sources
+
+Adapted from:
+
+- `github/QA_REVIEW_SYSTEM_PROMPT.md`
+- `github/pr_reviewer.md`
+- `github/pr_parallel_orchestrator.md`
+- `github/pr_orchestrator.md`
+- `github/pr_quality_agent.md`
+- `github/pr_logic_agent.md`
+- `github/pr_security_agent.md`
+- `github/pr_structural.md`
+- `github/pr_codebase_fit_agent.md`
+- `github/pr_finding_validator.md`
+- `github/partials/full_context_analysis.md`
+
+Additional credited discipline:
+
+- `.agents/skills/9arm-skills/scrutinize/SKILL.md`
+- Source pack: `9arm-skills`
+- Credit: `thananon/9arm-skills`
+- Upstream: https://github.com/thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+
+## Process
+
+### 1. Load Review Context
+
+Read the available context:
+
+- PR diff or local `git diff`
+- changed filenames
+- linked stage artifacts under `devflow/runs/{ID}-*/`
+- `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md`, `60-report.md`, and `70-release.md` when relevant
+- project patterns and existing code around the changed files
+- legacy JSON only when migration context is still genuinely relevant
+
+### 2. Select Review Lanes
+
+Start with the `scrutinize` lens before detailed lane review:
+
+- Intent check: should this change exist in this form?
+- Smaller alternative: can the same outcome be reached with less code, lower risk, or existing patterns?
+- Actual path trace: follow runtime behavior beyond the diff.
+- Precision check: were assumptions explicit, edits surgical, success criteria verified, and uncertainty surfaced instead of guessed?
+
+Then select only the review lanes that match the scope. Do not run every lane by default; the review should be proportional to the change.
+
+| Lane | Use When |
+| :--- | :--- |
+| Correctness / bugs | Always, unless the user explicitly asks for a narrow non-code review. |
+| Type safety | Typed code, public types, schema changes, casts, `any`, or boundary parsing changed. |
+| Maintainability | The change adds duplication, cross-file patterns, API shape, migration bridges, or technical debt. |
+| Simplicity | The change adds abstractions, indirection, configuration, generalized utilities, or complex control flow. |
+| Testability | Important logic is mixed with IO, hidden state, time, random values, constructors, globals, or hard-coded dependencies. |
+| Coverage | New or changed behavior should have tests, especially bug fixes and business logic. |
+| Docs accuracy | Commands, setup, workflows, schemas, public APIs, examples, or user-visible behavior changed. |
+| AGENTS.md adherence | An `AGENTS.md` or equivalent project instruction file exists for the changed scope. |
+| Security | Auth, authorization, secrets, user input, external data, dependencies, or persistence boundaries changed. |
+| Performance | Queries, loops, rendering, data volume, hot paths, or synchronous work changed. |
+
+When a lane is skipped, briefly note why if the omission could surprise the reader. For tiny reviews, it is acceptable to state only the lanes used.
+
+### 3. Validate Findings
+
+Before reporting a finding:
+
+- verify it against the changed code
+- check whether it affects new code or pre-existing code
+- ensure it is actionable
+- include file and line references when possible
+- avoid style-only comments unless they hide real risk
+- keep each finding in its strongest matching lane; do not report the same issue twice under different labels
+- drop findings that are only suspicions, preferences, or theoretical improvements without a concrete failure mode
+- for AGENTS.md findings, quote the exact project instruction being violated
+- for docs findings, show the mismatch between what the docs say and what the code now does
+
+### 4. Output Findings First
+
+Use code-review style:
+
+1. Findings ordered by severity
+2. Open questions or assumptions
+3. Short summary
+4. Test gaps or residual risk
+
+When saving a substantial report, include a short `Source Discipline` section crediting `9arm-skills/scrutinize` and, where useful, brief `Intent Check`, `Smaller Alternative Considered`, and `Actual Path Trace` sections. Preserve the required PR review template headings.
+
+## Output
+
+Return a PR review. Do not modify files unless the user explicitly asks for fixes.
+
+**MANDATORY RULE:** Before saving a PR review report, inspect `.agent/resources/schemas/pr_review.template.md` and use its required headings and table structure.
+
+Before reporting completion, run:
+
+Review `{report_path}` against `pr_review.template.md`, keep the required headings, and remove placeholder text before completion.
+
+Replace any placeholder or template text with concrete findings, file references, risk, and verification gaps.
+
+**MANDATORY RULE:** If a running ID is linked to this PR, always save this review report to `pr_review.md` inside that workspace directory when possible:
+
+```text
+devflow/runs/{ID}-*/pr_review.md
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Verification and release support command, not a numbered stage
+- Typical entry points: `/50-Verify`, `PR`, `Agent code-reviewer`
+- Typical handoff targets: `PR-Followup`, `/60-Report`, `/70-Release`, `Wiki`
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/pr_review.template.md`
+- Related commands: `/50-Verify`, `PR`, `PR-Followup`, `Agent`, `/60-Report`, `/70-Release`, `Wiki`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/40-Implement {ID}` when review finds required fixes, or `/60-Report {ID}` when the review is clean and the run needs the final summary refreshed before release execution.
+- **Why**: PR review either creates corrective implementation work or clears the path toward final summary alignment and release-facing packaging.
+- **Alternatives**:
+  - `/70-Release` when the report is already aligned and only release execution remains
+  - `Wiki` when the review establishes a durable convention or risk pattern
+  - `PR-Followup {target}` when the PR already has comments that need classification and response
+