@jakkrichm/create-nexus-devflow 2.0.19 → 2.0.21

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

@@ -1,70 +0,0 @@
----
-name: simplify
-description: "[Devflow] Code simplification and refactoring for clarity and maintainability without altering runtime behavior."
----
-
-# Code Simplification & Refactoring
-
-## Overview
-
-This is the comprehensive code simplification master skill for Nexus-DevFlow. It reduces cognitive load, cleans up unnecessary abstractions, flattens deep nesting, and removes dead code while **preserving 100% exact runtime behavior**.
-
-**Core Rule**: Every simplification must pass: *"Would a new team member understand this faster than the original, without any behavioral regression?"*
-
----
-
-## 1. The Five Principles of Simplification
-
-1. **Preserve Behavior Exactly**: Same inputs, outputs, error conditions, side effects, and ordering.
-2. **Follow Project Conventions**: Consistency with neighboring files beats personal style preferences.
-3. **Delete Dead & Unused Code**: Remove abandoned helpers, dead branch paths, and leftover debugging code.
-4. **Flatten Control Flow**: Replace nested conditionals and callback pyramids with guard clauses and early returns.
-5. **Eliminate Speculative Generalization**: Replace single-use abstractions with clear, direct implementations.
-
----
-
-## 2. High-Impact Simplification Techniques
-
-### A. Guard Clauses Over Nested Conditionals
-```typescript
-// Before: Deep indentation
-function processOrder(order) {
-  if (order) {
-    if (order.isValid) {
-      if (order.isPaid) {
-        return fulfill(order);
-      }
-    }
-  }
-}
-
-// After: Early returns
-function processOrder(order) {
-  if (!order || !order.isValid) return;
-  if (!order.isPaid) return;
-  return fulfill(order);
-}
-```
-
-### B. Inline Single-Use Helpers & Dead Shims
-If a helper function is only called once and adds indirection without semantic clarity, inline it directly.
-
-### C. Remove Dead Code & Leftover Comments
-Delete commented-out code blocks, `// removed` notes, and unused variables (`_unused`). Version control (Git) remembers the history.
-
----
-
-## 3. Verification & Safety Loop
-
-1. Run unit tests before touching code (`npm test` -> GREEN).
-2. Apply one small refactoring step at a time.
-3. Rerun tests immediately after each step. If tests break, revert and reconsider.
-4. Verify overall build and linter checks.
-
----
-
-## Relationship To DevFlow 2.0
-
-- **Classification**: Companion command & Refactoring support
-- **Mainline integration**: Used during `40-execute` (Refactor step of TDD) or `50-verify`.
-- **Handoff**: `50-verify` (proves zero regressions).

package/template/.agents/skills/skill-development/SKILL.md

@@ -1,86 +0,0 @@
----
-name: skill-development
-description: "[Devflow] Guides the creation and maintenance of agent skills. Use when building new skills or modifying existing ones to ensure they follow the PRP framework standards."
----
-
-# Skill Development (Skill Anatomy)
-
-## Overview
-
-This skill defines the standard structure and format of agent-skills skill files. It serves as the "source of truth" for creating new capabilities within the PRP framework.
-
-## When to Use
-- When contributing or creating a new skill.
-- When refactoring existing skills to match the standard.
-- When you need to understand the structural requirements of a `SKILL.md` file.
-
----
-
-## 🏗️ Skill Structure (Anatomy)
-
-Every skill lives in its own directory under `skills/`:
-
-```text
-skills/
-  skill-name/
-  ├── SKILL.md           # Required: The skill definition
-  └── supporting-file.md # Optional: Reference material loaded on demand
-```
-
-### 1. Frontmatter (Required)
-
-```yaml
----
-name: skill-name-with-hyphens
-description: Brief statement of what the skill does. Use when [specific trigger conditions].
----
-```
-
-**Rules:**
-- `name`: Lowercase, hyphen-separated. Must match the directory name.
-- `description`: Starts with what the skill does (third person), followed by trigger conditions. Maximum 1024 characters.
-
-### 2. Standard Sections
-
-A `SKILL.md` should contain these sections:
-
-| Section | Purpose |
-|:---|:---|
-| **# Skill Title** | Clear, descriptive title. |
-| **## Overview** | One-two sentences explaining what this skill does and why it matters. |
-| **## When to Use** | Triggers (symptoms/task types) and when NOT to use. |
-| **## Core Process** | The main workflow, broken into numbered steps or phases. |
-| **## Patterns/Techniques**| Detailed guidance, code examples, or templates. |
-| **## Rationalizations** | A table of excuses agents use to skip steps vs. the reality. |
-| **## Red Flags** | Signs that the skill is being violated. |
-| **## Verification** | Checklist of exit criteria with evidence requirements. |
-
----
-
-## ✍️ Writing Principles
-
-1. **Process over knowledge**: Skills are workflows, not reference docs. Focus on steps, not facts.
-2. **Specific over general**: "Run `npm test`" is better than "verify the tests".
-3. **Evidence over assumption**: Every verification checkbox requires proof (logs, output).
-4. **Anti-rationalization**: pair common agent excuses with factual counter-arguments.
-5. **Token-conscious**: If a section doesn't change agent behavior, remove it.
-
----
-
-## 🚫 Common Rationalizations
-
-| Rationalization | Reality |
-|:---|:---|
-| "This is a simple change, I can skip the spec." | Simple changes often have hidden side effects. The spec prevents regressions. |
-| "I'll add tests after the implementation." | TDD ensures the code is testable from the start and prevents "forgetting" tests. |
-| "I don't need to read the explorer findings, I know the code." | Assumed knowledge is the primary source of bugs. Always verify patterns. |
-
----
-
-## ✅ Verification Checklist
-
-- [ ] Directory name matches `name` in frontmatter.
-- [ ] `SKILL.md` is all uppercase.
-- [ ] All mandatory sections (Overview, Process, Rationalizations, Verification) are present.
-- [ ] Verification steps are objective and require evidence.
-- [ ] Language is imperative and actionable.

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

@@ -1,39 +0,0 @@
----
-name: spec
-description: "[Devflow] Fast-Track Spec router in DevFlow (Blueprint Mode) - aliases and routes to /feature or /fix to create the living current-feature.md contract in context."
-argument-hint: "{feature title, bug description, IDEA-xxx, or running-id}"
----
-
-# Fast-Track: Spec Router (Blueprint Mode)
-
-$ARGUMENTS
-
-Unified Fast-Track entry point that routes to `/feature` or `/fix` to create and maintain the **Single Living Spec (`devflow/context/current-feature.md`)**.
-
-> [!TIP]
-> **Preferred Commands**:
-> - ใช้ **`/feature <title>`** สำหรับฟีเจอร์ใหม่หรืองานพัฒนาทั่วไป
-> - ใช้ **`/fix <bug-description>`** สำหรับแก้บั๊กหรือ hotfix
-
-## Invocations & Aliases
-
-- `/feature <title>`: Fast-Track feature workflow (แนะนำ)
-- `/fix <bug-description>`: Fast-Track ad-hoc bugfix workflow (แนะนำ)
-- `/spec <title>` or `/spec IDEA-xxx`: Generic Fast-Track specification
-- `$feature`, `$fix`, `$spec`: Codex CLI invocation
-
-## Fast-Track Mainline Workflow
-
-```text
-/feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
-```
-
-## Behavior & Contract
-
-When invoked:
-
-1. Checks Single Active Run Guardrail: rejects if an uncompleted active run already exists in `devflow/context/current-stage.md` or `devflow/context/current-feature.md`.
-2. If the input describes a bug or hotfix, routes to `/fix` behavior.
-3. Otherwise, routes to `/feature` behavior.
-4. Allocates sequential ID without prefix (`xxx-slug`), generates `devflow/context/current-feature.md` in **Thai (`th`)**.
-5. Updates `devflow/context/current-stage.md` and reports next step: `/implement`.

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

@@ -1,207 +0,0 @@
----
-name: spec-driven-development
-description: "[Devflow] 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. **`current-feature.md`**: Fast-Track Single Living Spec delivery contract.
-2. **`20-spec.md`**: Deep-Track formal specification delivery contract.
-
-**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/tailwind-patterns/SKILL.md

@@ -1,269 +0,0 @@
----
-name: tailwind-patterns
-description: "[Devflow] 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.