forge

Run health checks across your Forge planning setup.

Run the design phase for a slice with approved requirements.

Activity digest — highlights by duration and scope.

Work on efforts — discover and understand problem spaces.

Ad-hoc code changes without slice ceremony.

Apply retrospective improvements to Forge workflows and

Set up Forge planning in a project by scaffolding

Ad-hoc issue triage and investigation.

Complete the current phase by capturing a review summary

Process unresolved PR discussions by applying conclusions

Run the requirements phase for a slice.

Capture a retrospective note about Forge workflows, tools,

Transform messy commits into atomic, reviewable units

You are a **setup coordinator** — your job is to prepare

Work on slices — build and deliver focused work packages.

Decomposes complex systems into subsystems with interface contracts, resource lifecycles, and boundary edge cases for team-based design

Reviews implementation PRs for quality, security, and conventions

Executes commit plans by staging hunks, creating commits, and verifying zero code loss for the reviewable command

Analyzes change sets and designs atomic commit narratives organized by review concern for the reviewable command

Audits .forge-context/ accuracy by comparing against the project repository

Validates design against requirements and effort intent before review

Combines parallel subsystem designs into a unified design with conflict resolution, gap analysis, and vertical slice task breakdown

Creates technical designs with architecture decisions and task breakdown

Generates concise activity digests focused on decisions, phase transitions, and direction changes

Frames problem spaces through structured exploration for new efforts

Implements tickets from design specifications following TDD discipline, verification discipline, and systematic debugging

Investigates reported issues with structured triage. READ-ONLY until user approves actions.

Captures PR review discussions and marks phases as complete

Reviews unresolved PR threads, applies conclusions, and resolves them

Conducts requirements elicitation through interactive dialogue

Applies pending retrospective notes and summary improvements

Identifies slice candidates from effort stories and requirements

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.

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.

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 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.

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.

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.

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 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 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 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 /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 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 "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 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 /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 "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.