featureforge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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