forge

Plugin forge from marketplace forge in AlisinaDevelo/md-files. Commands read from the repo's manifest — 1 month ago.

Skills (26)

• api-design

  Use when designing or reviewing an API — REST, GraphQL, gRPC, or a library interface. Covers consistency, resource modeling, versioning and evolution, error contracts, pagination, and idempotency so the interface stays usable and changeable after it ships.

• caching-strategies

  Use when designing or debugging a cache — choosing a caching pattern, setting TTLs and invalidation, picking a layer (client/CDN/app/DB), or fixing staleness, a low hit rate, or a stampede. Complements performance-profiling (which finds the bottleneck); this decides whether and how to cache it.

• code-review-rubric

  Use when reviewing code or a pull request to apply a consistent quality bar. Provides a severity-ranked rubric covering correctness, security, tests, readability, and maintainability, plus how to write feedback that gets fixed. See CHECKLIST.md for the full pre-merge checklist.

• concurrency-and-parallelism

  Use when writing or reviewing concurrent code — threads, async/await, shared state, locks, and parallel work — or diagnosing a race condition, deadlock, or heisenbug that only appears under load. Covers the patterns that make concurrency correct and the traps that make it intermittently wrong.

• conventional-commits

  Use when writing git commit messages and structuring commits. Covers the Conventional Commits format, choosing the right type/scope, breaking-change notation, and how to split work into small, atomic, reviewable commits.

• doctor

  Use before orchestration, stack delivery, or a release when the host and repository need a read-only capability and merge-readiness preflight. Run the Forge Doctor CLI, interpret pass/warn/fail/unknown evidence, and never mutate policy or install tools.

• error-handling

  Use when designing how code handles failure — where to catch, what to propagate, fail-fast vs recover, retries and idempotency, and error types. Covers building robust failure paths without swallowing bugs or over-engineering for impossible cases.

• feature-flags

  Use when adding, rolling out, or cleaning up feature flags — gating a change, doing a progressive/canary release, building a kill switch, or removing a stale flag. Covers flag types, safe rollout, and the discipline that keeps flags from becoming permanent tech debt.

• forge-catalog

  Use when choosing which Forge agent, skill, command, bundle, or workflow should handle a request; when comparing Forge capabilities; when building a focused install surface; or when a user asks "what should I use?" before starting work. Routes to the smallest useful Forge capability instead of loadi

• git-workflow

  Use when working with git beyond writing a commit message — branching, rebasing vs merging, resolving conflicts, recovering lost work, and bisecting to find a bad commit. Covers what is safe on shared branches and what is not.

• iterate-to-done

  Use when running a solve-loop over a task ledger — repeatedly pick the next ready task, dispatch it, verify against acceptance criteria, update the ledger, and repeat until done or blocked. Covers the loop, its stop conditions, and how to drive it recurring or in the background with the harness (/lo

• observability

  Use when adding logging, metrics, or tracing to code, or designing how a service is monitored. Covers the three pillars, structured logging, what to measure (RED/ USE), useful alerts, and the SLO mindset — so failures are debuggable after the fact.

• open-source-contribution

  Use when preparing or reviewing an upstream open-source contribution: reproduce an issue, follow maintainer rules, run exact-head checks, prepare a focused PR and reconcile review feedback. Covers fork identity, DCO/CLA gates and local evidence.

• orchestration

  Use when driving a large, multi-part task end to end with multiple models — planning at a high tier, decomposing into a task ledger, and delegating each piece to the right specialist at the right model (plan with Opus/Fable, implement with Sonnet, mechanical work with Haiku). Covers the conductor lo

• performance-profiling

  Use when investigating a performance problem — slow endpoints, high latency, memory/CPU pressure, or N+1 queries. A measure-first method to find the real bottleneck and verify the gain, instead of guessing at optimizations.

• policy

  Use when an orchestrated run may create an external effect or mutate a protected resource. Defines versioned action envelopes, declarative profiles, scoped one-use approvals, staged previews, pre-effect re-evaluation, and privacy-safe decision receipts for Forge mutation adapters.

• prompt-engineering

  Use when authoring or improving Claude Code agents, skills, slash commands, or CLAUDE.md instructions. Covers how to write a triggering description, structure a system prompt, scope tools, and apply progressive disclosure so the model actually uses what you build. See PATTERNS.md for operating-disci

• pull-request-authoring

  Use when opening a pull request — writing the description, sizing the change, and making it easy and fast to review. Covers PR structure, what reviewers need, and how to keep PRs small enough to actually get good review.

• refactoring-catalog

  Use when improving the structure of existing code without changing behavior — identifying code smells and applying the right named refactoring safely. Covers the discipline of behavior-preserving change; see CATALOG.md for the smell→fix reference.

• root-cause-debugging

  Use when diagnosing a bug, failing test, crash, or wrong output. A disciplined, hypothesis-driven method for finding the true root cause from evidence instead of guessing or masking symptoms. Use before writing any fix.

• safe-database-migrations

  Use when writing or reviewing a database schema migration, especially on a live system. Covers the expand/contract pattern for zero-downtime changes, avoiding long locks, safe backfills, and always having a rollback path.

• stacked-changes

  Use when a feature is too large for one reviewable pull request; when creating, restacking, reviewing, repairing, or landing dependent GitHub pull requests; or when choosing between vanilla git/gh, Graphite, and Sapling for a stacked-change workflow.

• task-ledger

  Use when turning a plan into trackable tasks and working them to done — a lightweight issue tracker for an orchestrated run. Covers the task format (acceptance criteria, status, dependencies, assigned agent + model) and three backends: local markdown files (default), GitHub issues via gh, or Jira/Li

• technical-writing

  Use when writing developer-facing documentation — READMEs, API references, architecture docs, ADRs, runbooks, and docstrings. Covers structure by document type, writing for the reader's task, and keeping docs accurate against the code.

• test-driven-development

  Use when implementing a feature or fixing a bug test-first: write a failing test, make it pass with the minimum code, then refactor. Covers the red-green-refactor loop, what is worth testing, and the common pitfalls that make TDD backfire.

• threat-modeling

  Use when designing or reviewing a feature for security before it ships — to systematically identify what can go wrong and where the defenses must be. Covers the STRIDE method, trust boundaries, and turning threats into concrete controls. Defensive use only.

Slash commands (22)

• /forge:changelog

  Draft a changelog entry from the commits since the last release

• /forge:commit

  Create a well-formed Conventional Commit for the staged changes

• /forge:debug

  Diagnose a bug or failing test and find the root cause before fixing

• /forge:docs

  Write or update documentation grounded in the actual code

• /forge:doctor

  Run the read-only Forge capability and merge-readiness preflight

• /forge:explain

  Explain how a file, function, or system works — clearly and accurately

• /forge:forge

  Choose the right Forge agent, skill, command, bundle, or workflow for a goal

• /forge:optimize

  Diagnose and fix a performance problem, measuring before and after

• /forge:orchestrate

  Plan a big goal at a high tier, decompose into a task ledger, and solve it by delegating each task to the right specialist and model

• /forge:plan

  Produce a step-by-step implementation plan before writing code

• /forge:policy

  Evaluate Forge policy, stage an effect, issue a scoped approval, or record a committed outcome

• /forge:pr

  Draft a pull request description from the branch's commits and incremental diff

• /forge:refactor

  Refactor code to improve structure while preserving behavior exactly

• /forge:review

  Review the current diff for correctness, security, and maintainability

• /forge:scaffold

  Scaffold a new module/component matching the repo's existing conventions

• /forge:security-scan

  Defensive security review of the current diff or a target path

• /forge:solve-loop

  Drain the current task ledger by repeatedly dispatching ready tasks, verifying results, and updating task status

• /forge:stack-review

  Review a stacked pull request series bottom-up against each immediate parent

• /forge:stack

  Plan, inspect, submit, restack, repair, or land a stack of dependent pull requests

• /forge:tasks

  Create, list, or update the task ledger (local files, or GitHub issues via gh)

• /forge:test

  Write or extend tests for the given code, matching the repo's harness

• /forge:tidy

  Clean up the current diff — remove cruft and simplify, without changing behavior

Subagents (20)

• accessibility-auditor

  Use this agent to audit and fix web/UI accessibility against WCAG — semantics, keyboard navigation, ARIA, contrast, focus management, and screen-reader support. Invoke when building or reviewing user-facing UI, or when a11y compliance is required. Examples — (1) User: "Is this modal accessible?" (2)

• api-designer

  Use this agent to design or review APIs — REST, GraphQL, gRPC, or library interfaces — for consistency, evolvability, and a good developer experience. Invoke when adding endpoints, designing a public interface, or reviewing API surface before it ships and becomes hard to change. Examples — (1) User:

• architect

  Use this agent to design an implementation strategy before writing code — for non-trivial features, refactors, or anything touching multiple systems. It returns a step-by-step plan, identifies the critical files, and weighs architectural trade-offs. Invoke when the user asks "how should I build X" o

• code-archaeologist

  Use this agent to understand an unfamiliar, large, or legacy codebase — tracing how a feature works, reconstructing intent, and mapping data and control flow before you change anything. Invoke when onboarding to a repo, before modifying code you didn't write, or when asked "how does X work here?". E

• code-reviewer

  Use this agent to review a diff, pull request, or recently written code for correctness, security, readability, and maintainability. Invoke it proactively after a logical chunk of work is complete and before committing or opening a PR. Examples — (1) User: "I just finished the auth refactor, can you

• data-engineer

  Use this agent for data-pipeline and analytics-infrastructure work — ETL/ELT design, batch vs streaming, warehouse/lakehouse modeling, partitioning, and data quality. Invoke when building or fixing pipelines, modeling analytical tables, or debugging a data-correctness issue. Distinct from database-e

• database-expert

  Use this agent for database work — schema design, query optimization, indexing, migrations, and data-integrity decisions across SQL and NoSQL stores. Invoke when designing a data model, debugging a slow query, planning a migration, or choosing a storage strategy. Examples — (1) User: "Design the sch

• debugger

  Use this agent to diagnose a failing test, exception, crash, or incorrect behavior and find the root cause before any fix is written. Invoke it when the user reports a bug, pastes a stack trace, or says something "doesn't work." Examples — (1) User: "This test fails intermittently in CI but passes l

• dependency-auditor

  Use this agent to audit project dependencies for known vulnerabilities, license risk, staleness, and supply-chain hygiene — and to plan safe upgrades. Invoke before a release, during routine maintenance, or when a CVE is reported. Examples — (1) User: "Audit our dependencies before the release." (2)

• devops-engineer

  Use this agent for CI/CD, containerization, infrastructure-as-code, deployment, and observability work. Invoke when writing pipelines, Dockerfiles, Terraform, Kubernetes manifests, or debugging a deploy. Examples — (1) User: "Write a multi-stage Dockerfile for this Go service." (2) User: "Our GitHub

• docs-writer

  Use this agent to write or improve documentation — READMEs, API references, architecture docs, runbooks, ADRs, docstrings, and onboarding guides — grounded in the actual code. Invoke when docs are missing, stale, or unclear. Examples — (1) User: "Write a README for this service." (2) User: "Document

• frontend-specialist

  Use this agent for frontend work — component architecture, state management, rendering performance, and correct, accessible, responsive UI in React/Vue/Svelte and modern web stacks. Invoke when building or reviewing UI, debugging render behavior, or improving perceived performance. Examples — (1) Us

• incident-responder

  Use this agent during a production incident to triage, mitigate, and find the cause under time pressure — and to drive the blameless postmortem afterward. Invoke when something is down or degraded in production. Examples — (1) User: "The API is returning 500s in prod right now." (2) User: "Latency s

• migration-specialist

  Use this agent to plan and execute a migration — a framework or library major upgrade, a language version bump, or an API/schema cutover — incrementally and reversibly. Invoke when a dependency has breaking changes, or when moving from one technology/pattern to another across a codebase. Examples —

• performance-optimizer

  Use this agent to diagnose and fix performance problems — slow endpoints, high latency, excessive memory/CPU, N+1 queries, or scaling issues. It measures before it optimizes. Invoke when something is "slow," a profile/benchmark needs interpreting, or before scaling a hot path. Examples — (1) User: "

• refactoring-specialist

  Use this agent to improve the structure of existing code without changing its behavior — reducing duplication, untangling complexity, improving names, and extracting seams. Invoke when code is hard to change, when the user asks to "clean up" or "simplify," or after a feature lands and the surroundin

• security-auditor

  Use this agent for defensive security review of code, configuration, or dependencies — threat modeling, finding vulnerabilities, and hardening. Invoke before shipping anything that handles auth, secrets, user input, payments, or PII. Examples — (1) User: "Audit this login endpoint before we deploy."

• sre

  Use this agent for reliability engineering — defining SLOs and error budgets, capacity and load planning, reducing toil, and hardening a service against failure before it breaks. Invoke proactively when designing for scale/reliability or when asked "is this production-ready?". Distinct from incident

• tech-lead

  Use this agent to coordinate a large or ambiguous task end-to-end — breaking it down, deciding which specialists to involve, sequencing the work, and keeping the whole effort coherent. Invoke for multi-faceted requests that span planning, implementation, review, and testing. Examples — (1) User: "Sh

• test-engineer

  Use this agent to design and write tests — unit, integration, property-based, or regression — that assert behavior and meaningfully reduce risk. Invoke after implementing a feature, when coverage is thin, or when reproducing a bug as a failing test. Examples — (1) User: "Add tests for the new pricin

Hooks (5)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/session-context.py"

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/guard-bash.py"

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/scan-secrets.py"

• PostToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/format-file.sh"

• Stop

  "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/notify.sh"

Similar plugins