@jakkrichm/create-nexus-devflow 2.0.0

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

@@ -0,0 +1,183 @@
+---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.
+
+## Required Section Content
+
+Before completing any generated artifact:
+
+- preserve every heading required by the selected template
+- write concrete information under every heading
+- when no information exists or the section does not apply, write exactly `-`
+- never leave a heading immediately followed by another heading with no body content
+- remove template placeholders from the final artifact
+- do not invent facts merely to avoid using `-`
+- 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:
+
+- 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.

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

@@ -0,0 +1,155 @@
+---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.
+
+## Required Section Content
+
+Before completing any generated artifact:
+
+- preserve every heading required by the selected template
+- write concrete information under every heading
+- when no information exists or the section does not apply, write exactly `-`
+- never leave a heading immediately followed by another heading with no body content
+- remove template placeholders from the final artifact
+- do not invent facts merely to avoid using `-`
+- 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.
+

package/template/.claude/skills/9arm-skills/README.md

@@ -0,0 +1,51 @@
+---
+name: 9arm-skills
+description: Credited engineering discipline pack adapted from thananon/9arm-skills for Antigravity IDE and Nexus-DevFlow workflows.
+source_pack: 9arm-skills
+credit: thananon/9arm-skills
+upstream: https://github.com/thananon/9arm-skills
+adapted_for: Antigravity IDE / Nexus-DevFlow
+---
+
+# 9arm-Skills Discipline Pack
+
+This pack adapts the engineering discipline ideas from `9arm-skills` into the Nexus-DevFlow `.agent` bundle.
+
+`9arm-skills` is used as a credited thinking layer, not as a replacement for Nexus-DevFlow. Users should keep invoking the normal workflows (`Debug`, `PR-Review`, `Insight`, `Agent`, `Help`). The workflow applies the relevant 9arm discipline internally and still writes the usual Nexus reports and artifacts.
+
+## Credit
+
+- Source pack: `9arm-skills`
+- Credit: `thananon/9arm-skills`
+- Upstream: https://github.com/thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+
+## Workflow Mapping
+
+| Nexus-DevFlow Workflow | Applied 9arm Skill | Purpose |
+|---|---|---|
+| `Debug` | `debug-mantra` | Reproduce before fixing, trace the real fail path, falsify hypotheses, and preserve breadcrumbs. |
+| `Insight` | `post-mortem` | Turn validated bug fixes and incidents into durable team knowledge. |
+| `PR-Review` | `scrutinize` | Review intent, smaller alternatives, actual paths, and findings before approving changes. |
+| `Agent code-reviewer` | `scrutinize` | Apply outsider review discipline to specialist code reviews. |
+| `PR`, `/60-Report`, `/70-Release`, `Help` | `management-talk` | Translate engineering details into stakeholder-readable status, impact, owner, and next step. |
+
+## Output Rule
+
+Keep Nexus-DevFlow output formats intact:
+
+- Debug output still goes to `.workspaces/debug/rca-{slug}.md`.
+- PR review output still uses the PR review report contract.
+- Specialist reports still go to `.workspaces/reports/`.
+- Lessons still go to `.workspaces/lessons.md` or task logs.
+
+When a report uses this pack, include a short source discipline note:
+
+```md
+## Source Discipline
+- Source pack: 9arm-skills
+- Applied skill: {skill-name}
+- Credit: thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+```
+

package/template/.claude/skills/9arm-skills/debug-mantra/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: 9arm-skills/debug-mantra
+description: Use during debugging and RCA. Requires reproduction, real fail-path tracing, hypothesis falsification, and breadcrumb cross-reference before proposing a fix.
+source_pack: 9arm-skills
+credit: thananon/9arm-skills
+upstream: https://github.com/thananon/9arm-skills
+adapted_for: Antigravity IDE / Nexus-DevFlow
+---
+
+# Debug Mantra
+
+## Purpose
+
+Stop the Antigravity IDE agent from guessing during debug work. The agent must prove the bug path before recommending or applying a fix.
+
+This skill is a credited adaptation of `9arm-skills/debug-mantra` for Nexus-DevFlow.
+
+## Mantra
+
+```text
+Reproduce -> Trace fail path -> Falsify hypothesis -> Cross-reference breadcrumbs
+```
+
+## Required Discipline
+
+### 1. Reproduce First
+
+Do not propose a fix until there is a credible reproduction story.
+
+Capture:
+
+- exact symptom
+- expected behavior
+- observed behavior
+- reproduction steps
+- reproduction rate
+- environment or data conditions
+
+If the issue is intermittent, document the conditions and instrumentation needed to catch it instead of pretending it is solved.
+
+### 2. Trace The Real Fail Path
+
+Follow the actual runtime path end-to-end:
+
+- user action or incoming request
+- entrypoint
+- service/module boundaries
+- data reads and writes
+- external calls
+- final failure point
+
+Evidence should cite file paths, line numbers when available, commands, logs, or observed runtime output.
+
+### 3. Falsify Hypotheses
+
+List 2-4 plausible hypotheses and try to disprove them. A hypothesis that was ruled out is useful evidence and should be recorded.
+
+Use this table in RCA notes when helpful:
+
+| Hypothesis | Test / Evidence | Result | Ruled In/Out |
+|---|---|---|---|
+| {Hypothesis} | {Evidence} | {Result} | {Status} |
+
+### 4. Cross-Reference Breadcrumbs
+
+Keep a breadcrumb ledger so the investigation can be audited later:
+
+| Breadcrumb | Source | What It Proves | Follow-up |
+|---|---|---|---|
+| {Observation} | {File / command / log} | {Claim supported} | {Next step} |
+
+## Nexus-DevFlow Output
+
+When used by `Debug`, preserve the existing RCA output contract:
+
+- inspect `.agent/resources/schemas/rca.template.md`
+- write `devflow/debug/rca-{slug}.md`
+- include the normal RCA sections
+- add a short `Source Discipline` note crediting `9arm-skills/debug-mantra`
+
+Do not replace the RCA template with a custom 9arm-only format.
+
+## Hard Stop
+
+If there is no reproduction, no trace, and no falsified hypothesis, the correct output is an investigation plan, not a fix.
+

package/template/.claude/skills/9arm-skills/management-talk/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: 9arm-skills/management-talk
+description: Use to translate engineering detail into stakeholder-readable updates, PR summaries, changelog notes, standups, Slack/JIRA comments, or leadership talking points.
+source_pack: 9arm-skills
+credit: thananon/9arm-skills
+upstream: https://github.com/thananon/9arm-skills
+adapted_for: Antigravity IDE / Nexus-DevFlow
+---
+
+# Management Talk
+
+## Purpose
+
+Translate engineering-to-engineering detail into decision-ready communication for PMs, leads, release managers, support, and executives.
+
+This skill is a credited adaptation of `9arm-skills/management-talk` for Nexus-DevFlow.
+
+## What To Preserve
+
+Keep:
+
+- current status
+- user or business impact
+- risk
+- owner
+- next step
+- timeline or blocking condition
+- validation status
+
+Remove or compress unless needed:
+
+- internal function names
+- long file paths
+- commit SHAs
+- implementation details that do not affect decisions
+- speculative blame
+
+## Output Shapes
+
+### Status Update
+
+```md
+## Source Discipline
+- Source pack: 9arm-skills
+- Applied skill: management-talk
+- Credit: thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+
+## Current Status
+## Impact
+## Owner
+## Next Step
+## Risk / Blocker
+```
+
+### PR / Release Summary
+
+```md
+## What Changed
+## Why It Matters
+## Validation
+## Risk
+## Rollback / Follow-up
+```
+
+### Incident / Bug Summary
+
+```md
+## What Happened
+## Who Was Affected
+## Current State
+## Fix / Mitigation
+## Prevention
+```
+
+## Nexus-DevFlow Output
+
+Use this skill inside `PR`, `/60-Report`, `/70-Release`, and `Help` when the user needs a human-readable summary. Keep existing Nexus output formats and destinations intact.
+

package/template/.claude/skills/9arm-skills/post-mortem/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: 9arm-skills/post-mortem
+description: Use after a bug, outage, or regression has been fixed and validated. Converts the fix into durable engineering knowledge.
+source_pack: 9arm-skills
+credit: thananon/9arm-skills
+upstream: https://github.com/thananon/9arm-skills
+adapted_for: Antigravity IDE / Nexus-DevFlow
+---
+
+# Post-Mortem
+
+## Purpose
+
+Convert a resolved issue into team memory. A fix is not complete until the team can explain what broke, why it broke, how it was fixed, how it was validated, and why it slipped through.
+
+This skill is a credited adaptation of `9arm-skills/post-mortem` for Nexus-DevFlow.
+
+## When To Use
+
+Use after:
+
+- `Debug` found a root cause
+- `/40-Implement` applied a fix
+- `/50-Verify` or manual validation proved the fix
+- a production incident, regression, or high-risk bug deserves durable learning
+
+Do not write a confident post-mortem before the fix and validation evidence exist.
+
+## Required Inputs
+
+- reliable reproduction or incident timeline
+- root cause
+- fix summary
+- validation evidence
+- affected user or system impact
+- prevention measure or follow-up
+
+If inputs are missing, list the gaps and request the missing evidence.
+
+## Report Sections
+
+Use these sections inside `devflow/lessons.md`, task logs, or a task-linked report when appropriate:
+
+```md
+## Source Discipline
+- Source pack: 9arm-skills
+- Applied skill: post-mortem
+- Credit: thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+
+## What Broke
+## Impact
+## Reliable Repro / Timeline
+## Root Cause
+## Fix
+## Validation Evidence
+## Why It Slipped Through
+## Prevention / Follow-up
+```
+
+## Nexus-DevFlow Output
+
+Prefer existing destinations:
+
+- task-specific insight: record the final lesson in the active markdown artifacts for that running ID, or in `devflow/lessons.md`
+- project-wide lesson: `devflow/lessons.md` using `.agent/resources/schemas/lessons.template.md`
+- release-facing summary: `/70-Release`
+- stakeholder summary: `management-talk`
+
+Keep the output concise and actionable. Avoid blame.
+

package/template/.claude/skills/9arm-skills/scrutinize/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: 9arm-skills/scrutinize
+description: Use for plan, PR, and code review. Starts by challenging whether the change should exist, then checks smaller alternatives and traces actual code paths.
+source_pack: 9arm-skills
+credit: thananon/9arm-skills
+upstream: https://github.com/thananon/9arm-skills
+adapted_for: Antigravity IDE / Nexus-DevFlow
+---
+
+# Scrutinize
+
+## Purpose
+
+Review with an outsider perspective before accepting a plan, PR, or code change. The first question is not "is this code correct?" but "should this change exist in this form?"
+
+This skill is a credited adaptation of `9arm-skills/scrutinize` for Nexus-DevFlow.
+
+## Review Sequence
+
+### 1. Intent Check
+
+Clarify:
+
+- what problem the change is solving
+- what user or system behavior should change
+- what is explicitly out of scope
+- whether the change matches the task, spec, or PR description
+
+### 2. Smaller / Safer Alternative
+
+Before reviewing details, ask:
+
+- can this be solved with less code?
+- can this reuse an existing pattern?
+- can the risk be split into smaller changes?
+- is any dependency, abstraction, migration, or API surface unnecessary?
+
+### 3. Trace The Actual Path
+
+Do not review only the diff. Follow the end-to-end path that will execute after the change:
+
+- entrypoint
+- existing callers
+- changed module
+- downstream effects
+- persistence or external boundaries
+- error path and fallback behavior
+
+### 4. Findings First
+
+Report actionable findings first, ordered by severity. Avoid style-only comments unless style hides real risk.
+
+## Nexus-DevFlow Output
+
+When used by `PR-Review`, preserve `.agent/resources/schemas/pr_review.template.md` and add scrutiny context without replacing the required sections.
+
+Recommended extra sections:
+
+```md
+## Source Discipline
+- Source pack: 9arm-skills
+- Applied skill: scrutinize
+- Credit: thananon/9arm-skills
+- Adapted for: Antigravity IDE / Nexus-DevFlow
+
+## Intent Check
+## Smaller Alternative Considered
+## Actual Path Trace
+```
+
+For `Agent code-reviewer`, save substantial reports under `devflow/reports/` unless the invoking workflow has a more specific destination.
+