@jakkrichm/create-nexus-devflow 2.0.19 → 2.0.21

package/template/.claude/skills/database-design/scripts/schema_validator.py

@@ -1,172 +0,0 @@
-#!/usr/bin/env python3
-"""
-Schema Validator - Database schema validation
-Validates Prisma schemas and checks for common issues.
-
-Usage:
-    python schema_validator.py <project_path>
-
-Checks:
-    - Prisma schema syntax
-    - Missing relations
-    - Index recommendations
-    - Naming conventions
-"""
-
-import sys
-import json
-import re
-from pathlib import Path
-from datetime import datetime
-
-# Fix Windows console encoding
-try:
-    sys.stdout.reconfigure(encoding='utf-8', errors='replace')
-except:
-    pass
-
-
-def find_schema_files(project_path: Path) -> list:
-    """Find database schema files."""
-    schemas = []
-    
-    # Prisma schema
-    prisma_files = list(project_path.glob('**/prisma/schema.prisma'))
-    schemas.extend([('prisma', f) for f in prisma_files])
-    
-    # Drizzle schema files
-    drizzle_files = list(project_path.glob('**/drizzle/*.ts'))
-    drizzle_files.extend(project_path.glob('**/schema/*.ts'))
-    for f in drizzle_files:
-        if 'schema' in f.name.lower() or 'table' in f.name.lower():
-            schemas.append(('drizzle', f))
-    
-    return schemas[:10]  # Limit
-
-
-def validate_prisma_schema(file_path: Path) -> list:
-    """Validate Prisma schema file."""
-    issues = []
-    
-    try:
-        content = file_path.read_text(encoding='utf-8', errors='ignore')
-        
-        # Find all models
-        models = re.findall(r'model\s+(\w+)\s*{([^}]+)}', content, re.DOTALL)
-        
-        for model_name, model_body in models:
-            # Check naming convention (PascalCase)
-            if not model_name[0].isupper():
-                issues.append(f"Model '{model_name}' should be PascalCase")
-            
-            # Check for id field
-            if '@id' not in model_body and 'id' not in model_body.lower():
-                issues.append(f"Model '{model_name}' might be missing @id field")
-            
-            # Check for createdAt/updatedAt
-            if 'createdAt' not in model_body and 'created_at' not in model_body:
-                issues.append(f"Model '{model_name}' missing createdAt field (recommended)")
-            
-            # Check for @relation without fields
-            relations = re.findall(r'@relation\([^)]*\)', model_body)
-            for rel in relations:
-                if 'fields:' not in rel and 'references:' not in rel:
-                    pass  # Implicit relation, ok
-            
-            # Check for @@index suggestions
-            foreign_keys = re.findall(r'(\w+Id)\s+\w+', model_body)
-            for fk in foreign_keys:
-                if f'@@index([{fk}])' not in content and f'@@index(["{fk}"])' not in content:
-                    issues.append(f"Consider adding @@index([{fk}]) for better query performance in {model_name}")
-        
-        # Check for enum definitions
-        enums = re.findall(r'enum\s+(\w+)\s*{', content)
-        for enum_name in enums:
-            if not enum_name[0].isupper():
-                issues.append(f"Enum '{enum_name}' should be PascalCase")
-        
-    except Exception as e:
-        issues.append(f"Error reading schema: {str(e)[:50]}")
-    
-    return issues
-
-
-def main():
-    project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
-    
-    print(f"\n{'='*60}")
-    print(f"[SCHEMA VALIDATOR] Database Schema Validation")
-    print(f"{'='*60}")
-    print(f"Project: {project_path}")
-    print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
-    print("-"*60)
-    
-    # Find schema files
-    schemas = find_schema_files(project_path)
-    print(f"Found {len(schemas)} schema files")
-    
-    if not schemas:
-        output = {
-            "script": "schema_validator",
-            "project": str(project_path),
-            "schemas_checked": 0,
-            "issues_found": 0,
-            "passed": True,
-            "message": "No schema files found"
-        }
-        print(json.dumps(output, indent=2))
-        sys.exit(0)
-    
-    # Validate each schema
-    all_issues = []
-    
-    for schema_type, file_path in schemas:
-        print(f"\nValidating: {file_path.name} ({schema_type})")
-        
-        if schema_type == 'prisma':
-            issues = validate_prisma_schema(file_path)
-        else:
-            issues = []  # Drizzle validation could be added
-        
-        if issues:
-            all_issues.append({
-                "file": str(file_path.name),
-                "type": schema_type,
-                "issues": issues
-            })
-    
-    # Summary
-    print("\n" + "="*60)
-    print("SCHEMA ISSUES")
-    print("="*60)
-    
-    if all_issues:
-        for item in all_issues:
-            print(f"\n{item['file']} ({item['type']}):")
-            for issue in item["issues"][:5]:  # Limit per file
-                print(f"  - {issue}")
-            if len(item["issues"]) > 5:
-                print(f"  ... and {len(item['issues']) - 5} more issues")
-    else:
-        print("No schema issues found!")
-    
-    total_issues = sum(len(item["issues"]) for item in all_issues)
-    # Schema issues are warnings, not failures
-    passed = True
-    
-    output = {
-        "script": "schema_validator",
-        "project": str(project_path),
-        "schemas_checked": len(schemas),
-        "issues_found": total_issues,
-        "passed": passed,
-        "issues": all_issues
-    }
-    
-    print("\n" + json.dumps(output, indent=2))
-    
-    sys.exit(0)
-
-
-if __name__ == "__main__":
-    main()

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

@@ -1,63 +0,0 @@
----
-name: deploy
-description: "[Devflow] Production deployment pre-flight checks, smoke validation, and deployment execution."
----
-
-# Production Deployment & Launch Readiness
-
-## Overview
-
-This is the comprehensive deployment master skill for Nexus-DevFlow. It handles pre-flight validation, multi-platform deployment execution (Vercel, Render, Railway, Fly.io, Docker), health checks, smoke verification, and safe rollback readiness.
-
-```text
-Pre-Flight Checks ➔ Build & Smoke Test ➔ Deployment Execution ➔ Health Verification ➔ Release Logging
-```
-
----
-
-## 1. Pre-Flight Verification Checklist
-
-Before initiating any deployment, verify:
-1. **Code & Quality**: Zero syntax/type errors, linters clean, unit & integration tests passing (`npm test`).
-2. **Security**: No secrets in source code, environment variables documented in `.env.example`, `npm audit` checked.
-3. **Database & Migrations**: Schema migrations verified backwards-compatible and applied.
-4. **Performance & Assets**: Production bundles compiled, assets compressed, Core Web Vitals considered.
-5. **Observability**: Healthcheck endpoint (`/api/health`) responsive, error tracking configured.
-
----
-
-## 2. Platform Deployment Matrix
-
-| Target Platform | Deploy Method / Command | Verification Method |
-| :--- | :--- | :--- |
-| **Vercel** | `vercel --prod` or Git push | Inspect deployment URL & build logs |
-| **Render / Railway** | `railway up` or Git integration | Check service status & container logs |
-| **Fly.io** | `fly deploy` | Check `fly status` and HTTP response |
-| **Docker / VPS** | `docker compose up -d --build` | Check container health & PM2 logs |
-
----
-
-## 3. Post-Deployment Smoke Verification & Health Check
-
-1. Send an HTTP request to the deployed domain: verify HTTP 200 OK.
-2. Test critical paths (Authentication, API endpoints, core database transactions).
-3. Confirm telemetry and error log stream are free of unhandled exceptions.
-
----
-
-## 4. Rollback Readiness
-
-Always have an immediate rollback plan before triggering production releases:
-- Pin the previous stable build artifact, Docker image tag, or Git commit hash.
-- If post-deployment smoke tests fail, trigger rollback immediately:
-  ```text
-  deploy rollback
-  ```
-
----
-
-## Relationship To DevFlow 2.0
-
-- **Classification**: Companion command & Delivery support
-- **Mainline integration**: Invoked after `70-release` when ready to deploy.
-- **Handoff**: `60-report`, `changelog`, `rollback`

package/template/.claude/skills/documentation-and-adrs/SKILL.md

@@ -1,278 +0,0 @@
----
-name: documentation-and-adrs
-description: "[Devflow] Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase."
----
-
-# Documentation and ADRs
-
-## Overview
-
-Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase.
-
-## When to Use
-
-- Making a significant architectural decision
-- Choosing between competing approaches
-- Adding or changing a public API
-- Shipping a feature that changes user-facing behavior
-- Onboarding new team members (or agents) to the project
-- When you find yourself explaining the same thing repeatedly
-
-**When NOT to use:** Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes.
-
-## Architecture Decision Records (ADRs)
-
-ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write.
-
-### When to Write an ADR
-
-- Choosing a framework, library, or major dependency
-- Designing a data model or database schema
-- Selecting an authentication strategy
-- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
-- Choosing between build tools, hosting platforms, or infrastructure
-- Any decision that would be expensive to reverse
-
-### ADR Template
-
-Store ADRs in `docs/decisions/` with sequential numbering:
-
-```markdown
-# ADR-001: Use PostgreSQL for primary database
-
-## Status
-Accepted | Superseded by ADR-XXX | Deprecated
-
-## Date
-2025-01-15
-
-## Context
-We need a primary database for the task management application. Key requirements:
-- Relational data model (users, tasks, teams with relationships)
-- ACID transactions for task state changes
-- Support for full-text search on task content
-- Managed hosting available (for small team, limited ops capacity)
-
-## Decision
-Use PostgreSQL with Prisma ORM.
-
-## Alternatives Considered
-
-### MongoDB
-- Pros: Flexible schema, easy to start with
-- Cons: Our data is inherently relational; would need to manage relationships manually
-- Rejected: Relational data in a document store leads to complex joins or data duplication
-
-### SQLite
-- Pros: Zero configuration, embedded, fast for reads
-- Cons: Limited concurrent write support, no managed hosting for production
-- Rejected: Not suitable for multi-user web application in production
-
-### MySQL
-- Pros: Mature, widely supported
-- Cons: PostgreSQL has better JSON support, full-text search, and ecosystem tooling
-- Rejected: PostgreSQL is the better fit for our feature requirements
-
-## Consequences
-- Prisma provides type-safe database access and migration management
-- We can use PostgreSQL's full-text search instead of adding Elasticsearch
-- Team needs PostgreSQL knowledge (standard skill, low risk)
-- Hosting on managed service (Supabase, Neon, or RDS)
-```
-
-### ADR Lifecycle
-
-```
-PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
-```
-
-- **Don't delete old ADRs.** They capture historical context.
-- When a decision changes, write a new ADR that references and supersedes the old one.
-
-## Inline Documentation
-
-### When to Comment
-
-Comment the *why*, not the *what*:
-
-```typescript
-// BAD: Restates the code
-// Increment counter by 1
-counter += 1;
-
-// GOOD: Explains non-obvious intent
-// Rate limit uses a sliding window — reset counter at window boundary,
-// not on a fixed schedule, to prevent burst attacks at window edges
-if (now - windowStart > WINDOW_SIZE_MS) {
-  counter = 0;
-  windowStart = now;
-}
-```
-
-### When NOT to Comment
-
-```typescript
-// Don't comment self-explanatory code
-function calculateTotal(items: CartItem[]): number {
-  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
-}
-
-// Don't leave TODO comments for things you should just do now
-// TODO: add error handling  ← Just add it
-
-// Don't leave commented-out code
-// const oldImplementation = () => { ... }  ← Delete it, git has history
-```
-
-### Document Known Gotchas
-
-```typescript
-/**
- * IMPORTANT: This function must be called before the first render.
- * If called after hydration, it causes a flash of unstyled content
- * because the theme context isn't available during SSR.
- *
- * See ADR-003 for the full design rationale.
- */
-export function initializeTheme(theme: Theme): void {
-  // ...
-}
-```
-
-## API Documentation
-
-For public APIs (REST, GraphQL, library interfaces):
-
-### Inline with Types (Preferred for TypeScript)
-
-```typescript
-/**
- * Creates a new task.
- *
- * @param input - Task creation data (title required, description optional)
- * @returns The created task with server-generated ID and timestamps
- * @throws {ValidationError} If title is empty or exceeds 200 characters
- * @throws {AuthenticationError} If the user is not authenticated
- *
- * @example
- * const task = await createTask({ title: 'Buy groceries' });
- * console.log(task.id); // "task_abc123"
- */
-export async function createTask(input: CreateTaskInput): Promise<Task> {
-  // ...
-}
-```
-
-### OpenAPI / Swagger for REST APIs
-
-```yaml
-paths:
-  /api/tasks:
-    post:
-      summary: Create a task
-      requestBody:
-        required: true
-        content:
-          application/json:
-            schema:
-              $ref: '#/components/schemas/CreateTaskInput'
-      responses:
-        '201':
-          description: Task created
-          content:
-            application/json:
-              schema:
-                $ref: '#/components/schemas/Task'
-        '422':
-          description: Validation error
-```
-
-## README Structure
-
-Every project should have a README that covers:
-
-```markdown
-# Project Name
-
-One-paragraph description of what this project does.
-
-## Quick Start
-1. Clone the repo
-2. Install dependencies: `npm install`
-3. Set up environment: `cp .env.example .env`
-4. Run the dev server: `npm run dev`
-
-## Commands
-| Command | Description |
-|---------|-------------|
-| `npm run dev` | Start development server |
-| `npm test` | Run tests |
-| `npm run build` | Production build |
-| `npm run lint` | Run linter |
-
-## Architecture
-Brief overview of the project structure and key design decisions.
-Link to ADRs for details.
-
-## Contributing
-How to contribute, coding standards, PR process.
-```
-
-## Changelog Maintenance
-
-For shipped features:
-
-```markdown
-# Changelog
-
-## [1.2.0] - 2025-01-20
-### Added
-- Task sharing: users can share tasks with team members (#123)
-- Email notifications for task assignments (#124)
-
-### Fixed
-- Duplicate tasks appearing when rapidly clicking create button (#125)
-
-### Changed
-- Task list now loads 50 items per page (was 20) for better UX (#126)
-```
-
-## Documentation for Agents
-
-Special consideration for AI agent context:
-
-- **CLAUDE.md / rules files** — Document project conventions so agents follow them
-- **Spec files** — Keep specs updated so agents build the right thing
-- **ADRs** — Help agents understand why past decisions were made (prevents re-deciding)
-- **Inline gotchas** — Prevent agents from falling into known traps
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. |
-| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. |
-| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. |
-| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
-| "Comments get outdated" | Comments on *why* are stable. Comments on *what* get outdated — that's why you only write the former. |
-
-## Red Flags
-
-- Architectural decisions with no written rationale
-- Public APIs with no documentation or types
-- README that doesn't explain how to run the project
-- Commented-out code instead of deletion
-- TODO comments that have been there for weeks
-- No ADRs in a project with significant architectural choices
-- Documentation that restates the code instead of explaining intent
-
-## Verification
-
-After documenting:
-
-- [ ] ADRs exist for all significant architectural decisions
-- [ ] README covers quick start, commands, and architecture overview
-- [ ] API functions have parameter and return type documentation
-- [ ] Known gotchas are documented inline where they matter
-- [ ] No commented-out code remains
-- [ ] Rules files (CLAUDE.md etc.) are current and accurate

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

@@ -1,47 +0,0 @@
-# ADR Format
-
-ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, and so on.
-
-Create the `docs/adr/` directory lazily, only when the first ADR is needed.
-
-## Template
-
-```md
-# {Short title of the decision}
-
-{1-3 sentences: what is the context, what did we decide, and why.}
-```
-
-That is enough for many ADRs. The value is in recording that a decision was made and why, not in filling out sections.
-
-## Optional Sections
-
-Only include these when they add genuine value:
-
-- Status frontmatter: `proposed`, `accepted`, `deprecated`, or `superseded by ADR-NNNN`
-- Considered Options: only when the rejected alternatives are worth remembering
-- Consequences: only when non-obvious downstream effects need to be called out
-
-## Numbering
-
-Scan `docs/adr/` for the highest existing number and increment by one.
-
-## When To Offer An ADR
-
-All three of these must be 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 a decision is easy to reverse, skip it. If it is not surprising, nobody will need the explanation. If there was no real alternative, there is nothing to record beyond doing the obvious thing.
-
-## What Qualifies
-
-- Architectural shape, such as monorepo structure or event-sourced write models.
-- Integration patterns between contexts.
-- Technology choices that carry lock-in, such as database, message bus, auth provider, or deployment target.
-- Boundary and scope decisions.
-- Deliberate deviations from the obvious path.
-- Constraints not visible in the code.
-- Rejected alternatives when the rejection is non-obvious.

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

@@ -1,60 +0,0 @@
-# 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

@@ -1,74 +0,0 @@
----
-name: domain-modeling
-description: "[Devflow] 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`.