Menu
SkillsMP has collected 43 skills from CaioWF/keel. Open a skill to review its source and details.
Showing 40 of 43 collected skills.
Use when designing the structure of a feature or module (in the plan phase, or when refactoring) to apply language-agnostic engineering principles — Clean Architecture, SOLID, testing strategy, and tactical DDD. Container of guides; each concept is a…
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…
Use when PAUSING/ending a session (writes the current state to docs/STATE.md to resume later) or when RESUMING (reads docs/STATE.md and the active spec, recomposes context, and proposes the next step). Maintains continuity across human and agent sessions.
Use at the end of a session or feature — from `handoff` (pause), from `finishing-a-development-branch`, or on request — to distill what was learned about the project into its living docs. Routes environment/test/convention facts into CLAUDE.md marker blocks…
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 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 when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
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 executing implementation plans with independent tasks in the current session
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
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 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
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 evaluator flags failures to run .specify/gates/run-gates.sh and apply minimal fixes, looping until gates are green. Does not invent new gates.
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.
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 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.
Use after implement-feature to score the current implementation against the active feature's spec.md Acceptance Criteria, following specs/<feature>/contract.md and recording each verdict in it. Read-only on code — the contract's status lines are the only…
Orchestrates the implement-feature, evaluator, fix-runner loop for the active feature until all Acceptance Criteria 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 when a hard-to-reverse architectural decision is made — during plan-writer, a refactor, a doubt-driven trade-off, or a handoff PAUSE — to write it as an immutable ADR in docs/architecture/adr/ from the ADR template, or to supersede an existing one.
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 after implement-and-evaluate confirms acceptance criteria and gates are green, for a final pre-merge review against the constitution and the checklist template.
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 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…
Opt-in autonomous driver for the implementation loop — runs implement-and-evaluate to completion without human check-ins, under a global iteration budget and a stall guard, escalating with a diagnosis instead of running away. Use when a human wants the active…
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 once per project, before any feature work, to fill out the project product brief (product, user, problem/value, north-star metric, non-goals) from the product template into .specify/memory/product.md. The product layer that pairs the engineering-only…
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.
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…
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 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…
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 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…
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…
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.