codeforge-dev 1.7.0 → 1.9.0

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/ast-grep-patterns/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: ast-grep-patterns
+description: >-
+  This skill should be used when the user asks to "use ast-grep",
+  "structural search", "syntax-aware search", "find code patterns",
+  "search with ast-grep", "use tree-sitter", "find function calls structurally",
+  or discusses ast-grep patterns, structural code search, meta-variables,
+  tree-sitter parsing, or syntax-aware code matching.
+version: 0.1.0
+---
+
+# AST-Grep Patterns
+
+## Mental Model
+
+Text search finds **strings**. Structural search finds **code constructs**. When you need to find all calls to `fetch()` regardless of arguments, a regex like `fetch\(.*\)` matches strings inside comments, string literals, and variable names containing "fetch." ast-grep matches the actual function call in the syntax tree.
+
+**When to use which tool:**
+
+| Need | Tool | Why |
+|------|------|-----|
+| Simple text or identifier | `Grep` | Fastest for literal text matching |
+| Code pattern with variable parts | `ast-grep` (`sg`) | Understands syntax, ignores comments/strings |
+| Full parse tree or all symbols | `tree-sitter` | Deepest structural insight per file |
+| File names by pattern | `Glob` | Path-based discovery |
+
+**Default to Grep** for simple searches. Escalate to ast-grep when:
+- The pattern has variable sub-expressions (any arguments, any name)
+- You need to distinguish code from comments/strings
+- The pattern spans multiple syntax elements (function with decorator, class with method)
+
+---
+
+## Meta-Variable Reference
+
+ast-grep uses meta-variables to match parts of the syntax tree:
+
+| Syntax | Meaning | Example |
+|--------|---------|---------|
+| `$NAME` | Matches exactly one AST node | `console.log($MSG)` matches `console.log("hi")` |
+| `$$$ARGS` | Matches zero or more nodes (variadic) | `func($$$ARGS)` matches `func()`, `func(a)`, `func(a, b, c)` |
+| `$_` | Wildcard — matches one node, not captured | `if ($_ ) { $$$BODY }` matches any if-statement |
+
+**Key distinctions:**
+- `$X` captures and can be referenced — use when you care about what matched
+- `$_` is a throwaway — use when you just need "something here"
+- `$$$X` is greedy — it captures everything between fixed anchors
+
+---
+
+## Tool Invocation
+
+### ast-grep (`sg`)
+
+```bash
+# Basic pattern search
+sg run -p 'PATTERN' -l LANGUAGE
+
+# Search in specific directory
+sg run -p 'PATTERN' -l LANGUAGE path/to/dir/
+
+# With JSON output for parsing
+sg run -p 'PATTERN' -l LANGUAGE --json
+```
+
+**Language identifiers**: `python`, `javascript`, `typescript`, `go`, `rust`, `java`, `c`, `cpp`, `css`, `html`
+
+### tree-sitter
+
+```bash
+# Extract all definitions (functions, classes, methods)
+tree-sitter tags /path/to/file.py
+
+# Parse file and show syntax tree
+tree-sitter parse /path/to/file.py
+
+# Parse and show tree for specific language
+tree-sitter parse --language python /path/to/file.py
+```
+
+---
+
+## Common Cross-Language Patterns
+
+### Function Calls
+
+```bash
+# Any call to a specific function
+sg run -p 'fetch($$$ARGS)' -l javascript
+
+# Method call on any object
+sg run -p '$OBJ.save($$$ARGS)' -l python
+
+# Chained method calls
+sg run -p '$OBJ.filter($$$A).map($$$B)' -l javascript
+```
+
+### Function/Method Definitions
+
+```bash
+# Python function
+sg run -p 'def $NAME($$$PARAMS): $$$BODY' -l python
+
+# Async Python function
+sg run -p 'async def $NAME($$$PARAMS): $$$BODY' -l python
+
+# JavaScript/TypeScript function
+sg run -p 'function $NAME($$$PARAMS) { $$$BODY }' -l javascript
+
+# Arrow function assigned to variable
+sg run -p 'const $NAME = ($$$PARAMS) => $$$BODY' -l javascript
+```
+
+### Import Statements
+
+```bash
+# Python imports
+sg run -p 'from $MODULE import $$$NAMES' -l python
+sg run -p 'import $MODULE' -l python
+
+# JavaScript/TypeScript imports
+sg run -p 'import $$$NAMES from "$MODULE"' -l javascript
+sg run -p 'import { $$$NAMES } from "$MODULE"' -l typescript
+```
+
+### Class Definitions
+
+```bash
+# Python class
+sg run -p 'class $NAME($$$BASES): $$$BODY' -l python
+
+# TypeScript class
+sg run -p 'class $NAME { $$$BODY }' -l typescript
+
+# Class with extends
+sg run -p 'class $NAME extends $BASE { $$$BODY }' -l typescript
+```
+
+### Error Handling
+
+```bash
+# Python try/except
+sg run -p 'try: $$$TRY except $EXCEPTION: $$$EXCEPT' -l python
+
+# JavaScript try/catch
+sg run -p 'try { $$$TRY } catch ($ERR) { $$$CATCH }' -l javascript
+```
+
+### Decorators / Attributes
+
+```bash
+# Python decorator
+sg run -p '@$DECORATOR def $NAME($$$PARAMS): $$$BODY' -l python
+
+# Specific decorator
+sg run -p '@app.route($$$ARGS) def $NAME($$$PARAMS): $$$BODY' -l python
+
+# TypeScript decorator
+sg run -p '@$DECORATOR class $NAME { $$$BODY }' -l typescript
+```
+
+---
+
+## Combining Tools
+
+Use ast-grep for structural finding, then Grep and Read for context:
+
+1. **Find structurally**: `sg run -p 'pattern' -l lang` → get file paths and line numbers
+2. **Filter textually**: Use `Grep` on the results to narrow by specific strings
+3. **Read context**: Use `Read` to examine surrounding code for the matches
+
+Example workflow — find all Express route handlers that don't have error handling:
+
+```bash
+# Step 1: Find all route handlers
+sg run -p 'app.$METHOD($PATH, $$$HANDLERS)' -l javascript
+
+# Step 2: Check which handlers lack try/catch (use Grep on matched files)
+# Grep for the handler function names, then check for try/catch blocks
+
+# Step 3: Read the full handler to confirm
+```
+
+---
+
+## tree-sitter Integration
+
+Use `tree-sitter` when you need the full syntax tree, not just pattern matches:
+
+- **`tree-sitter tags`** — Extracts all definitions (functions, classes, methods, variables) from a file. Use for getting a file's API surface quickly.
+- **`tree-sitter parse`** — Shows the complete syntax tree. Use for debugging ast-grep patterns that don't match as expected, or for understanding unfamiliar syntax.
+
+---
+
+## Ambiguity Policy
+
+| Ambiguity | Default |
+|-----------|---------|
+| **Search tool not specified** | Use Grep for simple text; ast-grep for structural patterns |
+| **Language not specified** | Infer from file extensions in the search directory |
+| **Pattern too broad** | Narrow by directory first, then refine the pattern |
+| **No results from ast-grep** | Fall back to Grep — the pattern may not match the exact syntax tree structure |
+| **Complex nested pattern** | Break into simpler patterns and combine results |
+
+---
+
+## Reference Files
+
+| File | Contents |
+|------|----------|
+| [Language Patterns](references/language-patterns.md) | Complete pattern catalog for Python, TypeScript/JavaScript, Go, and Rust — function calls, class definitions, imports, async patterns, and more with exact `sg` commands |

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/ast-grep-patterns/references/language-patterns.md

@@ -0,0 +1,327 @@
+# Language-Specific AST-Grep Patterns
+
+Complete pattern reference organized by language. Each pattern includes the `sg` command and example matches.
+
+---
+
+## Python
+
+### Function Definitions
+
+```bash
+# All functions
+sg run -p 'def $NAME($$$PARAMS): $$$BODY' -l python
+
+# Async functions
+sg run -p 'async def $NAME($$$PARAMS): $$$BODY' -l python
+
+# Functions with return type annotation
+sg run -p 'def $NAME($$$PARAMS) -> $RET: $$$BODY' -l python
+
+# Functions with specific decorator
+sg run -p '@staticmethod
+def $NAME($$$PARAMS): $$$BODY' -l python
+```
+
+### Class Definitions
+
+```bash
+# Any class
+sg run -p 'class $NAME: $$$BODY' -l python
+
+# Class with base classes
+sg run -p 'class $NAME($$$BASES): $$$BODY' -l python
+
+# Dataclass
+sg run -p '@dataclass
+class $NAME: $$$BODY' -l python
+
+# Pydantic model
+sg run -p 'class $NAME(BaseModel): $$$BODY' -l python
+```
+
+### Decorators
+
+```bash
+# Any decorated function
+sg run -p '@$DEC
+def $NAME($$$P): $$$B' -l python
+
+# FastAPI/Flask route
+sg run -p '@app.route($$$ARGS)
+def $NAME($$$P): $$$B' -l python
+
+# pytest fixture
+sg run -p '@pytest.fixture
+def $NAME($$$P): $$$B' -l python
+
+# Property
+sg run -p '@property
+def $NAME(self): $$$B' -l python
+```
+
+### Imports
+
+```bash
+# From imports
+sg run -p 'from $MOD import $$$NAMES' -l python
+
+# Star import
+sg run -p 'from $MOD import *' -l python
+
+# Aliased import
+sg run -p 'import $MOD as $ALIAS' -l python
+```
+
+### Try/Except
+
+```bash
+# Basic try/except
+sg run -p 'try:
+    $$$TRY
+except $EXC:
+    $$$HANDLER' -l python
+
+# Bare except (code smell)
+sg run -p 'try:
+    $$$TRY
+except:
+    $$$HANDLER' -l python
+```
+
+### Comprehensions
+
+```bash
+# List comprehension
+sg run -p '[$EXPR for $VAR in $ITER]' -l python
+
+# Dict comprehension
+sg run -p '{$KEY: $VAL for $VAR in $ITER}' -l python
+
+# Generator with condition
+sg run -p '($EXPR for $VAR in $ITER if $COND)' -l python
+```
+
+### Async Patterns
+
+```bash
+# Async with
+sg run -p 'async with $CTX as $VAR: $$$BODY' -l python
+
+# Await expression
+sg run -p 'await $EXPR' -l python
+
+# Async for
+sg run -p 'async for $VAR in $ITER: $$$BODY' -l python
+```
+
+---
+
+## TypeScript / JavaScript
+
+### Function Calls
+
+```bash
+# Specific function call
+sg run -p 'fetch($$$ARGS)' -l typescript
+
+# Method call
+sg run -p '$OBJ.addEventListener($$$ARGS)' -l typescript
+
+# Console methods
+sg run -p 'console.$METHOD($$$ARGS)' -l javascript
+
+# React hook
+sg run -p 'useState($$$ARGS)' -l typescript
+sg run -p 'useEffect($$$ARGS)' -l typescript
+```
+
+### JSX / React Components
+
+```bash
+# Component usage
+sg run -p '<$Component $$$PROPS />' -l typescript
+
+# Component with children
+sg run -p '<$Component $$$PROPS>$$$CHILDREN</$Component>' -l typescript
+
+# Specific component
+sg run -p '<Button $$$PROPS>$$$CHILDREN</Button>' -l typescript
+```
+
+### Imports / Exports
+
+```bash
+# Named import
+sg run -p 'import { $$$NAMES } from "$MOD"' -l typescript
+
+# Default import
+sg run -p 'import $NAME from "$MOD"' -l typescript
+
+# Dynamic import
+sg run -p 'import($PATH)' -l typescript
+
+# Named export
+sg run -p 'export const $NAME = $VAL' -l typescript
+
+# Export function
+sg run -p 'export function $NAME($$$P) { $$$B }' -l typescript
+```
+
+### Class Methods
+
+```bash
+# Method definition
+sg run -p 'class $C { $$$B1 $METHOD($$$P) { $$$B2 } $$$B3 }' -l typescript
+
+# Async method
+sg run -p 'async $METHOD($$$P) { $$$BODY }' -l typescript
+
+# Constructor
+sg run -p 'constructor($$$PARAMS) { $$$BODY }' -l typescript
+```
+
+### Arrow Functions
+
+```bash
+# Arrow with body
+sg run -p 'const $NAME = ($$$P) => { $$$BODY }' -l typescript
+
+# Arrow with expression
+sg run -p 'const $NAME = ($$$P) => $EXPR' -l typescript
+
+# Callback arrow
+sg run -p '($$$P) => $EXPR' -l typescript
+```
+
+---
+
+## Go
+
+### Function Signatures
+
+```bash
+# Function definition
+sg run -p 'func $NAME($$$PARAMS) $$$RETURN { $$$BODY }' -l go
+
+# Method (with receiver)
+sg run -p 'func ($RECV $TYPE) $NAME($$$PARAMS) $$$RETURN { $$$BODY }' -l go
+
+# Function returning error
+sg run -p 'func $NAME($$$P) ($$$R, error) { $$$B }' -l go
+```
+
+### Struct Definitions
+
+```bash
+# Struct
+sg run -p 'type $NAME struct { $$$FIELDS }' -l go
+
+# Interface
+sg run -p 'type $NAME interface { $$$METHODS }' -l go
+```
+
+### Goroutines and Concurrency
+
+```bash
+# Goroutine launch
+sg run -p 'go $FUNC($$$ARGS)' -l go
+
+# Defer statement
+sg run -p 'defer $FUNC($$$ARGS)' -l go
+
+# Channel send
+sg run -p '$CH <- $VAL' -l go
+
+# Channel receive
+sg run -p '$VAR := <-$CH' -l go
+
+# Select statement
+sg run -p 'select { $$$CASES }' -l go
+```
+
+### Error Handling
+
+```bash
+# Error check pattern
+sg run -p 'if err != nil { $$$BODY }' -l go
+
+# Error wrapping
+sg run -p 'fmt.Errorf($$$ARGS)' -l go
+```
+
+---
+
+## Rust
+
+### Function and Impl Blocks
+
+```bash
+# Function
+sg run -p 'fn $NAME($$$PARAMS) -> $RET { $$$BODY }' -l rust
+
+# Impl block
+sg run -p 'impl $TYPE { $$$METHODS }' -l rust
+
+# Trait implementation
+sg run -p 'impl $TRAIT for $TYPE { $$$METHODS }' -l rust
+
+# Public function
+sg run -p 'pub fn $NAME($$$PARAMS) -> $RET { $$$BODY }' -l rust
+```
+
+### Match Arms
+
+```bash
+# Match statement
+sg run -p 'match $EXPR { $$$ARMS }' -l rust
+
+# Specific match arm (harder — ast-grep matches full expressions better)
+```
+
+### Macro Invocations
+
+```bash
+# println! macro
+sg run -p 'println!($$$ARGS)' -l rust
+
+# vec! macro
+sg run -p 'vec![$$$ITEMS]' -l rust
+
+# Any macro
+sg run -p '$MACRO!($$$ARGS)' -l rust
+```
+
+### Error Handling
+
+```bash
+# unwrap calls (potential panics)
+sg run -p '$EXPR.unwrap()' -l rust
+
+# expect calls
+sg run -p '$EXPR.expect($MSG)' -l rust
+
+# ? operator (harder to match as standalone — use in function context)
+```
+
+### Async Patterns
+
+```bash
+# Async function
+sg run -p 'async fn $NAME($$$P) -> $RET { $$$B }' -l rust
+
+# .await
+sg run -p '$EXPR.await' -l rust
+
+# tokio::spawn
+sg run -p 'tokio::spawn($$$ARGS)' -l rust
+```
+
+---
+
+## Tips
+
+- **Pattern doesn't match?** Use `tree-sitter parse file.ext` to see the actual syntax tree structure. ast-grep patterns must match the tree structure, which sometimes differs from how code appears visually.
+- **Too many results?** Add more context to the pattern (surrounding code) or search within a specific directory.
+- **Cross-language search?** Run separate `sg` commands per language — ast-grep requires a language specification.
+- **Combine with Grep:** Use ast-grep to find structural patterns, then Grep to filter results by specific strings within matches.

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/dependency-management/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: dependency-management
+description: >-
+  This skill should be used when the user asks to "check dependencies",
+  "audit dependencies", "find outdated packages", "check dependency health",
+  "scan for vulnerabilities", "find unused dependencies", "license check",
+  "npm audit", "pip audit", "cargo audit", or discusses dependency analysis,
+  supply chain security, package version gaps, or license compliance.
+version: 0.1.0
+---
+
+# Dependency Management
+
+## Mental Model
+
+Dependency health is **ongoing hygiene**, not a one-time audit. Every dependency is a trust relationship — you inherit its bugs, vulnerabilities, and license obligations. Healthy projects monitor five dimensions continuously:
+
+1. **Currency** — How far behind are you? Major gaps accumulate breaking changes; patch gaps leave security holes open.
+2. **Security** — Are there known vulnerabilities? Severity × exploitability × exposure = actual risk.
+3. **Unused** — Dead dependencies increase attack surface and slow installs for zero value.
+4. **Conflicts** — Version mismatches cause subtle runtime bugs that are expensive to diagnose.
+5. **Licensing** — License obligations propagate transitively. One GPL dependency can change your distribution obligations.
+
+Treat dependency updates like any other code change: assess, plan, execute, verify.
+
+---
+
+## Ecosystem Detection
+
+Identify which package managers are in use before running any analysis. A project may span multiple ecosystems (e.g., Python backend + Node.js frontend).
+
+| Ecosystem | Manifest Files | Lock Files |
+|-----------|---------------|------------|
+| **Node.js** | `package.json` | `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` |
+| **Python** | `pyproject.toml`, `setup.py`, `requirements*.txt`, `Pipfile` | `poetry.lock`, `uv.lock`, `Pipfile.lock` |
+| **Rust** | `Cargo.toml` | `Cargo.lock` |
+| **Go** | `go.mod` | `go.sum` |
+
+Use `Glob` to discover manifests. Read each manifest to count direct dependencies before running analysis commands.
+
+For monorepos, identify each workspace/package separately and analyze independently.
+
+---
+
+## Analysis Workflow
+
+### Phase 1: Outdated Packages
+
+Check currency across all detected ecosystems. Categorize findings by version gap:
+
+- **Major** — Likely breaking changes. Review changelog before upgrading.
+- **Minor** — New features, generally low risk.
+- **Patch** — Bug fixes and security patches. Upgrade promptly.
+
+Prioritize patch-level upgrades first — they carry the least risk and often fix security issues.
+
+### Phase 2: Security Vulnerabilities
+
+Run ecosystem-specific audit tools. For each finding, report:
+- Package name and installed version
+- Vulnerability ID (CVE, GHSA)
+- Severity (critical / high / medium / low)
+- Fixed version (if available)
+- Whether it is a **direct** or **transitive** dependency
+
+Direct dependencies are simpler to fix. Transitive vulnerabilities may require upgrading an intermediary package.
+
+### Phase 3: Unused Dependencies
+
+Cross-reference manifest declarations with source imports:
+1. Read the manifest to list declared dependencies.
+2. Search for import/require statements across all source files.
+3. Flag packages with zero import matches as potentially unused.
+
+Mark known implicit-use categories separately: plugins, CLI tools, type packages (`@types/*`), test frameworks in `devDependencies`, build tools, and runtime-loaded modules. These get a "verify manually" note rather than a definitive "unused" label.
+
+### Phase 4: Version Conflicts
+
+Check for conflicting version requirements in the dependency tree. Peer dependency issues in Node.js, version resolution conflicts in Python, and duplicate packages at different versions all indicate problems.
+
+### Phase 5: License Compliance
+
+Classify all dependency licenses and flag risk:
+- **Permissive** (MIT, BSD, Apache-2.0, ISC) — Safe for all use.
+- **Weak copyleft** (LGPL, MPL) — Safe as library, restrictions on modifications.
+- **Strong copyleft** (GPL, AGPL) — May require source disclosure. Flag for commercial projects.
+- **Unknown/Missing** — Flag for manual review. Unlicensed code carries legal risk.
+
+---
+
+## Version Gap Classification
+
+| Gap | Risk | Action |
+|-----|------|--------|
+| Patch (0.0.x) | Low | Upgrade promptly — bug fixes and security patches |
+| Minor (0.x.0) | Low–Medium | Review changelog, usually safe to upgrade |
+| Major (x.0.0) | Medium–High | Review migration guide, test thoroughly |
+| Multiple majors behind | High | Plan incremental upgrade path, one major at a time |
+
+---
+
+## Vulnerability Severity
+
+CVSS scores provide a starting point but need context:
+
+| CVSS Range | Label | Typical Action |
+|------------|-------|---------------|
+| 9.0–10.0 | Critical | Patch immediately. These often have active exploits. |
+| 7.0–8.9 | High | Patch within days. Check if your usage triggers the vulnerability. |
+| 4.0–6.9 | Medium | Patch within weeks. Assess exploitability in your context. |
+| 0.1–3.9 | Low | Patch during regular maintenance. Low exploitability. |
+
+A critical vulnerability in a transitive dependency used only in tests has lower effective risk than a medium vulnerability in a direct dependency exposed to user input. Always assess exploitability in context.
+
+---
+
+## Ambiguity Policy
+
+| Ambiguity | Default |
+|-----------|---------|
+| **Scope not specified** | Run all five phases (outdated, security, unused, conflicts, licenses) |
+| **Ecosystem not specified** | Analyze all detected ecosystems |
+| **Severity threshold** | Report all severities, highlight critical and high |
+| **Update recommendations** | Advisory only — never modify manifests or lock files |
+| **Direct vs transitive** | Always distinguish; prioritize direct dependencies |
+
+---
+
+## Reference Files
+
+| File | Contents |
+|------|----------|
+| [Ecosystem Commands](references/ecosystem-commands.md) | Per-ecosystem command tables for npm, pip/uv, cargo, and go — outdated checks, audits, unused detection, conflict checks, and license listing |
+| [License Compliance](references/license-compliance.md) | License classification table, SPDX identifiers, commercial implications, common conflicts, and recommended actions per risk level |