Forge

Query forge's live, always-fresh code map — a dependency graph of the repo with god-nodes, modules, and neighbors/impact (blast-radius) queries. Use before editing to know what depends on a file, to find the most-depended-on hotspots, to map an unfamiliar codebase's architecture, or whenever you need current structural context instead of guessing.

Build an accurate mental map of unfamiliar code before changing it. Use when starting work in a codebase or area you don't know well, before editing code whose ripple effects you can't predict, or when the user asks how something works or where something lives.

Design the shape of a non-trivial module, API, or system before implementing it. Use when a design decision has more than one reasonable answer, when introducing a new abstraction or interface, or when getting the shape wrong would be expensive to undo.

Turn a vague idea into an approved, written spec before any code is written. Use before building a feature, adding functionality, or changing behavior — whenever the work is more than a trivial mechanical edit and the requirements aren't already pinned down.

Find the root cause of a bug, test failure, or performance regression before proposing any fix. Use the moment something is broken, throwing, failing, flaky, or slower than expected — and resist the urge to patch first.

Build or redesign frontend UI that doesn't look templated or AI-generated. Use when creating components, pages, landing pages, or restyling existing UI — before writing CSS/markup, and before shipping any visual work.

Measure non-deterministic behavior — LLM features, agents, prompts, or a skill itself — with repeatable evals instead of one-shot checks. Use when building or tuning AI/LLM functionality (ranking, extraction, generation, agent loops), when a feature could pass once by luck, or when validating that a prompt or skill actually changes behavior.

Distill durable "instincts" (trigger → action patterns) from this session into project-scoped memory that auto-loads at the start of future sessions in this repo. Use when the user asks you to learn or remember a workflow pattern, after solving something non-obvious worth not re-deriving, at the end of a productive session, or when invoked directly.

Run multiple independent pieces of work in parallel with fresh subagents, then integrate the results. Use when you have 2+ tasks with no shared state or sequential dependency, when executing an implementation plan whose slices are independent, or when one large task decomposes into chunks that can progress at the same time.

Break an approved spec or design into a precise, executable implementation plan. Use after the what/why and the shape are agreed, and before writing implementation code for any multi-step task.

The operating doctrine for all engineering work — think before coding, simplicity first, surgical changes, goal-driven execution, and evidence over assertion. Use at the start of any non-trivial task, before writing or changing code, when choosing between approaches, or whenever you feel the urge to assume, over-build, or claim something works without checking.

Recall what you and the user did in PAST Claude Code sessions, and resume a specific past chat to go deeper. Use when the user references earlier work ("what did we decide about X", "have we done this before", "continue that thing from the other day"), asks what they were working on, wants to pick up an old conversation, or asks you to remember across chats.

Review code changes for correctness and quality before merging. Use after implementing a meaningful chunk or feature, between plan tasks, or before opening a PR — to catch issues while they're cheap.

Finish a completed piece of work and integrate it cleanly — verify, then decide how to merge, PR, or set it aside. Use when implementation is done and tests pass, and you need to land the work and clean up.

Implement features and fix bugs test-first with a strict red-green-refactor loop. Use whenever you are about to write implementation code or fix a bug — before the production code exists.

Prove that work is actually complete, fixed, or passing before saying so. Use right before claiming success, marking a task done, committing, or opening a PR — any moment you're about to assert that something works.