@jakkrichm/create-nexus-devflow 2.1.0 → 2.2.1

package/template/.claude/skills/try/SKILL.md

@@ -1,108 +1,120 @@
 ---
 name: try
-description: "[Devflow] Generate human manual QA review walkthrough guide (where to go, what to click, what to expect)."
+description: "[devflow][B] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
 ---
 
-# try - Manual QA & Review Walkthrough Guide
+# try - manual review guide
 
 Where this sits in the workflow:
 
-```text
-40-execute or 50-verify or 60-report  ->  [try]  ->  human review & verification
-(work implemented / verified)                  (manual    (where to go,
-                                               steps)     what to click)
-```
+    /implement or /complete  ->  [try]  ->  human review
+    (work exists)                (manual   (where to go,
+                                  path)     what to click)
 
-`50-verify` proves behavior from automated QA and test runs. `try` gives the user and testers an actionable, step-by-step manual walkthrough: start this command, open this route, click these controls, expect this result, and watch for these failure signs.
+`/check` proves behavior from the agent side. `/try` gives the user a practical
+manual walkthrough: start this command, open this route, click these controls,
+expect this result, and watch for these failure signs.
 
-It is always **read-only 100%**. It does not edit files, install dependencies, commit, merge, push, or run destructive commands.
+It is always read-only. It does not edit files, install dependencies, commit,
+merge, push, or run destructive commands.
 
 ## Input
 
 Optional scope:
 
-- **no argument**: use the active run in `devflow/context/current-stage.md` (or the latest completed run under `devflow/runs/`)
-- `latest`: use the most recent completed run in `devflow/runs/`
-- a run ID or path: e.g. `try RUN-002-add-onboard-adopt-doctor-skills`
-- a specific route, endpoint, or CLI command: focus the walkthrough on that surface
+- no argument: use the active feature, fix, or rollback in
+  `devflow/context/current-feature.md`
+- `latest`: use the most recent archive under `devflow/history/features/`,
+  `devflow/history/fixes/`, or `devflow/history/rollbacks/`
+- a step name or number: focus the guide on that current-feature step
+- a path, route, or command: include it as the main thing to try
 
-If there is no active run and no run history, ask what change or feature the user wants to test manually.
+If there is no active feature and no useful archive, ask what change the user
+wants to try instead of guessing.
 
-## Step 1 - Find The Work To Explain
+## Step 1 - find the work to explain
 
 Read:
 
-- `AGENTS.md` (Commands section)
-- `devflow/context/current-stage.md`
+- `AGENTS.md`
+- `devflow/context/current-feature.md`
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
-- Active run artifacts: `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md` (or archived run artifacts)
-- Current git branch and status
+- `devflow/build-plan.md`
+- latest files under `devflow/history/features/`,
+  `devflow/history/fixes/`, and `devflow/history/rollbacks/`, if the current
+  feature is reset
+- git branch and working tree status
 
-Do not dump the full spec. Extract only the concrete routes, screens, CLI commands, API endpoints, test data, and expected outcomes that a human needs to verify the feature.
+Prefer the active spec. If `current-feature.md` is the reset stub, use the most
+recent archived feature, fix, or rollback by filename or modification time and
+say that is what you used.
 
-## Step 2 - Identify How To Run The App
+Do not dump the spec. Pull out the routes, commands, UI surfaces, CLI commands,
+API endpoints, data states, and done-whens that matter for a human trying it.
+For a rollback, lead with the path that proves the removed behavior is gone, then
+include one unaffected regression path from the rollback spec.
 
-Check the Commands section in `AGENTS.md`. Adapt to the project type:
+## Step 2 - identify how to run the app
 
-- **Web app**: dev server command (e.g. `npm run dev`), local URL (e.g. `http://localhost:3000`), and specific route/screen.
-- **Server / API**: start command, base URL, endpoint, HTTP method, payload, and expected response shape.
-- **CLI**: exact CLI command, flags, arguments, and expected terminal output.
-- **Library / Module**: sample usage snippet, REPL call, or interactive test command.
-- **Fullstack / Microservices**: minimal combined startup commands (e.g. backend + frontend).
+Use the Commands section in `AGENTS.md`. Match the project type:
 
-If a startup command is missing or unclear in `AGENTS.md`, report that as a configuration gap rather than guessing.
+- **Web app** - dev server command, URL, and the route or screen to open.
+- **Server/API** - server command, base URL, endpoint, method, and expected
+  response shape.
+- **CLI** - exact command(s), arguments, and expected output.
+- **Library** - example command, test fixture, REPL snippet, or sample call.
+- **Hybrid app** - list the smallest set of commands needed, such as backend plus
+  web dev server.
 
-## Step 3 - Produce The Manual Walkthrough Guide
+If the app may already be running, say how to reuse it. If a command is missing
+from `AGENTS.md`, report that as a gap rather than inventing certainty.
 
-Format the guide with these 5 standard sections:
+## Step 3 - write the manual guide
 
-1. **1. Start** - exact command(s) to start the system and where to run them.
-2. **2. Open** - URL(s), screens, tabs, API endpoints, or terminal locations.
-3. **3. Do** - specific clicks, form inputs, toggles, selections, or arguments.
-4. **4. Expect** - expected visible UI change, response payload, state change, output, or absence of errors.
-5. **5. Watch For** - common failure symptoms, console errors, network 4xx/5xx errors, stale state, layout breakage, or safety warnings.
+Produce a short guide with these sections:
 
-### Example Walkthrough Style:
+1. **Start** - commands to run and where to run them.
+2. **Open** - URLs, screens, tabs, API endpoints, or CLI commands.
+3. **Do** - clicks, inputs, selections, or command arguments.
+4. **Expect** - visible result, output, response, state change, file, or lack of
+   error.
+5. **Watch For** - common wrong outcomes, console or network errors, stale data,
+   missing fields, bad empty states, layout issues, or safety warnings.
 
-```markdown
-### 1. Start
-Run `npm run dev` in the project root.
+Keep it concrete. Prefer:
 
-### 2. Open
-Navigate to `http://localhost:3000/dashboard/reports`.
+    Open http://127.0.0.1:7788/api/snapshot
+    Expect a JSON object with `generated_at`, `services`, `projects`, and
+    `conflicts`.
 
-### 3. Do
-1. Click the **"Export Report"** button in the top right.
-2. Select **"Format: HTML"** from the dropdown.
-3. Click **"Download"**.
+Avoid:
 
-### 4. Expect
-- A new file `report.html` is downloaded.
-- The UI displays a green success toast: *"Report exported successfully"*.
-- The downloaded HTML file opens in the browser with full styling and charts.
+    Check that the snapshot works.
 
-### 5. Watch For
-- Spinner hanging indefinitely without downloading.
-- Console error related to `Blob` or `URL.createObjectURL`.
-- Broken styling or unrendered Mermaid charts in the exported HTML.
-```
+## Step 4 - include confidence and gaps
 
-## Step 4 - Include Confidence, Best Signal & Gaps
+End with:
 
-Conclude with:
+- **Best signal** - the one thing the user should try first.
+- **Optional deeper checks** - only if useful.
+- **Gaps** - anything the guide cannot know from the docs, such as missing route
+  names, seed data, credentials, or external services.
 
-- **Best Signal**: the single most critical action the user should try first to confirm functionality.
-- **Edge Cases & Error Flows**: optional secondary checks (e.g. invalid input, empty state, network failure).
-- **Gaps & Assumptions**: anything the guide cannot know for certain (e.g. seed credentials, third-party API keys, required database fixtures).
+If the feature is not user-visible, say so and provide the closest manual signal,
+such as an API response, CLI output, log line, or unit test command.
 
 ## Rules
 
-- **Strictly Read-Only**: Never edit code, commit, push, install packages, or mutate repository state.
-- **Do Not Run Automatically**: Do not launch the server or run commands unless the user explicitly instructs you to do so in the chat.
-- **Be Concrete & Specific**: Provide exact URLs, button labels, and payloads.
-- **Acknowledge Uncertainty**: If a route or behavior is not specified in the spec, state it clearly as an assumption.
+- Read-only only. Do not edit, commit, merge, push, install, or delete.
+- Do not run the app unless the user explicitly asks you to try it for them.
+- Do not pretend a path is known when the spec does not say it. Give the best
+  likely path and label uncertainty.
+- Keep the guide short enough to follow while the app is open.
+- Match the project's commands from `AGENTS.md`.
 
-## Output Formatting
+## Formatting
 
-Follow the project conventions in `devflow/context/ai-interaction.md`: concise, scannable markdown with numbered steps and clear bold headers.
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with numbered
+steps for the manual path and short bullets for warnings.

package/template/AGENTS.md

@@ -25,15 +25,16 @@ The workflow and skills are exposed through tool-specific adapters:
 
 - **OpenAI Codex, Google Antigravity & GitHub Copilot**: `.agents/skills/<skill>/SKILL.md`
 - **Claude Code**: `.claude/skills/<skill>/SKILL.md`
+- **OpenCode**: `AGENTS.md` plus the compatible `.agents/skills/` or `.claude/skills/` tree already installed for the selected tools
 
-Unused adapter families can be removed. Codex, Antigravity, and GitHub Copilot share `.agents/` and `AGENTS.md`. Claude Code projects keep `.claude/` and `AGENTS.md` (via `CLAUDE.md`).
+Unused adapter families can be removed. Codex, Antigravity, GitHub Copilot, and OpenCode share `.agents/` and `AGENTS.md`. OpenCode can also reuse `.claude/` when Claude Code is selected. Claude Code projects keep `.claude/` and `AGENTS.md` (via `CLAUDE.md`). Do not duplicate the same DevFlow skills under `.opencode/skills/`; OpenCode already discovers the compatible trees.
 
 ### Universal Invocation & Agent Directives:
 
-1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `00-explore`, `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-deliver`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `idea`, `ci`, `test`, `autopilot`, `prototype`, `report-html`, `brief`, `discovery`, `audit`, `release`). The way you invoke commands depends on your AI Provider / Tool:
-   - **Canonical Name (Plain text)**: Directly invoke or prompt the command by its standard name (e.g., `feature`, `40-execute`, `devflow`).
-   - **Slash Prefix (`/`)**: For tools supporting slash commands (Claude Code, Google Antigravity, Gemini CLI), e.g., `/feature`, `/fix`, `/implement`, `/40-execute`, `/devflow`.
-   - **Dollar Prefix (`$`)**: For OpenAI Codex CLI or skill-invocation tools, e.g., `$feature`, `$fix`, `$40-execute`, `$devflow`.
+1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `discovery`, `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-deliver`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `idea`, `ci`, `test`, `autopilot`, `prototype`, `report-html`, `brief`, `audit`, `release`, `brainstorm`, `grill`). The way you invoke commands depends on your AI Provider / Tool:
+   - **Canonical Name (Plain text)**: Directly invoke or prompt the command by its standard name (e.g., `feature`, `40-execute`, `devflow`, `discovery`).
+   - **Slash Prefix (`/`)**: For tools supporting slash commands (Claude Code, Google Antigravity, Gemini CLI), e.g., `/feature`, `/fix`, `/implement`, `/40-execute`, `/devflow`, `/discovery`.
+   - **Dollar Prefix (`$`)**: For OpenAI Codex CLI or skill-invocation tools, e.g., `$feature`, `$fix`, `$40-execute`, `$devflow`, `$discovery`.
 2. **OpenAI Codex & Non-Native CLI Tools**: In environments without automatic background skill discovery (such as OpenAI Codex CLI, Aider, or generic terminals), **you MUST use your file reading tool to inspect `.agents/skills/<skill>/SKILL.md` before executing the stage** to strictly follow its schema, artifact contract, and quality gates.
 3. **Google Antigravity & Claude Code**: Native skill engines automatically discover and surface `.agents/skills/` and `.claude/skills/`.
 4. **State-Aware Inspection**: When unsure what to do next, invoke `devflow` to automatically inspect `devflow/context/current-stage.md` and active context in `devflow/context/`.
@@ -66,10 +67,10 @@ Recommended for 85% of daily work (features, bug fixes, UI improvements, iterati
 Recommended for large architectural epics, database migrations, and multi-agent coordination:
 
 ```text
-00-explore ──▶ 10-define ──▶ 20-spec ──▶ 30-plan ──▶ 40-execute ──▶ 50-verify ──▶ 60-report ──▶ 70-deliver
+discovery ──▶ 10-define ──▶ 20-spec ──▶ 30-plan ──▶ 40-execute ──▶ 50-verify ──▶ 60-report ──▶ 70-deliver
 ```
 
-1. `00-explore`: Explore request before delivery commitment without allocating running ID (`00-explore.md`).
+1. `discovery`: Unified pre-delivery discovery & exploration (project-level roadmap planning or feature-level exploration with 5 lenses: Brainstorm, Research, PRD, Bug Triage, Grill) before delivery commitment (`devflow/discoveries/{DISC-ID}/discovery.md`).
 2. `10-define`: Turn approved discovery into bounded delivery run in `devflow/context/current-run/10-define.md`.
 3. `20-spec`: Formalize markdown-first delivery contract & acceptance criteria (`20-spec.md`).
 4. `30-plan`: Breakdown spec into executable tasks with test decisions (`30-plan.md` + checklists).

package/template/devflow/build-plan.md

@@ -60,3 +60,11 @@
   - *Dependencies*: Feature 6
   - *Scope*: พัฒนาระบบกระจายงานแบบคู่ขนานให้ Subagents (Coder, QA Verifier, Security Auditor) และระบบ Indexing Local Codebase Graph เพื่อดึงบริบทที่แม่นยำสูงสุด
 
+---
+
+## 🔄 Phase 8: Upstream Synchronization & Multi-Adapter Expansion
+
+- [x] **8. Sync Upstream v0.13.0 (Adopt Visibility, OpenCode & Multi-Adapter Selection)** `[Size: M]`
+  - *Dependencies*: None
+  - *Scope*: ผสานความสามารถ Adopt Workflow Visibility (Commit vs Local-only), การรองรับ OpenCode และ Multi-Adapter Checkbox Prompt ใน CLI พร้อมอัปเดต Doctor checks และซิงก์ Baseline SHA เป็น v0.13.0 (`0b65166`)
+

package/template/devflow/context/ai-interaction.md

@@ -120,3 +120,14 @@ Progress lives in persistent files, not in transient chat history:
 - `autopilot` is an explicit opt-in command (`/autopilot`). Never suggest it as the default next action.
 - When invoked, it runs one bounded spec/plan/implement/verify pass.
 - Autopilot **MUST stop** before `/complete`, merge, push, deploy, or any destructive action.
+
+---
+
+## 9. Socratic Alignment & Grilling Discipline (`/grill`)
+
+- **Align Before You Build**: When plans, domain language, or architectural boundaries are fuzzy, invoke `/grill` (or use the Grilling Lens in `00-explore`) to conduct a structured interview before creating specifications.
+- **Codebase-Grounded Inquiry**: Inspect existing context and code before asking questions. Never ask questions the codebase already answers.
+- **Turn Discipline**: Ask only 1–2 high-leverage questions per turn with clear recommended defaults. Never dump a wall of questions.
+- **Lazy Inline Persistence**:
+  - Immediately append resolved terms to `devflow/context/glossary.md`.
+  - Immediately record major, hard-to-reverse architectural decisions as Architecture Decision Records in `devflow/decisions/ADR-xxx-{slug}.md`.

package/template/devflow/context/coding-standards.md

@@ -58,11 +58,12 @@
 
 ```text
 nexus-devflow/
-├── .agents/skills/             # Codex & Google Antigravity skill definitions
+├── .agents/skills/             # Codex, Google Antigravity & Copilot skill definitions
 ├── .claude/skills/             # Claude Code mirrored skill adapters
 ├── .nexus/                     # Metadata tracking & upstream baseline ledger
 ├── devflow/                    # Framework workspace context, history, and discoveries
 │   ├── context/                # Living source-of-truth context files
+│   ├── decisions/              # Architecture Decision Records (ADRs)
 │   ├── discoveries/            # Pre-delivery discovery records (00-explore.md)
 │   ├── history/                # Master delivery archive (features/, fixes/, rollbacks/, HISTORY.md)
 │   └── ideas.md                # Idea Inbox and backlog
@@ -140,3 +141,16 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
   - `Major`: Breaking architectural change
   - `Minor`: New feature addition
   - `Patch`: Bug fix or documentation update
+
+---
+
+## 11. Architecture Decision Records (ADRs) & Domain Glossary
+
+- **Domain Glossary (`devflow/context/glossary.md`)**:
+  - Keep domain terms concise, precise, and unambiguous.
+  - Define entity boundaries, invariants, and lifecycle rules.
+  - Do NOT store implementation specs or ephemeral task lists in the glossary.
+- **Architecture Decision Records (`devflow/decisions/ADR-xxx-{slug}.md`)**:
+  - Store durable, high-impact, hard-to-reverse architectural decisions in `devflow/decisions/`.
+  - Number sequentially (`ADR-001`, `ADR-002`, ...).
+  - Must include: Context, Decision, Alternatives Considered (with trade-offs), and Consequences (positive gains and accepted risks).

package/template/devflow/context/current-stage.md

@@ -2,7 +2,7 @@
 
 - **Active Discovery ID**: `None`
 - **Active Running ID**: `None`
-- **Current Stage**: `Idle (Ready for new /feature, /fix, /00-explore, or /10-define)`
+- **Current Stage**: `Idle (Ready for new /feature, /fix, /discovery, or /10-define)`
 - **Living Spec**: `None`
 - **Last Completed Run**: `None`
 - **Last Updated**: `None`

package/template/devflow/decisions/README.md

@@ -0,0 +1,24 @@
+# 🏛️ Architecture Decision Records (ADRs)
+
+This directory stores durable Architecture Decision Records (ADRs) produced during `/grill`, `00-explore`, or high-stakes architectural design sessions.
+
+---
+
+## 📋 ADR Format & Standards
+
+Each ADR is named `ADR-xxx-{slug}.md` (e.g. `ADR-001-database-schema-migration.md`) and follows this structure:
+
+```markdown
+# ADR-xxx: {Title}
+
+- **Status**: Accepted | Proposed | Deprecated | Superseded by ADR-yyy
+- **Date**: YYYY-MM-DD
+- **Context**: Problem statement, background, and why this decision was needed.
+- **Decision**: The selected architectural approach or invariant.
+- **Alternatives Considered**:
+  - *Option 1*: Pros / Cons
+  - *Option 2*: Pros / Cons
+- **Consequences**:
+  - *Positive*: Benefits and capabilities unlocked
+  - *Trade-offs / Risks*: Costs, complexity, or constraints
+```

package/template/devflow/history/HISTORY.md

@@ -8,7 +8,7 @@ This master ledger tracks all released delivery runs, milestones, and rollbacks
 
 | Completed Date | Run ID | Category | Title | Git Commit | Status | Archive Link |
 | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
-| _No shipped runs yet_ | - | - | Run `/feature` or `/00-explore` to start your first delivery run | - | - | - |
+| _No shipped runs yet_ | - | - | Run `/feature` or `/discovery` to start your first delivery run | - | - | - |
 
 ---
 

package/template/devflow/history/features/README.md

@@ -0,0 +1,5 @@
+# Completed Features Archive
+
+Finished feature specs, enhancements, architecture migrations, and tooling runs are archived here as `xxx-name.md` (for Fast-Track single living specs) or `xxx-name/` (for Deep-Track stage runs).
+
+Together they form the project's permanent feature build history, recording what was built, why, and how it was verified.

package/template/devflow/history/fixes/README.md

@@ -0,0 +1,5 @@
+# Completed Fixes Archive
+
+Finished bug fixes, hotfixes, regressions, security patches, and performance optimizations are archived here as `xxx-name.md` (for Fast-Track single living specs) or `xxx-name/` (for Deep-Track stage runs).
+
+Together they form the project's permanent bug resolution history, recording root causes, TDD test decisions, and empirical proof.

package/template/devflow/history/rollbacks/README.md

@@ -0,0 +1,5 @@
+# Completed Rollbacks Archive
+
+Safely reversed features and rollback execution records are archived here as `YYYY-MM-DD-xxx-name.md` (or `YYYY-MM-DD-xxx-name/`).
+
+Together they form the project's safe feature reversal ledger, documenting target commits, dependency review, and post-reversal verification.

package/template/.agents/skills/00-explore/SKILL.md

@@ -1,84 +0,0 @@
----
-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: Explore
-
-$ARGUMENTS
-
-Explore a request before delivery commitment. Create or resume a Discovery ID, choose only the supporting route that the uncertainty requires, and finish with a visible `Proceed`, `Defer`, or `Reject` decision. Do not create a Running ID in this stage.
-
-## Usage
-
-```text
-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-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
-
-## Markdown-First Contract
-
-Write the primary discovery artifact to:
-
-```text
-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.
-
-## Process
-
-### Loop Contract
-
-Run discovery as a decision-and-routing loop, not as task initialization.
-
-- **Intent**: understand the request, select proportionate supporting inquiry, and decide whether the idea should enter delivery definition.
-- **Context**: read the request, discovery artifact when resuming, project context, constraints, and available evidence.
-- **Action**: restate the problem, identify the decision-blocking uncertainty, select `Brainstorm`, `PRD`, `Research`, `Debug`, or direct decision, then synthesize returned findings.
-- **Observation**: use concrete evidence such as option tradeoffs, product framing, research results, root cause, stakeholder constraints, open questions, and visible risk.
-- **Stop Condition**: stop when the selected route and evidence are recorded, open questions are visible, and the decision is `Proceed`, `Defer`, or `Reject`.
-- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`.
-
-### 1. Supporting Routes & Built-in Lenses
-
-1. **Brainstorming Lens (Divergent & Convergent)**:
-   - Formulate 2-3 viable options.
-   - Construct a **Trade-off Comparison Table**:
-     | Option | Pros | Cons | Recommendation |
-     | :--- | :--- | :--- | :--- |
-2. **Research & Empirical Proof Lens**:
-   - Inspect existing codebase patterns with search tools (`grep_search`, `rg`).
-   - Conduct external web search if library feasibility or API contracts are uncertain.
-   - Record verifiable empirical facts.
-3. **PRD & Scoping Lens**:
-   - Problem Statement & Target User Persona.
-   - Core User Stories (`As a... I want to... So that...`).
-   - In-Scope vs. Out-of-Scope boundaries.
-4. **Issue & Bug Triage Lens**:
-   - Classify severity (`Critical/Blocker`, `Major`, `Minor`).
-   - Determine whether root-cause analysis (`debug`) is required before spec.
-
-### 2. Decision & Approval Gate
-
-Set one decision:
-- `Proceed`: enough value and evidence exist to define delivery work
-- `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-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

package/template/.claude/skills/00-explore/SKILL.md

@@ -1,84 +0,0 @@
----
-name: 00-explore
-description: "[Devflow] 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: Explore
-
-$ARGUMENTS
-
-Explore a request before delivery commitment. Create or resume a Discovery ID, choose only the supporting route that the uncertainty requires, and finish with a visible `Proceed`, `Defer`, or `Reject` decision. Do not create a Running ID in this stage.
-
-## Usage
-
-```text
-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-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
-
-## Markdown-First Contract
-
-Write the primary discovery artifact to:
-
-```text
-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.
-
-## Process
-
-### Loop Contract
-
-Run discovery as a decision-and-routing loop, not as task initialization.
-
-- **Intent**: understand the request, select proportionate supporting inquiry, and decide whether the idea should enter delivery definition.
-- **Context**: read the request, discovery artifact when resuming, project context, constraints, and available evidence.
-- **Action**: restate the problem, identify the decision-blocking uncertainty, select `Brainstorm`, `PRD`, `Research`, `Debug`, or direct decision, then synthesize returned findings.
-- **Observation**: use concrete evidence such as option tradeoffs, product framing, research results, root cause, stakeholder constraints, open questions, and visible risk.
-- **Stop Condition**: stop when the selected route and evidence are recorded, open questions are visible, and the decision is `Proceed`, `Defer`, or `Reject`.
-- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`.
-
-### 1. Supporting Routes & Built-in Lenses
-
-1. **Brainstorming Lens (Divergent & Convergent)**:
-   - Formulate 2-3 viable options.
-   - Construct a **Trade-off Comparison Table**:
-     | Option | Pros | Cons | Recommendation |
-     | :--- | :--- | :--- | :--- |
-2. **Research & Empirical Proof Lens**:
-   - Inspect existing codebase patterns with search tools (`grep_search`, `rg`).
-   - Conduct external web search if library feasibility or API contracts are uncertain.
-   - Record verifiable empirical facts.
-3. **PRD & Scoping Lens**:
-   - Problem Statement & Target User Persona.
-   - Core User Stories (`As a... I want to... So that...`).
-   - In-Scope vs. Out-of-Scope boundaries.
-4. **Issue & Bug Triage Lens**:
-   - Classify severity (`Critical/Blocker`, `Major`, `Minor`).
-   - Determine whether root-cause analysis (`debug`) is required before spec.
-
-### 2. Decision & Approval Gate
-
-Set one decision:
-- `Proceed`: enough value and evidence exist to define delivery work
-- `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-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