@jakkrichm/create-nexus-devflow 2.0.0

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

@@ -0,0 +1,311 @@
+---
+name: shipping-and-launch
+description: 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

@@ -0,0 +1,73 @@
+---
+name: silent-failure-audit
+description: 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/simplify/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: simplify
+description: Simplify workflow
+---
+
+---
+description: Simplify code for clarity and maintainability while preserving behavior.
+---
+
+# Simplify - Code Simplification And Refactoring
+
+Invoke the `code-simplification` skill.
+
+Primary behavior already lives in:
+
+```text
+.agents/skills/code-simplification/SKILL.md
+```
+
+Treat this workflow file as a wrapper around that skill.
+
+Use this workflow when the code works but has grown harder to read, harder to change, or more general than necessary.
+
+In DevFlow 2.0, `Simplify` is a supporting implementation workflow. It usually pairs with `/40-Implement` and should end in `/50-Verify`.
+
+## Process
+
+1. Read project instructions and study local conventions.
+2. Identify the target code: recent changes unless a broader scope is specified.
+3. Understand purpose, callers, edge cases, and test coverage before touching it.
+4. Scan for simplification opportunities:
+   - deep nesting to guard clauses or extracted helpers
+   - long functions to responsibility-based splits
+   - nested ternaries to clearer control flow
+   - vague names to descriptive names
+   - duplicated logic to shared helpers
+   - dead code to removal after confirmation
+   - speculative abstraction to simpler concrete flow
+5. Inspect `.agent/resources/schemas/refactoring.template.md` before generating a report.
+6. Apply each simplification incrementally and run verification after each meaningful change.
+7. Save the refactoring report to:
+
+```text
+devflow/reports/{date}-refactoring-{slug}.md
+```
+
+8. Verify tests pass, the build succeeds, and the diff stays behavior-preserving.
+
+If tests fail after a simplification, revert that specific change and reconsider.
+
+## Output
+
+Return:
+
+- what was simplified
+- what was intentionally left alone
+- validation evidence
+- remaining risks or debt
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: `/40-Implement`, `/50-Verify`, `PR-Review`, `Agent`
+- Typical handoff targets: `/40-Implement`, `/50-Verify`, `PR-Review`
+
+## Sources
+
+- `AGENTS.md`
+- `.agents/skills/code-simplification/SKILL.md`
+- `.agent/resources/schemas/refactoring.template.md`
+- Related commands: `/40-Implement`, `/50-Verify`, `PR-Review`, `Agent`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/50-Verify`
+- **Why**: simplification should finish with explicit proof that behavior did not regress
+- **Alternative**: `/40-Implement` when simplification exposed a deeper implementation change rather than a pure refactor
+

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

@@ -0,0 +1,86 @@
+---
+name: skill-development
+description: 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.