dmulcahey/featureforge

brainstorming

You MUST use this before exploring a feature idea, behavior change, or architecture direction. Refines user intent, requirements, and design before implementation.

dispatching-parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

document-release

Use when implementation is complete and release notes, changelog, TODO, or handoff documentation need a release-quality pass before merge

executing-plans

Use when you have an engineering-approved FeatureForge implementation plan and need to execute it in a separate session

finishing-a-development-branch

Use when implementation is complete, verification passes, and you need to decide how to integrate the work through merge, PR, or cleanup

plan-ceo-review

Use when a written FeatureForge design or architecture spec needs CEO or founder review before implementation planning, including scope expansion, selective expansion, hold-scope rigor, or scope reduction

plan-eng-review

Use when a written FeatureForge implementation plan from a CEO-approved spec needs engineering review before execution or when workflow/operator explicitly routes to late refresh-test-plan regeneration

plan-fidelity-review

Use when an engineering-reviewed draft FeatureForge implementation plan needs a final first-class fidelity review against the CEO-approved spec before engineering approval

project-memory

Use when setting up or updating repo-visible project memory under docs/project_notes, or when recording durable bugs, decisions, key facts, or issue breadcrumbs without changing FeatureForge workflow authority

qa-only

Use when you need browser-based QA, repro steps, screenshots, evidence, and reports, but do not want the agent to fix any code

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

requesting-code-review

Use after implementation work or an intentional review checkpoint, and before merging, to verify the work meets requirements

subagent-driven-development

Use when executing an engineering-approved FeatureForge implementation plan with mostly independent tasks in the current session

systematic-debugging

Use when investigating a bug, regression, test failure, or unexpected behavior before proposing fixes

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

using-featureforge

Use when starting any conversation or deciding which skill or workflow stage applies before any response, clarification, or action

using-git-worktrees

Use when the user wants an isolated workspace for feature work or parallel branch-based development - creates isolated git worktrees with smart directory selection and safety verification

verification-before-completion

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

writing-plans

Use when you have a CEO-approved FeatureForge spec for a multi-step task and need to write the implementation plan before touching code

writing-skills

Use when creating new skills, editing existing skills, or verifying skills work before deployment

featureforge-upgrade

Use when FeatureForge detects an installed update and needs to upgrade the local runtime checkout before continuing