getff

night-mode

Use when running a task FULLY AUTONOMOUSLY (overnight / unattended) as an orchestrator. Trigger on «работай всю ночь автономно», «оставляю на ночь», «прогони сам до готовности», «автономный режим», night mode, overnight autonomous, run to completion unattended. NOT for a single delegated edit (/orchestrator) or a one-shot review (/reviewer).

orchestrator

TRIGGER when: «оркестратор/orchestrator», «старшая/младшая модель», «делегируй/delegate», «Mode A/B», «file-prompt», «umbrella», «батч правок/batch fixes», «пакет фиксов»; ИЛИ первая из серии мелких правок одной темы; ИЛИ задача распадается на ≥3 независимых подзадач; ИЛИ «автономно / волнами / работай без остановок / прогони очередь кикофов сам» при ≥2 kickoff'ах → Queue mode. SKIP: тривиальная правка по точному пути (≤5 строк, 1 файл).

reviewer

Use when the operator or an orchestrator asks for an interactive review with a verdict — «проверь», «ревью», «вердикт», «это правильно?», «оцени результат», «phase N закрыт», review, second opinion, independent review, verify deliverable, "is this correct?" — and the deliverable is a GO/REVISE/STOP verdict or a verified answer, not code. NOT for implementing fixes or writing tests (orchestrator work), and NOT for the cold PR-boundary protocols (agents/fidelity-auditor.md, agents/review-sidecar.md — those are dispatched, not interactive).

self-reflection

Use when introducing or extending a rule, principle, pattern, methodology, discipline, or process change in this repository. Auto-trigger on «правило», «принцип», «дисциплина», «методология», «процесс», recommend, introduce rule, new principle, discipline change, process rule, meta, recursive, applies to itself, check own work, self-review, forward check, backward check, closing recommendation, discipline-bearing artefact, self-reflection, anti-pattern, or any edit touching `.claude/rules/`, `packages/core/principles/`, `docs/meta-factory/EXECUTION-PLAN.md`, `docs/meta-factory/prior-art-evaluations.md`, `CLAUDE.md`. Do NOT trigger on simple typo fixes, code edits without rule changes, or routine PR work.

story

Use when work is done / a PR was pushed, or when the user asks to recap what was done — «расскажи что сделали», «расскажи историю», story, recap, «по актам».

aif-orchestrator-discipline

> **Authoritative for:** orchestrator-worker discipline for aif-dispatched agents — REPORT format, park-vs-proceed contract, stage-gate verification, condensed orchestrator-planning (launch-table, Mode A/B, stage-gate) and reviewer-discipline (GO/REVISE/STOP, DECISION-NEEDED). > **NOT authoritative for:** project goal — see consumer's README.md. The FULL orchestrator workflow, which is split across two operator-side skills: quota zones, queue-mode anti-collusion and the Phase -1 dual-reviewer be

aif-review-project-context

> **Authoritative for:** project-specific review conventions injected into AI Factory's `aif-review` skill (and its background `review-sidecar`) — the anti-tautology / two-AI test-review checks this project requires in addition to AIF's generic review. > **NOT authoritative for:** project goal — see the consumer's README.md. The generic correctness/security/performance review — that stays owned by AIF's `aif-review` SKILL.md; this file augments it.

aif-rules-check-project-context

> **Authoritative for:** project-specific rule checks injected into AI Factory's `aif-rules-check` skill (and its `rules-sidecar`) — the two checks from this project's `RULES.md` that are NOT enforced at an earlier deterministic channel (R10 naming, R4/R17 test-existence) and therefore need a verify-time pass. > **NOT authoritative for:** project goal — see the consumer's README.md. The R1–R20 corpus itself — that lives in `.ai-factory/RULES.md`, which `rules-sidecar` already reads; this file on

installing-enforcement

Use when the user wants to actually WIRE the hard enforcement layer (git pre-commit/pre-push hooks + CI) into their repo, or asks "how do I make these rules actually fail the build / block a commit / run in CI", or wants to turn the rules-as-tests methodology from advice into a build-failing gate. Explains the soft-vs-hard boundary and points at the /getff:install-enforcement command.

tool-bootstrapping

Use when analysing project stack for MCP or skill recommendations. Triggers: tool bootstrapping, MCP installation, skill discovery, project onboarding tools, package.json deps changed, .ai-factory/tool-decisions.md, AIF /aif, tool detection, инструменты, бутстраппинг, MCP серверы, скиллы, зависимости, онбординг, подбор инструментов, предложение инструментов, подтверждение установки, tool proposal confirmation, incremental tool re-evaluation, rejected tools memory, memory persistence for tools.

using-getff

Use when starting any conversation in a repo that has the getff plugin installed — establishes how to find and use the getff skills, the instruction-priority ladder (the project's own CLAUDE.md/AGENTS.md win), and the "invoke the relevant skill before responding" discipline. Trigger on session start, before any first reply, and whenever code quality, linting, CI, pre-commit/pre-push hooks, architecture rules, mutation/contract testing, or "stop the AI breaking my conventions" comes up.

getff

Use when treating any codebase rule (architectural, naming, dependency, test-quality, contract, SLO) as an executable test that fails the build when violated, or when the user asks about enforcing code quality, fighting AI-generated code drift, setting up linters/tests/CI/pre-commit hooks, designing review processes, mutation testing, contract testing, fitness functions, observability-driven development, SLO-as-code, or any version of "how do I make my codebase resistant to AI agents breaking my conventions". Also trigger on any mention of ArchUnit, Stryker, Pact, dependency-cruiser, AI Factory (aif), Husky, lint-staged, ESLint flat config, Zod validation strategy, or shift-left/shift-right testing. Strongly trigger when the user mentions Claude Code, Cursor, or Copilot writing code that "looks fine but is wrong" — that is the core problem this skill addresses.