The-Forge-Flow-CC

Use when making git commits. Conventional commit format and rules.

Use when running security review on a diff/PR/file. Research-vs-Reporting discipline, three-tier confidence gate, attacker-controllable taxonomy.

Use when invoking plannotator for approval review of generated .tff-cc milestone artifacts (plan, verification, spec).

Use when starting design or discovery work. MUST use before any creative work.

Use when the user wants to report a bug, file an issue, or send feedback about tff-cc. Triggers on phrases like 'report issue', 'file a bug', 'tff-cc broke', 'something is wrong with tff-cc', 'open an issue', '/report-issue'.

Use when creating, refining, or composing skills. Evidence-driven pattern analysis.

Use when verifying acceptance criteria. Binary verdict per criterion. Evidence-based.

Use when creating or modifying agents. Standardized template, identity-only, skills-loaded.

Use when reviewing architecture decisions. C4 model, dependency inversion, hexagonal boundaries.

Use when reviewing or requesting code review. Two-stage protocol with fresh-reviewer enforcement.

Use when generating or maintaining codebase documentation. Divio framework.

Use when executing approved plans. Wave-based execution with fresh subagent per task.

Use when shipping work. Pre-PR checklist, structured merge/PR decision, branch cleanup.

Use when designing or reviewing system architecture. Hexagonal + DDD + CQRS patterns.

Use when processing review feedback. Technical rigor, not performative agreement.

Use when stress-testing design specs. Devil's advocate for assumptions, unknowns, scope.

Use when debugging. 4-phase investigation, root cause, minimal fix.

Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.

Use when completing any task. Evidence before claims, always.

Use when creating implementation plans. Break specs into bite-sized tasks (2-5 min each).