tff-mono

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

Use during discuss-slice and plan-slice to stress-test a spec or plan against domain vocabulary before approval.

Use during research-slice to build disposable experiments that answer technical uncertainty.

Use during project:init to scaffold repo-level agent configuration (CLAUDE.md, AGENTS.md, tracker labels).

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

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

Use during discuss-slice to synthesize conversation context into a formal PRD with user stories, implementation decisions, testing decisions, and exclusions.

Use ad-hoc to classify the current slice or task into type and readiness state using the tff state model.

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

Use during research-slice and execute-slice when unfamiliar with a section of code. Go up a layer of abstraction and map relevant modules and callers.

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

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 starting design or discovery work. MUST use before any creative work.

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 making git commits. Conventional commit format and rules.

Use when creating a new Claude Code skill in this project. Scaffolds the skill directory and SKILL.md with correct frontmatter, required sections, and validates against skill-authoring conventions.

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 the user wants to report a bug, file an issue, or send feedback. Triggers on phrases like 'report issue', 'file a bug', 'something is wrong', 'open an issue', '/report-issue'.

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

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

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

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