Borrowing it
Nothing to install: this file belongs to webhook-co/webhook. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/webhook-co/webhook/main/.claude/commands/feature-dev.mdgit clone --depth 1 https://github.com/webhook-co/webhookWrote 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/commands/webhook-co/webhook/feature-dev)<a href="https://agentmods.dev/commands/webhook-co/webhook/feature-dev"><img src="https://agentmods.dev/badge/commands/webhook-co/webhook/feature-dev/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/commands/webhook-co/webhook/feature-dev"><img src="https://agentmods.dev/badge/commands/webhook-co/webhook/feature-dev.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.00000 | $0.00757 |
| Opus 5.5 | $0.00000 | $0.00303 |
| Sonnet 5.5 | $0.00000 | $0.00151 |
| Haiku 4.5 | $0.00000 | $0.00076 |
Grade A, and why
feature-dev 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 1mo 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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/feature-dev
Take a feature from a rough idea to reviewed, tested implementation through explicit phases. Don't jump straight to code — move through the phases in order and check in at the gates.
Phase 1 — discovery
Restate the goal in one line: who it's for, which surface(s) (CLI / API / web / MCP), and the outcome
they want. If the ask is vague, run the brainstorming skill / /brainstorming first and come back
with an agreed brief.
Phase 2 — codebase exploration
Understand before changing. Find where this lives: the relevant apps/* and packages/*, the
shared/ types, existing patterns for the same capability on other surfaces, and the tests that
cover the area. Note constraints discovered (DO ownership, RLS, the container-delivery seam). Use the
Explore subagent for broad searches when useful.
Phase 3 — clarifying questions
Before designing, ask the questions whose answers would change the design — auth/tenant context, data sensitivity (PII/PHI, raw payloads in R2), parity scope, ordering/performance needs, and which non-negotiables apply. Ask rather than assume. Wait for answers on anything load-bearing.
Phase 4 — architecture design (multiple approaches)
Present two or three viable approaches with concrete tradeoffs (complexity, parity cost,
performance, blast radius, how cleanly each respects the non-negotiables). Recommend one and say why
— have a point of view. Get agreement before implementing. Design for parity from the start: a
capability added to one surface is considered for all four, with shared shared/ types.
Phase 5 — implementation
Implement the agreed approach under TDD (failing test first → minimum code → refactor; see the
test-driven-development skill). Workers handlers stay thin (validate → delegate → respond); retries
via DO Alarms; delivery idempotent and dedup-by-event-id; Standard-Webhooks-native signing only;
open-core code must not import from ee/. For new MCP surface work, use the build-mcp-server skill.
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.
- 1mo ago First seen · 60 lines · 0 tokens per session scan A 64919c500871
feature-dev is a command published in the GitHub repository webhook-co/webhook (0 stars, last pushed 18d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 757 tokens. 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 commands, from other repositories
local
Command "local" from getsentry/toolkit, covering sentry local run, browser ui, endpoints, tail output and agent tracing.
auth
Bare sentry auth logs in when you're logged out and shows status when you're already authenticated. sentry auth login always starts the login flow.
debug-files
Command "debug-files" from getsentry/toolkit, covering notes on find and important notes.
feedback
Modern User Feedback is stored as Feedback issues. sentry feedback list always limits issue searches to issue.category:feedback; it does not use the legacy User Reports API.
release
A typical CI release creates the release, associates commits, finalizes it, and records a deploy. The sentry release create examples above show the full sequence.
trace
With trace view --json --fields, summary fields such as traceId and duration select trace metadata. Bare attribute names such as http.method request that attribute on every span and return it under each span's additionalattributes. The output retains spanid and children so that attributes on nested spans stay…