@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

package/template/.agents/skills/60-report/SKILL.md

@@ -1,44 +1,44 @@
 ---name: 60-report
-
-description: Report stage in DevFlow 2.0 - produce the final standardized markdown and HTML summary for the full running flow.
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 60: Report
-
-$ARGUMENTS
-
-Produce the final human-friendly summary of the full running flow in both Markdown and HTML so the outcome is easy to communicate every time.
-
-## Usage
-
-```text
-/60-Report {running-id or workspace path}
-```
-
-Use this when:
-
-- verification is complete and the run is ready for a final standardized summary before release
-- the team needs a standardized summary for communication
-- non-technical readers should be able to understand what happened
-
-## Markdown-First Contract
-
-Write the primary stage artifacts to:
-
-```text
-devflow/runs/{ID}-{slug}/60-report.md
-devflow/runs/{ID}-{slug}/60-report.html
-```
-
-using:
-
-```text
-.agent/resources/schemas/report.template.md
-```
-
-Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
-
+
+description: Report stage in DevFlow 2.0 - produce the final standardized markdown and HTML summary for the full running flow.
+argument-hint: "{running-id or workspace path}"
+---
+
+# Phase 60: Report
+
+$ARGUMENTS
+
+Produce the final human-friendly summary of the full running flow in both Markdown and HTML so the outcome is easy to communicate every time.
+
+## Usage
+
+```text
+/60-Report {running-id or workspace path}
+```
+
+Use this when:
+
+- verification is complete and the run is ready for a final standardized summary before release
+- the team needs a standardized summary for communication
+- non-technical readers should be able to understand what happened
+
+## Markdown-First Contract
+
+Write the primary stage artifacts to:
+
+```text
+devflow/runs/{ID}-{slug}/60-report.md
+devflow/runs/{ID}-{slug}/60-report.html
+```
+
+using:
+
+```text
+.agent/resources/schemas/report.template.md
+```
+
+Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
+
 ## Required Section Content
 
 Before completing any generated artifact:
@@ -52,132 +52,132 @@ Before completing any generated artifact:
 - re-read the saved artifact and verify every heading satisfies this rule
 
 ## Process
-
-### Loop Contract
-
-Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
-
-- **Intent**: produce a final markdown and HTML summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
-- **Context**: read all relevant stage artifacts, checklist files, verify impact notes, release notes, validation output, and supporting artifacts that materially explain the result.
-- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions, then render the HTML report.
-- **Observation**: use concrete evidence such as checklist completion, blocked or skipped items, validation results, release state, impact notes, and unresolved follow-ups.
-- **Adjustment**: if evidence is missing, return to the owning stage; if the report must support continuation, use `handoff`; if the run produced reusable lessons, use `insight-capture` or `Wiki`.
-- **Stop Condition**: stop when `70-report.md` and `70-report.html` both exist, summarize the outcome accurately, include checklist and evidence snapshots, and name any remaining follow-up work.
-- **Handoff**: `70-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
-
-### 1. Gather Full Run Context
-
-Read all relevant stage artifacts:
-
+
+### Loop Contract
+
+Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
+
+- **Intent**: produce a final markdown and HTML summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
+- **Context**: read all relevant stage artifacts, checklist files, verify impact notes, release notes, validation output, and supporting artifacts that materially explain the result.
+- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions, then render the HTML report.
+- **Observation**: use concrete evidence such as checklist completion, blocked or skipped items, validation results, release state, impact notes, and unresolved follow-ups.
+- **Adjustment**: if evidence is missing, return to the owning stage; if the report must support continuation, use `handoff`; if the run produced reusable lessons, use `insight-capture` or `Wiki`.
+- **Stop Condition**: stop when `70-report.md` and `70-report.html` both exist, summarize the outcome accurately, include checklist and evidence snapshots, and name any remaining follow-up work.
+- **Handoff**: `70-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
+
+### 1. Gather Full Run Context
+
+Read all relevant stage artifacts:
+
 - the shared `00-discover.md` referenced by `source_discovery` when it materially explains the delivery decision
-- `10-define.md`
-- `20-spec.md`
-- `30-plan.md`
-- `40-implement.md`
-- `50-verify.md`
-- `checklists/implementation-checklist.md` when present
-- `checklists/verification-checklist.md` when present
-
-Include supporting artifacts only when they add real context.
-
-### 2. Summarize The Run
-
-Explain:
-
-- what problem was addressed
-- what direction was chosen
-- what was implemented
-- how it was verified
-- how checklist progress moved across the run
-- what approval or review state remained at each important gate
-- what the release recommendation is
-- what follow-up items still exist
-
-### 3. Produce Standardized Outputs
-
-Write:
-
-- a readable Markdown report for contributors
-- a consistent HTML report for stakeholder sharing
-
-In phase 1, `artifact_language` governs the markdown report text. HTML output is derived directly from `60-report.md` through the shared markdown-to-html renderer.
-
-To render the HTML consistently from the markdown report, use one of:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-npm run render:html -- --stage 60-report <workspace-path-or-running-id>
-```
-
-Keep checklist summaries and follow-up status inside `60-report.md` so they carry through into the rendered HTML.
-
-Both outputs should summarize checklist state when checklist artifacts exist, including:
-
-- completion progress
-- blocked or skipped items
-- notable evidence snapshots
-- approval status, review blockers, and next allowed command when they still matter
-- remaining follow-up work
-
-The HTML should stay visually consistent across runs while preserving the report markdown as the source of truth.
-
-### 4. Keep The Audience In Mind
-
-Prefer clarity over internal detail.
-
-Do not bury the outcome inside implementation trivia. The report should help a reader understand the run without replaying the whole workflow.
-
-When checklists exist, use them as the most human-readable operational record of what actually happened.
-Use `handoff` when the report must support continued work, and `insight-capture` when the run produced lessons that should become reusable knowledge.
-
-### 5. Manual Review Soft Gate
-
-Use the report as the final visibility checkpoint before release.
-If any stage still shows unresolved approval, blockers, or deferred work:
-
-- surface that state clearly in `60-report.md`
-- pull the relevant signal forward from checklist approval sections when they exist
-- do not imply the phase is fully closed when review is still open
-- recommend the real next action, even if that means returning to an earlier stage
-
-## Output
-
-Report:
-
-- what the run accomplished
-- checklist completion status and remaining items
-- important remaining follow-ups
-- where `60-report.md` and `60-report.html` were written
-- render command used or recommended:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-```
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `/50-Verify`
-- Next state: `/70-Release` when the summary is aligned and release can proceed
-- Common companion commands: `Wiki` for durable knowledge capture, `Help` for routing or explanation
-- Support skills: `handoff`, `insight-capture`, and writing skills when final reporting must support continuation or reusable learning
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/report.template.md`
-- Related commands: `/50-Verify`, `/70-Release`, `Wiki`, `Help`
-
-## Next Workflow Recommendation
-
-- **Primary**: `/70-Release {ID}` after `60-report.md` and `60-report.html` reflect the verified state clearly.
-- **Render HTML**: `npm run report:html -- {ID}` after `60-report.md` is finalized so the standardized stakeholder HTML stays in sync
-- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues
-- **Additional Alternative**: `handoff` when another session or agent must continue from the completed run.
-
-## Nexus Event
-
-- Use `Wiki` when the final summary should become durable project or framework knowledge.
-- Use `Help` when approval signals, ownership, or route timing still feel ambiguous.
-- Return to `/50-Verify` when unresolved evidence, blockers, or review state mean the report should not advance yet.
+- `10-define.md`
+- `20-spec.md`
+- `30-plan.md`
+- `40-implement.md`
+- `50-verify.md`
+- `checklists/implementation-checklist.md` when present
+- `checklists/verification-checklist.md` when present
+
+Include supporting artifacts only when they add real context.
+
+### 2. Summarize The Run
+
+Explain:
+
+- what problem was addressed
+- what direction was chosen
+- what was implemented
+- how it was verified
+- how checklist progress moved across the run
+- what approval or review state remained at each important gate
+- what the release recommendation is
+- what follow-up items still exist
+
+### 3. Produce Standardized Outputs
+
+Write:
+
+- a readable Markdown report for contributors
+- a consistent HTML report for stakeholder sharing
+
+In phase 1, `artifact_language` governs the markdown report text. HTML output is derived directly from `60-report.md` through the shared markdown-to-html renderer.
+
+To render the HTML consistently from the markdown report, use one of:
+
+```text
+npm run report:html -- <workspace-path-or-running-id>
+npm run render:html -- --stage 60-report <workspace-path-or-running-id>
+```
+
+Keep checklist summaries and follow-up status inside `60-report.md` so they carry through into the rendered HTML.
+
+Both outputs should summarize checklist state when checklist artifacts exist, including:
+
+- completion progress
+- blocked or skipped items
+- notable evidence snapshots
+- approval status, review blockers, and next allowed command when they still matter
+- remaining follow-up work
+
+The HTML should stay visually consistent across runs while preserving the report markdown as the source of truth.
+
+### 4. Keep The Audience In Mind
+
+Prefer clarity over internal detail.
+
+Do not bury the outcome inside implementation trivia. The report should help a reader understand the run without replaying the whole workflow.
+
+When checklists exist, use them as the most human-readable operational record of what actually happened.
+Use `handoff` when the report must support continued work, and `insight-capture` when the run produced lessons that should become reusable knowledge.
+
+### 5. Manual Review Soft Gate
+
+Use the report as the final visibility checkpoint before release.
+If any stage still shows unresolved approval, blockers, or deferred work:
+
+- surface that state clearly in `60-report.md`
+- pull the relevant signal forward from checklist approval sections when they exist
+- do not imply the phase is fully closed when review is still open
+- recommend the real next action, even if that means returning to an earlier stage
+
+## Output
+
+Report:
+
+- what the run accomplished
+- checklist completion status and remaining items
+- important remaining follow-ups
+- where `60-report.md` and `60-report.html` were written
+- render command used or recommended:
+
+```text
+npm run report:html -- <workspace-path-or-running-id>
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/50-Verify`
+- Next state: `/70-Release` when the summary is aligned and release can proceed
+- Common companion commands: `Wiki` for durable knowledge capture, `Help` for routing or explanation
+- Support skills: `handoff`, `insight-capture`, and writing skills when final reporting must support continuation or reusable learning
+
+## Sources
+
+- `AGENTS.md`
+- `docs/workspace-artifacts.md`
+- `.agent/resources/schemas/report.template.md`
+- Related commands: `/50-Verify`, `/70-Release`, `Wiki`, `Help`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/70-Release {ID}` after `60-report.md` and `60-report.html` reflect the verified state clearly.
+- **Render HTML**: `npm run report:html -- {ID}` after `60-report.md` is finalized so the standardized stakeholder HTML stays in sync
+- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues
+- **Additional Alternative**: `handoff` when another session or agent must continue from the completed run.
+
+## Nexus Event
+
+- Use `Wiki` when the final summary should become durable project or framework knowledge.
+- Use `Help` when approval signals, ownership, or route timing still feel ambiguous.
+- Return to `/50-Verify` when unresolved evidence, blockers, or review state mean the report should not advance yet.

package/template/.agents/skills/70-release/SKILL.md

@@ -1,43 +1,43 @@
 ---name: 70-release
-
-description: Release stage in DevFlow 2.0 - package verified work for delivery, merge, PR, deployment, or handoff.
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 70: Release
-
-$ARGUMENTS
-
-Package approved work for delivery after the report stage has captured the final verified story. This stage turns report sign-off into release-ready execution and handoff.
-
-## Usage
-
-```text
-/70-Release {running-id or workspace path}
-```
-
-Use this when:
-
-- `/60-Report` is complete
-- the work needs release execution or a release-facing handoff packet
-- downstream stakeholders need delivery notes instead of raw implementation detail
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/runs/{ID}-{slug}/70-release.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/release.template.md
-```
-
-Before writing `70-release.md`, read `artifact_language` from `release.template.md` and produce the artifact in that language.
-
+
+description: Release stage in DevFlow 2.0 - package verified work for delivery, merge, PR, deployment, or handoff.
+argument-hint: "{running-id or workspace path}"
+---
+
+# Phase 70: Release
+
+$ARGUMENTS
+
+Package approved work for delivery after the report stage has captured the final verified story. This stage turns report sign-off into release-ready execution and handoff.
+
+## Usage
+
+```text
+/70-Release {running-id or workspace path}
+```
+
+Use this when:
+
+- `/60-Report` is complete
+- the work needs release execution or a release-facing handoff packet
+- downstream stakeholders need delivery notes instead of raw implementation detail
+
+## Markdown-First Contract
+
+Write the primary stage artifact to:
+
+```text
+devflow/runs/{ID}-{slug}/70-release.md
+```
+
+using:
+
+```text
+.agent/resources/schemas/release.template.md
+```
+
+Before writing `70-release.md`, read `artifact_language` from `release.template.md` and produce the artifact in that language.
+
 ## Required Section Content
 
 Before completing any generated artifact:
@@ -51,105 +51,105 @@ Before completing any generated artifact:
 - re-read the saved artifact and verify every heading satisfies this rule
 
 ## Process
-
-### Loop Contract
-
-Run release as a readiness-packaging loop, not as a celebratory summary.
-
-- **Intent**: convert verified work into a clear release, PR, merge, deploy, or handoff packet without hiding unresolved risk.
-- **Context**: read `50-verify.md`, `50-verify-impact.md` when present, `40-implement.md`, `20-spec.md`, checklist state, and any PR, deploy, merge, or handoff notes.
-- **Action**: summarize delivered scope, user/system impact, readiness state, validation evidence, rollback or mitigation notes, and follow-up items.
-- **Observation**: use concrete evidence such as verify verdict, failed or skipped checks, impact notes, residual risks, merge/deploy constraints, and checklist status.
-- **Adjustment**: if release readiness becomes uncertain, return to `/50-Verify`; if fixes are required, return to `/40-Implement`; if context must transfer, use `handoff`.
-- **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
-- **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
-
-### 1. Load Verified Context
-
-Read:
-
-- `60-report.md`
-- `50-verify.md`
-- `40-implement.md`
-- `20-spec.md`
-- any PR, deploy, merge, or handoff notes already captured
-
-### 2. Package The Release Outcome
-
-Summarize:
-
-- what is being delivered
-- what changed in user or system terms
-- what state the work is in for PR, deploy, merge, or handoff
-- what follow-up items remain
-
-### 3. Write `70-release.md`
-
-Keep the language understandable for someone who did not do the work.
-Follow the `artifact_language` configured in `release.template.md`.
-
-Prefer clear release-note style wording:
-
-- what was added
-- what changed
-- what was fixed
-- what is intentionally deferred
-
-### 4. Confirm Readiness
-
-If release readiness changes because unresolved issues are found:
-
-- route back to `/50-Verify` or `/40-Implement`
-
-Do not package unfinished work as release-ready through wording tricks.
-Use `resolving-merge-conflicts` when merge or rebase conflicts block packaging. Use `handoff` when release output must transfer to another agent or session without duplicating artifacts.
-
-### 5. Manual Review Soft Gate
-
-Before closing the mainline run, warn when release approval is still pending.
-If release blockers, operator questions, or handoff approvals remain open:
-
-- mark them visibly in `70-release.md`
-- recommend human confirmation before closing the phase
-- keep the mainline closeout as a soft recommendation only
-
-## Output
-
-Report:
-
-- delivered scope
-- release, PR, merge, deploy, or handoff state
-- follow-up items
-- recommended next step
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `/60-Report`
-- Next state: End of the mainline run when release packaging or handoff is complete
-- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
-- Support skills: `resolving-merge-conflicts`, `handoff`, and `setup-pre-commit` when release packaging needs conflict resolution, transfer notes, or local quality gates
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/release.template.md`
-- Related commands: `/60-Report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
-
-## Next Workflow Recommendation
-
-- **Primary**: End of Timeline flow
-- **Why**: The report is already complete, and this phase is the final release-facing execution step.
-- **Alternatives**:
-  - `/60-Report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
-  - `/50-Verify` - choose this when release readiness becomes uncertain.
-  - `/40-Implement` - choose this when additional fixes are needed before release can proceed.
-  - `handoff` - choose this when release-ready context must move to another session, agent, or stakeholder packet.
-
-## Nexus Event
-
-- Use `Commit`, `PR`, `Deploy`, `Merge`, or `Changelog` when release execution still needs a concrete lane.
-- Return to `/60-Report` when release notes, scope, or handoff wording diverge from the approved summary.
-- Return to `/50-Verify` or `/40-Implement` when release readiness changes because unresolved issues are discovered.
-
+
+### Loop Contract
+
+Run release as a readiness-packaging loop, not as a celebratory summary.
+
+- **Intent**: convert verified work into a clear release, PR, merge, deploy, or handoff packet without hiding unresolved risk.
+- **Context**: read `50-verify.md`, `50-verify-impact.md` when present, `40-implement.md`, `20-spec.md`, checklist state, and any PR, deploy, merge, or handoff notes.
+- **Action**: summarize delivered scope, user/system impact, readiness state, validation evidence, rollback or mitigation notes, and follow-up items.
+- **Observation**: use concrete evidence such as verify verdict, failed or skipped checks, impact notes, residual risks, merge/deploy constraints, and checklist status.
+- **Adjustment**: if release readiness becomes uncertain, return to `/50-Verify`; if fixes are required, return to `/40-Implement`; if context must transfer, use `handoff`.
+- **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
+- **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
+
+### 1. Load Verified Context
+
+Read:
+
+- `60-report.md`
+- `50-verify.md`
+- `40-implement.md`
+- `20-spec.md`
+- any PR, deploy, merge, or handoff notes already captured
+
+### 2. Package The Release Outcome
+
+Summarize:
+
+- what is being delivered
+- what changed in user or system terms
+- what state the work is in for PR, deploy, merge, or handoff
+- what follow-up items remain
+
+### 3. Write `70-release.md`
+
+Keep the language understandable for someone who did not do the work.
+Follow the `artifact_language` configured in `release.template.md`.
+
+Prefer clear release-note style wording:
+
+- what was added
+- what changed
+- what was fixed
+- what is intentionally deferred
+
+### 4. Confirm Readiness
+
+If release readiness changes because unresolved issues are found:
+
+- route back to `/50-Verify` or `/40-Implement`
+
+Do not package unfinished work as release-ready through wording tricks.
+Use `resolving-merge-conflicts` when merge or rebase conflicts block packaging. Use `handoff` when release output must transfer to another agent or session without duplicating artifacts.
+
+### 5. Manual Review Soft Gate
+
+Before closing the mainline run, warn when release approval is still pending.
+If release blockers, operator questions, or handoff approvals remain open:
+
+- mark them visibly in `70-release.md`
+- recommend human confirmation before closing the phase
+- keep the mainline closeout as a soft recommendation only
+
+## Output
+
+Report:
+
+- delivered scope
+- release, PR, merge, deploy, or handoff state
+- follow-up items
+- recommended next step
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/60-Report`
+- Next state: End of the mainline run when release packaging or handoff is complete
+- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Support skills: `resolving-merge-conflicts`, `handoff`, and `setup-pre-commit` when release packaging needs conflict resolution, transfer notes, or local quality gates
+
+## Sources
+
+- `AGENTS.md`
+- `docs/workspace-artifacts.md`
+- `.agent/resources/schemas/release.template.md`
+- Related commands: `/60-Report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+
+## Next Workflow Recommendation
+
+- **Primary**: End of Timeline flow
+- **Why**: The report is already complete, and this phase is the final release-facing execution step.
+- **Alternatives**:
+  - `/60-Report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
+  - `/50-Verify` - choose this when release readiness becomes uncertain.
+  - `/40-Implement` - choose this when additional fixes are needed before release can proceed.
+  - `handoff` - choose this when release-ready context must move to another session, agent, or stakeholder packet.
+
+## Nexus Event
+
+- Use `Commit`, `PR`, `Deploy`, `Merge`, or `Changelog` when release execution still needs a concrete lane.
+- Return to `/60-Report` when release notes, scope, or handoff wording diverge from the approved summary.
+- Return to `/50-Verify` or `/40-Implement` when release readiness changes because unresolved issues are discovered.
+