@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/workflow-documentation-sync/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: workflow-documentation-sync
+description: Enforces the synchronization and comprehensive update of documentation, manuals, usage guides, and examples whenever a new workflow is introduced or modified in the project. Use when introducing new workflows or changing existing ones.
+---
+
+# Workflow Documentation Sync
+
+## Overview
+This skill ensures that whenever a DevFlow 2.0 workflow or companion command is introduced or modified, all associated documents, user guides, manuals, and usage examples are thoroughly and systematically updated. This prevents outdated context and ensures humans and AI agents have an accurate, uniform understanding of the available tools.
+
+## When to Use
+- When creating a new workflow file under `.agents/skills/*.md`.
+- When modifying the inputs, outputs, processes, or rules of an existing workflow.
+- When deprecating or removing a workflow.
+
+Do NOT use when modifying source code logic that doesn't impact workflow interface, arguments, or overall process.
+
+---
+
+## 🏗️ Core Process
+
+### Step 1: Identify Documentation Targets
+Whenever a workflow is added or modified, compile the list of documents that must be synchronized:
+1. **User Guide / Manual**: [**`USAGE.md`**](file:///d:/nexus-devflow/USAGE.md) (The main IDE user manual).
+2. **Workflow Index**: `.agents/skills/README.md` (if present) or any registry that lists command interfaces.
+3. **Template/Example files**: Any scratch templates, templates, or example files that demonstrate workflow inputs.
+
+### Step 2: Extract Workflow Metadata
+Identify the exact interface changes:
+- What is the **Command trigger**? (e.g., `/70-Release` or `Brainstorm`)
+- What are the **Arguments**? (e.g., Target Branch, default main)
+- What is the **Process flow**? (Pre-flight -> Execution -> Cleanup)
+- What are the **Mandatory Rules**? (e.g., Enforced branch checks)
+
+### Step 3: Comprehensive Updates
+Update all target files systematically:
+1. **Update USAGE.md**: Locate the quick command index and detail sections. Inject the new workflow command, its purpose, argument syntax, full execution steps, and real-world examples.
+2. **Update Workflow Index**: Add the new workflow to the lists of available command surfaces.
+3. **Create Examples**: If the workflow uses complex parameters or stage artifacts, ensure clean, tested examples are placed in the task workspace or referenced guides.
+
+### Step 4: Verify Alignment
+Ensure that:
+- The command prefix is consistent across all documents.
+- Any manual steps described in the guide match the automation logic of the workflow file.
+- Outdated versions or deleted arguments are removed from all documents.
+
+---
+
+## 🛠️ Documentation Template for USAGE.md
+
+When injecting a new workflow into `USAGE.md`, use the following structure:
+
+```markdown
+### 🔀 /{Workflow-Name} - {Workflow-Title}
+- **วัตถุประสงค์**: {Brief description of what it does in Thai}
+- **วิธีใช้งาน**:
+  ```powershell
+  /{Workflow-Name} [Arguments]
+  ```
+- **ขั้นตอนการทำงาน (Process)**:
+  1. {Step 1}
+  2. {Step 2}
+- **กฎเกณฑ์และ Gotchas (Rules & Gotchas)**:
+  - {Mandatory rules or things to watch out for}
+- **ตัวอย่างการใช้งาน (Example)**:
+  - `/{Workflow-Name} {Example-Arguments}`
+```
+
+---
+
+## 🚫 Common Rationalizations
+
+| Rationalization | Reality |
+|:---|:---|
+| "I'll update USAGE.md in the next task." | Undocumented workflows are forgotten workflows. Doc drift starts with a single missed update. |
+| "The prompt in the workflow file is self-documenting." | Workflow prompts are optimized for AI. Humans need clean, Thai-friendly usage instructions with clear examples. |
+| "The workflow is too simple to need examples." | Even simple workflows (like Merge or PR) have edge cases (e.g., force delete warnings) that must be documented. |
+
+---
+
+## ✅ Verification Checklist
+
+- [ ] Every new/modified workflow has been mapped to `USAGE.md`.
+- [ ] Argument parameters in the markdown guide perfectly match the actual `.md` workflow trigger.
+- [ ] Real-world, copy-pasteable execution examples are provided.
+- [ ] Deprecated or old workflow definitions have been removed or clearly marked as legacy to prevent hallucination.
+- [ ] Verification command output or terminal execution proof is recorded.

package/template/.agents/skills/writing-great-skills/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: writing-great-skills
+description: Maintainer reference for writing predictable DevFlow skills. Use when creating, importing, pruning, or refactoring .agent/skills content.
+disable-model-invocation: true
+---
+
+# Writing Great Skills
+
+Use this maintainer support skill when editing `.agent/skills`.
+
+A skill exists to make a process predictable. It should make the agent take the same kind of action in the same kind of situation, without bloating context or competing with workflow ownership.
+
+## Invocation
+
+Choose the lowest-load invocation mode:
+
+- Model-invoked skill: use when the agent must discover and apply the skill on its own.
+- User-invoked skill: use when only humans or another explicit router should call it.
+- Router skill: use when many user-invoked skills create cognitive load.
+
+In DevFlow, public workflow surface should stay stable. New skills usually start as support skills, not public companion commands.
+
+## Description Rules
+
+- Front-load the leading word.
+- Include only distinct trigger branches.
+- Remove synonyms that repeat the same trigger.
+- Keep stage ownership out of the description; put lifecycle placement in the body.
+
+## Information Hierarchy
+
+Put material where it belongs:
+
+1. In-skill steps: actions every invocation needs.
+2. In-skill reference: rules frequently needed during execution.
+3. External reference files: details only some branches need.
+
+Use progressive disclosure for long reference material.
+
+## Splitting Rules
+
+Split a skill only when:
+
+- it needs independent model invocation
+- a long step sequence causes premature completion
+- branches are different enough that one file causes confusion
+
+Do not split only because a file is aesthetically long.
+
+## Pruning Rules
+
+- Keep one source of truth for each rule.
+- Delete no-op advice that does not change behavior.
+- Delete stale upstream assumptions when importing.
+- Prefer DevFlow stage names and artifact paths.
+
+## Import Checklist
+
+- [ ] Fits `docs/skill-selection-policy.md`.
+- [ ] Does not create a new mainline stage.
+- [ ] Does not expand public companion commands by accident.
+- [ ] Names owning DevFlow stages.
+- [ ] Describes output location.
+- [ ] Routes contradictions back to the owning stage.
+- [ ] Passes `npm run validate`.

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

@@ -0,0 +1,170 @@
+---name: 00-discover
+
+description: Discover 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
+
+$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-Discover {title or request}
+/00-Discover {discovery-id}
+```
+
+Use this when:
+
+- a new request needs discussion before the team commits to delivery
+- 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-discover.md
+```
+
+using:
+
+```text
+.agent/resources/schemas/discover.template.md
+```
+
+Before writing `00-discover.md`, read `artifact_language` from `discover.template.md` and produce the artifact in that language.
+
+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.
+
+## 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 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, the discovery artifact when resuming, companion outputs, 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.
+- **Adjustment**: invoke only the companion route needed to resolve the current uncertainty; every companion invoked by Discover must return to this Discovery ID for synthesis.
+- **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}`. `Defer` and `Reject` end without allocating a Running ID.
+
+### 1. Create Or Resume The Discovery
+
+- inspect `devflow/discoveries/`
+- create a collision-free Discovery ID or resume the one supplied
+- generate a stable slug
+- do not inspect or increment numeric Running IDs during this stage
+
+### 2. Ground The Request
+
+- restate the request in plain language
+- identify the affected users, stakeholders, or systems
+- capture known constraints and decision-blocking unknowns
+- distinguish an idea worth exploring from delivery work already approved elsewhere
+
+### 3. Select The Supporting Route
+
+Choose proportionally:
+
+- `Brainstorm` when several viable directions need comparison
+- `PRD` when user value, product outcomes, MVP boundaries, or success measures need framing
+- `Research` when facts, codebase evidence, feasibility, or external constraints are missing
+- `Debug` when the request begins with a failure and root cause is unknown
+- direct decision when the request and evidence are already clear
+
+Routes are not mutually exclusive, but do not stack them by default. Record why each selected route is necessary. Pass the Discovery ID to the companion and require its output to link back to the discovery.
+
+### 4. Synthesize Returned Findings
+
+After each companion route:
+
+- update `00-discover.md` with the durable findings and source path
+- reassess whether another route is materially necessary
+- return to the Discover decision rather than jumping directly to `/10-Define`
+
+### 5. Decide
+
+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
+
+Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `/10-Define`.
+
+### 6. Write `00-discover.md`
+
+- preserve the template headings
+- follow the configured `artifact_language`
+- replace placeholders with concrete context
+- record selected routes, returned findings, open questions, decision, and rationale
+- keep `related_runs` empty until `/10-Define` materializes approved slices
+
+### 7. Manual Review Gate
+
+Before `/10-Define`:
+
+- confirm the selected route and evidence are sufficient
+- confirm the decision is `Proceed`
+- set `Approval Status` to `Approved`
+
+Do not allocate Running IDs when the decision or approval is pending.
+
+## Output
+
+Report:
+
+- Discovery ID and artifact path
+- request and problem summary
+- selected support route and why
+- important findings and open questions
+- `Proceed`, `Defer`, or `Reject` decision
+- recommended next step, including `/10-Define {discovery_id}` only when Proceed is approved
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline discovery stage
+- Previous state: request intake
+- Next state: `/10-Define {discovery_id}` only after approved Proceed
+- Common companion routes: `Brainstorm`, `PRD`, `Research`, `Debug`
+- Running ID lifecycle: begins in `/10-Define`, not in Discover
+
+## Sources
+
+- `AGENTS.md`
+- `docs/workspace-artifacts.md`
+- `.agent/resources/schemas/discover.template.md`
+
+## Next Workflow Recommendation
+
+- **Primary**: the selected companion route, or `/10-Define {discovery_id}` after approved Proceed
+- **Alternatives**:
+  - `Brainstorm {discovery_id}` for unresolved options
+  - `PRD {discovery_id}` for product framing
+  - `Research {discovery_id}` for missing evidence
+  - `Debug {discovery_id}` for unknown root cause
+  - no next command when the decision is Defer or Reject
+
+## Nexus Event
+
+- Use `grill-with-docs` when focused clarification could change the decision or selected route.
+- Use `prototype` when runnable evidence is the fastest way to settle feasibility.

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

@@ -0,0 +1,170 @@
+---name: 10-define
+
+description: Define stage in DevFlow 2.0 - turn an approved discovery into one or more bounded delivery runs with stable scope.
+argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
+---
+
+# Phase 10: Define
+
+$ARGUMENTS
+
+Convert an approved `Proceed` discovery into bounded delivery slices. Allocate one Running ID per independently specifiable and reviewable slice, then write one `10-define.md` contract per generated run. This is the first stage that creates Running IDs.
+
+## Usage
+
+```text
+/10-Define {discovery-id or discovery path}
+/10-Define {running-id or run path}
+```
+
+Use a Discovery ID to materialize new delivery runs. Use an existing Running ID only to revise or split a definition that already exists.
+
+## Markdown-First Contract
+
+For every approved delivery slice, write:
+
+```text
+devflow/runs/{ID}-{slug}/10-define.md
+```
+
+using:
+
+```text
+.agent/resources/schemas/define.template.md
+```
+
+Before writing any `10-define.md`, read `artifact_language` from `define.template.md` and produce every generated 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 definition as a scope-stabilization and run-allocation loop.
+
+- **Intent**: turn an approved discovery into the smallest coherent set of delivery runs that can each be specified, planned, implemented, and verified without carrying the entire initiative context.
+- **Context**: read the approved `00-discover.md`, linked Brainstorm/PRD/Research/Debug outputs, project-wide rules, existing run IDs, and dependencies between candidate slices.
+- **Action**: lock initiative and scope boundaries, decompose delivery slices, review the run map, allocate collision-free Running IDs, and write one `10-define.md` per slice.
+- **Observation**: use independent acceptance boundaries, release boundaries, ownership, dependencies, context size, cross-domain coupling, and reviewability as evidence for splitting or combining slices.
+- **Adjustment**: merge slices that are only implementation tasks; split slices that require separate specs, releases, ownership, or large independent context; return to `/00-Discover` if the decision or product direction is still unstable.
+- **Stop Condition**: stop when the run map is approved, IDs are materialized without collision, each run has stable in/out scope, and every generated run can proceed independently to `/20-Spec {running_id}`.
+- **Handoff**: each `10-define.md` must identify its source Discovery ID, sibling runs, dependencies, scope, non-goals, and exact next command.
+
+### 1. Validate The Discovery Gate
+
+For new delivery work, require:
+
+- `Decision: Proceed`
+- `Approval Status: Approved`
+- a resolvable Discovery ID and `00-discover.md`
+
+If either gate is missing, do not create a Running ID. Return to `/00-Discover {discovery_id}`.
+
+### 2. Build The Delivery Run Map
+
+Define candidate slices around coherent delivery outcomes, not small tasks.
+
+Create separate runs when work has materially independent:
+
+- acceptance or verification boundaries
+- release or rollback boundaries
+- domain context or ownership
+- dependency sequencing
+- implementation context large enough to threaten reliable planning or review
+
+Keep ordinary subtasks inside `/30-Plan` and checklists.
+
+For every slice record:
+
+- title and slug
+- outcome and scope boundary
+- exclusions
+- dependencies
+- shared project constraints
+- reason it deserves one Running ID
+
+### 3. Review Before Allocation
+
+Present the proposed run map for human review before consuming numeric IDs when the split is large, disputed, or high risk. A single clear slice may proceed directly when approval is already explicit.
+
+### 4. Allocate Running IDs
+
+- inspect `devflow/runs/` immediately before allocation
+- choose sequential IDs after the highest existing numeric Running ID
+- never reuse a gap merely because it is available
+- create each target directory immediately to reserve it
+- recheck for collisions before writing artifacts
+- if any collision occurs, stop, rescan, and allocate a fresh contiguous range
+
+One invocation may create one or many Running IDs. Record the complete allocation back into the source discovery's `related_runs` and allocated-run section.
+
+### 5. Write One `10-define.md` Per Run
+
+- preserve template headings
+- set `source_discovery`
+- identify sibling runs and dependencies
+- carry forward only the project context needed by this slice
+- make scope, non-goals, assumptions, and success criteria explicit
+- keep implementation tasks out of Define
+
+### 6. Split An Existing Run When Necessary
+
+If an existing definition is too broad:
+
+- propose a replacement run map
+- preserve traceability to the original run and discovery
+- allocate new IDs only after approval
+- mark the old definition as `Superseded` and list its replacement runs
+- do not silently fork scope during `/20-Spec`
+
+### 7. Manual Review Gate
+
+Before recommending `/20-Spec`, confirm each generated definition independently. Approval of one run must not imply approval of every sibling run.
+
+## Output
+
+Report:
+
+- source Discovery ID
+- proposed and allocated run map
+- workspace path for every generated run
+- scope and dependency summary per run
+- any superseded run
+- exact `/20-Spec {running_id}` commands for approved runs
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow and Running ID creation boundary
+- Previous state: approved `/00-Discover`
+- Next state: `/20-Spec {running_id}` per generated run
+- Running ID lifecycle: starts here
+
+## Sources
+
+- `AGENTS.md`
+- `docs/workspace-artifacts.md`
+- `.agent/resources/schemas/define.template.md`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/20-Spec {running_id}` for each approved run
+- **Alternatives**:
+  - `/00-Discover {discovery_id}` when the go/no-go decision or direction is unstable
+  - `Research {discovery_id}` when evidence still blocks a reliable split
+  - `grill-with-docs` when boundaries or terminology remain ambiguous
+
+## Nexus Event
+
+- Use `domain-modeling` when sibling runs need shared language or durable architectural decisions.
+- Use `planning-and-task-breakdown` only after the delivery boundary is stable; small tasks belong in `/30-Plan`, not separate Running IDs.

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

@@ -0,0 +1,156 @@
+---name: 20-spec
+
+description: Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition.
+argument-hint: "{running-id or workspace path}"
+---
+
+# Phase 20: Spec
+
+$ARGUMENTS
+
+Turn the defined work into a specification that is concrete enough for planning and explicit enough to serve as the delivery contract.
+
+## Usage
+
+```text
+/20-Spec {running-id or workspace path}
+```
+
+Use this when:
+
+- the goal and scope are stable
+- the team needs testable or reviewable requirements
+- planning should not start until the contract is explicit
+
+## Markdown-First Contract
+
+Write the primary stage artifact to:
+
+```text
+devflow/runs/{ID}-{slug}/20-spec.md
+```
+
+using:
+
+```text
+.agent/resources/schemas/spec.template.md
+```
+
+Before writing `20-spec.md`, read `artifact_language` from `spec.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 specification as a contract-hardening loop, not as a prose expansion of the definition.
+
+- **Intent**: produce requirements and acceptance criteria that are concrete enough for planning and review.
+- **Context**: read the run's `10-define.md`, follow its `source_discovery` link when original framing matters, and read relevant research, hard constraints, and domain or codebase decisions that shape this run's delivery contract.
+- **Action**: write requirements, acceptance criteria, constraints, and out-of-scope items, then inspect whether each requirement is testable and unambiguous.
+- **Observation**: use concrete evidence such as ambiguous wording, unchecked assumptions, edge cases, missing acceptance criteria, conflicting constraints, and implementation details that are not true constraints.
+- **Adjustment**: if facts are missing, route to `Research`; if requirements need stress-testing, use `grill-with-docs`; if module or interface boundaries affect the contract, use `codebase-design`; if scope is unstable or still contains multiple independently deliverable contracts, return to `/10-Define` and split the run before continuing.
+- **Stop Condition**: stop when every requirement has checkable acceptance criteria, hard constraints are explicit, out-of-scope items are visible, and `/30-Plan` can break the work down without inventing intent.
+- **Handoff**: `20-spec.md` must tell `/30-Plan` what must be delivered, how success will be checked, what constraints cannot move, and what is intentionally excluded.
+
+### 1. Read Definition Artifacts
+
+Read:
+
+- `10-define.md`
+- the shared `00-discover.md` referenced by `source_discovery` when the original framing still matters
+- research notes if they impose real constraints
+
+### 2. Write The Specification
+
+Define:
+
+- core requirements
+- acceptance criteria
+- hard constraints
+- explicit out-of-scope items
+
+The spec should be strong enough that planning can break it into executable units without guessing intent.
+
+### 3. Handle Missing Certainty
+
+If the spec cannot be written confidently:
+
+- call `Research` when facts are missing
+- use `grill-with-docs` when requirements, acceptance criteria, constraints, or out-of-scope items need to be stress-tested against scenarios and domain language
+- use `codebase-design` when requirements imply module boundaries, interface contracts, seams, or testability constraints
+- record assumptions explicitly when they are unavoidable
+
+Do not hide uncertainty inside vague requirement text.
+
+Do not combine sibling Running IDs into one spec. If this run still contains multiple independent acceptance, release, ownership, or context boundaries, stop and return to `/10-Define {running_id}` for an explicit split.
+
+### 4. Finalize `20-spec.md`
+
+- preserve the template headings
+- follow the `artifact_language` configured in `spec.template.md`
+- replace all placeholders
+- keep implementation details out unless they are true constraints
+- make sure the acceptance criteria can actually be checked
+
+### 5. Manual Review Soft Gate
+
+Before recommending `/30-Plan`, check whether the delivery contract has been human-reviewed.
+If `Approval Status` is not approved yet:
+
+- warn that planning may drift if the spec is still under review
+- recommend review of requirements, exclusions, and acceptance criteria first
+- keep `/30-Plan` as a soft recommendation only
+
+## Output
+
+Report:
+
+- core requirements
+- acceptance criteria
+- hard constraints
+- out-of-scope items
+- manual review warnings when the contract is still pending
+- recommended next step
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/10-Define`
+- Next state: `/30-Plan` when the contract is implementation-ready
+- Common companion commands: `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate` when product or integration context is still incomplete; support skills: `grill-with-docs`, `domain-modeling`, and `codebase-design` when the spec depends on precise domain language, durable decisions, or module/interface constraints
+
+## Sources
+
+- `AGENTS.md`
+- `docs/workspace-artifacts.md`
+- `.agent/resources/schemas/spec.template.md`
+- Related commands: `/10-Define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `/30-Plan`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/30-Plan`
+- **Why**: The specification is now concrete enough to break into executable work.
+- **Alternatives**:
+  - `Research` - choose this when the spec still depends on missing facts.
+  - `grill-with-docs` - choose this when the spec is readable but not yet tough enough to plan from.
+  - `codebase-design` - choose this when interface shape or testability constraints must be settled before planning.
+  - `/10-Define` - choose this when the scope itself is still unstable.
+
+## Nexus Event
+
+- 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.
+