keel

Ingest a raw source into the project's OKF knowledge bundle — distill it into concept pages, refresh the index, and log the change. keel's compounding "LLM wiki" loop.

Use when implementation is complete, gates pass, and you need to decide how to integrate the work — presents structured options (merge, PR, keep, discard) and handles the chosen workflow, including worktree cleanup. Closes the SDD cycle after review-and-simplify.

Use when executing implementation plans with independent tasks in the current session

Orchestrates the implement-feature, evaluator, fix-runner loop for the active feature until all Criterios de Aceitacao are met and quality gates are green.

Use after the plan is approved to break the active feature's plan into a concrete task checklist, written into specs/<feature>/tasks.md from the tasks template.

Use while implementing a feature that has retries, queues, background jobs, external calls, or any critical path an on-call engineer will need to reason about in production. Invoke when adding a new endpoint, dependency, or async flow, and before considering such a feature done — instrumentation is developed alongside the code, like tests, not bolted on after.

Performance lens over a feature's changed code — read-only. Appended to review-and-simplify's lens registry by the ui-review pack. Also usable standalone.

Use after tasks-writer to cross-check the active feature's spec, plan, and tasks for gaps or contradictions before implementation begins. Read-only advisory — makes no code or doc changes.

Use before a non-trivial decision stands — an architecture choice under uncertainty, branching logic, a cross-module contract, an unverifiable claim, or any change with irreversible blast radius. Invoke when you feel confident about a decision that has not been independently checked, and before committing non-trivial code or asserting a non-obvious fact.

Use after analyze reports clean to implement the active feature's tasks.md, one task at a time with TDD, once spec.md and plan.md both carry status:approved.

Use when writing framework- or library-specific code — an API call, config, lifecycle hook, or pattern whose exact shape you are recalling from memory rather than confirming. Invoke before adopting a framework idiom, when unsure whether an API signature is current, or whenever a decision depends on version-specific behavior.

Use after the spec is clarified to write the technical plan for the active feature into specs/<feature>/plan.md from the plan template, with status:draft frontmatter.

SaaS-domain security lens over a feature's changed auth/billing/tenant surface — read-only. Complements the agnostic security-review lens with the domain checks it does not make (server-side enforcement of client gates, tenant isolation, entitlement/paywall bypass, auth-flow abuse). Appended to review-lenses.txt by the saas-security pack. Also usable standalone.

Use at feature start (or when the map is stale) to map the repo's structure ONCE into docs/codebase-map.md — a token-lean, depth-limited structural map that plan-writer, analyze, and implement-feature reuse instead of re-exploring the tree each phase.

Naming-convention lens consulted BEFORE writing code — camelCase in code, snake_case at the DB boundary, and one consistent name per concept across layers. Appended to impl-conventions.txt by the stack-conventions pack. Also usable standalone.

PostgreSQL convention lens consulted BEFORE writing schema/migrations — indexing, constraints, row-level security, and timestamp/type hygiene. Appended to impl-conventions.txt by the stack-conventions pack. Also usable standalone.

TypeScript convention lens consulted BEFORE writing code — strictness, type-at-the-boundary, discriminated unions over booleans, and no-any hygiene. Appended to impl-conventions.txt by the stack-conventions pack. Also usable standalone.

Use after evaluator flags failures to run .specify/gates/run-gates.sh and apply minimal fixes, looping until gates are green. Does not invent new gates.

MANDATORY pre-commit orchestrator — fans out review lenses (code-review, security-review) in parallel, then runs a behavior-preserving simplify pass, before any commit is proposed.

REST/HTTP API contract lens over a feature's changed endpoints — read-only. Appended to review-and-simplify's lens registry by the api-review pack. Also usable standalone.

Database migration/schema-change safety lens over a feature's diff — read-only. Appended to review-and-simplify's lens registry by the api-review pack. Also usable standalone.

Accessibility lens (WCAG) over a UI feature's changed code — read-only. Appended to review-and-simplify's lens registry by the ui-review pack. Also usable standalone.

Use ao desenhar a estrutura de uma feature ou módulo (na fase de plano, ou ao refatorar) para aplicar princípios de engenharia agnósticos de linguagem — Clean Architecture, SOLID, estratégia de testes e DDD tático. Container de guias; cada conceito é um companheiro.

Dedicated security lens over a feature's changed code — read-only. Invoked by review-and-simplify, also usable standalone.

REQUIRED before writing any implementation code for a feature or bugfix. Write the test first, watch it fail, write minimal code to pass. Test BEHAVIOR (what the code does), never implementation details or mocks.

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when receiving code review feedback (from the user, a human reviewer, or the review-and-simplify lenses), before implementing suggestions — especially if feedback seems unclear or technically questionable. Requires technical rigor and verification, not performative agreement or blind implementation.

Use once per project, before any feature work, to fill out the project constitution (principles, code standards, SDD process) from the constitution template into .specify/memory/constitution.md.

Use ao PAUSAR/encerrar uma sessão (grava o estado atual em docs/STATE.md para retomar depois) ou ao RETOMAR (lê docs/STATE.md e a spec ativa, recompõe o contexto e propõe o próximo passo). Mantém continuidade entre sessões de humanos e agentes.

Use after implement-and-evaluate confirms acceptance criteria and gates are green, for a final pre-merge review against the constitution and the checklist template.

Behavior-preserving cleanup pass over recently-changed code. Invoked by review-and-simplify after the review lenses, before a commit is proposed.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use after spec-writer to surface ambiguities or gaps in the active feature's spec.md as explicit questions, then update the spec in place once answered.

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

Use after implement-feature to score the current implementation against the active feature's spec.md Criterios de Aceitacao, emitting a pass/fail list. Read-only — makes no code changes.

Use after brainstorming settles on a feature idea to write the Product Requirements Document for a new feature into specs/<feature>/prd.md from the PRD template, creating the feature's spec folder and marking it active.

Use after the PRD exists to write the functional spec for the active feature into specs/<feature>/spec.md from the spec template, with status:draft frontmatter.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes