forge-server 0.1.0

package/plugin/skills/debugging/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: debugging
+description: This skill should be used when encountering bugs, test failures, unexpected behavior, or error messages during development. Used by all implementation agents to systematically diagnose and fix issues rather than guessing.
+user-invocable: false
+---
+
+# Debugging Skill
+
+## Purpose
+
+Provide a systematic, evidence-based methodology for diagnosing and fixing bugs, test failures, and unexpected behavior. Apply this skill whenever something does not work as expected — a test fails, an error appears, a feature behaves incorrectly, or a system produces unexpected output. The methodology eliminates guessing, prevents wasted effort, and ensures fixes address root causes rather than symptoms.
+
+---
+
+## Cardinal Rule: Do Not Guess
+
+Never make a change to fix a bug without first understanding why the bug occurs. Guessing leads to:
+
+- Changes that mask the bug without fixing it.
+- Multiple simultaneous changes that make it impossible to determine which one helped.
+- New bugs introduced by speculative fixes.
+- Wasted time when the guess is wrong and the debugging cycle restarts.
+
+Every fix must be preceded by a hypothesis that is supported by evidence. "I think this might fix it" is not a hypothesis. "The JWT validation fails because the issuer claim does not match the configured issuer URL due to a trailing slash difference" is a hypothesis.
+
+---
+
+## The Seven-Step Debugging Method
+
+### Step 1: REPRODUCE
+
+Confirm the bug exists and establish a reliable reproduction path.
+
+- Get the exact error message. Copy it verbatim. Do not paraphrase or summarize — exact wording matters because error messages are searchable and specific.
+- Get the exact steps to reproduce: what command was run, what input was provided, what sequence of actions led to the failure.
+- Reproduce the bug locally. If the bug only occurs in a specific environment, identify the environmental difference (env vars, database state, network configuration, dependency versions).
+- If the bug is intermittent, identify the conditions under which it occurs and does not occur. Intermittent bugs are usually race conditions, caching issues, or state-dependent failures.
+
+**Do not proceed until the bug is reproducible.** A bug that cannot be reproduced cannot be verified as fixed.
+
+### Step 2: ISOLATE
+
+Narrow the scope from "something is broken" to "this specific thing is broken."
+
+- **Binary search the call stack**: Start at the entry point (API endpoint, event handler, user action). Trace the execution path. Identify where the actual behavior diverges from expected behavior. Check the halfway point first — is the data correct there? If yes, the bug is downstream. If no, the bug is upstream. Continue halving.
+- **Isolate the layer**: Is the bug in the controller, the service, the database query, the external API call, the data transformation, or the response serialization? Each layer can be tested independently.
+- **Isolate the input**: Does the bug occur with all inputs or only specific ones? Narrow the input to the minimal reproduction case. A bug that occurs with one specific email address is easier to diagnose than one that "sometimes fails."
+- **Check recent changes**: If the code worked before and does not work now, identify what changed. Use `git log`, `git diff`, and `git bisect` to narrow the introducing commit. This is often the fastest path to isolation.
+
+### Step 3: UNDERSTAND
+
+Read the code around the failure point. Read it carefully, line by line.
+
+- Read the actual error message. Not a summary. Not what was expected. The actual message. Many debugging sessions are extended by hours because the developer glanced at the error and assumed they understood it.
+- Read the stack trace from top to bottom. The top frame is the point of failure. The frames below show how execution arrived there. Look for the transition from framework code to application code — that transition is usually where the bug lives.
+- Read the function that failed. Read its callers. Read its dependencies. Understand the flow of data through the failure point.
+- Check the types: is a value `undefined` when it should be a string? Is an array empty when it should have elements? Is a number `NaN`? Type mismatches are the most common category of runtime bugs.
+
+### Step 4: HYPOTHESIZE
+
+Form ONE specific, testable hypothesis about the root cause.
+
+A good hypothesis:
+- Identifies a specific location (file, function, line).
+- Identifies a specific mechanism (wrong variable, missing null check, incorrect type conversion, race condition).
+- Predicts what the fix would look like (even roughly).
+- Is falsifiable — there is an observation that would prove it wrong.
+
+A bad hypothesis:
+- "Something is wrong with the authentication." (Too vague — where? what?)
+- "The database is broken." (Too broad — which query? what failure mode?)
+- "It might be a timing issue." (Untestable without specifics.)
+
+Form only one hypothesis at a time. Do not maintain a mental list of five possibilities and try to test them all simultaneously.
+
+### Step 5: VERIFY
+
+Test the hypothesis with a targeted observation.
+
+- Add a single log statement or breakpoint at the hypothesized failure point. Check if the variable has the expected value. Check if the code path executes at all.
+- Make no other changes. The goal is to observe, not to fix. If the observation confirms the hypothesis, proceed to the fix. If the observation refutes the hypothesis, return to Step 4 with the new information.
+- For hypotheses about data flow: log the value at the point of creation, at any transformation points, and at the point of consumption. The transformation where the value changes from correct to incorrect is the bug location.
+- For hypotheses about control flow: log entry and exit of suspected functions. Confirm the code path matches expectations.
+
+**The verification rule**: the evidence must either clearly support or clearly refute the hypothesis. If the result is ambiguous, the observation point was wrong — add a more targeted observation.
+
+### Step 6: FIX
+
+Make the smallest change that fixes the root cause.
+
+- Fix the root cause, not the symptom. If a function receives `undefined` because the caller passes the wrong argument, fix the caller — do not add a null check in the function (unless the function's contract should accept undefined).
+- Make exactly one change. If the fix requires multiple changes, make them one at a time and verify after each one.
+- Do not "fix" adjacent code that is not related to the bug. Unrelated changes in a bug fix create confusion in the commit history and risk introducing new bugs.
+- Remove any debugging artifacts (log statements, breakpoints) before finalizing the fix.
+
+### Step 7: VERIFY FIX
+
+Confirm the fix resolves the bug and does not introduce regressions.
+
+- Run the original reproduction steps. The bug must no longer occur.
+- Run all related tests. They must pass.
+- Run the full test suite if practical. If the full suite is too slow, run at minimum the test suite for the affected module and any modules that depend on it.
+- If the bug was discovered without a test, write a test that reproduces the bug (fails without the fix, passes with it). This prevents the bug from recurring.
+
+---
+
+## Common Debugging Pitfalls
+
+### Fixing Symptoms Instead of Root Causes
+
+Symptom: "The API returns 500 when the user has no profile."
+Bad fix: Catch the 500 and return 200 with an empty response.
+Good fix: Find why a missing profile causes a crash (null dereference in the profile serializer) and handle the null case properly.
+
+The symptom fix hides the bug. The root cause fix eliminates it.
+
+### Making Multiple Changes at Once
+
+When debugging, make ONE change at a time. If the bug disappears after making three changes simultaneously, it is unknown which change fixed it — and the other two changes may introduce latent bugs.
+
+If the temptation to make multiple changes is strong, write them all down, then apply them one at a time, testing after each.
+
+### Not Reading the Actual Error Message
+
+Error messages are written by developers who encountered the same situation. They contain specific information: the operation that failed, the expected state, the actual state, and often a suggestion. Read the entire message before taking action.
+
+Common error messages that are often misread:
+- `Cannot read property 'x' of undefined` — the object is undefined, not the property. Find why the object is undefined.
+- `Module not found` — check the import path, not the module's existence. Typos, wrong relative paths, and missing index files are the usual causes.
+- `Connection refused` — the target service is not running or is on the wrong port. Check the service, not the client code.
+
+### Assuming Instead of Verifying
+
+"The environment variable is set." — Verify it. Log `process.env.THE_VAR` and check.
+"The database has the record." — Verify it. Query the database directly.
+"The function is being called." — Verify it. Add a log at the first line.
+"The request is reaching the server." — Verify it. Check server logs.
+
+Every assumption is a potential false assumption. Verify the ones that matter.
+
+### Not Checking for the Same Bug Elsewhere
+
+If a bug exists because a specific pattern is wrong (e.g., a missing null check), search the codebase for the same pattern. The same bug likely exists in every location where the pattern appears.
+
+Use grep/ripgrep to search for the buggy pattern and fix all occurrences, not just the one that was reported.
+
+---
+
+## NestJS-Specific Debugging
+
+### SWC Hoisting Issues
+
+**Symptom**: Environment variables are `undefined` at runtime even though they are set in `.env` files.
+
+**Root cause**: SWC (the NestJS compiler) hoists all `require()` calls above executable code in CommonJS output. Any module that reads `process.env` at the top level (outside a function) executes before `dotenv.config()` has been called, even if `dotenv.config()` appears earlier in the source.
+
+**Diagnosis**: Check if the failing module has a top-level `process.env` read:
+```typescript
+// This reads env at module load time — BEFORE dotenv runs
+const databaseUrl = process.env.DATABASE_URL!;
+const sql = postgres(databaseUrl);
+```
+
+**Fix**: Defer environment variable reads until first use, via a Proxy, a getter function, or lazy initialization inside the provider factory.
+
+### Dependency Injection Failures
+
+**Symptom**: `Nest can't resolve dependencies of the XService (?, YService)`. The `?` indicates the missing dependency.
+
+**Diagnosis checklist**:
+1. Is the missing dependency decorated with `@Injectable()`?
+2. Is the module that provides the missing dependency imported in the consuming module's `imports` array?
+3. If the dependency is provided with a custom token (e.g., `'DRIZZLE'`), is the `@Inject('DRIZZLE')` decorator present on the constructor parameter?
+4. Is there a circular dependency between modules? NestJS cannot resolve circular module imports without `forwardRef()`.
+
+**Fix**: Address the specific gap identified in the checklist. Do not scatter `@Global()` decorators to make the error go away — that hides architectural problems.
+
+### Circular Dependencies
+
+**Symptom**: `A circular dependency has been detected` or, more insidiously, silent `undefined` injection where a service is injected as `undefined`.
+
+**Diagnosis**: Trace the import chain. Module A imports Module B, which imports Module A. Or Service A injects Service B, which injects Service A.
+
+**Fix options**:
+1. Use `forwardRef(() => ModuleName)` in the module imports if the circular dependency is architecturally intentional.
+2. Extract the shared logic into a third module that both A and B depend on (preferred — eliminates the cycle).
+3. Use events or message patterns to decouple the services rather than direct injection.
+
+### Migration Errors
+
+**Symptom**: `relation "table_name" already exists` or `column "x" of relation "y" does not exist` after schema changes.
+
+**Diagnosis**: Check if `db:generate` was run after schema changes. Drizzle does not auto-generate migrations on `db:migrate` — the generate step must run first.
+
+**Fix**: Run `db:generate` to create the migration file, inspect it for correctness, then run `db:migrate`.
+
+### Import Style Errors
+
+**Symptom**: `jwt.verify is not a function` or `jwksClient is not a function` at runtime.
+
+**Root cause**: In CommonJS mode (which NestJS requires), packages like `jsonwebtoken` and `jwks-rsa` export their default differently. Namespace imports (`import * as jwt from 'jsonwebtoken'`) produce the wrong shape.
+
+**Fix**: Use default imports: `import jwt from 'jsonwebtoken'`, `import jwksClient from 'jwks-rsa'`.
+
+---
+
+## Debugging Test Failures
+
+Test failures are bugs in either the test or the production code. Apply the same seven-step method:
+
+1. **Read the failure message**: What was expected? What was received? In which test?
+2. **Isolate the test**: Run only the failing test. Does it fail in isolation? If it only fails when run with other tests, there is a test pollution issue (shared state, missing cleanup).
+3. **Check if the test is correct**: Is the test's expectation actually correct? Is the test setup adequate? Sometimes the test is wrong, not the code.
+4. **Check if the test is testing the right thing**: Is the test interacting with the real code or with a mock? A test that passes with a mock but fails with real code reveals a mock that does not match the real implementation.
+5. **Trace the execution**: Add targeted logging in the code under test to see what actually happens during the test run.
+
+---
+
+## When to Escalate
+
+If three specific hypotheses have been tested and refuted, step back. The problem framing may be wrong.
+
+**Reframing questions**:
+- "Am I looking at the right component?" — Is the bug actually in a different service, a middleware, a proxy, or a configuration?
+- "Am I looking at the right layer?" — Is this a code bug, a configuration bug, an infrastructure bug, or a data bug?
+- "Am I looking at the right time?" — Does the bug occur during request processing, during initialization, during shutdown, or during a background job?
+- "Is this actually a bug?" — Is the behavior incorrect, or is the expectation wrong? Check the requirements.
+
+If reframing does not help after a fourth hypothesis, document everything that has been tried, the evidence gathered, and the hypotheses tested. Present this documentation when seeking help. "I tried X, Y, Z and here is what I observed" is infinitely more useful than "it doesn't work."
+
+---
+
+## Debugging Tools and Techniques
+
+### Log-Based Debugging
+
+When adding diagnostic logs:
+- Log at the boundary of the suspected failure zone, not everywhere.
+- Include the variable values, not just "reached here."
+- Use structured logging: `logger.debug({ userId, tokenExp, now }, 'JWT validation check')` is better than `console.log('checking jwt')`.
+- Remove all diagnostic logs before committing the fix.
+
+### Git Bisect
+
+When a feature that previously worked is now broken and the introducing commit is unknown:
+
+1. Identify a known-good commit (where the feature works).
+2. Run `git bisect start`, `git bisect bad` (current), `git bisect good <good-commit>`.
+3. Git checks out a midpoint commit. Test the feature. Mark as `good` or `bad`.
+4. Repeat until git identifies the introducing commit.
+
+This finds the introducing commit in O(log n) steps rather than O(n) manual checks.
+
+### Minimal Reproduction
+
+When a bug is complex or environment-dependent, create a minimal reproduction:
+
+1. Start with a clean project or test file.
+2. Add only the code necessary to trigger the bug.
+3. Strip away everything else: other modules, unrelated configuration, extra dependencies.
+
+The minimal reproduction either reveals the bug immediately (because the stripped-down context makes it obvious) or proves that the bug depends on something in the larger context (which narrows the scope).
+
+---
+
+## Post-Fix Checklist
+
+After fixing any bug, complete this checklist before considering the work done:
+
+- [ ] The original reproduction steps no longer trigger the bug.
+- [ ] A regression test exists that fails without the fix and passes with it.
+- [ ] All existing tests still pass.
+- [ ] All diagnostic logging and debugging artifacts have been removed.
+- [ ] The same buggy pattern has been searched for and fixed elsewhere in the codebase.
+- [ ] The fix addresses the root cause, not just the symptom.
+- [ ] The fix is the smallest change necessary — no unrelated improvements bundled in.

package/plugin/skills/fix/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: fix
+description: Detect and fix issues in your current changes — reads git diff, checks known gotchas, runs build and lint, fixes iteratively.
+version: 0.1.0
+---
+
+# /fix — Context-Aware Code Fixer
+
+Detect and fix issues in the current changeset by combining git diff context, repo stack knowledge, known gotchas, and build/lint output.
+
+## Context Gathering (run in parallel)
+
+1. **Current changeset**: Run `git diff` and `git diff --cached` to see what's changed.
+2. **Repo stack**: Call `mcp__dk-forge__get_manifest` to read the repo's `.forge/manifest.yaml` for stack tags (e.g., nestjs, react, typescript).
+3. **Known gotchas**: Call `mcp__dk-forge__get_gotchas` filtered by the repo's stack tags — surface pitfalls relevant to the current tech.
+4. **Build output**: Run the repo's build command (detect from `package.json` scripts — typically `npm run build` or `npx tsc --noEmit`) and capture errors.
+5. **Lint output**: Run the repo's lint command (typically `npm run lint` or `npx eslint .`) and capture warnings/errors.
+
+## Fix Strategy
+
+### Build Errors (highest priority)
+- Parse TypeScript/compiler errors from build output.
+- Cross-reference with gotchas — many build failures have known solutions.
+- Fix type errors, missing imports, incorrect module resolution.
+
+### Lint Errors
+- Parse ESLint/Prettier output.
+- Auto-fix what's auto-fixable (`--fix` flag).
+- For remaining errors, apply manual fixes based on the rule and context.
+
+### Changeset Review
+- Review the diff for common mistakes:
+  - Missing null checks on new code paths.
+  - Unused imports added.
+  - Console.log/debugger statements left in.
+  - Inconsistent naming with existing conventions.
+- Cross-reference changed files with `get_gotchas` for stack-specific pitfalls.
+
+### Stack-Specific Checks
+
+Adapt checks based on detected stack:
+
+**NestJS**: Verify decorator metadata, check DI wiring, validate module imports/exports.
+**React**: Check hook rules, verify key props in lists, validate prop types.
+**TypeScript**: Verify strict mode compliance, check for `any` type leaks.
+**Drizzle**: Validate schema changes have corresponding migrations.
+
+## Execution
+
+1. Gather all context in parallel.
+2. Prioritize: build errors → lint errors → changeset issues.
+3. Fix each issue, explaining what was wrong and why.
+4. Re-run build and lint after fixes to verify resolution.
+5. If new issues surface from fixes, iterate (max 3 rounds).
+
+## Output
+
+Report what was fixed:
+- Number of build errors resolved.
+- Number of lint issues resolved.
+- Any manual issues flagged for user review.
+- Remaining issues that could not be auto-fixed.

package/plugin/skills/frontend-design/.skillfish.json

@@ -0,0 +1,10 @@
+{
+  "version": 2,
+  "name": "frontend-design",
+  "owner": "anthropics",
+  "repo": "claude-code",
+  "path": "plugins/frontend-design/skills/frontend-design",
+  "branch": "main",
+  "sha": "3bd61bab4d6b858c5d3af8adf14b917ce853e4c5",
+  "source": "manual"
+}

package/plugin/skills/frontend-design/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: frontend-design
+description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
+license: Complete terms in LICENSE.txt
+---
+
+This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
+
+The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
+
+## Design Thinking
+
+Before coding, understand the context and commit to a BOLD aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
+- **Constraints**: Technical requirements (framework, performance, accessibility).
+- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
+
+**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
+
+Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
+- Production-grade and functional
+- Visually striking and memorable
+- Cohesive with a clear aesthetic point-of-view
+- Meticulously refined in every detail
+
+## Frontend Aesthetics Guidelines
+
+Focus on:
+- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
+- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
+- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
+- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
+
+NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
+
+**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
+
+Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

package/plugin/skills/gotchas/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: gotchas
+description: Surface known pitfalls, patterns, and past decisions before you start coding. Avoid repeating old mistakes.
+version: 0.1.0
+---
+
+# /gotchas — Known Pitfalls & Patterns
+
+Surface known gotchas, established patterns, and past decisions before starting work. Avoids repeating mistakes that previous pipeline runs or developers have already discovered.
+
+## Behavior
+
+### Gotchas (default)
+
+Call `mcp__dk-forge__get_gotchas` to retrieve known pitfalls.
+
+```
+/gotchas
+/gotchas stack:nestjs
+/gotchas stack:react,typescript
+```
+
+Optionally filter by stack tags to get relevant gotchas only.
+
+### Patterns
+
+When the user asks about established patterns, call `mcp__dk-forge__get_patterns`.
+
+```
+/gotchas patterns
+/gotchas how do we handle errors
+```
+
+### Targeted Search
+
+When the user asks about a specific topic, call `mcp__dk-forge__search_knowledge` with the query.
+
+```
+/gotchas authentication
+/gotchas database migrations
+/gotchas docker deployment
+```
+
+## Output Format
+
+Present each item with:
+1. **Title/summary** — what the gotcha or pattern is.
+2. **Confidence score** — how well-established this knowledge is (0-1).
+3. **Context** — where this was discovered (which pipeline run, which repo).
+4. **Actionable advice** — what to do or avoid.
+
+## When to Use
+
+- **Before starting implementation** — check gotchas for the relevant stack/domain.
+- **When hitting a strange error** — search for known issues.
+- **When making architectural decisions** — check past decisions and their rationale.
+- **During code review** — verify the approach aligns with established patterns.
+
+## Boosting Knowledge
+
+When a gotcha proves valuable (it saved time or prevented a bug), call `mcp__dk-forge__boost_knowledge` with the knowledge item ID to increase its confidence score. This makes it more visible in future searches.

package/plugin/skills/graph-orchestrator/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: graph-orchestrator
+description: This skill enables graph-based orchestration for multi-agent workflows, inspired by LangGraph. Define agent nodes, edges with conditions, and execute stateful flows with cycles and parallelism.
+user-invocable: false
+---
+
+## Overview
+This skill enables graph-based orchestration for multi-agent workflows, inspired by LangGraph. Define agent nodes, edges with conditions, and execute stateful flows with cycles and parallelism.
+
+## Workflow
+### 1. Define Graph
+- Nodes: Agents or functions
+- Edges: Transitions with conditions
+- State: JSON object passed between nodes
+
+### 2. Execute Graph
+- Start from entry node
+- Route based on state/conditions
+- Handle cycles (max iterations)
+
+### 3. Persist State
+- Checkpoint to JSON file
+
+## Setup
+- Use Python dicts for graph definition
+- Conditions as lambda functions
+
+## Usage in Supervisor
+- Define workflow graphs
+- Execute with current state
+- Update state after each node
+
+## Anti-Patterns
+- Avoid infinite cycles
+- Keep graphs simple
+
+## References
+- LangGraph: https://github.com/langchain-ai/langgraph

package/plugin/skills/history/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: history
+description: Git intelligence — find hotspots, search commits by meaning, and trace file evolution.
+version: 0.1.0
+---
+
+# /history — Git Intelligence
+
+Query indexed git history with semantic search over commit messages, hotspot analysis, and file change velocity. More powerful than raw `git log` — uses indexed data with vector similarity for natural language queries.
+
+## Modes
+
+### Hotspots (default for bare `/history`)
+
+Call `mcp__dk-forge__get_git_context` with `mode: "hotspots"`.
+
+Shows the most frequently changed files — these are complexity magnets and likely sources of bugs.
+
+```
+/history
+/history hotspots
+```
+
+### Commit Search
+
+Call `mcp__dk-forge__get_git_context` with `mode: "commit_search"` and the user's query.
+
+Semantic search over commit messages — find commits by intent, not just keyword.
+
+```
+/history why was auth refactored
+/history commits about performance
+/history when did we add caching
+```
+
+### File History
+
+Call `mcp__dk-forge__get_git_context` with `mode: "file_history"` and `file_path`.
+
+See the commit history for a specific file.
+
+```
+/history src/auth/auth.service.ts
+/history file src/pipeline/engine.ts
+```
+
+## Output Format
+
+- **Hotspots**: Ranked list of files by change frequency, with change count and last-modified date.
+- **Commit search**: Matching commits with hash, message, author, date, and files changed.
+- **File history**: Chronological commit list for the file with messages and authors.
+
+## Use Cases
+
+- **Where should I look first?** — Hotspots show the most active (and often most fragile) code.
+- **Why does this code look like this?** — Commit search finds the reasoning behind changes.
+- **Who knows about this?** — File history shows who has been working on a file.
+- **When did this break?** — Narrow down when a behavior changed by searching commit messages.

package/plugin/skills/impact/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: impact
+description: Analyze code dependencies — who calls this function, what breaks if you change it, how data flows between symbols.
+version: 0.1.0
+---
+
+# /impact — Dependency & Call Graph Analysis
+
+Analyze code dependencies by traversing the actual call/import graph. Far more accurate than text search for understanding who uses a symbol, what depends on it, and what would break if it changes.
+
+## Prerequisites
+
+The repo must be registered and indexed. FalkorDB graph store provides the richest results; without it, falls back to vector-based similarity.
+
+## Behavior
+
+### Impact Analysis (default)
+
+Call `mcp__dk-forge__get_impact_graph` with the symbol name.
+
+```
+/impact UserService
+/impact handleAuthentication
+/impact DatabaseModule
+```
+
+**Parameters:**
+- `direction: "inbound"` — who calls/imports this symbol (callers, dependents).
+- `direction: "outbound"` — what does this symbol call/import (callees, dependencies).
+- `direction: "both"` — full picture (default).
+- `depth` — how many levels to traverse (1-5, default 3).
+
+### Flow Tracing
+
+When the user asks "how does data flow from A to B", call `mcp__dk-forge__search_logic_flow`.
+
+```
+/impact flow from AuthController to DatabaseService
+/impact trace UserDTO to API response
+```
+
+This finds the shortest path between two symbols in the call/dependency graph.
+
+## Output Format
+
+Present results as a dependency tree:
+1. **The symbol** at the center.
+2. **Inbound edges** — callers grouped by file.
+3. **Outbound edges** — callees grouped by file.
+4. **Blast radius** — count of transitive dependents to convey change risk.
+
+For flow traces, present the path as a chain: `A → B → C → D` with file paths.
+
+## Use Cases
+
+- **Before refactoring**: Understand what breaks if a function signature changes.
+- **During code review**: Verify a change doesn't have unintended downstream effects.
+- **Understanding architecture**: Map how modules connect without reading every file.
+- **Change risk assessment**: Count dependents to gauge the blast radius of a change.