forge

Plugin forge from marketplace renefatuaki in renefatuaki/skills. Commands read from the repo's manifest — 2 days ago.

Skills (70)

• clean-code

  clean-code, the rules for readable code. Use when writing code, editing or refactoring code, or when the user names the clean-code skill. Covers names, functions, control flow, classes and vertical layout, and delegates comments to code-comments and documentation to project-docs.

• code-comments

  code-comments, the rules for every code comment. Use when writing code, editing code that carries comments, reviewing comments, or when the user names the code-comments skill.

• typescript-best-practices

  TypeScript best practices. Use when reading or editing any .ts or .tsx file.

• diagrams

  diagrams, the rules for every Mermaid diagram. Use whenever you explain in chat how code, a set of files or a feature works, even when the user only asks what the files do. Also use when a flow, a process, a lifecycle, a data model, a type hierarchy or an architecture is explained in documentation,

• project-docs

  project-docs, the rules for every Markdown file that documents a project. Use when writing or editing a README.md or a file under docs/, when a code change alters behaviour the documentation describes, or when the user names the project-docs skill.

• technical-writing

  Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.

• unslop

  Cut AI tells from any writing.

• commit

  commit, the rules for every git commit. Use whenever the user wants to commit, save, check in or "commit that", asks for a commit message, wants a messy stage split into clean commits, asks for Conventional Commits, or when a task ends with committing the work. Use it before every `git commit` you r

• tidy-history

  tidy-history, folds the commits of the current branch into one commit per change. Use whenever the user wants to tidy, clean up, squash or rewrite the history of a branch, fold fixups into the commits they finish, or when the pull-request skill pushes a branch.

• issue

  issue, the rules for every GitHub issue. Use whenever the user wants to create an issue, report a bug, request a feature, plan a task, set up issue templates, or when another skill needs an issue for the work at hand. Use it before every `gh issue create` you run, even when the user did not name the

• loop-on-ci

  Monitor PR checks and fix failures until green. Uses gh pr checks as the source of truth for PR-attached checks.

• next-steps

  next-steps, what is still open and in which order to do it, as a short numbered list. Use whenever the user asks what is open, what comes next, what to review, merge or test, or wants a fresh summary of the session's open work, even when they do not name the skill.

• project

  project, the rules for every GitHub Project. Use whenever the user wants to create a project, bring one in line with the field set, or when another skill needs a project with Priority and Size. Use it before every `gh project create` you run, even when the user did not name the project skill.

• pull-request-review

  pull-request-review, the rules for testing a pull request in the running application. Use whenever the user wants a pull request tested or accepted by its test plan, or asks which pull requests wait for their review. Use it before every `gh pr review` you run, even when the user did not name the pul

• pull-request

  pull-request, the rules for every GitHub pull request. Use whenever the user wants to open a pull request, wants a pull request template, or when a task ends with opening one. Use it before every `gh pr create` you run, even when the user did not name the pull-request skill.

• review-queue

  review-queue, the open pull requests of a repository as a table in the order to review them. Use whenever the user asks which pull requests are open, which one to review next, or in which order to review them.

• today-issues

  today-issues, the plan for today's tickets of a GitHub Project. Use whenever the user asks what to work on today, which ticket comes next, or which tickets can run in parallel.

• automate-me

  Use for \"automate me\", \"create/update/refresh my -mode skill\", \"turn/capture my preferences or working style into a skill\", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via skill-creator + unslop, optionally pulling fresh evidence from recent transcr

• bro

  Restate the last message in plain human language, with no jargon.

• correct

  Find the mistakes agents keep repeating in this repo and make each one impossible. Try architecture first, then types, then a lint whose error names the fix, then a test, and write docs last. Prove each check fails on a real past mistake. Repeat this each time the operator corrects you. Use for /cor

• in-your-own-words

  Restate in your own words what you think the user's goals are and what problem they're trying to solve. Use for /in-your-own-words.

• recall

  Reconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', before start

• reflect

  Spawn three parallel review subagents over the active transcript, surface learnings, and route each to a concrete edit on an existing skill. Use when the user says reflect.

• setup-models

  Configure which models this plugin uses per role and at what reasoning budget. Writes an always-loaded Claude Code rule that overrides the skill defaults. Use for /setup-models, "configure models", "model budget", or changing this plugin's model choices.

• sharpen

  Make a task deeper, not bigger, then rewrite the prompt. Use for /sharpen.

• teach

  Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.

• principle-attack-the-premise

  Apply when two or more fixes that share one premise have failed the same gate. Write the premise down and test it directly before you write another fix that assumes it.

• principle-boundary-discipline

  Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.

• principle-build-the-lever

  Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your subagents follow) instead of working by hand. The tool is the artifact a reviewer can rerun.

• principle-encode-lessons-in-structure

  Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.

• principle-exhaust-the-design-space

  Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing.

• principle-experience-first

  Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.

• principle-explain-the-number

  Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.

• principle-fix-root-causes

  Apply when debugging. Trace each symptom back to the first place the system went wrong and fix it there. A guard is a fix only when the state it handles is legitimate.

• principle-foundational-thinking

  Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious.

• principle-guard-the-context-window

  Apply when context is filling up: large outputs, long files, repeated reads, fan-out planning. Route bulk to subagents; keep summaries in the main thread, not raw payloads.

• principle-laziness-protocol

  Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem.

• principle-make-operations-idempotent

  Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.

• principle-migrate-callers-then-delete-legacy-apis

  Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.

• principle-minimize-reader-load

  Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope.

• principle-model-the-domain

  Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files.

• principle-never-block-on-the-human

  Apply when tempted to ask 'should I do X?' on reversible work.

• principle-outcome-oriented-execution

  Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code.

• principle-prove-it-works

  Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'

• principle-redesign-from-first-principles

  Apply when integrating a new requirement into an existing design.

• principle-separate-before-serializing-shared-state

  Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant.

• principle-sequence-verifiable-units

  Apply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs. Break work into small units that each end in a verifiable state, check each before the next, and order delivery so the sequence proves itself to a reviewer.

• principle-subtract-before-you-add

  Apply when sequencing an addition, refactor, or rewrite. Remove dead code, redundant validators, and stub references first, then build on the simpler base.

• principle-test-behavior-not-implementation

  Apply when you write, change, or keep a test. Assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.

• principle-type-system-discipline

  Apply when designing types, reviewing a function signature, or writing code in any statically-typed language. Make illegal states unrepresentable, brand semantic primitives, parse external data at boundaries, exhaust variants, derive from authoritative schemas.

• package-manager

  package-manager, which JavaScript package manager a repository uses and its commands. Use before installing a dependency, running a one-off tool with npx, pnpx, yarn dlx or bunx, or when another skill needs the repository's package manager.

• benchmark-checklist

  Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.

• control-cli

  Build or adapt a local harness to drive, inspect, and profile an interactive CLI or TUI without external services. Use for CLI UX checks, startup regressions, memory leaks, hangs, prompt flows, or terminal demos.

• control-ui

  Build or adapt a local browser/CDP harness to drive and inspect a web, IDE, or Electron UI. Use for local UI verification, screenshots, accessibility snapshots, perf profiles, visual diffs, or reproducing UI bugs.

• create-formal-verification-skill

  Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for /create-formal-verification-skill, \"model-check this race\", \"prove this invariant\", or when concurrency, retries, s

• create-verification-skill

  Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for /create-verification-skill, \"make a control skill for this repo\", or when a project has no scripted way to prove UI/CLI/service behavior.

• maintain-formal-verification-skill

  Bring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a bug in the code. Use

• maintain-verification-skill

  Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or \"audit the verify skill\".

• verify-this

  Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE.

• architect

  Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

• arena

  Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

• blast-radius

  Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.

• engineering

  engineering, the frame for working every development task through the playbook that matches it, from a question about the code to a GitHub issue worked to a pull request ready for review. Use when the user starts a task with `/engineering`, names an issue with `/engineering #42`, or a today-issues s

• figure-it-out

  Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions. Use for /figure-it-out or 'figure it out'.

• how

  Use for \"how does X work\", code walkthroughs before changing something, and placement / ownership / layering questions (\"where should this live\", \"which package owns this\", \"is this the right layer\"). Explains subsystem architecture, runtime flow, onboarding mental models. Use why for motiva

• interrogate

  Use for \"interrogate\", \"adversarial review\", \"multi-model review\", \"challenge this\", \"stress test this code\", \"find blind spots\", or \"tear this apart\". Multiple LLM reviewers challenge changes from independent angles.

• show-me-your-work

  Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human review

• swarm

  Fan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration.

• tdd

  Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

• why

  Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, prod

Subagents (2)

• ci-watcher

  Watch PR CI for the current branch and report pass/fail with relevant failure links. Use when waiting for CI results or CI has failed. Use proactively to monitor branch CI.

• engineer

  Delegate subagent for code-writing and helper tasks spawned during an `/engineering` run. Use for delegates, not as the runner for `/engineering` itself. Spawn a fresh `forge:engineer` for each new task, and resume one only in the strict cases that the engineering skill's Subagents section names. Re

Hooks (6)

• SessionStart

  node "${CLAUDE_PLUGIN_ROOT}/hooks/session-context.mts"

• UserPromptSubmit

  node "${CLAUDE_PLUGIN_ROOT}/hooks/check-turn.mts"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/load-comment-rules.mts"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/check-turn.mts"

• Stop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/check-turn.mts"

• SubagentStop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/check-turn.mts"

Similar plugins