@jakkrichm/create-nexus-devflow 2.0.25 → 2.1.0

package/template/{.claude/skills/00-discover → .agents/skills/00-explore}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: 00-discover
-description: "[Devflow] Discover stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID."
+name: 00-explore
+description: "[devflow][D] Explore stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID."
 argument-hint: "{title, request, or discovery-id}"
 ---
 
-# Phase 00: Discover
+# Phase 00: Explore
 
 $ARGUMENTS
 
@@ -13,15 +13,15 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 ## Usage
 
 ```text
-00-discover {title or request}
-00-discover IDEA-xxx
-00-discover {discovery-id}
+00-explore {title or request}
+00-explore IDEA-xxx
+00-explore {discovery-id}
 ```
 
 Use this when:
 
 - a new request needs discussion before the team commits to delivery
-- exploring a pending idea from `devflow/ideas.md` (`00-discover IDEA-xxx`)
+- exploring a pending idea from `devflow/ideas.md` (`00-explore IDEA-xxx`)
 - the best route may be `Brainstorm`, `PRD`, `Research`, or `Debug`
 - supporting findings need to be synthesized into a go/no-go decision
 
@@ -30,7 +30,7 @@ Use this when:
 Write the primary discovery artifact to:
 
 ```text
-devflow/discoveries/{DISCOVERY_ID}-{slug}/00-discover.md
+devflow/discoveries/{DISCOVERY_ID}-{slug}/00-explore.md
 ```
 
 A Discovery ID uses a separate namespace such as `DISC-YYYYMMDD-NNN`. It is not a Running ID and must not reserve a numeric delivery run.
@@ -74,11 +74,11 @@ Set one decision:
 - `Defer`: the idea remains relevant but timing, evidence, or ownership is not ready
 - `Reject`: the idea should not proceed under the current framing
 
-### 3. Write `00-discover.md`
+### 3. Write `00-explore.md`
 
 Record selected routes, returned findings, open questions, decision, and rationale.
 
 ## Next Workflow Recommendation
 
 - **Primary**: `10-define {discovery_id}` only after approved Proceed
-- **Defer/Reject**: No next command needed
+- **Defer/Reject**: No next command needed

package/template/.agents/skills/10-define/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 10-define
-description: "[Devflow] Define stage in DevFlow 2.0 - turn an approved discovery into a bounded delivery run in context/current-run with stable scope."
+description: "[devflow][D] Define stage in DevFlow 2.0 - turn an approved discovery into a bounded delivery run in context/current-run with stable scope."
 argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
 ---
 
@@ -37,13 +37,13 @@ using:
 1. Inspect `devflow/context/current-stage.md`, `devflow/context/current-feature.md`, and `devflow/context/current-run/`.
 2. If an active uncompleted run exists:
    - **HALT and reject opening a new define stage**.
-   - Warn the user to complete or close the active run with `/complete` or `70-release` first.
+   - Warn the user to complete or close the active run with `/complete` or `70-deliver` first.
 
 ### 2. Validate The Discovery Gate
 Require:
 - `Decision: Proceed`
 - `Approval Status: Approved`
-- A resolvable Discovery ID and `00-discover.md`
+- A resolvable Discovery ID and `00-explore.md`
 
 ### 3. Allocate Sequential ID
 - Inspect `devflow/history/HISTORY.md` and allocate sequential ID without prefix (e.g. `022-{slug}`).
@@ -51,4 +51,4 @@ Require:
 - Write `devflow/context/current-run/10-define.md`.
 - Update `devflow/context/current-stage.md`:
   - `Active Running ID`: `{ID}`
-  - `Current Stage`: `10-define (Completed -> Ready for 20-spec)`
+  - `Current Stage`: `10-define (Completed -> Ready for 20-spec)`

package/template/.agents/skills/20-spec/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 20-spec
-description: "[Devflow] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
+description: "[devflow][D] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -69,7 +69,7 @@ Run specification as a contract-hardening loop, not as a prose expansion of the
 Read:
 
 - `10-define.md`
-- the shared `00-discover.md` referenced by `source_discovery` when the original framing still matters
+- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
 - research notes if they impose real constraints
 
 ### 2. Write The Specification
@@ -153,4 +153,3 @@ Report:
 - Use `Research` when a requirement, rule, or integration constraint still lacks evidence.
 - Use `Spec-Research`, `Competitor`, or `PRD` when the contract needs stronger external, product, or market framing before planning.
 - Use `grill-with-docs` when available if clarification could materially change acceptance criteria, edge cases, exclusions, or rules.
-

package/template/.agents/skills/30-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 30-plan
-description: "[Devflow] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
+description: "[devflow][D] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
 ---
 # Phase 30: Plan Implementation
 
@@ -55,7 +55,7 @@ Run planning as an evidence loop, not as a one-shot outline.
 Read:
 
 - `devflow/runs/{ID}-*20-spec.md`
-- `10-define.md` and the shared `00-discover.md` referenced by `source_discovery` when they help clarify intent
+- `10-define.md` and the shared `00-explore.md` referenced by `source_discovery` when they help clarify intent
 
 ### 2. Assess Complexity
 
@@ -218,4 +218,3 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 - **Reason**: Plans often discover stable patterns that future sessions should reuse.
 - **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*30-plan.md`
 
-

package/template/.agents/skills/40-execute/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 40-execute
-description: "[Devflow] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
+description: "[devflow][D] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
 ---
 # Phase 40: Execute Code
 
@@ -158,4 +158,4 @@ Report:
 - **Needed**: `yes` when coding discovers a reusable implementation pattern, gotcha, or context optimization.
 - **Scope**: `project` unless the discovery is about DevFlow itself.
 - **Reason**: Coding findings are useful only when they are stable enough to help future tasks.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-execute.md`
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-execute.md`

package/template/.agents/skills/50-verify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 50-verify
-description: "[Devflow] Verify stage in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement."
+description: "[devflow][D] Verify stage in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement."
 ---
 
 # Phase 50: Verify Quality
@@ -52,4 +52,4 @@ Execute verification across all essential quality dimensions:
 Report:
 - QA verdict across all verification lanes
 - Evidence commands and outputs
-- Next command: `60-report {ID}` (if pass) or `40-execute {ID}` (if fail)
+- Next command: `60-report {ID}` (if pass) or `40-execute {ID}` (if fail)

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

@@ -1,6 +1,6 @@
 ---
 name: 60-report
-description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
+description: "[devflow][D] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -53,5 +53,5 @@ Structure the report in **Thai (`th`)**:
 
 ## Next Workflow Recommendation
 
-- **Primary**: `70-release {ID}`
-- **Optional Standalone HTML**: `/report:html`
+- **Primary**: `70-deliver {ID}`
+- **Optional Standalone HTML**: `/report:html`

package/template/{.claude/skills/70-release → .agents/skills/70-deliver}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: 70-release
-description: "[Devflow] Release stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
+name: 70-deliver
+description: "[devflow][D] Deliver stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
 argument-hint: "{running-id or workspace path}"
 ---
 
-# Phase 70: Release
+# Phase 70: Deliver
 
 $ARGUMENTS
 
@@ -13,7 +13,7 @@ Package approved work for delivery after the report stage has captured the final
 ## Usage
 
 ```text
-70-release {id or workspace path}
+70-deliver {id or workspace path}
 ```
 
 ## Markdown-First Contract
@@ -21,20 +21,14 @@ Package approved work for delivery after the report stage has captured the final
 Write the primary stage artifact to:
 
 ```text
-devflow/context/current-run/70-release.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/release.template.md
+devflow/context/current-run/70-deliver.md
 ```
 
 ## Process & Quality Gates
 
 ### 0. Step 0 Safety Pass & Findings Ledger Gate
 
-Before packaging, merging, or releasing:
+Before packaging, merging, or delivering:
 
 1. **Findings Ledger Blockers**:
    - Inspect `devflow/context/findings.md`.
@@ -75,4 +69,4 @@ Set `devflow/context/current-stage.md` to:
 - `Active Running ID`: `None (Idle)`
 - `Current Stage`: `Idle (Ready for new run)`
 - `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
-- `Last Updated`: `{YYYY-MM-DD}`
+- `Last Updated`: `{YYYY-MM-DD}`

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

@@ -1,95 +1,158 @@
 ---
 name: adopt
-description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlow context files."
+description: "[devflow][B] Bring the blueprint into an existing (brownfield) codebase. Surveys the real repo, interviews for intent, generates the owned plans and coding standards, documents existing verification and CI, and points to the optional standalone CI setup. Use when the user runs /adopt, is overlaying the blueprint onto an app that already has meaningful code, or asks to adopt or bootstrap the workflow into an existing project. For freshly scaffolded or early projects, use onboard instead."
 ---
 
-# adopt - Bootstrap Nexus-DevFlow from an Existing Codebase
+# adopt - bootstrap the blueprint from an existing codebase
 
 Where this sits in the workflow:
 
-```text
-existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  00-discover or 10-define
-(already has code)     (survey +    (seeded from the real code;               (first feature / refactoring
-                        interview)   shipped architecture documented)          delivery lifecycle)
-```
+    existing codebase  ->  [adopt]  ->  project-plan + build-plan + coding-standards  ->  /overview  ->  normal loop
+    (already has code)     (survey +     (seeded from the real code; shipped               (project-       (/feature,
+                            interview)     features already checked off)                    overview.md)     /implement, ...)
 
-Standard onboarding assumes a freshly scaffolded, near-empty app. That does not fit a codebase that already has thousands of lines of working code.
+The standard onboarding assumes a freshly scaffolded, near-empty app: you write
+the two plans from scratch and build forward. That doesn't fit a project that
+already has thousands of lines of working code. `/adopt` is the brownfield
+on-ramp: it reads what's already there, asks you only for what the code can't tell
+it (the *why* and the *roadmap*), and produces the same input files the rest of
+the workflow expects - so an existing project joins the loop without you
+hand-writing everything.
 
-`adopt` is the brownfield on-ramp for Nexus-DevFlow: it reads what is already there, asks only for what the code cannot reveal (the *intent*, the *why*, and the *upcoming roadmap*), and produces the exact context files the rest of the DevFlow lifecycle expects (`project-overview.md`, `coding-standards.md`, `AGENTS.md` commands).
-
----
+It generates the inputs; it does not generate `project-overview.md`. That stays
+`/overview`'s job. `/adopt` ends by telling you to run `/overview`.
 
 ## Input
 
-A description of what the project is, if provided. Otherwise, inspect the repository directly. No argument is required.
-
----
-
-## Step 0 - Confirm Brownfield Safety
-
-Inspect `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`:
-
-- If they contain default placeholders or empty templates, proceed.
-- If they already hold rich, user-owned content, stop and inform the user; offer to refresh specific sections rather than overwriting existing context without confirmation.
-
-Never run a framework scaffolder (DevFlow is an overlay, never a generator).
-
----
-
-## Step 1 - Survey the Codebase (Read-Only)
+A description of what the project is, if the user offers one. Otherwise just the
+repository itself. No argument is required.
+
+## Step 0 - confirm it's brownfield and safe
+
+Look at `devflow/project-plan.md` and `devflow/build-plan.md`.
+
+- If they're missing or still the empty worksheet/placeholder, proceed.
+- If they already hold real content, this project is already adopted. Stop and say
+  so; offer to refresh a specific file instead of overwriting work the user owns.
+
+Never overwrite a filled-in plan without explicit confirmation. Never run a
+framework scaffolder (the blueprint is an overlay, never a generator).
+
+Protect the project README:
+
+- If the root `README.md` already looks like a real project README, leave it
+  alone.
+- If the root `README.md` is the copied Blueprint workflow doc (for example it
+  starts with `# AI Coding Blueprint`), report it as obsolete overlay content
+  and ask before replacing or removing it. Do not move it into `blueprint/`.
+- Do not create or overwrite a root project README for a brownfield app unless
+  the user explicitly asks. The existing project face belongs to the app, not the
+  workflow.
+
+## Step 1 - survey the codebase (read-only)
+
+Read the repo to establish the facts. Change nothing in this step. Establish:
+
+- **Stack and tooling** - language(s), framework(s), and versions, from the real
+  manifest (`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`,
+  `Gemfile`, `Cargo.toml`, etc.). Note the package manager actually in use (lockfile).
+- **Commands** - the real dev / build / test / lint scripts. These feed the
+  Commands section of `AGENTS.md` and, per the testing opt-in switch, decide
+  whether a testing gate even applies.
+- **Conventions in practice** - directory layout, component/file naming, styling
+  approach, state management, data-fetching pattern, error handling. Read what the
+  code *does*, not what a default template prescribes.
+- **Testing reality** - is a runner configured and are there tests, or none? Be
+  honest; don't describe a gate the project doesn't have.
+- **Verification and CI** - note any combined verification command, GitHub
+  remote, `.github/workflows/`, or external CI. Preserve what already exists.
+- **What the app already does** - the shipped features, inferred from routes,
+  pages, entry points, and modules. This becomes the *checked* part of the build plan.
+
+Keep notes; you'll turn them into the files in Step 3.
+
+## Step 2 - interview for intent
+
+The code reveals *what* and *how*, never *why* or *what next*. Ask the user a short
+set of questions (aim for three to five, not an interrogation) to fill the gaps:
+
+- What is this project for, and who uses it? (the problem and the users)
+- Is the stack and structure you found intentional, or are there parts they'd call
+  legacy / want to change?
+- What do you want to build next? (the unchecked items in the build plan)
+- Anything the survey got wrong or missed?
+
+If the user already gave intent up front, skip what they've answered. Don't ask
+what you can read from the code.
+
+## Step 3 - generate the inputs
+
+Write these, drawn from the survey (facts) and the interview (intent). Mark every
+inference you're unsure of with a clear `> TODO (confirm)` so the user can correct
+it rather than inherit a wrong guess.
+
+- **`devflow/project-plan.md`** - the what & why, following the existing
+  worksheet structure (problem, users, features, data, tech, monetization, UI/UX).
+  The "features" and "tech" sections describe what *already exists*; the rest comes
+  from the interview.
+- **`devflow/build-plan.md`** - the ordered feature list as a checklist. **Mark
+  shipped features `- [x]`** (this is the brownfield difference: the build plan
+  reflects reality, so most of an existing app starts checked) and the roadmap
+  items from the interview as `- [ ]`. This makes `/status` and `/feature` work
+  immediately - the next unchecked item is genuinely what's next.
+- **`devflow/context/coding-standards.md`** - rewrite the default to match the
+  project's *actual* conventions from Step 1, not the shipped Next.js/Prisma
+  defaults. Keep the Writing and Comments sections; replace the stack-specific ones
+  with what the code really does. Its Testing section must reflect the real testing
+  state (the opt-in switch is a `test` command in `AGENTS.md`).
+- **`AGENTS.md` Commands section** - fill in the real dev / build / test / lint
+  commands you found, so the rest of the workflow (and the testing gate) uses the
+  project's actual scripts. Include `Verify` when a real combined command exists.
+
+Do not write `project-overview.md`; that's `/overview`'s job, downstream of these.
+
+## Step 4 - point to optional CI setup
+
+Do not create or change Verify commands or GitHub workflows during adoption.
+Report any verification command or CI already present. When equivalent automatic
+pull-request checks are absent, mention the optional standalone setup:
 
-Read the repository to establish the facts. Change nothing in this step:
-
-- **Stack & Tooling**: Languages, frameworks, and versions from manifest files (`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc.). Note the active package manager from lockfiles.
-- **Commands**: Real dev, build, test, lint, and verify scripts.
-- **Conventions in Practice**: Directory layout, component naming, state management, styling, data-fetching, error handling, validation. Read what the code *actually does*.
-- **Testing Reality**: Inspect existing test suites, runners, and coverage. Be honest about test status.
-- **Shipped Capabilities & Architecture**: Inferred from routes, pages, controllers, database schemas, and entry points.
-
-Keep structured notes for generation in Step 3.
-
----
-
-## Step 2 - Interview for Intent
-
-The code reveals *what* and *how*, but not *why* or *what next*. Ask a short set of 3-4 questions to fill the gaps:
-
-1. **Purpose & Users**: What is the core problem this project solves, and who are the target users?
-2. **Architecture Status**: Is the current structure and stack intentional, or are there legacy parts/technical debt the team wants to change or refactor?
-3. **Upcoming Roadmap**: What are the top priorities to build, fix, or refactor next?
-4. **Clarifications**: Anything the survey got wrong or missed?
-
-*(If the user already provided this context in the prompt, skip questions that are already answered).*
-
----
+```text
+Run /ci or $ci when you want automatic GitHub checks.
+```
 
-## Step 3 - Generate the Context Artifacts
+Explain that CI is not required to finish adoption. The `/ci` skill owns
+project-specific Verify and GitHub workflow setup.
 
-Write the baseline context files drawn from the survey (facts) and interview (intent):
+## Step 5 - review gate, then hand off
 
-1. **`devflow/context/project-overview.md`**:
-   - Project Name, Purpose, and Target Users
-   - Architecture summary and directory layout
-   - Shipped capabilities and existing major modules
-   - Key technical stack components and verified commands
-   - Known technical debt or architectural focus areas
+Stop and show the user what you generated, calling out:
 
-2. **`devflow/context/coding-standards.md`**:
-   - Rewrite defaults to reflect the project's *actual* conventions discovered in Step 1
-   - Framework patterns, state management, error handling, styling, and test rules based on real code
+- the **build-plan split** - what you marked shipped vs not, since that's the
+  judgment most worth their eyes,
+- every `> TODO (confirm)` you left,
+- anything the survey and the interview disagreed on,
+- verification command and GitHub checks status.
 
-3. **`AGENTS.md` Commands Section**:
-   - Fill in the real dev, build, test, lint, and verify commands found during survey.
+These files are the ones the user *owns*. Have them review and adjust, then tell
+them to run `/overview` to distill the plans into `project-overview.md` and start
+the normal loop.
 
----
+## Rules
 
-## Step 4 - Review Gate and Handoff
+- **Read-only until Step 3.** The survey changes nothing; only generation writes.
+- **Reflect reality, don't prescribe.** `coding-standards.md` must match the code
+  that exists. A project using Zustand and REST routes should not be handed
+  standards about Server Actions and Prisma just because that's the default.
+- **Never invent intent.** Ask for the why and the roadmap; mark anything inferred
+  with `> TODO (confirm)`. Silent guesses about purpose are the main failure mode.
+- **Don't clobber owned work.** If the plans already have real content, confirm
+  before touching them. Never run a scaffolder.
+- **Be honest about testing.** If there's no runner, say testing is opt-in and not
+  yet set up; don't describe a gate the project hasn't adopted.
 
-Present the adoption summary for review:
+## Formatting
 
-- Shipped features and architectural baseline recorded
-- Inferred conventions and coding standards
-- Available verified commands in `AGENTS.md`
-- Recommended next step:
-  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the next major initiative or feature
-  - Run `10-define` (or `10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.