@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/spec-driven-development/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: spec-driven-development
+description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
+---
+
+# Spec-Driven Development
+
+## Overview
+
+Write a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing.
+
+## When to Use
+
+- Starting a new project or feature
+- Requirements are ambiguous or incomplete
+- The change touches multiple files or modules
+- You're about to make an architectural decision
+- The task would take more than 30 minutes to implement
+
+**When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.
+
+## The Gated Workflow
+
+Spec-driven development has four phases. Do not advance to the next phase until the current one is validated.
+
+```
+SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
+   │          │        │          │
+   ▼          ▼        ▼          ▼
+ Human      Human    Human      Human
+ reviews    reviews  reviews    reviews
+```
+
+### Phase 1: Specify
+
+Start with a high-level vision. Ask the human clarifying questions until requirements are concrete.
+
+**Surface assumptions immediately.** Before writing any spec content, list what you're assuming:
+
+```
+ASSUMPTIONS I'M MAKING:
+1. This is a web application (not native mobile)
+2. Authentication uses session-based cookies (not JWT)
+3. The database is PostgreSQL (based on existing Prisma schema)
+4. We're targeting modern browsers only (no IE11)
+→ Correct me now or I'll proceed with these.
+```
+
+Don't silently fill in ambiguous requirements. The spec's entire purpose is to surface misunderstandings *before* code gets written — assumptions are the most dangerous form of misunderstanding.
+
+**Write a spec document covering these six core areas:**
+
+1. **Objective** — What are we building and why? Who is the user? What does success look like?
+
+2. **Commands** — Full executable commands with flags, not just tool names.
+   ```
+   Build: npm run build
+   Test: npm test -- --coverage
+   Lint: npm run lint --fix
+   Dev: npm run dev
+   ```
+
+3. **Project Structure** — Where source code lives, where tests go, where docs belong.
+   ```
+   src/           → Application source code
+   src/components → React components
+   src/lib        → Shared utilities
+   tests/         → Unit and integration tests
+   e2e/           → End-to-end tests
+   docs/          → Documentation
+   ```
+
+4. **Code Style** — One real code snippet showing your style beats three paragraphs describing it. Include naming conventions, formatting rules, and examples of good output.
+
+5. **Testing Strategy** — What framework, where tests live, coverage expectations, which test levels for which concerns.
+
+6. **Boundaries** — Three-tier system:
+   - **Always do:** Run tests before commits, follow naming conventions, validate inputs
+   - **Ask first:** Database schema changes, adding dependencies, changing CI config
+   - **Never do:** Commit secrets, edit vendor directories, remove failing tests without approval
+
+## DevFlow 2.0 Specification Contract
+
+Every specification must stand on its own in markdown under `devflow/runs/{ID}-*/`:
+
+1. **`define.md`**: Decision and scope framing when the problem still needs clarification.
+2. **`spec.md`**: The delivery contract following the template below.
+
+**Spec template:**
+
+```markdown
+# Spec: [Project/Feature Name]
+
+## Objective
+[What we're building and why. User stories or acceptance criteria.]
+
+## Tech Stack
+[Framework, language, key dependencies with versions]
+
+## Commands
+[Build, test, lint, dev — full commands]
+
+## Project Structure
+[Directory layout with descriptions]
+
+## Code Style
+[Example snippet + key conventions]
+
+## Testing Strategy
+[Framework, test locations, coverage requirements, test levels]
+
+## Boundaries
+- Always: [...]
+- Ask first: [...]
+- Never: [...]
+
+## Success Criteria
+[How we'll know this is done — specific, testable conditions]
+
+## Open Questions
+[Anything unresolved that needs human input]
+```
+
+**Reframe instructions as success criteria.** When receiving vague requirements, translate them into concrete conditions:
+
+```
+REQUIREMENT: "Make the dashboard faster"
+
+REFRAMED SUCCESS CRITERIA:
+- Dashboard LCP < 2.5s on 4G connection
+- Initial data load completes in < 500ms
+- No layout shift during load (CLS < 0.1)
+→ Are these the right targets?
+```
+
+This lets you loop, retry, and problem-solve toward a clear goal rather than guessing what "faster" means.
+
+### Phase 2: Plan
+
+With the validated spec, generate a technical implementation plan:
+
+1. Identify the major components and their dependencies
+2. Determine the implementation order (what must be built first)
+3. Note risks and mitigation strategies
+4. Identify what can be built in parallel vs. what must be sequential
+5. Define verification checkpoints between phases
+
+The plan should be reviewable: the human should be able to read it and say "yes, that's the right approach" or "no, change X."
+
+### Phase 3: Tasks
+
+Break the plan into discrete, implementable tasks:
+
+- Each task should be completable in a single focused session
+- Each task has explicit acceptance criteria
+- Each task includes a verification step (test, build, manual check)
+- Tasks are ordered by dependency, not by perceived importance
+- No task should require changing more than ~5 files
+
+**Task template:**
+```markdown
+- [ ] Task: [Description]
+  - Acceptance: [What must be true when done]
+  - Verify: [How to confirm — test command, build, manual check]
+  - Files: [Which files will be touched]
+```
+
+### Phase 4: Implement
+
+Execute tasks one at a time following `incremental-implementation` and `test-driven-development` skills. Use `context-engineering` to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
+
+## Keeping the Spec Alive
+
+The spec is a living document, not a one-time artifact:
+
+- **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.
+- **Update when scope changes** — Features added or cut should be reflected in the spec.
+- **Commit the spec** — The spec belongs in version control alongside the code.
+- **Reference the spec in PRs** — Link back to the spec section that each PR implements.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "This is simple, I don't need a spec" | Simple tasks don't need *long* specs, but they still need acceptance criteria. A two-line spec is fine. |
+| "I'll write the spec after I code it" | That's documentation, not specification. The spec's value is in forcing clarity *before* code. |
+| "The spec will slow us down" | A 15-minute spec prevents hours of rework. Waterfall in 15 minutes beats debugging in 15 hours. |
+| "Requirements will change anyway" | That's why the spec is a living document. An outdated spec is still better than no spec. |
+| "The user knows what they want" | Even clear requests have implicit assumptions. The spec surfaces those assumptions. |
+
+## Red Flags
+
+- Starting to write code without any written requirements
+- Asking "should I just start building?" before clarifying what "done" means
+- Implementing features not mentioned in any spec or task list
+- Making architectural decisions without documenting them
+- Skipping the spec because "it's obvious what to build"
+
+## Verification
+
+Before proceeding to implementation, confirm:
+
+- [ ] The spec covers all six core areas
+- [ ] The human has reviewed and approved the spec
+- [ ] Success criteria are specific and testable
+- [ ] Boundaries (Always/Ask First/Never) are defined
+- [ ] The spec is saved to a file in the repository

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

@@ -0,0 +1,91 @@
+---
+name: spec-orchestration
+description: Coordinate Brainstorm, Research, PRD, competitor context, and spec critique before the work re-enters the numbered mainline. Use when a broad idea needs orchestration rather than a straight pass.
+---
+
+# Spec Orchestration
+
+## Overview
+
+This skill is the shared behavior layer behind `Spec-Orchestrate`.
+
+It keeps the valuable orchestration UX from the legacy prompt while making sure DevFlow 2.0 still routes back into the numbered mainline cleanly.
+
+## Related Assets
+
+This skill should reuse and align with:
+
+- `.agent/resources/schemas/spec_orchestration.template.md`
+- `Brainstorm`
+- `Research`
+- `Spec-Research`
+- `Competitor`
+- `PRD`
+
+## When to Use
+
+- when an idea is too broad for one straight pass through Discover, Define, and Spec
+- when multiple evidence lanes are needed before a real delivery contract can be written
+- when the user needs orchestration, not autonomous execution
+
+## Process
+
+### 1. Clarify The Idea
+
+Identify:
+
+- target user
+- core problem
+- desired outcome
+- constraints
+- acceptance signals
+
+### 2. Choose Only The Needed Support
+
+Route proportionally:
+
+- `Brainstorm` for option generation
+- `Research` or `Spec-Research` for external or technical proof
+- `Competitor` for market context
+- `PRD` for product framing
+- `/10-Define` for scope and decision locking
+- `/20-Spec` for delivery contract writing
+
+Do not stack every support surface by default.
+
+### 3. Critique Before Execution
+
+Check for:
+
+- missing acceptance criteria
+- unverified dependencies
+- unclear boundaries
+- hidden risks
+- ambiguous UX, API, or data behavior
+- wrong sequencing between framing and execution
+
+### 4. Save A Reusable Report
+
+Write the orchestration report to:
+
+```text
+devflow/reports/{date}-{slug}-spec-orchestration.md
+```
+
+Use `.agent/resources/schemas/spec_orchestration.template.md` and replace placeholder text fully.
+
+### 5. Route Back To Mainline
+
+- `/10-Define` when the idea still needs scope decisions
+- `/20-Spec` when enough evidence exists to write the delivery contract
+- `/30-Plan` only when the spec is already solid
+
+## Output
+
+Return:
+
+- what is already stable
+- what still needs proof or discovery
+- the supporting commands chosen
+- where the orchestration report was saved
+- the exact next command

package/template/.agents/skills/specialist-agent-routing/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: specialist-agent-routing
+description: Route a request to the right specialist agent and preserve the DevFlow 2.0 stage-first contract. Use when the user wants direct specialist judgment on a file, folder, workspace, or concern.
+---
+
+# Specialist Agent Routing
+
+## Overview
+
+This skill is the shared behavior layer behind `Agent`.
+
+It keeps direct specialist invocation available for advanced use, but makes clear that the owning workflow or mainline stage still controls lifecycle state.
+
+## When to Use
+
+- when the user explicitly wants a specialist persona
+- when a stage needs deeper focused judgment on a bounded target
+- when a file, folder, running ID workspace, or codebase concern maps better to one expert than to a whole workflow
+
+## Core Rule
+
+`Agent` is not a mainline stage and should not replace the owning workflow.
+
+Use it to add focused expertise, then route back to the correct lifecycle step.
+
+## Input Shape
+
+```text
+Agent {AGENT_NAME} {TARGET}
+```
+
+Examples:
+
+```text
+Agent requirements-engineer devflow/runs/007/spec.md
+Agent codebase-explorer src/services/
+Agent code-reviewer devflow/runs/007
+```
+
+## Process
+
+### 1. Load The Specialist
+
+Read:
+
+- `.agent/agents/{AGENT_NAME}.md`
+- the minimum necessary target context
+- relevant stage artifacts when the target belongs to a running ID
+
+### 2. Preserve Stage-First Contract
+
+- prefer `discover.md`, `define.md`, `spec.md`, `plan.md`, `implement.md`, `verify.md`, `release.md`, and `report.md`
+- do not silently mutate legacy JSON contracts
+- if the agent is only reviewing, return recommendations or save a report instead of pretending to execute the whole lifecycle
+
+### 3. Apply Specialist Discipline
+
+Examples:
+
+- `code-reviewer` -> correctness, risk, maintainability, findings-first review
+- `prp-core-debugger` -> RCA and validation evidence
+- `requirements-engineer` -> scope, ambiguity, acceptance criteria
+- `codebase-explorer` -> architecture, pattern, and data flow investigation
+
+### 4. Save A Reusable Report When Needed
+
+For substantial outputs, save to:
+
+```text
+devflow/reports/{date}-{agent-name}-{timestamp}.md
+```
+
+Use `.agent/resources/schemas/agent_report.template.md` unless the invoking workflow provides a more specific template.
+
+### 5. Route Back
+
+Return to the owning step:
+
+- `/10-Define`
+- `/20-Spec`
+- `/30-Plan`
+- `/40-Implement`
+- `/50-Verify`
+- `/70-Release`
+- `/60-Report`
+- `PR-Review`
+- `Research`
+
+## Skills That Should Not Be Invoked As Agents
+
+These former narrow agents now belong in the skill layer:
+
+- `code-simplification`
+- `type-design`
+- `silent-failure-audit`
+
+Invoke them through the responsible workflow or agent instead.
+
+## Output
+
+Return:
+
+- agent used
+- target reviewed
+- concise findings or changes
+- report path when a substantial report was written
+- exact recommended next route

package/template/.agents/skills/tailwind-patterns/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: tailwind-patterns
+description: Tailwind CSS v4 principles. CSS-first configuration, container queries, modern patterns, design token architecture.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# Tailwind CSS Patterns (v4 - 2025)
+
+> Modern utility-first CSS with CSS-native configuration.
+
+---
+
+## 1. Tailwind v4 Architecture
+
+### What Changed from v3
+
+| v3 (Legacy) | v4 (Current) |
+|-------------|--------------|
+| `tailwind.config.js` | CSS-based `@theme` directive |
+| PostCSS plugin | Oxide engine (10x faster) |
+| JIT mode | Native, always-on |
+| Plugin system | CSS-native features |
+| `@apply` directive | Still works, discouraged |
+
+### v4 Core Concepts
+
+| Concept | Description |
+|---------|-------------|
+| **CSS-first** | Configuration in CSS, not JavaScript |
+| **Oxide Engine** | Rust-based compiler, much faster |
+| **Native Nesting** | CSS nesting without PostCSS |
+| **CSS Variables** | All tokens exposed as `--*` vars |
+
+---
+
+## 2. CSS-Based Configuration
+
+### Theme Definition
+
+```
+@theme {
+  /* Colors - use semantic names */
+  --color-primary: oklch(0.7 0.15 250);
+  --color-surface: oklch(0.98 0 0);
+  --color-surface-dark: oklch(0.15 0 0);
+  
+  /* Spacing scale */
+  --spacing-xs: 0.25rem;
+  --spacing-sm: 0.5rem;
+  --spacing-md: 1rem;
+  --spacing-lg: 2rem;
+  
+  /* Typography */
+  --font-sans: 'Inter', system-ui, sans-serif;
+  --font-mono: 'JetBrains Mono', monospace;
+}
+```
+
+### When to Extend vs Override
+
+| Action | Use When |
+|--------|----------|
+| **Extend** | Adding new values alongside defaults |
+| **Override** | Replacing default scale entirely |
+| **Semantic tokens** | Project-specific naming (primary, surface) |
+
+---
+
+## 3. Container Queries (v4 Native)
+
+### Breakpoint vs Container
+
+| Type | Responds To |
+|------|-------------|
+| **Breakpoint** (`md:`) | Viewport width |
+| **Container** (`@container`) | Parent element width |
+
+### Container Query Usage
+
+| Pattern | Classes |
+|---------|---------|
+| Define container | `@container` on parent |
+| Container breakpoint | `@sm:`, `@md:`, `@lg:` on children |
+| Named containers | `@container/card` for specificity |
+
+### When to Use
+
+| Scenario | Use |
+|----------|-----|
+| Page-level layouts | Viewport breakpoints |
+| Component-level responsive | Container queries |
+| Reusable components | Container queries (context-independent) |
+
+---
+
+## 4. Responsive Design
+
+### Breakpoint System
+
+| Prefix | Min Width | Target |
+|--------|-----------|--------|
+| (none) | 0px | Mobile-first base |
+| `sm:` | 640px | Large phone / small tablet |
+| `md:` | 768px | Tablet |
+| `lg:` | 1024px | Laptop |
+| `xl:` | 1280px | Desktop |
+| `2xl:` | 1536px | Large desktop |
+
+### Mobile-First Principle
+
+1. Write mobile styles first (no prefix)
+2. Add larger screen overrides with prefixes
+3. Example: `w-full md:w-1/2 lg:w-1/3`
+
+---
+
+## 5. Dark Mode
+
+### Configuration Strategies
+
+| Method | Behavior | Use When |
+|--------|----------|----------|
+| `class` | `.dark` class toggles | Manual theme switcher |
+| `media` | Follows system preference | No user control |
+| `selector` | Custom selector (v4) | Complex theming |
+
+### Dark Mode Pattern
+
+| Element | Light | Dark |
+|---------|-------|------|
+| Background | `bg-white` | `dark:bg-zinc-900` |
+| Text | `text-zinc-900` | `dark:text-zinc-100` |
+| Borders | `border-zinc-200` | `dark:border-zinc-700` |
+
+---
+
+## 6. Modern Layout Patterns
+
+### Flexbox Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| Center (both axes) | `flex items-center justify-center` |
+| Vertical stack | `flex flex-col gap-4` |
+| Horizontal row | `flex gap-4` |
+| Space between | `flex justify-between items-center` |
+| Wrap grid | `flex flex-wrap gap-4` |
+
+### Grid Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| Auto-fit responsive | `grid grid-cols-[repeat(auto-fit,minmax(250px,1fr))]` |
+| Asymmetric (Bento) | `grid grid-cols-3 grid-rows-2` with spans |
+| Sidebar layout | `grid grid-cols-[auto_1fr]` |
+
+> **Note:** Prefer asymmetric/Bento layouts over symmetric 3-column grids.
+
+---
+
+## 7. Modern Color System
+
+### OKLCH vs RGB/HSL
+
+| Format | Advantage |
+|--------|-----------|
+| **OKLCH** | Perceptually uniform, better for design |
+| **HSL** | Intuitive hue/saturation |
+| **RGB** | Legacy compatibility |
+
+### Color Token Architecture
+
+| Layer | Example | Purpose |
+|-------|---------|---------|
+| **Primitive** | `--blue-500` | Raw color values |
+| **Semantic** | `--color-primary` | Purpose-based naming |
+| **Component** | `--button-bg` | Component-specific |
+
+---
+
+## 8. Typography System
+
+### Font Stack Pattern
+
+| Type | Recommended |
+|------|-------------|
+| Sans | `'Inter', 'SF Pro', system-ui, sans-serif` |
+| Mono | `'JetBrains Mono', 'Fira Code', monospace` |
+| Display | `'Outfit', 'Poppins', sans-serif` |
+
+### Type Scale
+
+| Class | Size | Use |
+|-------|------|-----|
+| `text-xs` | 0.75rem | Labels, captions |
+| `text-sm` | 0.875rem | Secondary text |
+| `text-base` | 1rem | Body text |
+| `text-lg` | 1.125rem | Lead text |
+| `text-xl`+ | 1.25rem+ | Headings |
+
+---
+
+## 9. Animation & Transitions
+
+### Built-in Animations
+
+| Class | Effect |
+|-------|--------|
+| `animate-spin` | Continuous rotation |
+| `animate-ping` | Attention pulse |
+| `animate-pulse` | Subtle opacity pulse |
+| `animate-bounce` | Bouncing effect |
+
+### Transition Patterns
+
+| Pattern | Classes |
+|---------|---------|
+| All properties | `transition-all duration-200` |
+| Specific | `transition-colors duration-150` |
+| With easing | `ease-out` or `ease-in-out` |
+| Hover effect | `hover:scale-105 transition-transform` |
+
+---
+
+## 10. Component Extraction
+
+### When to Extract
+
+| Signal | Action |
+|--------|--------|
+| Same class combo 3+ times | Extract component |
+| Complex state variants | Extract component |
+| Design system element | Extract + document |
+
+### Extraction Methods
+
+| Method | Use When |
+|--------|----------|
+| **React/Vue component** | Dynamic, JS needed |
+| **@apply in CSS** | Static, no JS needed |
+| **Design tokens** | Reusable values |
+
+---
+
+## 11. Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| Arbitrary values everywhere | Use design system scale |
+| `!important` | Fix specificity properly |
+| Inline `style=` | Use utilities |
+| Duplicate long class lists | Extract component |
+| Mix v3 config with v4 | Migrate fully to CSS-first |
+| Use `@apply` heavily | Prefer components |
+
+---
+
+## 12. Performance Principles
+
+| Principle | Implementation |
+|-----------|----------------|
+| **Purge unused** | Automatic in v4 |
+| **Avoid dynamism** | No template string classes |
+| **Use Oxide** | Default in v4, 10x faster |
+| **Cache builds** | CI/CD caching |
+
+---
+
+> **Remember:** Tailwind v4 is CSS-first. Embrace CSS variables, container queries, and native features. The config file is now optional.