keel

Invoke PROACTIVELY (do NOT judge the number directly, and NEVER produce a counter-estimate) whenever the user reports an engineering estimate, quote, or timeline someone gave them — "my engineer says 6 weeks, is that real?", "the agency/freelancer quoted 3 months", "is N weeks reasonable for [feature]?", "my dev says we can't ship without rebuilding X first" — or is deciding whether to approve, push back on, or defer quoted work. Fires on ANY reported estimate from an employee, agency, contractor, or co-founder, including when the user wants ammunition against it. The move is never re-estimating (Keel hasn't seen the code the estimator has): it arms the user with the three questions that make the estimate auditable, translates the number into money and opportunity cost, and coaches how to ask without burning trust. Especially for non-technical PMs and founders, whose failure mode is deference. Asking Keel to estimate new work from scratch routes to feature-decision.

Invoke PROACTIVELY (do NOT answer the build question directly) whenever a user wants to turn a product idea into a first build and no code exists yet — "I want to build an app/SaaS/tool that does X", "where do I start", "what would it take to build X", "what stack for a new X", or the post-brainstorm handoff "ok, now how do I actually build this?". This skill owns the HOW-do-I-build-it moment for pre-product ideas; brainstorming and idea-exploration skills own the earlier WHAT-should-this-be moment — when one of those has already clarified intent (in this conversation or as pasted output), do not re-explore: take the handoff and invoke this skill for the build question. Signals: no codebase, no team, no committed stack, non-technical founder. Produces a build map — 3–6 viable shapes for the first build with trade-offs and a consume/buy/build split — rather than a single verdict. A specific named technology routes to tech-evaluation; a feature on an existing system routes to feature-decision.

Prepares a startup for the enterprise-sales security gauntlet — the 200-item security questionnaire, the "do you have SOC 2?" question, the procurement review that decides whether the deal survives. Use this skill PROACTIVELY when the user mentions receiving a security questionnaire from a customer or prospect, an enterprise deal that requires security or compliance answers, being asked for SOC 2 / ISO 27001 / a DPA / a pen-test report, a customer's procurement, InfoSec, or legal review, "our first big customer wants...", or asks "are we enterprise-ready", "how do I answer this security questionnaire", "do we need SOC 2", "what will their security team ask". Also triggers when the user is planning to move upmarket and wants to prepare before the questionnaire arrives. Produces an honest posture assessment (what you can truthfully answer today, what to fix before replying, what to say about the gaps), a stage-aware SOC 2 decision (when your pipeline justifies starting the 3–5 month clock, and when compliance a

Evaluates a proposed technology choice (library, framework, ML model, infrastructure component, third-party service, or any new dependency) before it gets adopted into a project. Use this skill PROACTIVELY whenever the user mentions adopting, using, integrating, switching to, or building on top of a specific named technology — even if they don't explicitly ask for an evaluation. Common trigger phrases include "I'm thinking of using X", "should I use X", "let's go with X", "I'll add X", "we can use X for this", or any architecture proposal that names specific tools. Especially important to trigger when the user is non-technical or working solo without a CTO. Produces a structured evaluation covering segment-aware context, licensing (commercial fit), current maintenance health, alternatives, an antipattern cross-reference, longevity risk, and switching cost. Catches the kind of expensive mistake (wrong license, dying project, fundamentally wrong fit) that costs weeks to fix later.

Reviews a proposed or existing software architecture for a product, feature, or system. Use this skill PROACTIVELY whenever the user describes how their product is structured, proposes a new architecture, mentions splitting or merging services, brings up data model decisions, discusses scaling, or asks any structural "how should we build this" question — even if they don't explicitly ask for an architecture review. Common trigger phrases include "should we use microservices", "should we split this service", "we're going to architect it like this", "I'm thinking the data model should be", "we'll use a queue here", "we want to scale to X", "we're going to add a new service", "should I separate the frontend and backend", "our backend is doing too much", or any sketch of how a system or feature is structured. Also triggers when the user shares an architecture diagram, a system description, or a feature spec that implies structural choices. Especially important to trigger when the user is non-technical, is working

Supports feature-level technical decisions — surfaces alternative solutions for a proposed feature, checks alignment with the existing architecture, and assesses the tech-debt implications (what this introduces, what it pays down). This skill owns the "how should we BUILD this feature" moment — the technical-approach phase — and chains naturally after a brainstorming or intent-exploration session that has already clarified WHAT the feature should be. Use this skill PROACTIVELY whenever the user describes a feature they want to add, asks how to implement a capability, proposes a technical approach for a feature, asks whether a planned feature fits the existing system, OR has just finished clarifying a feature's intent and is ready to figure out how to build it. Common trigger phrases include "we want to add X", "how should we build [feature]", "I want users to be able to X", "we're going to add notifications/search/onboarding/billing/etc.", "what's the right way to build X", "should we build our own X or use Y

Recommends how to build a proposed feature — the simplest viable design, what to defer, what to prove first, build vs. buy, and what the feature implies for the rest of the system. Use this skill PROACTIVELY whenever the user describes a feature they want to build, asks "how should we build X", proposes adding functionality, drafts a feature spec, or mentions wanting to ship something new — even if they don't explicitly ask for a design memo. Common trigger phrases include "we want to add X", "how should we build a [feature]", "I want users to be able to X", "we're going to add notifications/search/onboarding/billing/etc.", "what's the right way to build X", "should we build our own X or use Y", "users are asking for X, how do we ship it". Also triggers when the user shares a PRD, feature spec, user story, or rough sketch of a new capability. Especially important to trigger when the user is non-technical and likely to under-scope, over-scope, or skip prove-first. Produces a structured feature design memo cove

Assesses cloud and infrastructure costs — current spend, projected spend, cost-per-unit (request/user/feature), top line items driving the bill, optimisation opportunities with ROI, and lock-in risks. Use this skill PROACTIVELY whenever the user mentions infrastructure costs, cloud bills, vendor pricing, scaling cost, "our bill is too high", "we're burning cash on infra", "is this expensive at scale", or shares a bill, an architecture with cost implications, or a pricing page. Common trigger phrases include "our AWS bill is X", "we're spending Y on Z", "how much will this cost at scale", "is this cheaper than Y", "what's the cost of running this", "should we be on a different plan", "how can we cut our cloud bill", "what does this scale to financially", "is Datadog worth the cost". Also triggers when the user describes an architecture with non-trivial cost shape (large databases, high-throughput compute, video/AI inference, observability vendors, data egress). Especially important to trigger when the user is

Audits a product's technical hygiene — backups, secrets, observability, deployment, basic security, testing on critical paths, and the operability of any AI-generated code. Produces a ranked list of "needed yesterday" items (non-negotiable) vs. "you don't need this yet" items (defer with a trigger). Use this skill PROACTIVELY when the user asks "is my system production-ready", "audit my project", "what should I clean up before [investors / customers / scaling]"; mentions shipping with AI tools (Cursor, Claude Code, v0, Lovable, Bolt) and wants to know if the code is solid; mentions a near-miss (leaked secret, data scare, surprise bill); or shares a repo, deployment config, or system description. Especially important for solo vibe coders who shipped working code but don't know what's load-bearing or fragile. Produces a structured audit with the artifact mapped first, items ranked by urgency, AI-generated code evaluated against three explicit tests, and a concrete two-week professionalisation plan.