@jakkrichm/create-nexus-devflow 2.0.0

package/template/.claude/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -0,0 +1,60 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- Be opinionated. When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- Keep definitions tight. One or two sentences max. Define what it is, not what it does.
+- Only include terms specific to this project's context. General programming concepts do not belong.
+- Group terms under subheadings when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+
+## Single vs Multi-Context Repos
+
+Single context: one `CONTEXT.md` at the repo root.
+
+Multiple contexts: a `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) - receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) - generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) - manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering -> Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment -> Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering <-> Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts.
+- If only a root `CONTEXT.md` exists, use single context.
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved.
+
+When multiple contexts exist and the current topic is unclear, ask.

package/template/.claude/skills/domain-modeling/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: domain-modeling
+description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
+---
+
+# Domain Modeling
+
+Actively build and sharpen the project's domain model as you design. This is the active discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down when they crystallize.
+
+## File Structure
+
+Most repos have a single context:
+
+```text
+/
+|-- CONTEXT.md
+|-- docs/
+|   `-- adr/
+|       |-- 0001-event-sourced-orders.md
+|       `-- 0002-postgres-for-write-model.md
+`-- src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```text
+/
+|-- CONTEXT-MAP.md
+|-- docs/
+|   `-- adr/                         system-wide decisions
+`-- src/
+    |-- ordering/
+    |   |-- CONTEXT.md
+    |   `-- docs/adr/                context-specific decisions
+    `-- billing/
+        |-- CONTEXT.md
+        `-- docs/adr/
+```
+
+Create files lazily. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During The Session
+
+### Challenge Against The Glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately and ask which meaning should win.
+
+### Sharpen Fuzzy Language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. For example, distinguish `Customer` from `User` when those concepts have different responsibilities.
+
+### Discuss Concrete Scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force precision about the boundaries between concepts.
+
+### Cross-Reference With Code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it and route the decision back to the active DevFlow stage.
+
+### Update `CONTEXT.md` Inline
+
+When a term is resolved, update `CONTEXT.md` as part of the session. Use the format in `CONTEXT-FORMAT.md`.
+
+`CONTEXT.md` is a glossary only. It should not contain implementation details, specification text, scratch notes, or implementation decisions.
+
+### Offer ADRs Sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. Hard to reverse: the cost of changing your mind later is meaningful.
+2. Surprising without context: a future reader will wonder why the decision was made.
+3. Based on a real trade-off: there were genuine alternatives and one was chosen for specific reasons.
+
+If any condition is missing, skip the ADR. Use the format in `ADR-FORMAT.md`.

package/template/.claude/skills/english-to-thai-translator/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: english-to-thai-translator
+description: English to Thai translation with context awareness for software development documentation and user interfaces.
+allowed-tools: Read, Grep, Glob
+---
+
+# 🇹🇭 English to Thai Translation Skill
+
+This skill enables AI agents to translate English text to Thai while maintaining technical accuracy and contextual meaning. It's designed specifically for software development environments where precise terminology is crucial.
+
+## 🎯 When to Use This Skill
+
+- Translating technical documentation from English to Thai
+- Localizing user interface elements (buttons, labels, messages)
+- Converting code comments and developer notes
+- Creating multilingual project specifications
+- Translating API documentation or technical requirements
+
+## 📝 Translation Guidelines
+
+### Technical Terminology
+- Maintain consistency with existing project terminology
+- Use appropriate Thai technical terms for software concepts
+- Preserve acronyms and abbreviations when they're standard in Thai context
+- When no direct Thai equivalent exists, use transliteration + explanation
+
+### Style and Tone
+- Keep formal tone for documentation and specifications
+- Use conversational tone for user-facing interfaces
+- Maintain consistent terminology throughout the document
+- Ensure translations are culturally appropriate for Thai audience
+
+### Special Considerations
+- **Code Comments**: Preserve code structure, translate only comments
+- **API Documentation**: Maintain parameter names and technical descriptions
+- **UI Text**: Follow Thai text direction (left-to-right) and spacing conventions
+- **Numbers and Dates**: Use Thai number formats and date conventions
+
+## 🛠️ Usage Examples
+
+### Example 1: Translating Documentation
+```
+Original English:
+"Configure the database connection parameters in the config file."
+
+Thai Translation:
+"ตั้งค่าพารามิเตอร์การเชื่อมต่อฐานข้อมูลในไฟล์กำหนดค่า"
+```
+
+### Example 2: Translating UI Elements
+```
+Original English:
+"Save Changes"
+
+Thai Translation:
+"บันทึกการเปลี่ยนแปลง"
+```
+
+### Example 3: Translating Technical Specifications
+```
+Original English:
+"The system shall validate user input before processing."
+
+Thai Translation:
+"ระบบจะต้องตรวจสอบข้อมูลที่ผู้ใช้ป้อนก่อนประมวลผล"
+```
+
+## 📚 Best Practices
+
+### DO ✅
+- Use proper Thai punctuation and spacing conventions
+- Maintain technical accuracy over literal translation
+- Ensure consistency with existing Thai terminology in the project
+- Preserve code formatting when translating comments
+
+### DON'T ❌
+- Don't translate technical terms without context consideration
+- Don't ignore cultural appropriateness for Thai audience
+- Don't break existing code structure or syntax
+- Don't create overly literal translations that lose meaning
+
+## 🧪 Quality Checks
+
+Before completing translation tasks, verify:
+1. Technical accuracy of translated terminology
+2. Cultural appropriateness of the translation
+3. Consistency with project's existing Thai documentation
+4. Proper formatting and spacing for UI elements
+5. No broken links or references in translated content
+
+## 🔄 Integration with PRPs Framework
+
+This skill works within the DevFlow 2.0 workflow:
+1. During `/10-Define` or `/20-Spec`, it can help create multilingual specifications
+2. In `/30-Plan`, it helps explain technical requirements in Thai
+3. During `/40-Implement`, it translates comments and documentation when needed
+4. In `/50-Verify` or `/60-Report`, it helps ensure translated content remains clear and correct
+
+## 📁 File Structure
+
+The skill is designed to work with:
+- Documentation files (`.md`, `.txt`)
+- Code comments (`.js`, `.ts`, `.py`, `.java`)
+- Configuration files that contain text to be translated
+- User interface text resources
+
+## ⚠️ Limitations
+
+This skill provides general translation capabilities but may require human review for:
+- Highly specialized technical domains
+- Cultural nuances and idioms
+- Creative content requiring artistic interpretation
+- Legal or regulatory documents requiring official translations
+
+## 📋 Language Constraints
+
+This skill is strictly limited to translating between English and Thai languages only. All output must be exclusively in either English or Thai, with no inclusion of:
+- Chinese (or any other language)
+- Mixed language content
+- Transliterations that include non-Thai characters
+- Any foreign language elements
+
+The translation must maintain pure English-to-Thai conversion without introducing additional languages or mixed scripts.
+
+*Generated by Nexus-DevFlow Specialist*

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

@@ -0,0 +1,83 @@
+---
+name: followup
+description: Followup workflow
+---
+
+---
+description: Follow-up Planning - Extend an existing completed or reviewed task without replacing the existing implementation plan.
+---
+
+# Phase 35: Follow-up Planning
+
+## Request: $ARGUMENTS
+
+Use this workflow when the user wants to add more functionality to an existing task after implementation, QA, or human review.
+
+Primary behavior now lives in the `review-followup-routing` skill using `task-followup` mode. Keep this workflow as the compatibility wrapper for extending an existing running ID.
+
+## Prompt Source
+
+Adapted from:
+
+- `followup_planner.md`
+
+## Core Rule
+
+Extend, do not replace.
+
+Preserve existing phases, subtasks, statuses, logs, QA results, and completed context.
+
+## Process
+
+### 1. Load Existing Task
+
+Read:
+
+- `devflow/runs/{ID}-*/10-define.md`
+- `devflow/runs/{ID}-*/20-spec.md`
+- `devflow/runs/{ID}-*/30-plan.md`
+- `devflow/runs/{ID}-*/40-implement.md`
+- `devflow/runs/{ID}-*/50-verify.md` if present
+
+### 2. Classify The Follow-Up
+
+Classify the request:
+
+- extension
+- enhancement
+- integration
+- refinement
+- bug fix after review
+
+### 3. Append New Work
+
+Use plan helpers:
+
+Append the follow-up scope directly to the relevant stage markdown files for the same running ID. Add new phases, subtasks, and validation notes in `30-plan.md` and carry resulting work into later stages.
+
+### 4. Ask For Confirmation
+
+After adding or proposing follow-up subtasks, ask the user to confirm before `/40-Implement`.
+
+## Output
+
+Return:
+
+- follow-up category
+- new phase/subtask plan
+- validation result
+- next command: `/40-Implement {ID}`
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: after review, triage, or release follow-up work is identified
+- Typical handoff targets: `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`
+
+## Sources
+
+- `AGENTS.md`
+- Related commands: `PR-Followup`, `Issue-Triage`, `Human-Feedback`, `/10-Define`, `/20-Spec`, `/40-Implement`
+
+

package/template/.claude/skills/frontend-ui-engineering/SKILL.md

@@ -0,0 +1,326 @@
+---
+name: frontend-ui-engineering
+description: Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
+---
+
+# Frontend UI Engineering
+
+## Overview
+
+Build production-quality user interfaces that are accessible, performant, and visually polished. The goal is UI that looks like it was built by a design-aware engineer at a top company — not like it was generated by an AI. This means real design system adherence, proper accessibility, thoughtful interaction patterns, and no generic "AI aesthetic."
+
+## When to Use
+
+- Building new UI components or pages
+- Modifying existing user-facing interfaces
+- Implementing responsive layouts
+- Adding interactivity or state management
+- Fixing visual or UX issues
+
+## Component Architecture
+
+### File Structure
+
+Colocate everything related to a component:
+
+```
+src/components/
+  TaskList/
+    TaskList.tsx          # Component implementation
+    TaskList.test.tsx     # Tests
+    TaskList.stories.tsx  # Storybook stories (if using)
+    use-task-list.ts      # Custom hook (if complex state)
+    types.ts              # Component-specific types (if needed)
+```
+
+### Component Patterns
+
+**Prefer composition over configuration:**
+
+```tsx
+// Good: Composable
+<Card>
+  <CardHeader>
+    <CardTitle>Tasks</CardTitle>
+  </CardHeader>
+  <CardBody>
+    <TaskList tasks={tasks} />
+  </CardBody>
+</Card>
+
+// Avoid: Over-configured
+<Card
+  title="Tasks"
+  headerVariant="large"
+  bodyPadding="md"
+  content={<TaskList tasks={tasks} />}
+/>
+```
+
+**Keep components focused:**
+
+```tsx
+// Good: Does one thing
+export function TaskItem({ task, onToggle, onDelete }: TaskItemProps) {
+  return (
+    <li className="flex items-center gap-3 p-3">
+      <Checkbox checked={task.done} onChange={() => onToggle(task.id)} />
+      <span className={task.done ? 'line-through text-muted' : ''}>{task.title}</span>
+      <Button variant="ghost" size="sm" onClick={() => onDelete(task.id)}>
+        <TrashIcon />
+      </Button>
+    </li>
+  );
+}
+```
+
+**Separate data fetching from presentation:**
+
+```tsx
+// Container: handles data
+export function TaskListContainer() {
+  const { tasks, isLoading, error } = useTasks();
+
+  if (isLoading) return <TaskListSkeleton />;
+  if (error) return <ErrorState message="Failed to load tasks" retry={refetch} />;
+  if (tasks.length === 0) return <EmptyState message="No tasks yet" />;
+
+  return <TaskList tasks={tasks} />;
+}
+
+// Presentation: handles rendering
+export function TaskList({ tasks }: { tasks: Task[] }) {
+  return (
+    <ul role="list" className="divide-y">
+      {tasks.map(task => <TaskItem key={task.id} task={task} />)}
+    </ul>
+  );
+}
+```
+
+## State Management
+
+**Choose the simplest approach that works:**
+
+```
+Local state (useState)           → Component-specific UI state
+Lifted state                     → Shared between 2-3 sibling components
+Context                          → Theme, auth, locale (read-heavy, write-rare)
+URL state (searchParams)         → Filters, pagination, shareable UI state
+Server state (React Query, SWR)  → Remote data with caching
+Global store (Zustand, Redux)    → Complex client state shared app-wide
+```
+
+**Avoid prop drilling deeper than 3 levels.** If you're passing props through components that don't use them, introduce context or restructure the component tree.
+
+## Design System Adherence
+
+### Avoid the AI Aesthetic
+
+AI-generated UI has recognizable patterns. Avoid all of them:
+
+| AI Default | Why It Is a Problem | Production Quality |
+|---|---|---|
+| Purple/indigo everything | Models default to visually "safe" palettes | Use project-specific color palettes |
+| Excessive gradients | Adds visual noise | Subtle or no gradients |
+| Rounded everything | Generic signals "safe" | Purposeful corner radii (sharp vs rounded) |
+| Generic hero sections | Template-driven, no context | Content-first, unique layouts |
+| Bento Grids | Used in every AI design | Use only when content truly benefits from it |
+| Shadows everywhere | Competitive depth noise | Subtle or no shadows |
+
+### UX Psychology & Layout
+- **Hick's Law**: More choices = slower decisions. Limit options, use progressive disclosure.
+- **8-Point Grid**: All spacing and sizing in multiples of 8 (Tight: 8px, Med: 16px, Large: 24px, XL: 48px+).
+- **Whitespace**: Generous whitespace signals luxury and improves scannability.
+- **Contrast**: Check WCAG (4.5:1 for normal text). Do not rely solely on color to convey information.
+
+### Spacing and Layout
+
+Use a consistent spacing scale. Don't invent values:
+
+```css
+/* Use the scale: 0.25rem increments (or whatever the project uses) */
+/* Good */  padding: 1rem;      /* 16px */
+/* Good */  gap: 0.75rem;       /* 12px */
+/* Bad */   padding: 13px;      /* Not on any scale */
+/* Bad */   margin-top: 2.3rem; /* Not on any scale */
+```
+
+### Typography
+
+Respect the type hierarchy:
+
+```
+h1 → Page title (one per page)
+h2 → Section title
+h3 → Subsection title
+body → Default text
+small → Secondary/helper text
+```
+
+Don't skip heading levels. Don't use heading styles for non-heading content.
+
+### Color
+
+- Use semantic color tokens: `text-primary`, `bg-surface`, `border-default` — not raw hex values
+- Ensure sufficient contrast (4.5:1 for normal text, 3:1 for large text)
+- Don't rely solely on color to convey information (use icons, text, or patterns too)
+
+## Accessibility (WCAG 2.1 AA)
+
+Every component must meet these standards:
+
+### Keyboard Navigation
+
+```tsx
+// Every interactive element must be keyboard accessible
+<button onClick={handleClick}>Click me</button>        // ✓ Focusable by default
+<div onClick={handleClick}>Click me</div>               // ✗ Not focusable
+<div role="button" tabIndex={0} onClick={handleClick}    // ✓ But prefer <button>
+     onKeyDown={e => e.key === 'Enter' && handleClick()}>
+  Click me
+</div>
+```
+
+### ARIA Labels
+
+```tsx
+// Label interactive elements that lack visible text
+<button aria-label="Close dialog"><XIcon /></button>
+
+// Label form inputs
+<label htmlFor="email">Email</label>
+<input id="email" type="email" />
+
+// Or use aria-label when no visible label exists
+<input aria-label="Search tasks" type="search" />
+```
+
+### Focus Management
+
+```tsx
+// Move focus when content changes
+function Dialog({ isOpen, onClose }: DialogProps) {
+  const closeRef = useRef<HTMLButtonElement>(null);
+
+  useEffect(() => {
+    if (isOpen) closeRef.current?.focus();
+  }, [isOpen]);
+
+  // Trap focus inside dialog when open
+  return (
+    <dialog open={isOpen}>
+      <button ref={closeRef} onClick={onClose}>Close</button>
+      {/* dialog content */}
+    </dialog>
+  );
+}
+```
+
+### Meaningful Empty and Error States
+
+```tsx
+// Don't show blank screens
+function TaskList({ tasks }: { tasks: Task[] }) {
+  if (tasks.length === 0) {
+    return (
+      <div role="status" className="text-center py-12">
+        <TasksEmptyIcon className="mx-auto h-12 w-12 text-muted" />
+        <h3 className="mt-2 text-sm font-medium">No tasks</h3>
+        <p className="mt-1 text-sm text-muted">Get started by creating a new task.</p>
+        <Button className="mt-4" onClick={onCreateTask}>Create Task</Button>
+      </div>
+    );
+  }
+
+  return <ul role="list">...</ul>;
+}
+```
+
+## Responsive Design
+
+Design for mobile first, then expand:
+
+```tsx
+// Tailwind: mobile-first responsive
+<div className="
+  grid grid-cols-1      /* Mobile: single column */
+  sm:grid-cols-2        /* Small: 2 columns */
+  lg:grid-cols-3        /* Large: 3 columns */
+  gap-4
+">
+```
+
+Test at these breakpoints: 320px, 768px, 1024px, 1440px.
+
+## Loading and Transitions
+
+```tsx
+// Skeleton loading (not spinners for content)
+function TaskListSkeleton() {
+  return (
+    <div className="space-y-3" aria-busy="true" aria-label="Loading tasks">
+      {Array.from({ length: 3 }).map((_, i) => (
+        <div key={i} className="h-12 bg-muted animate-pulse rounded" />
+      ))}
+    </div>
+  );
+}
+
+// Optimistic updates for perceived speed
+function useToggleTask() {
+  const queryClient = useQueryClient();
+
+  return useMutation({
+    mutationFn: toggleTask,
+    onMutate: async (taskId) => {
+      await queryClient.cancelQueries({ queryKey: ['tasks'] });
+      const previous = queryClient.getQueryData(['tasks']);
+
+      queryClient.setQueryData(['tasks'], (old: Task[]) =>
+        old.map(t => t.id === taskId ? { ...t, done: !t.done } : t)
+      );
+
+      return { previous };
+    },
+    onError: (_err, _taskId, context) => {
+      queryClient.setQueryData(['tasks'], context?.previous);
+    },
+  });
+}
+```
+
+## See Also
+
+For detailed accessibility requirements and testing tools, see `accessibility-checklist.md`.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Accessibility is a nice-to-have" | It's a legal requirement in many jurisdictions and an engineering quality standard. |
+| "We'll make it responsive later" | Retrofitting responsive design is 3x harder than building it from the start. |
+| "The design isn't final, so I'll skip styling" | Use the design system defaults. Unstyled UI creates a broken first impression for reviewers. |
+| "This is just a prototype" | Prototypes become production code. Build the foundation right. |
+| "The AI aesthetic is fine for now" | It signals low quality. Use the project's actual design system from the start. |
+
+## Red Flags
+
+- Components with more than 200 lines (split them)
+- Inline styles or arbitrary pixel values
+- Missing error states, loading states, or empty states
+- No keyboard navigation testing
+- Color as the sole indicator of state (red/green without text or icons)
+- Generic "AI look" (purple gradients, oversized cards, stock layouts)
+
+## Verification
+
+After building UI:
+
+- [ ] Component renders without console errors
+- [ ] All interactive elements are keyboard accessible (Tab through the page)
+- [ ] Screen reader can convey the page's content and structure
+- [ ] Responsive: works at 320px, 768px, 1024px, 1440px
+- [ ] Loading, error, and empty states all handled
+- [ ] Follows the project's design system (spacing, colors, typography)
+- [ ] No accessibility warnings in dev tools or axe-core