devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-core-skills/skills/input-validation/references/violations.md

@@ -1,224 +0,0 @@
-# Input Validation Violations
-
-Extended examples of validation violations to detect and fix.
-
-## Manual Validation Anti-Pattern
-
-```typescript
-// VIOLATION: Manual validation scatters checks
-function createUser(data: any): User {
-  if (!data.email || typeof data.email !== 'string') {
-    throw new Error('Invalid email');
-  }
-  if (!data.age || typeof data.age !== 'number' || data.age < 0) {
-    throw new Error('Invalid age');
-  }
-  if (!data.name || data.name.length > 100) {
-    throw new Error('Invalid name');
-  }
-  // ... more manual checks
-
-  return { email: data.email, age: data.age, name: data.name };
-}
-```
-
-**Problems**:
-- Scattered validation logic
-- Easy to miss edge cases
-- No type inference
-- Inconsistent error handling
-- Hard to maintain
-
----
-
-## Missing API Boundary Validation
-
-```typescript
-// VIOLATION: No validation at API boundary
-app.post('/api/users', async (req, res) => {
-  const user = await createUser(req.body); // Trusting external data!
-  res.json(user);
-});
-```
-
-**Security Risk**: HIGH - Injection attacks, data corruption possible
-
----
-
-## Trusting External API Responses
-
-```typescript
-// VIOLATION: Trusting external API response
-async function fetchUserData(userId: string): Promise<UserData> {
-  const response = await fetch(`https://api.example.com/users/${userId}`);
-  const data = await response.json();
-  return data; // No validation!
-}
-```
-
-**Risk**: Application crash if API changes structure, type safety lost
-
----
-
-## Unvalidated Environment Variables
-
-```typescript
-// VIOLATION: Trusting environment variables
-const config = {
-  port: process.env.PORT,           // Could be undefined or invalid
-  dbUrl: process.env.DATABASE_URL,  // No validation
-  apiKey: process.env.API_KEY       // Could be empty or malformed
-};
-```
-
-**Risk**: Runtime crashes, security issues from malformed config
-
----
-
-## SQL Injection Vulnerabilities
-
-```typescript
-// VIOLATION: Direct string interpolation (SQL injection risk)
-async function getUserByEmail(email: string): Promise<User> {
-  const query = `SELECT * FROM users WHERE email = '${email}'`;
-  return db.query(query);
-}
-
-// VIOLATION: No input validation before query
-async function searchUsers(searchTerm: string): Promise<User[]> {
-  return db.query('SELECT * FROM users WHERE name LIKE $1', [`%${searchTerm}%`]);
-}
-```
-
-**Security Risk**: CRITICAL - SQL injection allows data theft, modification, deletion
-
----
-
-## File Upload Without Validation
-
-```typescript
-// VIOLATION: Accepting any file upload
-app.post('/upload', async (req, res) => {
-  const file = req.files.document;
-  await file.mv(`./uploads/${file.name}`);  // No validation!
-  res.send('Uploaded');
-});
-```
-
-**Risks**:
-- Arbitrary file execution
-- Path traversal attacks
-- Storage exhaustion
-- Malware upload
-
----
-
-## URL Parameter Injection
-
-```typescript
-// VIOLATION: Unvalidated path parameters
-app.get('/users/:id', async (req, res) => {
-  const user = await db.users.findById(req.params.id);  // No validation!
-  res.json(user);
-});
-
-// VIOLATION: Unvalidated query parameters
-app.get('/search', async (req, res) => {
-  const results = await db.search(req.query.q);  // No validation!
-  res.json(results);
-});
-```
-
-**Risks**: NoSQL injection, type coercion attacks, DoS via crafted input
-
----
-
-## Header-Based Logic Without Validation
-
-```typescript
-// VIOLATION: Trusting request headers
-app.use((req, res, next) => {
-  const userId = req.headers['x-user-id'];
-  req.userId = userId;  // No validation!
-  next();
-});
-
-// VIOLATION: Trusting JWT without proper validation
-app.use((req, res, next) => {
-  const token = req.headers.authorization?.split(' ')[1];
-  const decoded = jwt.decode(token);  // decode != verify!
-  req.user = decoded;
-  next();
-});
-```
-
-**Risks**: Authentication bypass, privilege escalation
-
----
-
-## Webhook Payload Vulnerabilities
-
-```typescript
-// VIOLATION: Trusting webhook payloads
-app.post('/webhook', async (req, res) => {
-  const event = req.body;
-  await processPaymentEvent(event);  // No signature verification!
-  res.sendStatus(200);
-});
-```
-
-**Risks**: Spoofed events, unauthorized actions, data manipulation
-
----
-
-## GraphQL Input Vulnerabilities
-
-```typescript
-// VIOLATION: No depth/complexity limits
-const schema = buildSchema(`
-  type Query {
-    users(filter: UserFilter): [User]
-  }
-`);
-
-// No validation on nested input
-resolvers.Query.users = (_, { filter }) => {
-  return db.users.find(filter);  // filter passed directly to DB!
-};
-```
-
-**Risks**: Query complexity attacks, injection through nested objects
-
----
-
-## Form Data Without Sanitization
-
-```typescript
-// VIOLATION: Rendering user input without sanitization
-app.post('/profile', async (req, res) => {
-  const bio = req.body.bio;
-  await db.users.update({ bio });  // Stored XSS!
-  res.send(`Profile updated: ${bio}`);  // Reflected XSS!
-});
-```
-
-**Risks**: Cross-site scripting (XSS), stored attacks
-
----
-
-## Detection Patterns
-
-When reviewing code, look for these red flags:
-
-| Pattern | Risk Level |
-|---------|------------|
-| `req.body` without schema validation | HIGH |
-| `req.params` used directly | MEDIUM |
-| `req.query` used directly | MEDIUM |
-| `process.env` without validation | MEDIUM |
-| String interpolation in SQL | CRITICAL |
-| `JSON.parse` without schema | HIGH |
-| `eval()` or `Function()` with user input | CRITICAL |
-| File operations with user-provided paths | CRITICAL |
-| `jwt.decode` instead of `jwt.verify` | CRITICAL |
-| Missing webhook signature verification | HIGH |

package/plugins/devflow-core-skills/skills/search-first/SKILL.md

@@ -1,133 +0,0 @@
----
-name: search-first
-description: >-
-  This skill should be used when the user asks to "add a utility", "create a helper",
-  "implement parsing", "build a wrapper", or writes infrastructure/utility code that
-  may already exist as a well-maintained package. Enforces research before building.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Search-First
-
-Research before building. Check if a battle-tested solution exists before writing custom utility code.
-
-## Iron Law
-
-> **RESEARCH BEFORE BUILDING**
->
-> Never write custom utility code without first checking if a battle-tested solution
-> exists. The best code is code you don't write. A maintained package with thousands
-> of users will always beat a hand-rolled utility in reliability, edge cases, and
-> long-term maintenance.
-
-## When This Skill Activates
-
-**Triggers** — creating or modifying code that:
-- Parses, formats, or validates data (dates, URLs, emails, UUIDs, etc.)
-- Implements common algorithms (sorting, diffing, hashing, encoding)
-- Wraps HTTP clients, retries, rate limiting, caching
-- Handles file system operations beyond basic read/write
-- Implements CLI argument parsing, logging, or configuration
-- Creates test utilities (mocking, fixtures, assertions)
-
-**Does NOT trigger** for:
-- Domain-specific business logic unique to this project
-- Glue code connecting existing components
-- Trivial operations (< 5 lines, single-use)
-- Code that intentionally avoids external dependencies (e.g., zero-dep libraries)
-
----
-
-## Research Process
-
-### Phase 1: Need Analysis
-
-Before searching, define what you actually need:
-
-```
-Need: {one-sentence description of the capability}
-Constraints: {runtime, bundle size, license, zero-dep requirement}
-Must-haves: {non-negotiable requirements}
-Nice-to-haves: {optional features}
-```
-
-### Phase 2: Search
-
-Delegate research to an Explore subagent to keep main session context clean.
-
-**Spawn an Explore agent** with this prompt template:
-
-```
-Task(subagent_type="Explore"):
-"Research existing solutions for: {need description}
-
-Search for:
-1. npm/PyPI/crates packages that solve this (check package.json/requirements.txt for ecosystem)
-2. Existing utilities in this codebase (grep for related function names)
-3. Framework built-ins that already handle this
-
-For each candidate, find:
-- Package name and weekly downloads (if applicable)
-- Last publish date and maintenance status
-- Bundle size / dependency count
-- API surface relevant to our need
-- License compatibility
-
-Return top 3 candidates with pros/cons, or confirm nothing suitable exists."
-```
-
-### Phase 3: Evaluate
-
-Score each candidate against evaluation criteria. See `references/evaluation-criteria.md` for the full matrix.
-
-Quick checklist:
-- [ ] Last published within 12 months
-- [ ] Weekly downloads > 1,000 (npm) or equivalent traction
-- [ ] No known vulnerabilities (check Snyk/npm audit)
-- [ ] API fits the use case without heavy wrapping
-- [ ] License compatible with project (MIT/Apache/BSD preferred)
-- [ ] Bundle size acceptable for the project context
-
-### Phase 4: Decide
-
-Choose one of four outcomes:
-
-| Decision | When | Action |
-|----------|------|--------|
-| **Adopt** | Exact match, well-maintained, good API | Install and use directly |
-| **Extend** | Partial match, needs thin wrapper | Install + write minimal adapter |
-| **Compose** | No single package fits, but 2-3 small ones combine well | Install multiple, write glue code |
-| **Build** | Nothing fits, or dependency cost exceeds value | Write custom, document why |
-
-**Document the decision** in a code comment at the usage site:
-
-```typescript
-// search-first: Adopted date-fns for date formatting (2M weekly downloads, 30KB)
-// search-first: Built custom — no package handles our specific wire format
-```
-
----
-
-## Anti-Patterns
-
-| Anti-Pattern | Correct Approach |
-|-------------|-----------------|
-| Adding a dependency for 5 lines of trivial code | Build — dependency overhead exceeds value |
-| Choosing the most popular package without checking fit | Evaluate API fit, not just popularity |
-| Wrapping a package so heavily it obscures the original | If wrapping > 50% of original API, reconsider |
-| Skipping research because "I know how to build this" | Research anyway — maintenance cost matters more than initial build |
-| Installing a massive framework for one utility function | Look for focused, single-purpose packages |
-
-## Scope Limiter
-
-This skill concerns **utility and infrastructure code** only:
-- Data transformation, validation, formatting
-- Network operations, retries, caching
-- CLI tooling, logging, configuration
-- Test utilities and helpers
-
-It does NOT apply to **domain-specific business logic** where:
-- The logic encodes unique business rules
-- No generic solution could exist
-- The code is inherently project-specific

package/plugins/devflow-core-skills/skills/search-first/references/evaluation-criteria.md

@@ -1,101 +0,0 @@
-# Search-First — Evaluation Criteria
-
-Detailed package evaluation criteria and decision matrix for the 4-outcome model.
-
-## Evaluation Matrix
-
-Score each candidate on these axes (1-5 scale):
-
-| Criterion | Weight | 1 (Poor) | 3 (Acceptable) | 5 (Excellent) |
-|-----------|--------|-----------|-----------------|----------------|
-| **Maintenance** | High | No commits in 2+ years | Active, yearly releases | Regular releases, responsive maintainer |
-| **Adoption** | Medium | < 100 weekly downloads | 1K-10K weekly downloads | > 100K weekly downloads |
-| **API Fit** | High | Needs heavy wrapping | Partial fit, thin adapter needed | Direct use, clean API |
-| **Bundle Size** | Medium | > 500KB | 50-500KB | < 50KB |
-| **Security** | High | Known vulnerabilities | No known issues, few dependencies | Audited, zero/minimal dependencies |
-| **License** | Required | GPL/AGPL (restrictive) | LGPL (conditional) | MIT/Apache/BSD (permissive) |
-
-**Minimum thresholds**: License must be compatible. Security must be ≥ 3. All others are trade-offs.
-
-## Decision Matrix
-
-### Adopt (score ≥ 20/25, API Fit ≥ 4)
-
-The package directly solves the problem with minimal integration code.
-
-**Example**: Using `zod` for schema validation — exact fit, massive adoption, tiny bundle.
-
-```
-✅ Adopt: zod v3.22
-- Maintenance: 5 (monthly releases)
-- Adoption: 5 (4M weekly downloads)
-- API Fit: 5 (direct use for all validation)
-- Bundle Size: 4 (57KB)
-- Security: 5 (zero dependencies)
-- Total: 24/25
-```
-
-### Extend (score ≥ 15/25, API Fit ≥ 2)
-
-The package handles 60-80% of the need. Write a thin adapter for the rest.
-
-**Example**: Using `got` for HTTP but wrapping it with project-specific retry and auth logic.
-
-```
-✅ Extend: got v14
-- Maintenance: 4 (active)
-- Adoption: 5 (8M weekly downloads)
-- API Fit: 3 (need custom retry wrapper)
-- Bundle Size: 3 (150KB)
-- Security: 4 (minimal deps)
-- Total: 19/25
-Adapter: ~30 lines wrapping retry + auth headers
-```
-
-### Compose (no single package fits, but small packages combine)
-
-Two or three focused packages together solve the problem better than one large framework.
-
-**Example**: `ms` (time parsing) + `p-retry` (retry logic) + `quick-lru` (caching) instead of a monolithic HTTP client framework.
-
-**Rules for Compose**:
-- Maximum 3 packages in a composition
-- Each package must be focused (single responsibility)
-- Total combined bundle < what a monolithic alternative would cost
-- Glue code should be < 50 lines
-
-### Build (nothing fits, or dependency cost > value)
-
-Write custom code when:
-- No package scores ≥ 15/25
-- The code is < 50 lines and trivial
-- Zero-dependency constraint is explicit
-- The domain is too specific for generic packages
-
-**Required**: Document why Build was chosen:
-
-```typescript
-// search-first: Built custom — our wire format uses non-standard
-// ISO-8601 extensions that no date library handles correctly.
-// Evaluated: date-fns (no custom format support), luxon (500KB overhead),
-// dayjs (close but missing timezone edge case).
-```
-
-## Ecosystem-Specific Hints
-
-### Node.js / TypeScript
-- Check npm: `https://www.npmjs.com/package/{name}`
-- Bundle size: `https://bundlephobia.com/package/{name}`
-- Check if Node.js built-ins handle it (`node:crypto`, `node:url`, `node:path`)
-
-### Python
-- Check PyPI: `https://pypi.org/project/{name}`
-- Check if stdlib handles it (`urllib`, `json`, `pathlib`, `dataclasses`)
-
-### Rust
-- Check crates.io: `https://crates.io/crates/{name}`
-- Check if std handles it
-
-### Go
-- Check pkg.go.dev
-- Go standard library is extensive — check stdlib first

package/plugins/devflow-core-skills/skills/test-driven-development/SKILL.md

@@ -1,137 +0,0 @@
----
-name: test-driven-development
-description: This skill should be used when implementing new features, fixing bugs, or writing new code. Enforces RED-GREEN-REFACTOR.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
-activation:
-  file-patterns:
-    - "**/*.ts"
-    - "**/*.tsx"
-    - "**/*.js"
-    - "**/*.jsx"
-    - "**/*.py"
-  exclude:
-    - "node_modules/**"
-    - "dist/**"
-    - "**/*.test.*"
-    - "**/*.spec.*"
----
-
-# Test-Driven Development
-
-Enforce the RED-GREEN-REFACTOR cycle for all implementation work. Tests define the design. Code satisfies the tests. Refactoring improves the design without changing behavior.
-
-## Iron Law
-
-> **TESTS FIRST, ALWAYS**
->
-> Write the failing test before the production code. No exceptions. If you catch
-> yourself writing production code without a failing test, stop immediately, delete
-> the production code, write the test, watch it fail, then write the minimum code
-> to make it pass. The test IS the specification.
-
----
-
-## The Cycle
-
-### Step 1: RED — Write a Failing Test
-
-Write a test that describes the behavior you want. Run it. Watch it fail. The failure message IS your specification.
-
-```
-Describe what the code SHOULD do, not how it does it.
-One behavior per test. One assertion per test (ideally).
-Name tests as sentences: "returns error when email is invalid"
-```
-
-**Checkpoint:** The test MUST fail before proceeding. A test that passes immediately proves nothing.
-
-### Step 2: GREEN — Write Minimum Code to Pass
-
-Write the simplest production code that makes the failing test pass. No more, no less.
-
-```
-Hardcode first if that's simplest. Generalize when the next test forces it.
-Don't write code "you'll need later." Write code the test demands NOW.
-Don't optimize. Don't refactor. Don't clean up. Just pass the test.
-```
-
-**Checkpoint:** All tests pass. If any test fails, fix it before moving on.
-
-### Step 3: REFACTOR — Improve Without Changing Behavior
-
-Now clean up. Extract helpers, rename variables, simplify logic. Tests stay green throughout.
-
-```
-Run tests after every refactoring step.
-If a test breaks during refactor, undo immediately — you changed behavior.
-Apply DRY, extract patterns, improve readability.
-```
-
-**Checkpoint:** All tests still pass. Code is clean. Repeat from Step 1 for next behavior.
-
----
-
-## Rationalization Prevention
-
-These are the excuses developers use to skip TDD. Recognize and reject them.
-
-| Excuse | Why It Feels Right | Why It's Wrong | Correct Action |
-|--------|-------------------|---------------|----------------|
-| "I'll write tests after" | Need to see the shape first | Tests ARE the shape — they define the interface before implementation exists | Write the test first |
-| "Too simple to test" | It's just a getter/setter | Getters break, defaults change, edge cases hide in "simple" code | Write it — takes 30 seconds |
-| "I'll refactor later" | Just get it working now | "Later" never comes; technical debt compounds silently | Refactor now in Step 3 |
-| "Test is too hard to write" | Setup is complex, mocking is painful | Hard-to-test code = bad design; the test is telling you the interface is wrong | Simplify the interface first |
-| "Need to see the whole picture" | Can't test what I haven't designed yet | TDD IS design; each test reveals the next piece of the interface | Let the test guide the design |
-| "Tests slow me down" | Faster to just write the code | Faster until the first regression; TDD is faster for anything > 50 lines | Trust the cycle |
-
-See `references/rationalization-prevention.md` for extended examples with code.
-
----
-
-## Process Enforcement
-
-When implementing any feature under ambient IMPLEMENT/GUIDED or IMPLEMENT/ORCHESTRATED:
-
-1. **Identify the first behavior** — What is the simplest thing this feature must do?
-2. **Write the test** — Describe that behavior as a failing test
-3. **Run the test** — Confirm it fails (RED)
-4. **Write minimum code** — Just enough to pass (GREEN)
-5. **Refactor** — Clean up while tests stay green (REFACTOR)
-6. **Repeat** — Next behavior, next test, next cycle
-
-### File Organization
-
-- Test file lives next to production file: `user.ts` → `user.test.ts`
-- Follow project's existing test conventions (Jest, Vitest, pytest, etc.)
-- Import the module under test, not internal helpers
-
-### What to Test
-
-| Test | Don't Test |
-|------|-----------|
-| Public API behavior | Private implementation details |
-| Error conditions and edge cases | Framework internals |
-| Integration points (boundaries) | Third-party library correctness |
-| State transitions | Getter/setter plumbing (unless non-trivial) |
-
----
-
-## When TDD Does Not Apply
-
-- **QUICK depth** — Ambient classified as QUICK (chat, exploration, trivial edits)
-- **Non-code tasks** — Documentation, configuration, CI changes
-- **Exploratory prototyping** — User explicitly says "just spike this" or "prototype"
-- **Existing test suite changes** — Modifying tests themselves (test-patterns skill applies instead)
-
-When skipping TDD, never rationalize. State clearly: "Skipping TDD because: [specific reason from list above]."
-
----
-
-## Integration with Ambient Mode
-
-- **IMPLEMENT/GUIDED** → TDD enforced in main session. Write the failing test before production code. Skill loaded directly.
-- **IMPLEMENT/ORCHESTRATED** → TDD enforced via Coder agent (skill in Coder frontmatter). Every implementation gets test-first treatment.
-- **IMPLEMENT/QUICK** → TDD skipped (trivial single-file edit).
-- **DEBUG/GUIDED** → TDD applies to the fix in main session: write a test that reproduces the bug first, then fix.
-- **DEBUG/ORCHESTRATED** → TDD applies to the fix: write a test that reproduces the bug first, then fix.