@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

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

@@ -3,141 +3,141 @@ name: research
 description: Research workflow
 ---
 
----
-description: Codebase and evidence research. Transitional compatibility path for the Research companion command in DevFlow 2.0.
----
-
-# Research - Codebase And Evidence Exploration
-
-## Topic: $ARGUMENTS
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Research` is a companion command, not a numbered mainline workflow. The operational behavior remains detailed so it can still function like the original research workflow.
-
-## Purpose
-
-Use `Research` to answer complex questions with code evidence, source material, and structured findings.
-
+---
+description: Codebase and evidence research. Transitional compatibility path for the Research companion command in DevFlow 2.0.
+---
+
+# Research - Codebase And Evidence Exploration
+
+## Topic: $ARGUMENTS
+
+This file keeps its old numeric path for migration compatibility.
+
+In DevFlow 2.0, `Research` is a companion command, not a numbered mainline workflow. The operational behavior remains detailed so it can still function like the original research workflow.
+
+## Purpose
+
+Use `Research` to answer complex questions with code evidence, source material, and structured findings.
+
 Use it when:
-
-- facts are missing
-- source material must be collected
-- the codebase or external docs need deeper investigation
+
+- facts are missing
+- source material must be collected
+- the codebase or external docs need deeper investigation
 - Discover, Define, or Spec cannot proceed confidently without evidence
 
 Use `prototype` when the fastest reliable evidence is a runnable throwaway experiment rather than more reading.
-
+
 Preferred DevFlow 2.0 pairing:
-
-- from `/00-Discover`
-- from `/10-Define`
-- from `/20-Spec`
+
+- from `/00-Discover`
+- from `/10-Define`
+- from `/20-Spec`
 - from `/50-Verify` when validating a claim or implementation choice
 
 When invoked with a Discovery ID, link the research report to that discovery and return to `/00-Discover {discovery_id}` so Discover can synthesize the evidence and make the decision. Research must not allocate a Running ID.
-
----
-
-## Internal Process
-
-You are an orchestrator. Your goal is to perform deep technical or evidence research while preserving the richer research UX from the original workflow.
-
-Apply prompt addon patterns when the topic matches:
-
-| Topic | Addon pattern | Output |
-| :--- | :--- | :--- |
-| External libraries, APIs, SDKs, services | `spec_researcher` | validated integration notes with sources and implementation constraints |
-| Competitors, alternatives, market gaps | `competitor_analysis` | competitor list, pain points, differentiator opportunities |
-| Completed implementation lessons | `insight_extractor` | reusable patterns, gotchas, file insights, recommendations |
-| API/database/browser validation | `mcp_tools/*` | available validation steps for the current IDE/tooling |
-
-### Phase 1: Query Decomposition
-
-- clarify the research question
-- classify whether the work is mainly codebase research, external research, or both
-- identify the evidence needed to answer it
-
-### Phase 2: Exploration
-
-- locate relevant code with file and line references
-- trace data flows, architecture, and integration points
-- gather external documentation and source material when needed
-- prioritize "what is" over "what should be"
-
-### Phase 3: Synthesis And Documentation
-
-- summarize key findings
-- separate facts from inference
-- record constraints, risks, and unanswered questions
-- save the durable research note to disk
-
-### Phase 4: Knowledge Management
-
-- if significant patterns or durable lessons are discovered, recommend recording them in `devflow/lessons.md` or `Wiki`
-
-## Output Format
-
-Save the full research note to `devflow/research/{date}-{slug}.md`.
-
-Before generating the report:
-
-1. Inspect `.agent/resources/schemas/research.template.md`
-2. Preserve its required headings and tables
-3. Replace placeholder text with concrete evidence
-4. Re-check the output against `research.template.md`, ensure required headings remain, and remove all placeholders before completion
-
-Return a concise chat summary plus a persistent report with:
-
-```markdown
-## Research Summary: [Topic]
-
-### Question
-[What needed to be answered]
-
-### Findings
-- [Finding 1]
-- [Finding 2]
-
-### Evidence
-- [file:line, source, or doc link]
-
-### Constraints And Risks
-- [Constraint]
-
-### Open Questions
-- [Question still unanswered]
-
-### Recommended Next Step
-- [What to do with this research]
-```
-
-## Examples
-
-```text
-Research auth patterns in the current codebase
-Research Stripe webhook handling constraints
-Research competitor onboarding flows
-Research whether this API version is compatible
-```
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`
-- Typical handoff targets: return to the stage that asked for the evidence
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/research.template.md`
+
+---
+
+## Internal Process
+
+You are an orchestrator. Your goal is to perform deep technical or evidence research while preserving the richer research UX from the original workflow.
+
+Apply prompt addon patterns when the topic matches:
+
+| Topic | Addon pattern | Output |
+| :--- | :--- | :--- |
+| External libraries, APIs, SDKs, services | `spec_researcher` | validated integration notes with sources and implementation constraints |
+| Competitors, alternatives, market gaps | `competitor_analysis` | competitor list, pain points, differentiator opportunities |
+| Completed implementation lessons | `insight_extractor` | reusable patterns, gotchas, file insights, recommendations |
+| API/database/browser validation | `mcp_tools/*` | available validation steps for the current IDE/tooling |
+
+### Phase 1: Query Decomposition
+
+- clarify the research question
+- classify whether the work is mainly codebase research, external research, or both
+- identify the evidence needed to answer it
+
+### Phase 2: Exploration
+
+- locate relevant code with file and line references
+- trace data flows, architecture, and integration points
+- gather external documentation and source material when needed
+- prioritize "what is" over "what should be"
+
+### Phase 3: Synthesis And Documentation
+
+- summarize key findings
+- separate facts from inference
+- record constraints, risks, and unanswered questions
+- save the durable research note to disk
+
+### Phase 4: Knowledge Management
+
+- if significant patterns or durable lessons are discovered, recommend recording them in `devflow/lessons.md` or `Wiki`
+
+## Output Format
+
+Save the full research note to `devflow/research/{date}-{slug}.md`.
+
+Before generating the report:
+
+1. Inspect `.agent/resources/schemas/research.template.md`
+2. Preserve its required headings and tables
+3. Replace placeholder text with concrete evidence
+4. Re-check the output against `research.template.md`, ensure required headings remain, and remove all placeholders before completion
+
+Return a concise chat summary plus a persistent report with:
+
+```markdown
+## Research Summary: [Topic]
+
+### Question
+[What needed to be answered]
+
+### Findings
+- [Finding 1]
+- [Finding 2]
+
+### Evidence
+- [file:line, source, or doc link]
+
+### Constraints And Risks
+- [Constraint]
+
+### Open Questions
+- [Question still unanswered]
+
+### Recommended Next Step
+- [What to do with this research]
+```
+
+## Examples
+
+```text
+Research auth patterns in the current codebase
+Research Stripe webhook handling constraints
+Research competitor onboarding flows
+Research whether this API version is compatible
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`
+- Typical handoff targets: return to the stage that asked for the evidence
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/research.template.md`
 - Related commands: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`, `Spec-Research`, `Agent`
 - Support skills: `prototype`, `spec-research`, `competitor-analysis`, `insight-capture`
-
-## Next Workflow Recommendation
-
+
+## Next Workflow Recommendation
+
 - Default: return to the stage that asked for evidence; for discovery-owned research this is `/00-Discover {discovery_id}`
-- Common routes: `/10-Define`, `/20-Spec`, `/30-Plan`, or `/50-Verify`
-- Alternate: `Brainstorm` if the research opens multiple strategic options
-
+- Common routes: `/10-Define`, `/20-Spec`, `/30-Plan`, or `/50-Verify`
+- Alternate: `Brainstorm` if the research opens multiple strategic options
+

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

@@ -1,55 +1,55 @@
----
-name: review
-description: Two-axis review for changed work. Use inside /50-Verify or /70-Release when a branch, PR, or work-in-progress diff needs standards and spec review.
----
-
-# Review
-
-Use this support skill as one verification lane. `/50-Verify` owns validation evidence; this skill reviews a diff from two separate angles.
-
-## Axes
-
-- **Standards**: does the change follow documented repo conventions?
-- **Spec**: does the change implement the originating issue, PRD, spec, or stage artifact?
-
-Keep the axes separate so one does not hide the other.
-
-## Process
-
-1. Pin the fixed point.
-   - Use the user-supplied commit, branch, tag, or merge-base.
-   - If none is supplied, default to the active branch merge-base with `main` when available.
-   - Confirm the diff is non-empty.
-
-2. Identify the spec source.
-   - Prefer `devflow/runs/{ID}-*/20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
-   - If no spec exists, mark the Spec axis as skipped.
-
-3. Identify standards sources.
-   - Look for repo docs such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, workflow docs, or stage contracts.
-
-4. Review standards.
-   - Cite the violated standard.
-   - Distinguish hard violations from judgment calls.
-   - Skip issues that tooling already enforces unless tooling is missing.
-
-5. Review spec.
-   - Report missing or partial requirements.
-   - Report scope creep.
-   - Report implemented behavior that appears wrong against the spec.
-
-6. Aggregate findings.
-   - Present `Standards` and `Spec` separately.
-   - Lead with concrete findings and file references.
-   - Record residual risk and skipped axes.
-
-## Output
-
-Return:
-
-- fixed point and diff scope
-- standards sources
-- spec source or skipped reason
-- findings by axis
-- worst issue per axis
-- recommended DevFlow route
+---
+name: review
+description: Two-axis review for changed work. Use inside /50-Verify or /70-Release when a branch, PR, or work-in-progress diff needs standards and spec review.
+---
+
+# Review
+
+Use this support skill as one verification lane. `/50-Verify` owns validation evidence; this skill reviews a diff from two separate angles.
+
+## Axes
+
+- **Standards**: does the change follow documented repo conventions?
+- **Spec**: does the change implement the originating issue, PRD, spec, or stage artifact?
+
+Keep the axes separate so one does not hide the other.
+
+## Process
+
+1. Pin the fixed point.
+   - Use the user-supplied commit, branch, tag, or merge-base.
+   - If none is supplied, default to the active branch merge-base with `main` when available.
+   - Confirm the diff is non-empty.
+
+2. Identify the spec source.
+   - Prefer `devflow/runs/{ID}-*/20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
+   - If no spec exists, mark the Spec axis as skipped.
+
+3. Identify standards sources.
+   - Look for repo docs such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, workflow docs, or stage contracts.
+
+4. Review standards.
+   - Cite the violated standard.
+   - Distinguish hard violations from judgment calls.
+   - Skip issues that tooling already enforces unless tooling is missing.
+
+5. Review spec.
+   - Report missing or partial requirements.
+   - Report scope creep.
+   - Report implemented behavior that appears wrong against the spec.
+
+6. Aggregate findings.
+   - Present `Standards` and `Spec` separately.
+   - Lead with concrete findings and file references.
+   - Record residual risk and skipped axes.
+
+## Output
+
+Return:
+
+- fixed point and diff scope
+- standards sources
+- spec source or skipped reason
+- findings by axis
+- worst issue per axis
+- recommended DevFlow route

package/template/.claude/skills/review-followup-routing/SKILL.md

@@ -1,98 +1,98 @@
----
-name: review-followup-routing
-description: Classify review comments, extend existing work safely, and route corrective or future work back into the right DevFlow 2.0 stage. Use for PR follow-up and post-review follow-up planning.
----
-
-# Review Follow-up Routing
-
-## Overview
-
-This skill groups follow-up handling that used to be split across:
-
-- `PR-Followup`
-- `Followup`
-
-It keeps follow-up work attached to the right running ID without replacing the numbered mainline.
-
-## Related Foundation Assets
-
-This skill should reuse and align with:
-
-- `.agent/resources/schemas/pr_followup.template.md`
-- active stage markdown artifacts under `devflow/runs/{ID}-*/`
-
-## Supported Modes
-
-- `pr-followup`
-- `task-followup`
-
-## When to Use
-
-- after `PR-Review` when review comments need classification and response
-- after human feedback, QA, or release review when a task needs additional scoped work
-- when existing work should be extended instead of replaced
-
-## Process
-
-### 1. Load Current Context
-
-Read only the minimum needed:
-
-- existing running ID workspace artifacts
-- latest review comments, requested changes, or QA findings
-- current implementation or verification notes when relevant
-
-### 2. Classify The Follow-up
-
-Classify each item into a useful bucket such as:
-
-- fix now
-- already resolved
-- needs clarification
-- new scope follow-up
-- pre-existing issue
-- non-actionable
-
-For task follow-up, also classify the change shape:
-
-- extension
-- enhancement
-- integration
-- refinement
-- bug fix after review
-
-### 3. Preserve Existing History
-
-Extend existing markdown artifacts instead of replacing them:
-
-- keep current phases and completed work intact
-- append new phases, subtasks, notes, or decision logs
-- keep the same running ID unless the new scope truly deserves a separate work line
-
-### 4. Save Reusable Output
-
-For PR-centered follow-up, save a report under:
-
-```text
-devflow/reports/{date}-pr-followup-{ID}.md
-```
-
-Use `.agent/resources/schemas/pr_followup.template.md` when a formal report is required.
-
-For task follow-up, append the approved follow-up work directly into the relevant stage markdown files for the same running ID.
-
-### 5. Route Back
-
-- `/40-Implement` for immediate corrective work
-- `/50-Verify` when only verification needs another pass
-- `/10-Define` or `/20-Spec` when the follow-up becomes genuinely new scope
-
-## Output
-
-Return:
-
-- mode used
-- classification summary
-- what changes now versus later
-- where the follow-up was recorded
-- exact recommended next command
+---
+name: review-followup-routing
+description: Classify review comments, extend existing work safely, and route corrective or future work back into the right DevFlow 2.0 stage. Use for PR follow-up and post-review follow-up planning.
+---
+
+# Review Follow-up Routing
+
+## Overview
+
+This skill groups follow-up handling that used to be split across:
+
+- `PR-Followup`
+- `Followup`
+
+It keeps follow-up work attached to the right running ID without replacing the numbered mainline.
+
+## Related Foundation Assets
+
+This skill should reuse and align with:
+
+- `.agent/resources/schemas/pr_followup.template.md`
+- active stage markdown artifacts under `devflow/runs/{ID}-*/`
+
+## Supported Modes
+
+- `pr-followup`
+- `task-followup`
+
+## When to Use
+
+- after `PR-Review` when review comments need classification and response
+- after human feedback, QA, or release review when a task needs additional scoped work
+- when existing work should be extended instead of replaced
+
+## Process
+
+### 1. Load Current Context
+
+Read only the minimum needed:
+
+- existing running ID workspace artifacts
+- latest review comments, requested changes, or QA findings
+- current implementation or verification notes when relevant
+
+### 2. Classify The Follow-up
+
+Classify each item into a useful bucket such as:
+
+- fix now
+- already resolved
+- needs clarification
+- new scope follow-up
+- pre-existing issue
+- non-actionable
+
+For task follow-up, also classify the change shape:
+
+- extension
+- enhancement
+- integration
+- refinement
+- bug fix after review
+
+### 3. Preserve Existing History
+
+Extend existing markdown artifacts instead of replacing them:
+
+- keep current phases and completed work intact
+- append new phases, subtasks, notes, or decision logs
+- keep the same running ID unless the new scope truly deserves a separate work line
+
+### 4. Save Reusable Output
+
+For PR-centered follow-up, save a report under:
+
+```text
+devflow/reports/{date}-pr-followup-{ID}.md
+```
+
+Use `.agent/resources/schemas/pr_followup.template.md` when a formal report is required.
+
+For task follow-up, append the approved follow-up work directly into the relevant stage markdown files for the same running ID.
+
+### 5. Route Back
+
+- `/40-Implement` for immediate corrective work
+- `/50-Verify` when only verification needs another pass
+- `/10-Define` or `/20-Spec` when the follow-up becomes genuinely new scope
+
+## Output
+
+Return:
+
+- mode used
+- classification summary
+- what changes now versus later
+- where the follow-up was recorded
+- exact recommended next command