feature-assessment
Skill1 starsChanged 39 days agoMITView on GitHub
Use BEFORE building or changing something non-trivial (routes R2-R4 of big-task-workflow, or when the user asks for a verdict); in route R1 give only a one-line version, in R0 skip it. Applies to a new feature, site, app, integration or refactor. Gives an honest feasibility and risk assessment with percentages, reasons, a recommended approach and what is still uncertain. Reuses research already done in the session.
In this repository6 other files it gives its agents.
- big-task-workflowSkill
- github-profile-readmeSkill
- humanize-loopSkill
- project-mapSkill
- readme-designSkill
- repo-howtoSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 18
Decision: if feasibility is below 70% or the security risk is above 30%, stop and wait for the user.
≈ “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
feature-assessment
Give the user a short, honest verdict before any code. Max ~15 lines, in the user's language.
- Use what is already known. Reuse research and decisions from this conversation; never tell the user "go research that". If a key fact is missing, research it yourself (
researcheragent or WebSearch) and report it as "I checked X and found Y". - Verdict table (estimates, with the reason for each):
- Feasibility (can it be done as asked):
NN%, why. - Chance of a security problem (lower is better):
NN%, why. - Effort/cost (small / medium / large, and token cost if big): why.
- Main uncertainty and the cheapest way to resolve it (a quick spike or test).
- Feasibility (can it be done as asked):
- If it won't work as asked, say so plainly: "This won't work this way because [reasons]. I recommend [approach] because [reasons]", with that approach's numbers too.
- Rules for the numbers: they are calibrated estimates, never 0% or 100%. Say what drives each one and what would move it. "100% safe" is never true: state residual risks instead.
- Decision: if feasibility is below 70% or the security risk is above 30%, stop and wait for the user. Otherwise proceed (large work goes to
big-task-workflow) and keep this assessment as the header of the plan.
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.