@jakkrichm/create-nexus-devflow 2.0.11 → 2.0.13

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

@@ -1,239 +0,0 @@
----
-name: planning-and-task-breakdown
-description: "[Devflow] 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/pr-review/SKILL.md

@@ -1,143 +0,0 @@
----name: pr-review
-
-description: "[Devflow] 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
-

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

@@ -1,89 +0,0 @@
----
-name: pr-review-analysis
-description: "[Devflow] Review pull requests or local diffs with structured finding discipline, selective review lanes, and Nexus-DevFlow report templates. Use when the team needs a substantial review without turning review into a numbered workflow stage."
----
-
-# PR Review Analysis
-
-## Overview
-
-This skill is the shared behavior layer behind `PR-Review`.
-
-It preserves the stronger PR review UX from the legacy workflow while fitting DevFlow 2.0 as a non-mainline support capability.
-
-## Related Foundation Skills
-
-This skill should reuse and align with:
-
-- `.agents/skills/9arm-skills/scrutinize/SKILL.md`
-- `.agent/resources/schemas/pr_review.template.md`
-
-## When to Use
-
-- after `50-verify` when the change needs structured review before `60-report` and `70-release`
-- when a local diff, branch, or pull request needs findings-first analysis
-- when the user wants review without directly editing code
-
-Do not use this skill as a substitute for implementation, debugging, or formal release packaging.
-
-## Process
-
-### 1. Load Review Context
-
-Read the minimum relevant context:
-
-- PR diff or local `git diff`
-- changed files
-- linked stage artifacts under the running workspace when available
-- nearby project patterns and affected runtime paths
-
-### 2. Apply Scrutiny First
-
-Start with the `scrutinize` discipline:
-
-- intent check
-- smaller or safer alternative
-- actual runtime path trace
-- precision and evidence check
-
-### 3. Select Review Lanes
-
-Use only the lanes that match scope:
-
-- correctness
-- maintainability
-- simplicity
-- testability and coverage
-- docs accuracy
-- AGENTS or instruction adherence
-- security
-- performance
-
-### 4. Validate Findings
-
-Before reporting a finding:
-
-- verify it against the changed code
-- confirm whether it is new or pre-existing
-- keep it actionable
-- include file and line references whenever possible
-
-### 5. Save Reusable Report
-
-When saving a substantial report, preserve:
-
-```text
-devflow/runs/{ID}-*/pr_review.md
-```
-
-Use `.agent/resources/schemas/pr_review.template.md` and replace all placeholder text with real findings, questions, risks, and evidence gaps.
-
-## Output
-
-Return:
-
-- findings ordered by severity
-- open questions or assumptions
-- residual risks or test gaps
-- where the review report was saved
-- the recommended next route such as `40-implement`, `70-release`, or `PR-Followup`

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

@@ -1,59 +0,0 @@
----
-name: preview-local-check
-description: "[Devflow] 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.

package/template/.claude/skills/release-git-operations/SKILL.md

@@ -1,97 +0,0 @@
----
-name: release-git-operations
-description: "[Devflow] Handle commit, pull request, merge, deployment, and changelog work around Release. Use when packaging verified work for sharing, integration, deployment, or release communication."
----
-
-# Release Git Operations
-
-## Overview
-
-This skill groups release-adjacent git and deployment behavior that used to be spread across multiple companion workflows.
-
-It is the shared behavior layer behind:
-
-- `Commit`
-- `PR`
-- `Merge`
-- `Deploy`
-- `Changelog`
-
-## Related Foundation Skills
-
-This skill should reuse and align with:
-
-- `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- `.agents/skills/shipping-and-launch/SKILL.md`
-- `.agents/skills/deployment-procedures/SKILL.md`
-
-## When to Use
-
-- After `50-verify` when verified work is ready for packaging
-- During `70-release` when the team needs commit, PR, merge, deployment, or changelog support after the report is already aligned
-- When release communication must be built from markdown-first stage artifacts
-
-## Supported Modes
-
-- `commit`
-- `pr`
-- `merge`
-- `deploy`
-- `changelog`
-
-## Process
-
-### 1. Confirm Release Context
-
-Read the minimum required artifacts:
-
-- `verify.md`
-- `release.md`
-- `report.md` when relevant
-- git state and repository policy when relevant
-
-### 2. Run The Appropriate Mode
-
-#### Commit
-
-- stage the intended scope
-- use disciplined commit messaging
-- preserve branch safety rules
-
-#### PR
-
-- build PR narrative from markdown-first artifacts
-- preserve repository template fidelity
-- route follow-up review work cleanly
-
-#### Merge
-
-- confirm verification and review gates are satisfied
-- integrate safely using repository policy
-- route conflicts back to implementation or follow-up
-
-#### Deploy
-
-- apply shipping and launch discipline
-- verify platform-specific readiness
-- keep rollback and health checks explicit
-
-#### Changelog
-
-- summarize user-facing changes from stage artifacts and git evidence
-- avoid leaking low-value internal detail
-
-### 3. Route Back
-
-- return to `70-release` when packaging is still in progress
-- return to `60-report` when communication is the remaining task
-- return to `40-implement`, `50-verify`, or `PR-Followup` if release blockers are discovered
-
-## Output
-
-Return:
-
-- mode executed
-- artifacts or git actions produced
-- risks, blockers, or follow-up needs
-- recommended next stage or companion command