@jakkrichm/create-nexus-devflow 2.0.0

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

package/template/.agents/skills/agent/SKILL.md

@@ -0,0 +1,165 @@
+---name: agent
+
+description: Invoke Agent - Run a specialist persona on a file, folder, stage artifact, or codebase concern.
+---
+# Phase 90: Invoke Agent
+
+Run a specialist agent persona for targeted expertise while preserving the DevFlow 2.0 stage-first contract.
+
+Primary behavior now lives in the `specialist-agent-routing` skill. Keep this workflow as the compatibility wrapper and advanced user-facing agent entry point.
+
+## Usage
+
+```text
+Agent {AGENT_NAME} {TARGET}
+```
+
+Examples:
+
+```text
+Agent requirements-engineer devflow/runs/007-auth-refactor/20-spec.md
+Agent codebase-explorer src/services/
+Agent code-reviewer devflow/runs/007-auth-refactor
+```
+
+## Available Agents
+
+Agent definitions live in `../agents/`.
+
+Planning and requirements:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `prp-core-planner` | Create implementation plans from specs and codebase patterns. |
+| `requirements-engineer` | Refine `10-define.md` and `20-spec.md` before planning. |
+| `prp-core-prd-architect` | Draft PRD documents from early ideas. |
+| `orchestrator` | Coordinate complex work and recommend next specialist steps. |
+| `prp-core-boss` | Route `/goal` requests, decompose work, enforce turn budgets, and validate worker output. |
+
+Research and exploration:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `codebase-explorer` | Find files and patterns; analyze architecture, data flow, and module relationships. |
+| `web-researcher` | Research external APIs, docs, and best practices. |
+
+Implementation:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `prp-core-coder` | Implement planned subtasks. |
+| `prp-core-worker` | Execute focused Boss-assigned `/goal` subtasks and report validation status. |
+| `backend-specialist` | Backend, APIs, database, server logic. |
+| `frontend-specialist` | UI/UX and frontend implementation. |
+| `database-architect` | Schema, indexing, and query design. |
+
+Quality and debugging:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `test-engineer` | Unit and integration tests. |
+| `prp-core-debugger` | Root cause analysis. |
+| `code-reviewer` | Code review, risk, regressions. |
+| `security-auditor` | Security and logic risk. |
+| `performance-engineer` | Performance bottlenecks. |
+
+Git and docs:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `prp-core-git-committer` | Commit preparation and message quality. |
+| `prp-core-git-pr-maker` | Pull request summary and preparation. |
+| `documentation-maintainer` | Documentation impact analysis. |
+
+Maintenance and infrastructure:
+
+| Agent | Purpose |
+| :--- | :--- |
+| `ob-loop-engineer` | Overnight infrastructure maintenance, code debt pruning, and variant branch testing loops. |
+
+
+## Reusable Skills
+
+The following former narrow agents are now skills. Invoke them through the responsible agent or workflow instead of `Agent`:
+
+| Skill | Apply Through |
+| :--- | :--- |
+| `code-simplification` | `prp-core-coder`, `code-reviewer`, or `Simplify` |
+| `type-design` | `backend-specialist`, `frontend-specialist`, `database-architect`, or `code-reviewer` |
+| `silent-failure-audit` | `code-reviewer`, `test-engineer`, `backend-specialist`, or `security-auditor` |
+
+## Artifact Contract
+
+Specialist agents must use the DevFlow 2.0 stage-first contract:
+
+- Prefer `00-discover.md`, `10-define.md`, `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md`, `70-release.md`, and `60-report.md` as the primary artifacts.
+- Do not silently rewrite legacy JSON artifacts.
+- If migration work still requires JSON, prefer CLI-backed minimal updates instead of full-file rewrites.
+- If the specialist is only reviewing, recommend exact commands instead of mutating artifacts.
+- Keep reports readable without requiring a dashboard or JSON viewer.
+
+## 9arm-Skills Discipline Routing
+
+When the target task matches one of these review or communication modes, apply the credited local pack under `.agents/skills/9arm-skills/` while preserving the normal specialist output contract:
+
+| Situation | Apply |
+| :--- | :--- |
+| `code-reviewer`, PR review, plan critique, or change risk review | `9arm-skills/scrutinize` |
+| debug or RCA specialist work | `9arm-skills/debug-mantra` |
+| completed bug or regression lesson extraction | `9arm-skills/post-mortem` |
+| stakeholder-readable summary, PR body, release note, standup, or status update | `9arm-skills/management-talk` |
+
+Reports that use the pack should include a short `Source Discipline` note with credit to `thananon/9arm-skills`.
+
+## Process
+
+1. Load the persona from `../agents/{AGENT_NAME}.md`.
+2. Read the target file, folder, stage directory, or recent changes.
+3. Apply the persona's specialist logic.
+4. If artifact changes are needed, prefer stage markdown updates first.
+5. Record lightweight context usage in the report when the agent loads notable context.
+6. Produce either a concise report or a focused set of changes.
+
+## Output
+
+If a report is substantial, save it to:
+
+```text
+devflow/reports/{date}-{agent-name}-{timestamp}.md
+```
+
+Before saving a substantial agent report, inspect `.agent/resources/schemas/agent_report.template.md` and use its required headings unless the target workflow provides a more specific template.
+
+Before reporting completion, run:
+
+Review `{report_path}` against `agent_report.template.md`, keep the required headings, and remove placeholder text before completion.
+
+Replace any placeholder or template text with concrete files reviewed, findings, recommendations, and validation needs.
+
+For substantial reports, add a short `Context Usage Notes` subsection under the context reviewed area with files or artifacts loaded, any known token counts, and one practical optimization note for future runs.
+
+Short reports can be returned directly in chat.
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Specialist invocation command, not a numbered stage
+- Typical entry points: any stage that needs focused specialist judgment
+- Typical handoff targets: return to the owning workflow such as `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`, `/50-Verify`, `/60-Report`, `/70-Release`
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/agents/README.md`
+- `.agent/resources/schemas/agent_report.template.md`
+- Related commands: `Research`, `PR-Review`, `Debug`, `Help`, all mainline stages
+
+## Next Workflow Recommendation
+
+- **Primary**: the workflow that owns the target's lifecycle, such as `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`, `/50-Verify`, `/60-Report`, `/70-Release`, or `PR-Review`.
+- **Why**: `Agent` supplies specialist judgment; the owning workflow should execute the next lifecycle step.
+- **Alternatives**:
+  - `Research` when the specialist work uncovered unresolved external uncertainty
+  - `Wiki` when the specialist report contains reusable project knowledge
+  - `Help {target}` when the correct next route is unclear
+