@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.13

package/template/.agents/skills/shipping-and-launch/SKILL.md

@@ -1,311 +0,0 @@
----
-name: shipping-and-launch
-description: "[Devflow] Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy."
----
-
-# Shipping and Launch
-
-## Overview
-
-Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.
-
-## When to Use
-
-- Deploying a feature to production for the first time
-- Releasing a significant change to users
-- Migrating data or infrastructure
-- Opening a beta or early access program
-- Any deployment that carries risk (all of them)
-
-In DevFlow 2.0, this skill most often supports `70-release` and assumes `60-report` is already aligned as the communication baseline.
-
-## The Pre-Launch Checklist
-
-### Code Quality
-
-- [ ] All tests pass (unit, integration, e2e)
-- [ ] Build succeeds with no warnings
-- [ ] Lint and type checking pass
-- [ ] Code reviewed and approved
-- [ ] No TODO comments that should be resolved before launch
-- [ ] No `console.log` debugging statements in production code
-- [ ] Error handling covers expected failure modes
-
-### Security
-
-- [ ] No secrets in code or version control
-- [ ] `npm audit` shows no critical or high vulnerabilities
-- [ ] Input validation on all user-facing endpoints
-- [ ] Authentication and authorization checks in place
-- [ ] Security headers configured (CSP, HSTS, etc.)
-- [ ] Rate limiting on authentication endpoints
-- [ ] CORS configured to specific origins (not wildcard)
-
-### Performance
-
-- [ ] Core Web Vitals within "Good" thresholds
-- [ ] No N+1 queries in critical paths
-- [ ] Images optimized (compression, responsive sizes, lazy loading)
-- [ ] Bundle size within budget
-- [ ] Database queries have appropriate indexes
-- [ ] Caching configured for static assets and repeated queries
-
-### Accessibility
-
-- [ ] Keyboard navigation works for all interactive elements
-- [ ] Screen reader can convey page content and structure
-- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)
-- [ ] Focus management correct for modals and dynamic content
-- [ ] Error messages are descriptive and associated with form fields
-- [ ] No accessibility warnings in axe-core or Lighthouse
-
-### Infrastructure
-
-- [ ] Environment variables set in production
-- [ ] Database migrations applied (or ready to apply)
-- [ ] DNS and SSL configured
-- [ ] CDN configured for static assets
-- [ ] Logging and error reporting configured
-- [ ] Health check endpoint exists and responds
-
-### Documentation
-
-- [ ] README updated with any new setup requirements
-- [ ] API documentation current
-- [ ] ADRs written for any architectural decisions
-- [ ] Changelog updated
-- [ ] User-facing documentation updated (if applicable)
-
-## Feature Flag Strategy
-
-Ship behind feature flags to decouple deployment from release:
-
-```typescript
-// Feature flag check
-const flags = await getFeatureFlags(userId);
-
-if (flags.taskSharing) {
-  // New feature: task sharing
-  return <TaskSharingPanel task={task} />;
-}
-
-// Default: existing behavior
-return null;
-```
-
-**Feature flag lifecycle:**
-
-```
-1. DEPLOY with flag OFF     → Code is in production but inactive
-2. ENABLE for team/beta     → Internal testing in production environment
-3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
-4. MONITOR at each stage    → Watch error rates, performance, user feedback
-5. CLEAN UP                 → Remove flag and dead code path after full rollout
-```
-
-**Rules:**
-- Every feature flag has an owner and an expiration date
-- Clean up flags within 2 weeks of full rollout
-- Don't nest feature flags (creates exponential combinations)
-- Test both flag states (on and off) in CI
-
-## Staged Rollout
-
-### The Rollout Sequence
-
-```
-1. DEPLOY to staging
-   └── Full test suite in staging environment
-   └── Manual smoke test of critical flows
-
-2. DEPLOY to production (feature flag OFF)
-   └── Verify deployment succeeded (health check)
-   └── Check error monitoring (no new errors)
-
-3. ENABLE for team (flag ON for internal users)
-   └── Team uses the feature in production
-   └── 24-hour monitoring window
-
-4. CANARY rollout (flag ON for 5% of users)
-   └── Monitor error rates, latency, user behavior
-   └── Compare metrics: canary vs. baseline
-   └── 24-48 hour monitoring window
-   └── Advance only if all thresholds pass (see table below)
-
-5. GRADUAL increase (25% -> 50% -> 100%)
-   └── Same monitoring at each step
-   └── Ability to roll back to previous percentage at any point
-
-6. FULL rollout (flag ON for all users)
-   └── Monitor for 1 week
-   └── Clean up feature flag
-```
-
-### Rollout Decision Thresholds
-
-Use these thresholds to decide whether to advance, hold, or roll back at each stage:
-
-| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |
-|--------|-----------------|-------------------------------|-----------------|
-| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |
-| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |
-| Client JS errors | No new error types | New errors at <0.1% of sessions | New errors at >0.1% of sessions |
-| Business metrics | Neutral or positive | Decline <5% (may be noise) | Decline >5% |
-
-### When to Roll Back
-
-Roll back immediately if:
-- Error rate increases by more than 2x baseline
-- P95 latency increases by more than 50%
-- User-reported issues spike
-- Data integrity issues detected
-- Security vulnerability discovered
-
-## Monitoring and Observability
-
-### What to Monitor
-
-```
-Application metrics:
-├── Error rate (total and by endpoint)
-├── Response time (p50, p95, p99)
-├── Request volume
-├── Active users
-└── Key business metrics (conversion, engagement)
-
-Infrastructure metrics:
-├── CPU and memory utilization
-├── Database connection pool usage
-├── Disk space
-├── Network latency
-└── Queue depth (if applicable)
-
-Client metrics:
-├── Core Web Vitals (LCP, INP, CLS)
-├── JavaScript errors
-├── API error rates from client perspective
-└── Page load time
-```
-
-### Error Reporting
-
-```typescript
-// Set up error boundary with reporting
-class ErrorBoundary extends React.Component {
-  componentDidCatch(error: Error, info: React.ErrorInfo) {
-    // Report to error tracking service
-    reportError(error, {
-      componentStack: info.componentStack,
-      userId: getCurrentUser()?.id,
-      page: window.location.pathname,
-    });
-  }
-
-  render() {
-    if (this.state.hasError) {
-      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
-    }
-    return this.props.children;
-  }
-}
-
-// Server-side error reporting
-app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
-  reportError(err, {
-    method: req.method,
-    url: req.url,
-    userId: req.user?.id,
-  });
-
-  // Don't expose internals to users
-  res.status(500).json({
-    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
-  });
-});
-```
-
-### Post-Launch Verification
-
-In the first hour after launch:
-
-```
-1. Check health endpoint returns 200
-2. Check error monitoring dashboard (no new error types)
-3. Check latency dashboard (no regression)
-4. Test the critical user flow manually
-5. Verify logs are flowing and readable
-6. Confirm rollback mechanism works (dry run if possible)
-```
-
-## Rollback Strategy
-
-Every deployment needs a rollback plan before it happens:
-
-```markdown
-## Rollback Plan for [Feature/Release]
-
-### Trigger Conditions
-- Error rate > 2x baseline
-- P95 latency > [X]ms
-- User reports of [specific issue]
-
-### Rollback Steps
-1. Disable feature flag (if applicable)
-   OR
-1. Deploy previous version: `git revert <commit> && git push`
-2. Verify rollback: health check, error monitoring
-3. Communicate: notify team of rollback
-
-### Database Considerations
-- Migration [X] has a rollback: `npx prisma migrate rollback`
-- Data inserted by new feature: [preserved / cleaned up]
-
-### Time to Rollback
-- Feature flag: < 1 minute
-- Redeploy previous version: < 5 minutes
-- Database rollback: < 15 minutes
-```
-## See Also
-
-- For security pre-launch checks, see `references/security-checklist.md`
-- For performance pre-launch checklist, see `references/performance-checklist.md`
-- For accessibility verification before launch, see `references/accessibility-checklist.md`
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "It works in staging, it'll work in production" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |
-| "We don't need feature flags for this" | Every feature benefits from a kill switch. Even "simple" changes can break things. |
-| "Monitoring is overhead" | Not having monitoring means you discover problems from user complaints instead of dashboards. |
-| "We'll add monitoring later" | Add it before launch. You can't debug what you can't see. |
-| "Rolling back is admitting failure" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |
-
-## Red Flags
-
-- Deploying without a rollback plan
-- No monitoring or error reporting in production
-- Big-bang releases (everything at once, no staging)
-- Feature flags with no expiration or owner
-- No one monitoring the deploy for the first hour
-- Production environment configuration done by memory, not code
-- "It's Friday afternoon, let's ship it"
-
-## Verification
-
-Before deploying:
-
-- [ ] Pre-launch checklist completed (all sections green)
-- [ ] Feature flag configured (if applicable)
-- [ ] Rollback plan documented
-- [ ] Monitoring dashboards set up
-- [ ] Team notified of deployment
-
-After deploying:
-
-- [ ] Health check returns 200
-- [ ] Error rate is normal
-- [ ] Latency is normal
-- [ ] Critical user flow works
-- [ ] Logs are flowing
-- [ ] Rollback tested or verified ready

package/template/.agents/skills/silent-failure-audit/SKILL.md

@@ -1,73 +0,0 @@
----
-name: silent-failure-audit
-description: "[Devflow] Audits error handling, logging, fallbacks, and observability for silent failures. Use after adding catch blocks, fallback logic, retry handling, optional chaining, or user-facing failure paths."
----
-
-# Silent Failure Audit
-
-Use this skill to find errors that disappear, get logged without user impact, or fall back in ways that make failures hard to debug.
-
-## Core Rule
-
-Every important failure must be visible to the right audience: logged with context for maintainers, surfaced with actionable guidance for users, or intentionally propagated to a caller that can handle it.
-
-## When To Use
-
-- Code adds or changes try/catch, `.catch`, callbacks, result handling, or retry logic.
-- A fallback, default value, mock, optional chaining, or null coalescing branch could hide a failure.
-- A reviewer needs to assess whether error handling is observable and actionable.
-- A production incident involved confusing, missing, or misleading errors.
-
-## Audit Scope
-
-Review:
-
-- Empty or broad catch blocks.
-- Logs that omit operation, identifiers, input shape, or original error.
-- User-facing failures with vague or unactionable messages.
-- Fallbacks that silently substitute data or behavior.
-- Retry exhaustion paths.
-- Optional chaining or default values that mask required data.
-
-## Failure Patterns
-
-| Pattern | Severity | Why it matters |
-|---|---|---|
-| Empty catch block | Critical | The failure vanishes completely. |
-| Log and continue with no user signal | High | Operators may see logs, but users think the action worked. |
-| Silent default/null return | High | Callers cannot distinguish no data from failed data. |
-| Broad catch-all around unrelated work | High | Unexpected bugs are converted into normal control flow. |
-| Fallback without explicit visibility | Medium | Users and maintainers cannot tell degraded mode is active. |
-| Generic message only | Medium | Users cannot recover and maintainers lack breadcrumbs. |
-
-## Output Format
-
-```markdown
-## Silent Failure Audit: [Scope]
-
-### Scope
-- **Reviewing**: [PR diff / file / feature]
-- **Error handlers found**: [count]
-- **Files**: [files]
-
-### Findings
-#### [Severity] [Title]
-**Location**: `path/file.ts:45`
-**Pattern**: [Empty catch / silent fallback / generic message]
-**Problem**: [What is hidden]
-**User or operator impact**: [Concrete impact]
-**Required fix**: [Specific behavior/logging/message/propagation change]
-
-### Positive Patterns
-- `path/file.ts:88` logs operation context and surfaces an actionable user message.
-
-### Verdict
-[Pass / Needs fixes / Critical issues]
-```
-
-## Verification
-
-- Every critical or high finding identifies the hidden failure and concrete user/operator impact.
-- Required fixes preserve useful context from the original error.
-- Fallbacks are documented, observable, and intentional.
-- Passing audits mention the positive patterns that justify the pass.

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

@@ -1,91 +0,0 @@
----
-name: spec-orchestration
-description: "[Devflow] 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

@@ -1,107 +0,0 @@
----
-name: specialist-agent-routing
-description: "[Devflow] 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