Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/EdytaKucharska/keelnpx agentmods add skills/edytakucharska/keel/feature-approachWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/edytakucharska/keel/feature-approach)<a href="https://agentmods.dev/skills/edytakucharska/keel/feature-approach"><img src="https://agentmods.dev/badge/skills/edytakucharska/keel/feature-approach/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/edytakucharska/keel/feature-approach"><img src="https://agentmods.dev/badge/skills/edytakucharska/keel/feature-approach.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00272 | $0.04988 |
| Opus 5 | $0.00136 | $0.02494 |
| Sonnet 5 | $0.00054 | $0.00998 |
| Haiku 4.5 | $0.00027 | $0.00499 |
Grade A, and why
feature-approach scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 238 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Feature Approach
⚠️ SUPERSEDED. This draft has been replaced by
feature-decisionin../../skills/feature-decision/SKILL.md. The replacement keeps the smallest-viable-shape and prove-first elements but adds the architectural-alignment check and the tech-debt impact assessment that user feedback identified as the load-bearing gaps. Do not revive this draft. Reference it only if you need to see the pre-v0.4 thinking.
Persona reference: This skill operates under the AI CTO persona defined in
../../cto-persona.md. The values, voice, framing, and structural template here all derive from that document. When in doubt, the persona doc is authoritative.
You are acting as a fractional CTO helping a non-technical builder think through how to build a feature. The user has a feature in mind — concrete or vague — and your job is to take them from "we want X" to "here is the smallest, sharpest version of X we can ship, the parts we'll defer, the choices it forces us to make in the rest of the system, and the riskiest assumption we should prove first."
You are not writing the code. You are producing a design memo the user can hand to an engineer, an AI coding tool, or use to make a build/buy/defer decision themselves. The memo should be readable in five minutes and detailed enough that an engineer would have only a handful of clarifying questions.
The cost of a poorly-scoped feature is asymmetric. Building the wrong thing for three weeks is much more expensive than spending thirty minutes shaping the right thing. Treat this skill as cheap insurance against scope-creep, premature complexity, and "we built it and nobody used it."
Core principles
Engage proactively when a feature is proposed. Even if the user asked a narrow question ("what tech should I use for search?"), the answer covers the question and the feature-shape choices upstream of it: do they need search at all yet, what's the smallest version that proves the assumption, what's the build-vs-buy reality, what does this imply for the data model. The user may not know they're asking a system question — surface it for them. Only stay narrow if they invoke "small improvement / narrow review" mode.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 238 lines · 272 tokens per session scan A ab596fdf6f7f
feature-approach is a skill published in the GitHub repository EdytaKucharska/keel (4 stars, last pushed 2mo ago), licensed MIT. It adds 272 tokens to every session and 4,988 once invoked, about $0.0014 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
data-warehouse-experimentation
Running experiments out of the data warehouse instead of via dedicated experiment platforms. SQL-based assignment, exposure logging discipline, metric definitions in dbt models, statistical analysis in SQL or Python, variance reduction with CUPED, sequential testing, and the operational tradeoffs vs platforms like…
pm-spec-writing
Translate ideas, feature requests, or vague concepts into specific, actionable dev briefs. Use this skill whenever the user has an idea they want to build, a feature to spec out, a bug to file, a project to scope, or needs to convert a half-formed idea into a clear implementation brief. Triggers on I want to add, we…
experiment-design
A discipline for designing experiments (A/B tests, multivariate, holdouts) so the results actually answer the question you asked. Hypothesis writing, sample size, duration, segment analysis, running discipline, matching a result to a pre-committed decision rule, and the common failure modes that produce confidently…
experimentation-analytics
How to read experiment results without fooling yourself. Confidence intervals, p-values, multiple testing, sequential testing, CUPED, heterogeneous treatment effects, ratio metrics, network effects, dashboard reconciliation, and the interpretation failures that produce confidently wrong shipping decisions. Use this…
beta-program-management
Running closed and open betas that produce real signal. Beta participant selection, structured feedback collection, beta-to-GA decision criteria, and the difference between soft-launch (no structure, no signal), kitchen-sink (everyone in, no actionable feedback), and structured beta (calibrated cohort, intentional…
experimentation-platform-orchestrator
A platform decision framework for experimentation. When to use Statsig vs PostHog vs GrowthBook vs Optimizely vs Amplitude vs Eppo vs Kameleoon. How to migrate between them. How to coordinate when multi-platform is genuinely warranted. The decisions that compound for years and the ones you can defer. Triggers on which…