Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/sananthanarayan/skilldrop/feature-implement-loopnpx skills add sananthanarayan/skilldrop --skill feature-implement-loopgit clone --depth 1 https://github.com/sananthanarayan/skilldropWhat 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 | $0.00111 | $0.02264 |
| Opus 5 | $0.00056 | $0.01132 |
| Sonnet 5 | $0.00022 | $0.00453 |
| Haiku 4.5 | $0.00011 | $0.00226 |
Grade A, and why
feature-implement-loop 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 yesterday.
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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
feature-implement-loop
You drive a feature from spec to verified implementation through a self-correcting loop. The differentiator over plain code generation: you don't stop at "here's the code." You implement, adversarially challenge what you wrote, and regenerate to close the gaps — until every acceptance criterion has a passing test and the review surfaces no blocker/major findings, or a hard 3-round cap stops you and you report what's still open.
This is the dev-workflow loop counterpart to the artifact pipeline. It composes the devils-advocate review philosophy — driven as a full reviewer panel (correctness, security, craft) where subagents exist — into a build cycle. At the human's invocation layer it stands alone: hand it a spec, get back checked code.
Input
A feature/story with two parts:
- Description — what to build and why.
- Acceptance criteria — the conditions that define "done." If the user gives prose without explicit criteria, extract the implicit criteria first and echo them back as a numbered list before writing any code. No criteria, no loop — the criteria are the gate.
If acceptance criteria are missing and can't be inferred, ask for them (one question). Don't invent a gate the user didn't agree to.
How to respond
-
Restate the spec as a criteria checklist. Number every acceptance criterion. This list is the contract the loop closes against — each criterion must end the run mapped to a test.
-
Plan the verification first. For each criterion, name the test that will prove it (unit / integration / e2e, and the assertion). Surface criteria that can't be tested automatically (e.g. "looks good on mobile") and flag them as manual-verify up front — they don't block the loop but must appear in the final report.
-
Generate code + tests together. Write the implementation and the tests that cover the criteria in the same pass. Follow the repo's existing conventions, language, and test framework — read a neighbouring file first; don't impose a new style.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 89 lines · 111 tokens per session scan A 3913d5144795
feature-implement-loop is a skill published in the GitHub repository sananthanarayan/skilldrop (2 stars, last pushed 18d ago), licensed MIT. It adds 111 tokens to every session and 2,264 once invoked, about $0.0006 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
openlore-brainstorm
Transform a feature idea into an annotated story using a Domain Sketch or Constrained Option Tree. Use when asked to brainstorm, explore, or shape a feature before implementation.
openlore-execute-refactor
Apply a confirmed .openlore/refactor-plan.md with a test gate after each change. Use when asked to execute or continue an OpenLore refactoring plan.
openlore-plan-refactor
Identify a high-priority refactoring target, assess its blast radius, and write .openlore/refactor-plan.md without changing code. Use when asked to plan or prioritize a refactor.
openlore-debug
Debug with OpenLore structural context, an explicit root-cause hypothesis, and RED/GREEN verification. Use when a bug, failure, or regression needs diagnosis and repair.
openlore-analyze-codebase
Run a full static OpenLore analysis and summarize architecture, call graph, refactoring issues, and duplicate code. Use when asked to analyze, map, or assess a codebase without LLM inference.
team-repair
Re-index OKF v0.2 index.md/log.md files, derive CDR.md, rebuild .skills.json and AGENTS.md in team-ai-directives, migrate v0.1→v0.2 frontmatter, scan for rule conflicts, and verify directive freshness. Use when indexes are inconsistent, orphans are detected, after bulk changes, or for periodic team AI directives…