research-first-dev
Skill0 starsChanged 5 days agoMITView on GitHub
Version: 0.1.0 Applies to: Coding agents Trigger: Load when the task involves an unfamiliar library, API, framework version, or error the agent has not seen before.
In this repository3 other files it gives its agents.
- code-review-hawkSkill
- security-passSkill
- templatesSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Search the provided context, docs, or repository for that fact.
- Distinctive: line 15
If the fact cannot be verified, stop and say so.
- Distinctive: line 16
Only after the fact is verified, write the implementation.
- Distinctive: line 20
Never write implementation code before step 4 is complete.
- Distinctive: line 21
Never invent an API signature.
- Distinctive: line 22
Do not search for more than the specific fact needed.
- Distinctive: line 36
Do not use this skill for trivial changes where the API is already visible in the codebase.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Research First Dev
Version: 0.1.0 Applies to: Coding agents Trigger: Load when the task involves an unfamiliar library, API, framework version, or error the agent has not seen before.
Goal
Prevent the agent from writing code against assumptions. Force a short research step before any implementation, so the code matches the real API or behavior.
Instructions
- State the assumption the agent would otherwise make.
- Identify the specific fact that needs verification (API signature, version behavior, error cause).
- Search the provided context, docs, or repository for that fact.
- If the fact cannot be verified, stop and say so. Do not guess.
- Only after the fact is verified, write the implementation.
- Cite where the fact came from (file path, doc section, URL).
Constraints
- Never write implementation code before step 4 is complete.
- Never invent an API signature. If it is not verified, mark it as unverified.
- Do not search for more than the specific fact needed. Scope the research.
Expected Output
- Assumption: what the agent would have assumed.
- Verified fact: the fact, with source.
- Implementation: code that uses the verified fact.
- Unverified items: anything still uncertain, listed explicitly.
Example
Input: "Add pagination to the users endpoint using the client library."
Behavior: The agent checks the library docs for the pagination method instead of assuming page and limit parameters exist.
Output: Assumption, verified signature, implementation, unverified items.
Notes
Do not use this skill for trivial changes where the API is already visible in the codebase. Use it when the agent would otherwise guess.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

