agentsclimarketplace
Sign in

Feasibility attack

Skill ralfyishere/piensalo/micro-skills/feasibility-attack

Attack a proposal's feasibility before endorsing it: extract its binding requirements — resources, limits, permissions, dependencies, deadlines — and test each against known constraints. One hard infeasibility ends the endorsement.From its SKILL.md

Install
npx -y skills add ralfyishere/piensalo --skill feasibility-attack

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.9 KB, 528 tokens by cl100k_base, as published. Nobody here has run it

feasibility-attack

Trigger (observable): A novel proposal, plan, or idea is being evaluated or about to be endorsed, and it carries no cost, resource, or constraint check — enthusiasm and mechanism are present, arithmetic is not.

When NOT to activate: The proposal already includes a constraint-by-constraint feasibility case (then verify that case instead of rebuilding it); pure ideation where feasibility filtering was explicitly deferred; proposals already killed on other grounds.

Procedure

  1. Extract the proposal's binding requirements: budget, compute, headcount-time, API/rate limits, permissions, physical constraints, hard deadlines, and dependencies on parties who haven't agreed.
  2. For each requirement, test it against a known constraint with arithmetic or a citation — 'needs 40 req/s; the vendor caps at 10/s' — not vibes.
  3. Distinguish hard infeasibility (violates a limit that cannot move) from soft (expensive but purchasable). One hard hit ends the endorsement.
  4. For soft hits, state the price of relief (time, money, negotiation) so the proposer decides with the bill visible.
  5. Close constructively: the cheapest modification that restores feasibility, or a clean kill with the binding constraint named — never a defect list with no verdict.

Required output

A requirement-by-constraint table with pass / soft-hit (priced) / hard-hit (killing) results, ending in an explicit feasible / feasible-at-cost / infeasible verdict.

Verification

  • Every hard kill cites a named constraint with arithmetic or a source; assumed constraints cannot carry hard kills.
  • The output ends in an explicit feasible / feasible-at-cost / infeasible verdict that follows mechanically from the table.
  • Net effect: every binding requirement is tested against a named constraint, and the verdict follows from the hits.

Known risk: Killing ideas on assumed constraints that were never checked ('the API probably caps at...'). Mitigation: each constraint must be cited or computed, or it's labeled assumed and can't carry a hard kill.

Max intended cost: ≤350 added output tokens; a few lookups to confirm claimed limits.

Evidence status: DESIGNED — specified from documented reasoning-failure modes; not yet executed as a packaged skill.

Lineage: Derived from a documented reasoning-failure mode — endorsing novel ideas on mechanism and enthusiasm without feasibility arithmetic — combined with two evidence-backed principles: close with an explicit verdict rather than an unranked defect list, and recognize when a constraint space is exhausted rather than continuing to search it.

What ships with it: 6 files

7.1 KB alongside SKILL.md

evals/

examples/

Gives 0 of the 12 instructions most security skills give in 528 tokens

Counted across 648 of the 828 authors here whose files we hold, read 2026-08-07

  • Parameterize all database queriesin 68 of 648, across 51 files
  • Hash passwords using bcrypt, scrypt, or argon2in 49 of 648, across 36 files
  • Apply rate limiting to authentication endpointsin 48 of 648, across 24 files
  • Configure security headersin 35 of 648, across 19 files
  • Validate all inputsin 32 of 648, across 24 files
  • Validate all external input at the system boundaryin 29 of 648, across 19 files
  • Run containers as a non-root userin 28 of 648, across 15 files
  • Use httponly secure samesite cookies for sessionsin 26 of 648, across 15 files
  • Run dependency audits before every releasein 21 of 648, across 10 files
  • Encode output to prevent cross-site scriptingin 21 of 648, across 11 files
  • Copy dependencies before source codein 20 of 648, across 9 files
  • Store secrets in environment variablesin 20 of 648, across 18 files

Said here and by no other author read

  • extract the proposal's binding requirements
  • test each requirement against a known constraint
  • use arithmetic or citations for tests
  • distinguish hard infeasibility from soft hits
  • state the price of relief for soft hits
  • end with the cheapest feasible modification

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.