@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

package/template/.agents/skills/intelligent-routing/SKILL.md

@@ -1,176 +1,176 @@
----
-name: intelligent-routing
-description: Automatic agent and stage routing for DevFlow 2.0. Use when deciding which active workflow, skill, or specialist should own the next step.
-version: 2.0.0
----
-
-# Intelligent Routing For DevFlow 2.0
-
-## Purpose
-
-Analyze a user request and route it to the correct DevFlow 2.0 surface without requiring the user to name the exact workflow, skill, or agent.
-
-## Canonical Routing Order
-
-Always route in this order:
-
-1. Mainline stage if the request is lifecycle work
-2. Public companion command if the request is support work
-3. Specialist agent if the user needs focused expert judgment
-4. Internal companion or skill only when the public surface should stay thin
-
-Do not route new work into retired JSON-first commands, dashboard-first flows, or removed aliases.
-
-When routing to support skills, follow `docs/skill-selection-policy.md`.
-
-## Timeline Stages
-
-`/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release`
-
-## Public Companion Commands
-
-- `Goal`
-- `Brainstorm`
-- `Research`
-- `Debug`
-- `PRD`
-- `Issue-Triage`
-- `Wiki`
-- `Check-For-Updates`
-- `Help`
-
-## Specialist Agent Routing
-
-Use these agent mappings when expert judgment is the best next step:
-
-| Request Type | Route To |
-|---|---|
-| requirements clarification | `requirements-engineer` |
-| product framing | `prp-core-prd-architect` |
-| planning breakdown | `prp-core-planner` |
-| codebase exploration | `codebase-explorer` |
-| backend implementation or API review | `backend-specialist` |
-| frontend implementation or UI review | `frontend-specialist` |
-| schema and query design | `database-architect` |
-| implementation execution | `prp-core-coder` |
-| tests and coverage | `test-engineer` |
-| code review and risk review | `code-reviewer` |
-| security review | `security-auditor` |
-| performance review | `performance-engineer` |
-| root-cause debugging | `prp-core-debugger` |
-| release packaging and commit scope | `prp-core-git-committer`, `prp-core-git-pr-maker` |
-| broad orchestration across domains | `orchestrator` |
-| overnight maintenance loops and repo cleanup | `ob-loop-engineer` |
-
-## Lifecycle Routing Rules
-
-| User State | Recommended Route |
-|---|---|
+---
+name: intelligent-routing
+description: Automatic agent and stage routing for DevFlow 2.0. Use when deciding which active workflow, skill, or specialist should own the next step.
+version: 2.0.0
+---
+
+# Intelligent Routing For DevFlow 2.0
+
+## Purpose
+
+Analyze a user request and route it to the correct DevFlow 2.0 surface without requiring the user to name the exact workflow, skill, or agent.
+
+## Canonical Routing Order
+
+Always route in this order:
+
+1. Mainline stage if the request is lifecycle work
+2. Public companion command if the request is support work
+3. Specialist agent if the user needs focused expert judgment
+4. Internal companion or skill only when the public surface should stay thin
+
+Do not route new work into retired JSON-first commands, dashboard-first flows, or removed aliases.
+
+When routing to support skills, follow `docs/skill-selection-policy.md`.
+
+## Timeline Stages
+
+`/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release`
+
+## Public Companion Commands
+
+- `Goal`
+- `Brainstorm`
+- `Research`
+- `Debug`
+- `PRD`
+- `Issue-Triage`
+- `Wiki`
+- `Check-For-Updates`
+- `Help`
+
+## Specialist Agent Routing
+
+Use these agent mappings when expert judgment is the best next step:
+
+| Request Type | Route To |
+|---|---|
+| requirements clarification | `requirements-engineer` |
+| product framing | `prp-core-prd-architect` |
+| planning breakdown | `prp-core-planner` |
+| codebase exploration | `codebase-explorer` |
+| backend implementation or API review | `backend-specialist` |
+| frontend implementation or UI review | `frontend-specialist` |
+| schema and query design | `database-architect` |
+| implementation execution | `prp-core-coder` |
+| tests and coverage | `test-engineer` |
+| code review and risk review | `code-reviewer` |
+| security review | `security-auditor` |
+| performance review | `performance-engineer` |
+| root-cause debugging | `prp-core-debugger` |
+| release packaging and commit scope | `prp-core-git-committer`, `prp-core-git-pr-maker` |
+| broad orchestration across domains | `orchestrator` |
+| overnight maintenance loops and repo cleanup | `ob-loop-engineer` |
+
+## Lifecycle Routing Rules
+
+| User State | Recommended Route |
+|---|---|
 | new request, vague or clear | `/00-Discover`; it selects support inquiry and owns the delivery decision |
 | approved discovery needs one or more delivery boundaries | `/10-Define {discovery_id}` |
-| needs requirements and acceptance criteria | `/20-Spec` |
-| has a stable spec and needs execution plan | `/30-Plan` |
-| needs implementation work | `/40-Implement` |
-| needs testing, review, or validation evidence | `/50-Verify` |
-| needs packaging, commit, PR, or release handling | `/70-Release` |
-| needs the final summary or handoff narrative | `/60-Report` |
-
-## Routing Heuristics
-
-### Use a Timeline stage when:
-
-- the request advances a task through its lifecycle
-- the user needs an artifact in `.workspaces`
-- the next step should change stage ownership
-
-### Use a public companion command when:
-
-- the request supports a stage rather than replacing it
-- the user needs exploration, research, debugging, or help
-- the output is advisory or investigative
-
-### Use an internal clarification skill when:
-
-- the current stage is blocked by ambiguity, not by missing execution effort
-- a small amount of user interaction could change scope, acceptance criteria, or planning decisions
-- the public surface should stay the same and the questioning method is only supporting the active stage
-
-If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
-
-- `/10-Define` when scope or terminology is unstable
-- `/20-Spec` when acceptance criteria or rules are ambiguous
-- `/30-Plan` when architecture or verification choices are still reversible but unclear
-
-Do not use deep questioning by default in every stage. Collect only the information that affects the current Timeline-stage decision.
-
-### Use an internal clarification skill when:
-
-- the current stage is blocked by ambiguity, not by missing execution effort
-- a small amount of user interaction could change scope, acceptance criteria, or planning decisions
-- the public surface should stay the same and the questioning method is only supporting the active stage
-
-If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
-
-- `/10-Define` when scope or terminology is unstable
-- `/20-Spec` when acceptance criteria or rules are ambiguous
-- `/30-Plan` when architecture or verification choices are still reversible but unclear
-
-Do not use deep questioning by default in every stage. Collect only the information that affects the current stage decision.
-
-### Use a specialist agent when:
-
-- the user explicitly asks for one
-- a narrow expert lens is more useful than a workflow shell
-- the active stage already exists and only specialist judgment is missing
-
-### Use a support skill when:
-
-- a mainline stage or public companion already owns the work
-- the skill resolves a bounded uncertainty inside that owner
-- the skill is more specific than the general companion surface
-- the skill output can be captured in the owning stage artifact, `CONTEXT.md`, an ADR, or a focused doc
-
-Support skill limits:
-
-- choose one primary skill per pass
-- add at most two secondary skills when each has a distinct purpose
-- prefer the most specific skill when descriptions overlap
-- route back to the owning stage when a skill finds a lifecycle-level contradiction
-
-Key conflict defaults:
-
-| Conflict | Route |
-|---|---|
-| `Brainstorm` vs `grilling` | `Brainstorm` for option generation; `grilling` for stress-testing a candidate idea |
-| `grilling` vs `grill-with-docs` | `grill-with-docs` when a codebase or durable docs matter |
-| `grill-with-docs` vs `domain-modeling` | `grill-with-docs` interviews; `domain-modeling` records confirmed glossary terms or ADRs |
-| `to-prd` vs `PRD` | `PRD` owns the public surface; `to-prd` is an internal synthesis method |
-| `to-issues` vs `/30-Plan` | `/30-Plan` owns work breakdown; `to-issues` packages slices when issue tracker output is needed |
-| `implement` vs `/40-Implement` | `/40-Implement` owns implementation |
-| `review` vs `/50-Verify` | `/50-Verify` owns verification; `review` is one lane |
-
-## Examples
-
-| User Request | Route |
-|---|---|
+| needs requirements and acceptance criteria | `/20-Spec` |
+| has a stable spec and needs execution plan | `/30-Plan` |
+| needs implementation work | `/40-Implement` |
+| needs testing, review, or validation evidence | `/50-Verify` |
+| needs packaging, commit, PR, or release handling | `/70-Release` |
+| needs the final summary or handoff narrative | `/60-Report` |
+
+## Routing Heuristics
+
+### Use a Timeline stage when:
+
+- the request advances a task through its lifecycle
+- the user needs an artifact in `.workspaces`
+- the next step should change stage ownership
+
+### Use a public companion command when:
+
+- the request supports a stage rather than replacing it
+- the user needs exploration, research, debugging, or help
+- the output is advisory or investigative
+
+### Use an internal clarification skill when:
+
+- the current stage is blocked by ambiguity, not by missing execution effort
+- a small amount of user interaction could change scope, acceptance criteria, or planning decisions
+- the public surface should stay the same and the questioning method is only supporting the active stage
+
+If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
+
+- `/10-Define` when scope or terminology is unstable
+- `/20-Spec` when acceptance criteria or rules are ambiguous
+- `/30-Plan` when architecture or verification choices are still reversible but unclear
+
+Do not use deep questioning by default in every stage. Collect only the information that affects the current Timeline-stage decision.
+
+### Use an internal clarification skill when:
+
+- the current stage is blocked by ambiguity, not by missing execution effort
+- a small amount of user interaction could change scope, acceptance criteria, or planning decisions
+- the public surface should stay the same and the questioning method is only supporting the active stage
+
+If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
+
+- `/10-Define` when scope or terminology is unstable
+- `/20-Spec` when acceptance criteria or rules are ambiguous
+- `/30-Plan` when architecture or verification choices are still reversible but unclear
+
+Do not use deep questioning by default in every stage. Collect only the information that affects the current stage decision.
+
+### Use a specialist agent when:
+
+- the user explicitly asks for one
+- a narrow expert lens is more useful than a workflow shell
+- the active stage already exists and only specialist judgment is missing
+
+### Use a support skill when:
+
+- a mainline stage or public companion already owns the work
+- the skill resolves a bounded uncertainty inside that owner
+- the skill is more specific than the general companion surface
+- the skill output can be captured in the owning stage artifact, `CONTEXT.md`, an ADR, or a focused doc
+
+Support skill limits:
+
+- choose one primary skill per pass
+- add at most two secondary skills when each has a distinct purpose
+- prefer the most specific skill when descriptions overlap
+- route back to the owning stage when a skill finds a lifecycle-level contradiction
+
+Key conflict defaults:
+
+| Conflict | Route |
+|---|---|
+| `Brainstorm` vs `grilling` | `Brainstorm` for option generation; `grilling` for stress-testing a candidate idea |
+| `grilling` vs `grill-with-docs` | `grill-with-docs` when a codebase or durable docs matter |
+| `grill-with-docs` vs `domain-modeling` | `grill-with-docs` interviews; `domain-modeling` records confirmed glossary terms or ADRs |
+| `to-prd` vs `PRD` | `PRD` owns the public surface; `to-prd` is an internal synthesis method |
+| `to-issues` vs `/30-Plan` | `/30-Plan` owns work breakdown; `to-issues` packages slices when issue tracker output is needed |
+| `implement` vs `/40-Implement` | `/40-Implement` owns implementation |
+| `review` vs `/50-Verify` | `/50-Verify` owns verification; `review` is one lane |
+
+## Examples
+
+| User Request | Route |
+|---|---|
 | "I have an idea but not the shape yet" | `/00-Discover`, likely `Brainstorm`, then return to Discover |
 | "Turn this stable new goal into requirements" | `/00-Discover`, then `/10-Define {discovery_id}` before `/20-Spec {running_id}` |
 | "Fix this newly reported broken auth flow" | `/00-Discover`, likely `Debug`, then return to Discover before Define |
-| "Review this implementation for risks" | `/50-Verify` or `Agent code-reviewer ...` |
-| "Install or upgrade Nexus-DevFlow on this machine" | `Check-For-Updates` |
-| "Help me figure out which command to use" | `Help` |
-
-## Guardrails
-
-- Do not recommend removed numeric aliases such as old task/code/verify commands.
-- Do not mention legacy external control files as part of the routing model.
-- Do not invent agent names that are not present in the current repo.
-- If the request spans multiple domains and the owner is unclear, route to `orchestrator`.
-- If clarification is needed, ask only for information that can change the active stage decision.
-- If clarification is needed, ask only for information that can change the active stage decision.
-
-## Output Pattern
-
-When applying this skill, answer in one short line before proceeding:
-
-`Applying DevFlow 2.0 routing: <chosen route> because <reason>.`
+| "Review this implementation for risks" | `/50-Verify` or `Agent code-reviewer ...` |
+| "Install or upgrade Nexus-DevFlow on this machine" | `Check-For-Updates` |
+| "Help me figure out which command to use" | `Help` |
+
+## Guardrails
+
+- Do not recommend removed numeric aliases such as old task/code/verify commands.
+- Do not mention legacy external control files as part of the routing model.
+- Do not invent agent names that are not present in the current repo.
+- If the request spans multiple domains and the owner is unclear, route to `orchestrator`.
+- If clarification is needed, ask only for information that can change the active stage decision.
+- If clarification is needed, ask only for information that can change the active stage decision.
+
+## Output Pattern
+
+When applying this skill, answer in one short line before proceeding:
+
+`Applying DevFlow 2.0 routing: <chosen route> because <reason>.`

package/template/.agents/skills/issue-triage/SKILL.md

@@ -3,113 +3,113 @@ name: issue-triage
 description: Issue-Triage workflow
 ---
 
----
-description: Issue Triage Addon - Analyze GitHub issues, detect duplicates or spam, and route actionable work into DevFlow workflows.
----
-
-# Phase 57: Issue Triage Addon
-
-## Target: $ARGUMENTS
-
+---
+description: Issue Triage Addon - Analyze GitHub issues, detect duplicates or spam, and route actionable work into DevFlow workflows.
+---
+
+# Phase 57: Issue Triage Addon
+
+## Target: $ARGUMENTS
+
 Use this workflow to evaluate GitHub issues, bug reports, feature requests, support requests, duplicates, or noisy reports before creating or resuming work.
 Use `triage` as the support skill for classification, verification, and agent-ready briefs. Use `to-issues` only when a stable spec or PRD must be packaged into vertical slices.
-
-## Prompt Sources
-
-Adapted from:
-
-- `github/issue_analyzer.md`
-- `github/issue_triager.md`
-- `github/duplicate_detector.md`
-- `github/spam_detector.md`
-- `github/pr_ai_triage.md`
-
-## Process
-
-### 1. Read Issue Context
-
-Collect:
-
-- issue title and body
-- comments and maintainer notes
-- labels and linked PRs
-- reproduction steps
-- affected versions or environment
-- related files, logs, screenshots, or references
-
-### 2. Triage
-
-Classify the issue:
-
-- bug
-- feature request
-- documentation request
-- question or support
-- duplicate
-- spam or noise
-- needs more information
-
-Assess:
-
-- severity
-- user impact
-- reproducibility
-- affected area
-- confidence
-
-Separate:
-
-- what is already evidenced
-- what is inferred
-- what still needs proof
-
-### 3. Create Issue Triage Report
-
-- **MANDATORY:** Before generating the final report, inspect `.agent/resources/schemas/triage.template.md` for layout, required sections, and format.
-- Before reporting completion, run:
-
-Review `{report_path}` against `triage.template.md`, keep the required headings, and remove placeholder text before completion.
-
-- Replace any placeholder or template text with concrete issue summary, classification, impact, routing decision, and next command.
-- Save the final report to:
-
-```text
-devflow/issues/{date}-triage-{issue_number}.md
-```
-
-### 4. Route
-
-Use:
-
-- `Debug` for confirmed bugs needing root cause work
-- `Research` or `Spec-Research` for external dependency uncertainty
-- `PRD` for product-level feature requests that need problem framing
-- `/10-Define` for actionable work that still needs scope decisions
-- `/20-Spec` for work that is already stable enough to become a delivery contract
-- `Help` when the issue is not actionable yet
-
-## Output Triage Recommendation
-
-Return:
-
-- classification
-- duplicate or spam assessment
-- confidence level
-- recommended route into DevFlow 2.0
-- where the report was written
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Intake support command, not a numbered stage
-- Typical entry points: issue intake before scope or implementation begins
-- Typical handoff targets: `Debug`, `PRD`, `/10-Define`, `Research`, `Help`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/triage.template.md`
+
+## Prompt Sources
+
+Adapted from:
+
+- `github/issue_analyzer.md`
+- `github/issue_triager.md`
+- `github/duplicate_detector.md`
+- `github/spam_detector.md`
+- `github/pr_ai_triage.md`
+
+## Process
+
+### 1. Read Issue Context
+
+Collect:
+
+- issue title and body
+- comments and maintainer notes
+- labels and linked PRs
+- reproduction steps
+- affected versions or environment
+- related files, logs, screenshots, or references
+
+### 2. Triage
+
+Classify the issue:
+
+- bug
+- feature request
+- documentation request
+- question or support
+- duplicate
+- spam or noise
+- needs more information
+
+Assess:
+
+- severity
+- user impact
+- reproducibility
+- affected area
+- confidence
+
+Separate:
+
+- what is already evidenced
+- what is inferred
+- what still needs proof
+
+### 3. Create Issue Triage Report
+
+- **MANDATORY:** Before generating the final report, inspect `.agent/resources/schemas/triage.template.md` for layout, required sections, and format.
+- Before reporting completion, run:
+
+Review `{report_path}` against `triage.template.md`, keep the required headings, and remove placeholder text before completion.
+
+- Replace any placeholder or template text with concrete issue summary, classification, impact, routing decision, and next command.
+- Save the final report to:
+
+```text
+devflow/issues/{date}-triage-{issue_number}.md
+```
+
+### 4. Route
+
+Use:
+
+- `Debug` for confirmed bugs needing root cause work
+- `Research` or `Spec-Research` for external dependency uncertainty
+- `PRD` for product-level feature requests that need problem framing
+- `/10-Define` for actionable work that still needs scope decisions
+- `/20-Spec` for work that is already stable enough to become a delivery contract
+- `Help` when the issue is not actionable yet
+
+## Output Triage Recommendation
+
+Return:
+
+- classification
+- duplicate or spam assessment
+- confidence level
+- recommended route into DevFlow 2.0
+- where the report was written
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Intake support command, not a numbered stage
+- Typical entry points: issue intake before scope or implementation begins
+- Typical handoff targets: `Debug`, `PRD`, `/10-Define`, `Research`, `Help`
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/triage.template.md`
 - Related commands: `Debug`, `PRD`, `/10-Define`, `Research`, `Help`
 - Support skills: `triage`, `to-issues`, `domain-modeling`
-
-
+
+

package/template/.agents/skills/lint-and-validate/SKILL.md

@@ -1,45 +1,45 @@
----
-name: lint-and-validate
-description: Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Lint and Validate Skill
-
-> **MANDATORY:** Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.
-
-### Procedures by Ecosystem
-
-#### Node.js / TypeScript
-1. **Lint/Fix:** `npm run lint` or `npx eslint "path" --fix`
-2. **Types:** `npx tsc --noEmit`
-3. **Security:** `npm audit --audit-level=high`
-
-#### Python
-1. **Linter (Ruff):** `ruff check "path" --fix` (Fast & Modern)
-2. **Security (Bandit):** `bandit -r "path" -ll`
-3. **Types (MyPy):** `mypy "path"`
-
-## The Quality Loop
-1. **Write/Edit Code**
-2. **Run Audit:** `npm run lint && npx tsc --noEmit`
-3. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.
-4. **Fix & Repeat:** Submitting code with "FINAL AUDIT" failures is NOT allowed.
-
-## Error Handling
-- If `lint` fails: Fix the style or syntax issues immediately.
-- If `tsc` fails: Correct type mismatches before proceeding.
-- If no tool is configured: Check the project root for `.eslintrc`, `tsconfig.json`, `pyproject.toml` and suggest creating one.
-
----
-**Strict Rule:** No code should be committed or reported as "done" without passing these checks.
-
----
-
-## Scripts
-
-| Script | Purpose | Command |
-|--------|---------|---------|
-| `scripts/lint_runner.py` | Unified lint check | `python scripts/lint_runner.py <project_path>` |
-| `scripts/type_coverage.py` | Type coverage analysis | `python scripts/type_coverage.py <project_path>` |
-
+---
+name: lint-and-validate
+description: Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Lint and Validate Skill
+
+> **MANDATORY:** Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.
+
+### Procedures by Ecosystem
+
+#### Node.js / TypeScript
+1. **Lint/Fix:** `npm run lint` or `npx eslint "path" --fix`
+2. **Types:** `npx tsc --noEmit`
+3. **Security:** `npm audit --audit-level=high`
+
+#### Python
+1. **Linter (Ruff):** `ruff check "path" --fix` (Fast & Modern)
+2. **Security (Bandit):** `bandit -r "path" -ll`
+3. **Types (MyPy):** `mypy "path"`
+
+## The Quality Loop
+1. **Write/Edit Code**
+2. **Run Audit:** `npm run lint && npx tsc --noEmit`
+3. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.
+4. **Fix & Repeat:** Submitting code with "FINAL AUDIT" failures is NOT allowed.
+
+## Error Handling
+- If `lint` fails: Fix the style or syntax issues immediately.
+- If `tsc` fails: Correct type mismatches before proceeding.
+- If no tool is configured: Check the project root for `.eslintrc`, `tsconfig.json`, `pyproject.toml` and suggest creating one.
+
+---
+**Strict Rule:** No code should be committed or reported as "done" without passing these checks.
+
+---
+
+## Scripts
+
+| Script | Purpose | Command |
+|--------|---------|---------|
+| `scripts/lint_runner.py` | Unified lint check | `python scripts/lint_runner.py <project_path>` |
+| `scripts/type_coverage.py` | Type coverage analysis | `python scripts/type_coverage.py <project_path>` |
+