@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.2

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

@@ -1,97 +1,97 @@
----
-name: release-git-operations
-description: 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
+---
+name: release-git-operations
+description: 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

package/template/.agents/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/.agents/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