forge-plugin

Create and manage Flox development environments. Use when setting up a project environment during /forge:init, when a user asks to add a Flox environment, or when detecting and installing project dependencies. Covers flox init, search, install, manifest basics, and language-specific patterns. For advanced topics (services, builds, CUDA, layering, containers), suggest the full flox plugin.

This skill should be used when "restructuring commits", "organizing PR history", "making commits reviewable", or planning how to split work into atomic commits. The intellectual foundation for /reviewable. Do not use for writing commit messages (see git workflow guideline).

This skill should be used when the user redirects, corrects, or refines agent output — "no, actually", "that's not right", "you missed something". Captures correction moments to improve Forge workflows over time. Always active during feature work; log corrections as they occur.

This skill should be used when the user asks "what is an effort", "effort phases", "how do efforts work", "effort vs slice", or needs to understand the effort lifecycle. Covers the five phases: initialize, story capture, requirements, slice identification, and slice spawning.

Surface Forge plugin documentation when users ask "how does forge work", "forge help", "what commands are available", or need guidance on workflows, commands, or concepts. Use for onboarding, command reference, or workflow overview questions.

This skill should be used when a command needs the full implement-and-review cycle — spawning an implementation worker, running a code review gate, and making a post-review decision. Used by /forge:start-task and /implement. Do not use for review-only or implementation-only workflows.

This skill should be used when /forge:process-pr-discussions needs to orchestrate its three-phase pipeline — analyze unresolved threads, delegate changes to specialized agents, then resolve threads. Do not use outside the PR discussion processing command.

This skill should be used when the user asks "what is a slice", "slice phases", "how do slices work", "slice workflow", or needs to understand the slice delivery lifecycle. Covers four phases: requirements, design, implementation, and completion with phase gates and review.

This skill should be used when "breaking down tasks", "creating task table", "parallel tracks", "shippable increments", or planning implementation work in a design. Covers deployment coupling, parallel track identification, task consolidation, and the task table format. Do not use for ticket creation (see /forge:start-task).

This skill should be used when /forge:design detects 3+ subsystems with cross-boundary interactions and the user opts in to team-based design. Decomposes into subsystems, assigns parallel Designer agents, and synthesizes into a unified design. Do not use for fewer than 3 subsystems or single-component changes.

This skill should be used when exploring code in a project for "investigation", "design research", "finding what changed", "git log analysis", or "finding precedent". Provides git log analysis, code reading strategies, and file:line reference patterns. Do not use for Forge planning file reading.

This skill should be used when performing a "code review", "PR review", "review pull request", or evaluating implementation quality. Provides a two-stage process: Stage 1 checks spec compliance (does it do what was designed?), Stage 2 checks quality (is the code good?). Includes C/I/M severity classification. Do not use for design reviews or requirements reviews.

Generate activity digests and summaries of what happened in Forge. Use whenever the user asks "what happened", "catch me up", "what changed", "summary of activity", wants a digest, status update, or standup/sprint prep. Also use for questions about recent decisions, phase transitions, or active discussions. Even if the user doesn't say "digest" explicitly — any request to understand recent Forge activity should use this skill.

This skill should be used when "applying PR feedback", "processing discussion conclusions", "updating requirements from meeting notes", or any update that touches requirements.md, design.md, design-approach.md, or decisions.md. Ensures content lands at the correct abstraction level and in the correct document.

This skill should be used when presenting "investigation findings", "design decisions", "code review feedback", or any analysis that requires structured evidence. Provides evidence tables, confidence levels (High/Med/Low), fact vs speculation separation, and source citation patterns.

This skill should be used when posting to GitHub — creating issues, PR comments, PR reviews, or issue comments. Provides the signature format, project SHA retrieval pattern, and safe numbering conventions. Required for every GitHub post from a Forge agent or interactive session.

This skill should be used when a command spawns an agent that defines a "Research Lenses" section — detects agent teams capability, prompts user if available, and executes lenses as parallel subagents or team teammates. Do not use for agents without a Research Lenses section.

This skill should be used when debugging failures, "test is failing", "error I can't explain", "something broke", or any situation requiring structured diagnosis. Provides a 4-phase root-cause approach. Do not use for planning tests or writing new code.

This skill should be used when performing test-driven development, "write a failing test first", "RED-GREEN- REFACTOR", or implementing new functionality with tests. Covers the full TDD cycle with pragmatic exceptions for generated code and configuration files. Do not use for planning testing strategy (see testing-strategy).

This skill should be used when "planning tests", "testing strategy", "what tests do we need", or designing the testing section of a design document. Covers unit, integration, E2E, and performance testing levels. Do not use for writing actual test code (see tdd-discipline).

This skill should be used when completing tasks, "marking done", "claiming success", or before reporting any work as finished. Provides evidence-based completion discipline with test output, build logs, and manual testing patterns. Do not use for planning tests (see testing-strategy) or the TDD cycle (see tdd-discipline).

This skill should be used when "creating a worktree", "worktree naming", "ephemeral branch", "merge from worktree", "worktree cleanup", or navigating between worktrees. Covers naming conventions, ephemeral branch patterns, the CWD trap, and worktree setup. Do not use for general git workflow.