@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.13

package/template/.claude/skills/test-execution-and-coverage/SKILL.md

@@ -1,56 +0,0 @@
----
-name: test-execution-and-coverage
-description: "[Devflow] Generate missing tests, run existing tests, and summarize coverage and failures. Use when implementation or verification needs explicit testing evidence beyond a general TDD reminder."
----
-
-# Test Execution And Coverage
-
-## Overview
-
-This skill complements TDD by handling test generation, execution, and persistent reporting.
-
-## When to Use
-
-- During `40-implement` when tests need to be added
-- During `50-verify` when the test suite must be run and summarized
-- During `Debug` when a bug needs a reproduction test
-
-## Process
-
-### 1. Decide Test Mode
-
-- generate tests for a target
-- run the existing test suite
-- inspect coverage when the project supports it
-
-### 2. Use Project-Native Test Commands
-
-- prefer the project's real framework and real commands
-- highlight failed assertions clearly
-- distinguish test generation from test execution
-
-### 3. Save Reusable Report
-
-Write reusable output under:
-
-```text
-devflow/reports/{date}-test-report-{slug}.md
-```
-
-Use `.agent/resources/schemas/test_report.template.md` when saving a reusable report.
-
-### 4. Route Back
-
-- `50-verify` when tests support formal verification
-- `40-implement` when missing or failing tests require code changes
-- `Debug` when failures need RCA
-
-## Output
-
-Return:
-
-- what tests were generated or run
-- command output summary
-- pass/fail state
-- gaps and risks
-- recommended return stage

package/template/.claude/skills/using-agent-skills/SKILL.md

@@ -1,171 +0,0 @@
----
-name: using-agent-skills
-description: "[Devflow] Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked."
----
-
-# Using Agent Skills
-
-## Overview
-
-Agent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.
-
-## Skill Discovery
-
-When a task arrives, identify the development phase and apply the corresponding skill:
-
-```
-Task arrives
-    │
-    ├── Vague idea/need refinement? ──→ idea-refine
-    ├── New project/feature/change? ──→ spec-driven-development
-    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
-    ├── Implementing code? ────────────→ incremental-implementation
-    │   ├── UI work? ─────────────────→ frontend-ui-engineering
-    │   ├── API work? ────────────────→ api-and-interface-design
-    │   └── Need better context? ─────→ context-engineering
-    ├── Writing/running tests? ────────→ test-driven-development
-    │   └── Browser-based? ───────────→ browser-testing-with-devtools
-    ├── Something broke? ──────────────→ debugging-and-error-recovery
-    ├── Reviewing code? ───────────────→ code-review-and-quality
-    │   ├── Security concerns? ───────→ security-and-hardening
-    │   └── Performance concerns? ────→ performance-optimization
-    ├── Committing/branching? ─────────→ git-workflow-and-versioning
-    ├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
-    ├── Writing docs/ADRs? ───────────→ documentation-and-adrs
-    └── Deploying/launching? ─────────→ shipping-and-launch
-```
-
-## Core Operating Behaviors
-
-These behaviors apply at all times, across all skills. They are non-negotiable.
-
-### 1. Surface Assumptions
-
-Before implementing anything non-trivial, explicitly state your assumptions:
-
-```
-ASSUMPTIONS I'M MAKING:
-1. [assumption about requirements]
-2. [assumption about architecture]
-3. [assumption about scope]
-→ Correct me now or I'll proceed with these.
-```
-
-Don't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.
-
-### 2. Manage Confusion Actively
-
-When you encounter inconsistencies, conflicting requirements, or unclear specifications:
-
-1. **STOP.** Do not proceed with a guess.
-2. Name the specific confusion.
-3. Present the tradeoff or ask the clarifying question.
-4. Wait for resolution before continuing.
-
-**Bad:** Silently picking one interpretation and hoping it's right.
-**Good:** "I see X in the spec but Y in the existing code. Which takes precedence?"
-
-### 3. Push Back When Warranted
-
-You are not a yes-machine. When an approach has clear problems:
-
-- Point out the issue directly
-- Explain the concrete downside (quantify when possible — "this adds ~200ms latency" not "this might be slower")
-- Propose an alternative
-- Accept the human's decision if they override with full information
-
-Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
-
-### 4. Enforce Simplicity
-
-Your natural tendency is to overcomplicate. Actively resist it.
-
-Before finishing any implementation, ask:
-- Can this be done in fewer lines?
-- Are these abstractions earning their complexity?
-- Would a staff engineer look at this and say "why didn't you just..."?
-
-If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
-
-### 5. Maintain Scope Discipline
-
-Touch only what you're asked to touch.
-
-Do NOT:
-- Remove comments you don't understand
-- "Clean up" code orthogonal to the task
-- Refactor adjacent systems as a side effect
-- Delete code that seems unused without explicit approval
-- Add features not in the spec because they "seem useful"
-
-Your job is surgical precision, not unsolicited renovation.
-
-### 6. Verify, Don't Assume
-
-Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence (passing tests, build output, runtime data).
-
-## Failure Modes to Avoid
-
-These are the subtle errors that look like productivity but create problems:
-
-1. Making wrong assumptions without checking
-2. Not managing your own confusion — plowing ahead when lost
-3. Not surfacing inconsistencies you notice
-4. Not presenting tradeoffs on non-obvious decisions
-5. Being sycophantic ("Of course!") to approaches with clear problems
-6. Overcomplicating code and APIs
-7. Modifying code or comments orthogonal to the task
-8. Removing things you don't fully understand
-9. Building without a spec because "it's obvious"
-10. Skipping verification because "it looks right"
-
-## Skill Rules
-
-1. **Check for an applicable skill before starting work.** Skills encode processes that prevent common mistakes.
-
-2. **Skills are workflows, not suggestions.** Follow the steps in order. Don't skip verification steps.
-
-3. **Multiple skills can apply.** A feature implementation might involve `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `shipping-and-launch` in sequence.
-
-4. **When in doubt, start with a spec.** If the task is non-trivial and there's no spec, begin with `spec-driven-development`.
-
-## Lifecycle Sequence
-
-For a complete feature, the typical skill sequence is:
-
-```
-1. idea-refine                 → Refine vague ideas
-2. spec-driven-development     → Define what we're building
-3. planning-and-task-breakdown → Break into verifiable chunks
-4. context-engineering         → Load the right context
-5. incremental-implementation  → Build slice by slice
-6. test-driven-development     → Prove each slice works
-7. code-review-and-quality     → Review before merge
-8. git-workflow-and-versioning → Clean commit history
-9. documentation-and-adrs      → Document decisions
-10. shipping-and-launch        → Deploy safely
-```
-
-Not every task needs every skill. A bug fix might only need: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.
-
-## Quick Reference
-
-| Phase | Skill | One-Line Summary |
-|-------|-------|-----------------|
-| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |
-| Define | spec-driven-development | Requirements and acceptance criteria before code |
-| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |
-| Build | incremental-implementation | Thin vertical slices, test each before expanding |
-| Build | context-engineering | Right context at the right time |
-| Build | frontend-ui-engineering | Production-quality UI with accessibility |
-| Build | api-and-interface-design | Stable interfaces with clear contracts |
-| Verify | test-driven-development | Failing test first, then make it pass |
-| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |
-| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |
-| Review | code-review-and-quality | Five-axis review with quality gates |
-| Review | security-and-hardening | OWASP prevention, input validation, least privilege |
-| Review | performance-optimization | Measure first, optimize only what matters |
-| Ship | git-workflow-and-versioning | Atomic commits, clean history |
-| Ship | ci-cd-and-automation | Automated quality gates on every change |
-| Ship | documentation-and-adrs | Document the why, not just the what |
-| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |

package/template/.claude/skills/verification-orchestration/SKILL.md

@@ -1,68 +0,0 @@
----
-name: verification-orchestration
-description: "[Devflow] Coordinate multi-lane QA, specialist review, test planning, and verification follow-up. Use when 50-verify needs more structure than a single pass and the team needs a QA matrix or specialist routing."
----
-
-# Verification Orchestration
-
-## Overview
-
-This skill structures complex verification work across multiple QA lanes without replacing the main verification stage.
-
-## When to Use
-
-- `50-verify` is too broad for a single simple pass
-- the change needs correctness, regression, security, performance, and UX checks together
-- the team needs specialist routing for QA
-
-## Process
-
-### 1. Validate The Verification Context
-
-- inspect the owning stage artifacts first
-- confirm what implementation scope is actually under review
-- keep markdown stage artifacts as the source of truth
-
-### 2. Choose QA Lanes
-
-Typical lanes:
-
-- correctness and acceptance criteria
-- tests and regressions
-- security and data safety
-- performance and scalability
-- UX or manual verification
-- codebase fit and maintainability
-
-### 3. Route Specialist Help
-
-Use specialist agents only when needed, such as:
-
-- `code-reviewer`
-- `test-engineer`
-- `security-auditor`
-
-### 4. Save Reusable Report
-
-Write reusable output under:
-
-```text
-devflow/reports/{date}-qa-orchestrate-{id}.md
-```
-
-Use `.agent/resources/schemas/qa_orchestration.template.md` when saving a reusable report.
-
-### 5. Route Back
-
-- `50-verify` when the QA matrix strengthens verification evidence
-- `40-implement` when actionable fixes are required
-- `Followup` when findings become new scope
-
-## Output
-
-Return:
-
-- QA lanes used
-- specialist recommendations
-- findings and blockers
-- recommended return stage

package/template/.claude/skills/vulnerability-scanner/SKILL.md

@@ -1,276 +0,0 @@
----
-name: vulnerability-scanner
-description: "[Devflow] Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization."
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Vulnerability Scanner
-
-> Think like an attacker, defend like an expert. 2025 threat landscape awareness.
-
-## 🔧 Runtime Scripts
-
-**Execute for automated validation:**
-
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/security_scan.py` | Validate security principles applied | `python scripts/security_scan.py <project_path>` |
-
-## 📋 Reference Files
-
-| File | Purpose |
-|------|---------|
-| [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists |
-
----
-
-## 1. Security Expert Mindset
-
-### Core Principles
-
-| Principle | Application |
-|-----------|-------------|
-| **Assume Breach** | Design as if attacker already inside |
-| **Zero Trust** | Never trust, always verify |
-| **Defense in Depth** | Multiple layers, no single point |
-| **Least Privilege** | Minimum required access only |
-| **Fail Secure** | On error, deny access |
-
-### Threat Modeling Questions
-
-Before scanning, ask:
-1. What are we protecting? (Assets)
-2. Who would attack? (Threat actors)
-3. How would they attack? (Attack vectors)
-4. What's the impact? (Business risk)
-
----
-
-## 2. OWASP Top 10:2025
-
-### Risk Categories
-
-| Rank | Category | Think About |
-|------|----------|-------------|
-| **A01** | Broken Access Control | Who can access what? IDOR, SSRF |
-| **A02** | Security Misconfiguration | Defaults, headers, exposed services |
-| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity |
-| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |
-| **A05** | Injection | User input → system commands |
-| **A06** | Insecure Design | Flawed architecture |
-| **A07** | Authentication Failures | Session, credential management |
-| **A08** | Integrity Failures | Unsigned updates, tampered data |
-| **A09** | Logging & Alerting | Blind spots, no monitoring |
-| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |
-
-### 2025 Key Changes
-
-```
-2021 → 2025 Shifts:
-├── SSRF merged into A01 (Access Control)
-├── A02 elevated (Cloud/Container configs)
-├── A03 NEW: Supply Chain (major focus)
-├── A10 NEW: Exceptional Conditions
-└── Focus shift: Root causes > Symptoms
-```
-
----
-
-## 3. Supply Chain Security (A03)
-
-### Attack Surface
-
-| Vector | Risk | Question to Ask |
-|--------|------|-----------------|
-| **Dependencies** | Malicious packages | Do we audit new deps? |
-| **Lock files** | Integrity attacks | Are they committed? |
-| **Build pipeline** | CI/CD compromise | Who can modify? |
-| **Registry** | Typosquatting | Verified sources? |
-
-### Defense Principles
-
-- Verify package integrity (checksums)
-- Pin versions, audit updates
-- Use private registries for critical deps
-- Sign and verify artifacts
-
----
-
-## 4. Attack Surface Mapping
-
-### What to Map
-
-| Category | Elements |
-|----------|----------|
-| **Entry Points** | APIs, forms, file uploads |
-| **Data Flows** | Input → Process → Output |
-| **Trust Boundaries** | Where auth/authz checked |
-| **Assets** | Secrets, PII, business data |
-
-### Prioritization Matrix
-
-```
-Risk = Likelihood × Impact
-
-High Impact + High Likelihood → CRITICAL
-High Impact + Low Likelihood  → HIGH
-Low Impact + High Likelihood  → MEDIUM
-Low Impact + Low Likelihood   → LOW
-```
-
----
-
-## 5. Risk Prioritization
-
-### CVSS + Context
-
-| Factor | Weight | Question |
-|--------|--------|----------|
-| **CVSS Score** | Base severity | How severe is the vuln? |
-| **EPSS Score** | Exploit likelihood | Is it being exploited? |
-| **Asset Value** | Business context | What's at risk? |
-| **Exposure** | Attack surface | Internet-facing? |
-
-### Prioritization Decision Tree
-
-```
-Is it actively exploited (EPSS >0.5)?
-├── YES → CRITICAL: Immediate action
-└── NO → Check CVSS
-         ├── CVSS ≥9.0 → HIGH
-         ├── CVSS 7.0-8.9 → Consider asset value
-         └── CVSS <7.0 → Schedule for later
-```
-
----
-
-## 6. Exceptional Conditions (A10 - New)
-
-### Fail-Open vs Fail-Closed
-
-| Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) |
-|----------|-----------------|---------------------|
-| Auth error | Allow access | Deny access |
-| Parsing fails | Accept input | Reject input |
-| Timeout | Retry forever | Limit + abort |
-
-### What to Check
-
-- Exception handlers that catch-all and ignore
-- Missing error handling on security operations
-- Race conditions in auth/authz
-- Resource exhaustion scenarios
-
----
-
-## 7. Scanning Methodology
-
-### Phase-Based Approach
-
-```
-1. RECONNAISSANCE
-   └── Understand the target
-       ├── Technology stack
-       ├── Entry points
-       └── Data flows
-
-2. DISCOVERY
-   └── Identify potential issues
-       ├── Configuration review
-       ├── Dependency analysis
-       └── Code pattern search
-
-3. ANALYSIS
-   └── Validate and prioritize
-       ├── False positive elimination
-       ├── Risk scoring
-       └── Attack chain mapping
-
-4. REPORTING
-   └── Actionable findings
-       ├── Clear reproduction steps
-       ├── Business impact
-       └── Remediation guidance
-```
-
----
-
-## 8. Code Pattern Analysis
-
-### High-Risk Patterns
-
-| Pattern | Risk | Look For |
-|---------|------|----------|
-| **String concat in queries** | Injection | `"SELECT * FROM " + user_input` |
-| **Dynamic code execution** | RCE | `eval()`, `exec()`, `Function()` |
-| **Unsafe deserialization** | RCE | `pickle.loads()`, `unserialize()` |
-| **Path manipulation** | Traversal | User input in file paths |
-| **Disabled security** | Various | `verify=False`, `--insecure` |
-
-### Secret Patterns
-
-| Type | Indicators |
-|------|-----------|
-| API Keys | `api_key`, `apikey`, high entropy |
-| Tokens | `token`, `bearer`, `jwt` |
-| Credentials | `password`, `secret`, `key` |
-| Cloud | `AWS_`, `AZURE_`, `GCP_` prefixes |
-
----
-
-## 9. Cloud Security Considerations
-
-### Shared Responsibility
-
-| Layer | You Own | Provider Owns |
-|-------|---------|---------------|
-| Data | ✅ | ❌ |
-| Application | ✅ | ❌ |
-| OS/Runtime | Depends | Depends |
-| Infrastructure | ❌ | ✅ |
-
-### Cloud-Specific Checks
-
-- IAM: Least privilege applied?
-- Storage: Public buckets?
-- Network: Security groups tightened?
-- Secrets: Using secrets manager?
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Scan without understanding | Map attack surface first |
-| Alert on every CVE | Prioritize by exploitability + asset |
-| Ignore false positives | Maintain verified baseline |
-| Fix symptoms only | Address root causes |
-| Scan once before deploy | Continuous scanning |
-| Trust third-party deps blindly | Verify integrity, audit code |
-
----
-
-## 11. Reporting Principles
-
-### Finding Structure
-
-Each finding should answer:
-1. **What?** - Clear vulnerability description
-2. **Where?** - Exact location (file, line, endpoint)
-3. **Why?** - Root cause explanation
-4. **Impact?** - Business consequence
-5. **How to fix?** - Specific remediation
-
-### Severity Classification
-
-| Severity | Criteria |
-|----------|----------|
-| **Critical** | RCE, auth bypass, mass data exposure |
-| **High** | Data exposure, privilege escalation |
-| **Medium** | Limited scope, requires conditions |
-| **Low** | Informational, best practice |
-
----
-
-> **Remember:** Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"

package/template/.claude/skills/vulnerability-scanner/checklists.md

@@ -1,121 +0,0 @@
-# Security Checklists
-
-> Quick reference checklists for security audits. Use alongside vulnerability-scanner principles.
-
----
-
-## OWASP Top 10 Audit Checklist
-
-### A01: Broken Access Control
-- [ ] Authorization on all protected routes
-- [ ] Deny by default
-- [ ] Rate limiting implemented
-- [ ] CORS properly configured
-
-### A02: Cryptographic Failures
-- [ ] Passwords hashed (bcrypt/argon2, cost 12+)
-- [ ] Sensitive data encrypted at rest
-- [ ] TLS 1.2+ for all connections
-- [ ] No secrets in code/logs
-
-### A03: Injection
-- [ ] Parameterized queries
-- [ ] Input validation on all user data
-- [ ] Output encoding for XSS
-- [ ] No eval() or dynamic code execution
-
-### A04: Insecure Design
-- [ ] Threat modeling done
-- [ ] Security requirements defined
-- [ ] Business logic validated
-
-### A05: Security Misconfiguration
-- [ ] Unnecessary features disabled
-- [ ] Error messages sanitized
-- [ ] Security headers configured
-- [ ] Default credentials changed
-
-### A06: Vulnerable Components
-- [ ] Dependencies up to date
-- [ ] No known vulnerabilities
-- [ ] Unused dependencies removed
-
-### A07: Authentication Failures
-- [ ] MFA available
-- [ ] Session invalidation on logout
-- [ ] Session timeout implemented
-- [ ] Brute force protection
-
-### A08: Integrity Failures
-- [ ] Dependency integrity verified
-- [ ] CI/CD pipeline secured
-- [ ] Update mechanism secured
-
-### A09: Logging Failures
-- [ ] Security events logged
-- [ ] Logs protected
-- [ ] No sensitive data in logs
-- [ ] Alerting configured
-
-### A10: SSRF
-- [ ] URL validation implemented
-- [ ] Allow-list for external calls
-- [ ] Network segmentation
-
----
-
-## Authentication Checklist
-
-- [ ] Strong password policy
-- [ ] Account lockout
-- [ ] Secure password reset
-- [ ] Session management
-- [ ] Token expiration
-- [ ] Logout invalidation
-
----
-
-## API Security Checklist
-
-- [ ] Authentication required
-- [ ] Authorization per endpoint
-- [ ] Input validation
-- [ ] Rate limiting
-- [ ] Output sanitization
-- [ ] Error handling
-
----
-
-## Data Protection Checklist
-
-- [ ] Encryption at rest
-- [ ] Encryption in transit
-- [ ] Key management
-- [ ] Data minimization
-- [ ] Secure deletion
-
----
-
-## Security Headers
-
-| Header | Purpose |
-|--------|---------|
-| **Content-Security-Policy** | XSS prevention |
-| **X-Content-Type-Options** | MIME sniffing |
-| **X-Frame-Options** | Clickjacking |
-| **Strict-Transport-Security** | Force HTTPS |
-| **Referrer-Policy** | Referrer control |
-
----
-
-## Quick Audit Commands
-
-| Check | What to Look For |
-|-------|------------------|
-| Secrets in code | password, api_key, secret |
-| Dangerous patterns | eval, innerHTML, SQL concat |
-| Dependency issues | npm audit, snyk |
-
----
-
-> **Usage:** Copy relevant checklists into your PLAN.md or security report.