devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-code-review/skills/consistency-patterns/SKILL.md

@@ -1,140 +0,0 @@
----
-name: consistency-patterns
-description: This skill should be used when reviewing code for naming convention violations, pattern deviations, or inconsistent API styles.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Consistency Patterns
-
-Domain expertise for code consistency and unnecessary simplification detection. Use alongside `review-methodology` for complete consistency reviews.
-
-## Iron Law
-
-> **MATCH EXISTING PATTERNS OR JUSTIFY DEVIATION**
->
-> New code should look like existing code. If the codebase uses camelCase, use camelCase.
-> If errors return Result types, return Result types. Consistency trumps personal preference.
-> Deviation requires explicit justification and team agreement. One codebase, one style.
-
----
-
-## Consistency Categories
-
-### 1. Unnecessary Simplification
-
-Content truncation, stripped configuration, removed error context.
-
-```typescript
-// VIOLATION: Oversimplified error messages
-const errorMessages = {
-  INVALID_EMAIL: 'Invalid email',  // Was: detailed format guidance
-  USER_NOT_FOUND: 'Not found',     // Was: helpful next steps
-};
-
-// CORRECT: Preserve helpful context
-const errorMessages = {
-  INVALID_EMAIL: 'Please enter a valid email address in the format user@domain.com',
-  USER_NOT_FOUND: 'We could not find an account with that email. Please check or create a new account.',
-};
-```
-
-### 2. Pattern Violations
-
-Naming conventions, error handling styles, import/export organization.
-
-```typescript
-// EXISTING PATTERN: Result types
-function existingFunction(): Result<User, Error> {
-  if (!valid) return Err(new ValidationError('...'));
-  return Ok(user);
-}
-
-// VIOLATION: Throws instead of Result
-function newFunction(): User {
-  if (!valid) throw new Error('...');  // Different pattern!
-  return user;
-}
-
-// CORRECT: Match existing
-function newFunction(): Result<User, Error> {
-  if (!valid) return Err(new ValidationError('...'));
-  return Ok(user);
-}
-```
-
-### 3. Feature Regression
-
-Removed CLI options, changed return types, removed event emissions.
-
-```typescript
-// VIOLATION: Removed event emissions break listeners
-class OrderService {
-  async createOrder(data: OrderData) {
-    const order = await this.repository.create(data);
-    return order;  // Events removed - listeners won't fire!
-  }
-}
-
-// CORRECT: Preserve all event emissions
-class OrderService {
-  async createOrder(data: OrderData) {
-    const order = await this.repository.create(data);
-    this.events.emit('order.created', order);
-    this.events.emit('inventory.reserve', order.items);
-    return order;
-  }
-}
-```
-
-### 4. Style Inconsistency
-
-Brace style, quote style, trailing commas, naming conventions.
-
-```typescript
-// EXISTING: camelCase for functions
-function getUserById(id: string) { }
-function createOrder(data: OrderData) { }
-
-// VIOLATION: Different naming style
-function Process_Payment(amount: number) { }  // snake_case
-
-// CORRECT: Match existing
-function processPayment(amount: number) { }
-```
-
----
-
-## Extended References
-
-For extended examples and detection commands, see:
-
-- `references/violations.md` - Extended violation examples by category
-- `references/patterns.md` - Extended correct pattern examples
-- `references/detection.md` - Bash commands for detecting issues
-
----
-
-## Severity Guidelines
-
-| Severity | Description | Examples |
-|----------|-------------|----------|
-| **CRITICAL** | Breaking changes or significant content loss | API return types changed, CLI options removed, events removed |
-| **HIGH** | Inconsistency requiring attention | Error handling pattern mismatch, naming violations, export pattern change |
-| **MEDIUM** | Style inconsistency | Import organization, brace/quote style, formatting differences |
-| **LOW** | Minor observations | Personal preference territory, linter should catch |
-
----
-
-## Consistency Checklist
-
-Before approving changes, verify:
-
-- [ ] Naming matches existing patterns (camelCase, PascalCase, etc.)
-- [ ] Error handling matches existing approach (throw vs Result)
-- [ ] Import organization matches existing files
-- [ ] Export style matches existing modules
-- [ ] No user-facing content was unnecessarily shortened
-- [ ] No configuration options were silently removed
-- [ ] No CLI flags/options were removed without deprecation
-- [ ] All removed functionality has explicit justification

package/plugins/devflow-code-review/skills/database-patterns/SKILL.md

@@ -1,134 +0,0 @@
----
-name: database-patterns
-description: This skill should be used when reviewing database queries, migrations, indexes, or schema changes.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Database Patterns
-
-Domain expertise for database design and optimization. Use alongside `review-methodology` for complete database reviews.
-
-## Iron Law
-
-> **EVERY QUERY MUST HAVE AN EXECUTION PLAN**
->
-> Never deploy a query without understanding its execution plan. Every WHERE clause needs
-> an index analysis. Every JOIN needs cardinality consideration. "It works in dev" is not
-> validation. Production data volumes will expose every missing index and inefficient join.
-
-## Database Categories
-
-### 1. Schema Design Issues
-
-| Issue | Problem | Solution |
-|-------|---------|----------|
-| Missing Foreign Keys | No referential integrity, orphaned records | Add FK with ON DELETE action |
-| Denormalization | Unnecessary duplication, update anomalies | Normalize unless performance requires |
-| Poor Data Types | VARCHAR for everything, lost precision | Use appropriate types (DECIMAL, BOOLEAN, TIMESTAMP) |
-| Missing Constraints | No data validation at DB level | Add NOT NULL, CHECK, UNIQUE constraints |
-
-**Example - Missing Constraints:**
-```sql
--- VIOLATION
-CREATE TABLE products (id SERIAL, name VARCHAR(100), price DECIMAL);
-
--- CORRECT
-CREATE TABLE products (
-  id SERIAL PRIMARY KEY,
-  name VARCHAR(100) NOT NULL CHECK (LENGTH(TRIM(name)) > 0),
-  price DECIMAL(10, 2) NOT NULL CHECK (price >= 0)
-);
-```
-
-### 2. Query Optimization Issues
-
-| Issue | Problem | Solution |
-|-------|---------|----------|
-| N+1 Queries | Query per iteration, O(n) round trips | JOIN or batch with IN/ANY |
-| Missing Indexes | Full table scans on large tables | Add indexes for WHERE/JOIN columns |
-| Full Table Scans | Functions prevent index use | Functional indexes or query rewrite |
-| Inefficient JOINs | Joining before filtering | Filter early, select specific columns |
-
-**Example - N+1 Query:**
-```typescript
-// VIOLATION: 101 queries for 100 users
-for (const user of users) {
-  user.orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [user.id]);
-}
-
-// CORRECT: 2 queries total
-const orders = await db.query('SELECT * FROM orders WHERE user_id = ANY($1)', [userIds]);
-```
-
-### 3. Migration Issues
-
-| Issue | Problem | Solution |
-|-------|---------|----------|
-| Breaking Changes | Data loss, no recovery path | Phased approach with backups |
-| Data Loss Risk | Type changes truncate data | Validate before changing types |
-| Missing Rollback | Cannot undo migration | Always implement down() method |
-| Performance Impact | Table locks during migration | Add columns nullable, backfill in batches |
-
-**Example - Safe Column Addition:**
-```sql
--- Step 1: Add nullable (instant)
-ALTER TABLE users ADD COLUMN phone VARCHAR(20);
--- Step 2: Backfill in batches
-UPDATE users SET phone = 'UNKNOWN' WHERE phone IS NULL AND id BETWEEN 1 AND 10000;
--- Step 3: Add constraint after backfill
-ALTER TABLE users ALTER COLUMN phone SET NOT NULL;
-```
-
-### 4. Security Issues
-
-| Issue | Problem | Solution |
-|-------|---------|----------|
-| SQL Injection | String interpolation in queries | Parameterized queries only |
-| Excessive Privileges | App has GRANT ALL | Minimum required privileges |
-
-**Example - SQL Injection:**
-```typescript
-// VULNERABLE
-const query = `SELECT * FROM users WHERE email = '${email}'`;
-
-// SECURE
-const query = 'SELECT * FROM users WHERE email = $1';
-await db.query(query, [email]);
-```
-
----
-
-## Extended References
-
-For detailed examples and detection commands, see:
-
-- **[references/violations.md](references/violations.md)** - Extended violation examples with explanations
-- **[references/patterns.md](references/patterns.md)** - Correct patterns and migration strategies
-- **[references/detection.md](references/detection.md)** - Automated detection commands
-
----
-
-## Severity Guidelines
-
-| Severity | Criteria | Examples |
-|----------|----------|----------|
-| **CRITICAL** | Data integrity or severe performance | SQL injection, N+1 unbounded, data loss migrations, missing FK on critical relations |
-| **HIGH** | Significant database issues | Inefficient JOINs, missing constraints, migrations without rollback |
-| **MEDIUM** | Moderate concerns | Minor denormalization, missing non-critical indexes |
-| **LOW** | Minor improvements | Naming conventions, index organization |
-
----
-
-## Database Checklist
-
-Before approving database changes:
-
-- [ ] All queries have appropriate indexes
-- [ ] N+1 patterns identified and resolved
-- [ ] Migrations have rollback scripts
-- [ ] Data types are appropriate
-- [ ] Constraints enforce business rules
-- [ ] Foreign keys maintain referential integrity
-- [ ] No SQL injection vulnerabilities
-- [ ] Performance tested with production-like data volume

package/plugins/devflow-code-review/skills/dependencies-patterns/SKILL.md

@@ -1,141 +0,0 @@
----
-name: dependencies-patterns
-description: This skill should be used when reviewing dependency changes, lock files, or package additions.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Dependencies Patterns
-
-Domain expertise for dependency management and security analysis. Use alongside `review-methodology` for complete dependency reviews.
-
-## Iron Law
-
-> **EVERY DEPENDENCY IS AN ATTACK SURFACE**
->
-> Each package you add is code you didn't write but must trust. Minimize dependencies.
-> Pin versions. Audit regularly. A single compromised transitive dependency can compromise
-> your entire application. "It's a popular package" is not a security review.
-
----
-
-## Dependency Categories
-
-### 1. Security Vulnerabilities
-
-Known CVEs, vulnerable version ranges, malicious packages.
-
-**Violation**: Wide version range includes vulnerable versions
-```json
-{ "lodash": "^4.0.0" }  // Includes vulnerable 4.17.0-4.17.20
-```
-
-**Correct**: Pin to safe version
-```json
-{ "lodash": "^4.17.21" }  // First safe version
-```
-
-### 2. Version Management
-
-Unpinned versions, missing lockfiles, dependency conflicts.
-
-**Violation**: Unpinned allows any version
-```json
-{ "express": "*", "lodash": "latest" }
-```
-
-**Correct**: Pin with lockfile
-```json
-{ "express": "^4.18.2" }  // + committed lockfile
-```
-
-### 3. Dependency Health
-
-Outdated packages, unused dependencies, unnecessary heavy packages.
-
-**Violation**: Heavy dependency for simple task
-```json
-{ "moment": "^2.29.4" }  // 300KB for date formatting
-```
-
-**Correct**: Use native or lighter alternative
-```typescript
-new Date().toLocaleDateString();  // Native
-```
-
-### 4. License Issues
-
-Incompatible licenses (GPL in MIT project), missing licenses.
-
-**Violation**: GPL in proprietary code
-```bash
-# GPL-3.0: some-package  # Requires your code to be GPL too!
-```
-
-**Correct**: Use permissive licenses only
-```bash
-npx license-checker --failOn "GPL-3.0;AGPL-3.0"
-```
-
-### 5. Supply Chain Risks
-
-Deep transitive dependencies, unmaintained packages, typosquatting.
-
-**Violation**: Typosquatted package
-```json
-{ "loadsh": "1.0.0" }  // Typosquat of "lodash"
-```
-
-**Correct**: Verify package authenticity
-```bash
-npm view loadsh  # Check downloads, repo, maintainers
-```
-
----
-
-## Extended References
-
-For extended examples and detection commands, see:
-- `references/violations.md` - Extended violation examples by category
-- `references/patterns.md` - Correct dependency management patterns
-- `references/detection.md` - Detection commands and CI integration
-
----
-
-## Severity Guidelines
-
-| Severity | Indicators |
-|----------|------------|
-| **CRITICAL** | Known exploited CVEs (CISA KEV), confirmed malicious packages, typosquats |
-| **HIGH** | High severity CVEs, unmaintained packages, GPL in proprietary code |
-| **MEDIUM** | Medium CVEs, significantly outdated, wide version ranges, missing lockfile |
-| **LOW** | Unused dependencies, lighter alternatives available, minor version behind |
-
----
-
-## Dependency Review Checklist
-
-Before approving dependency changes:
-
-- [ ] No known CVEs in added packages
-- [ ] Version ranges appropriate (not too wide)
-- [ ] Lockfile updated and committed
-- [ ] Package actively maintained
-- [ ] License compatible
-- [ ] Package from verified publisher
-- [ ] Transitive dependencies reviewed
-- [ ] Package name verified (not typosquat)
-- [ ] Bundle size impact considered
-- [ ] Native alternatives considered
-
----
-
-## Common Vulnerability Sources
-
-| Registry | URL |
-|----------|-----|
-| npm Advisory | https://www.npmjs.com/advisories |
-| Snyk Vuln DB | https://snyk.io/vuln |
-| GitHub Advisory | https://github.com/advisories |
-| NVD | https://nvd.nist.gov/ |
-| CISA KEV | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |

package/plugins/devflow-code-review/skills/documentation-patterns/SKILL.md

@@ -1,125 +0,0 @@
----
-name: documentation-patterns
-description: This skill should be used when reviewing for documentation drift, missing API docs, or stale comments.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Documentation Patterns
-
-Domain expertise for documentation quality and alignment. Use alongside `review-methodology` for complete documentation reviews.
-
-## Iron Law
-
-> **DOCUMENTATION MUST MATCH REALITY**
->
-> Outdated documentation is worse than no documentation. It actively misleads. Every code
-> change that affects behavior requires a documentation check. Comments that explain "what"
-> instead of "why" are noise. The best documentation is code that doesn't need documentation.
-
----
-
-## Documentation Categories
-
-### 1. Code Documentation Issues
-
-| Issue | Problem | Fix |
-|-------|---------|-----|
-| Missing docstrings | Complex functions without explanation | Add JSDoc with params, returns, throws |
-| Outdated comments | Comments that contradict code | Update or remove |
-| "What" comments | `// Loop through users` | Explain "why" instead |
-| Magic algorithms | Complex logic without explanation | Document algorithm and rationale |
-
-**Brief Example - Missing vs. Complete:**
-```typescript
-// BAD: No documentation on complex function
-export function calculateProratedAmount(plan: Plan, startDate: Date, endDate: Date): number;
-
-// GOOD: Purpose, params, returns, edge cases documented
-/**
- * Calculates prorated billing amount when switching plans mid-cycle.
- * @param plan - The new plan to prorate to
- * @returns Prorated amount in cents (can be negative for downgrades)
- */
-export function calculateProratedAmount(plan: Plan, startDate: Date, endDate: Date): number;
-```
-
-### 2. API Documentation Issues
-
-| Issue | Problem | Fix |
-|-------|---------|-----|
-| Missing params | Callers don't know valid values | Document all params with types and constraints |
-| Missing returns | Return shape unknown | Describe return structure and units |
-| Missing errors | Callers don't know what to catch | List all thrown error types |
-
-**Brief Example - Incomplete vs. Complete:**
-```typescript
-// BAD: No params, no errors documented
-/** Creates a subscription. */
-async function createSubscription(userId: string, planId: string): Promise<Subscription>;
-
-// GOOD: Full contract documented
-/**
- * @param userId - User's unique identifier
- * @param planId - Plan ID from /plans endpoint
- * @throws {UserNotFoundError} If userId doesn't exist
- * @throws {PlanNotFoundError} If planId doesn't exist
- */
-async function createSubscription(userId: string, planId: string): Promise<Subscription>;
-```
-
-### 3. Alignment Issues
-
-| Issue | Problem | Fix |
-|-------|---------|-----|
-| Code-comment drift | Comment says 3 retries, code does 5 | Update comment or use constant |
-| Stale README | Examples use removed functions | Keep README in sync with code |
-| Missing changelog | Breaking changes undocumented | Document all notable changes |
-
-**Brief Example - Drift vs. Aligned:**
-```typescript
-// BAD: Comment doesn't match code
-// Retries up to 3 times
-for (let i = 0; i < 5; i++) { /* ... */ }
-
-// GOOD: Use constant to keep aligned
-const MAX_RETRIES = 5;
-for (let i = 0; i < MAX_RETRIES; i++) { /* ... */ }
-```
-
----
-
-## Extended References
-
-For extended examples and detection commands:
-
-- **[references/violations.md](references/violations.md)** - Extended violation examples with explanations
-- **[references/patterns.md](references/patterns.md)** - Complete correct pattern examples
-- **[references/detection.md](references/detection.md)** - Bash commands for finding issues
-
----
-
-## Severity Guidelines
-
-| Severity | Description | Examples |
-|----------|-------------|----------|
-| **CRITICAL** | Actively misleading | Comments contradict code; API docs with wrong types; README with broken steps; Changelog missing breaking changes |
-| **HIGH** | Significant gaps | Public APIs undocumented; Complex algorithms unexplained; Errors not documented; Migration guides missing |
-| **MEDIUM** | Moderate issues | Some params undocumented; Examples could be clearer; "What" comments instead of "why" |
-| **LOW** | Minor improvements | Could add more examples; Formatting inconsistencies; Typos |
-
----
-
-## Documentation Checklist
-
-Before approving changes:
-
-- [ ] All public APIs have JSDoc/docstrings
-- [ ] Parameters and return values documented
-- [ ] Error conditions documented
-- [ ] Complex algorithms explained
-- [ ] Comments explain "why", not "what"
-- [ ] README reflects current state
-- [ ] CHANGELOG updated for notable changes
-- [ ] No TODO comments for completed work
-- [ ] Examples work with current API

package/plugins/devflow-code-review/skills/knowledge-persistence/SKILL.md

@@ -1,128 +0,0 @@
----
-name: knowledge-persistence
-description: >-
-  This skill should be used when recording architectural decisions or pitfalls
-  to project knowledge files, or when loading prior decisions and known pitfalls
-  for context during investigation, specification, or review.
-user-invocable: false
-allowed-tools: Read, Write, Bash
----
-
-# Knowledge Persistence
-
-Record architectural decisions and pitfalls to `.memory/knowledge/` files. This is the single source of truth for the extraction procedure — commands reference this skill instead of inlining the steps.
-
-## Iron Law
-
-> **SINGLE SOURCE OF TRUTH**
->
-> All knowledge extraction follows this procedure exactly. Commands never inline
-> their own extraction steps — they read this skill and follow it.
-
----
-
-## File Locations
-
-```
-.memory/knowledge/
-├── decisions.md    # ADR entries (append-only)
-└── pitfalls.md     # PF entries (area-specific gotchas)
-```
-
-## File Formats
-
-### decisions.md (ADR entries)
-
-**Template header** (create if file missing):
-```
-<!-- TL;DR: 0 decisions. Key: -->
-# Architectural Decisions
-
-Append-only. Status changes allowed; deletions prohibited.
-```
-
-**Entry format**:
-```markdown
-## ADR-{NNN}: {Title}
-
-- **Date**: {YYYY-MM-DD}
-- **Status**: Accepted
-- **Context**: {Why this decision was needed}
-- **Decision**: {What was decided}
-- **Consequences**: {Tradeoffs and implications}
-- **Source**: {command and identifier, e.g. `/implement TASK-123`}
-```
-
-### pitfalls.md (PF entries)
-
-**Template header** (create if file missing):
-```
-<!-- TL;DR: 0 pitfalls. Key: -->
-# Known Pitfalls
-
-Area-specific gotchas, fragile areas, and past bugs.
-```
-
-**Entry format**:
-```markdown
-## PF-{NNN}: {Short description}
-
-- **Area**: {file paths or module names}
-- **Issue**: {What goes wrong}
-- **Impact**: {Consequences if hit}
-- **Resolution**: {How to fix or avoid}
-- **Source**: {command and identifier, e.g. `/code-review branch-name`}
-```
-
----
-
-## Extraction Procedure
-
-Follow these steps when recording decisions or pitfalls:
-
-1. **Read** the target file (`.memory/knowledge/decisions.md` or `.memory/knowledge/pitfalls.md`). If it doesn't exist, create it with the template header above.
-2. **Check capacity** — count `## ADR-` or `## PF-` headings. If >=50, log "Knowledge base at capacity — skipping new entry" and stop.
-3. **Find next ID** — find highest NNN via regex (`/^## ADR-(\d+)/` or `/^## PF-(\d+)/`), default to 0. Increment by 1.
-4. **Deduplicate** (pitfalls only) — skip if an entry with the same Area + Issue already exists.
-5. **Append** the new entry using the format above.
-6. **Update TL;DR** — rewrite the `<!-- TL;DR: ... -->` comment on line 1 to reflect the new count and key topics.
-
-## Lock Protocol
-
-When writing, use a mkdir-based lock:
-- Lock path: `.memory/.knowledge.lock`
-- Timeout: 30 seconds (fail if lock not acquired)
-- Stale recovery: if lock directory is >60 seconds old, remove it and retry
-- Release lock after write completes (remove lock directory)
-
-## Loading Knowledge for Context
-
-When a command needs prior knowledge as input (not recording):
-
-1. Read `.memory/knowledge/decisions.md` if it exists
-2. Read `.memory/knowledge/pitfalls.md` if it exists
-3. Pass content as context to downstream agents — prior decisions constrain scope, known pitfalls inform investigation
-
-If neither file exists, skip silently. No error, no empty-file creation.
-
-## Operation Budget
-
-Recording: do inline (no agent spawn), 2-3 Read/Write operations total.
-Loading: 1-2 Read operations, pass as context string.
-
----
-
-## Extended References
-
-For entry examples and status lifecycle details:
-- `references/examples.md` - Full decision and pitfall entry examples
-
----
-
-## Success Criteria
-
-- [ ] Entry appended with correct sequential ID
-- [ ] No duplicate pitfalls (same Area + Issue)
-- [ ] TL;DR comment updated with current count
-- [ ] Lock acquired before write, released after
-- [ ] Capacity limit (50) respected