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 skills add Fergius-Engineering/instincts --skill question-the-premisegit clone --depth 1 https://github.com/Fergius-Engineering/instinctsWrote 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/skills/fergius-engineering/instincts/question-the-premise)<a href="https://agentmods.dev/skills/fergius-engineering/instincts/question-the-premise"><img src="https://agentmods.dev/badge/skills/fergius-engineering/instincts/question-the-premise.svg" alt="Measured on agentmods" 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.00028 | $0.00454 |
| Opus 5 | $0.00014 | $0.00227 |
| Sonnet 5 | $0.00006 | $0.00091 |
| Haiku 4.5 | $0.00003 | $0.00045 |
Grade A, and why
question-the-premise 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 6d 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.
What it actually says
The rule
Working by hypothesis, test, confirm only helps inside the right frame. If two or three well-reasoned fixes all fail, the likely problem is your premise, not your next fix. Stop and ask: have I actually confirmed the bug is in the layer I'm attacking?
This sharpens superpowers' systematic-debugging: that skill runs the loop; this one says when to stop looping and suspect the frame itself.
Fires when
Two or three fixes on the same hypothesis have all failed. A symptom that looks impossible — works in one path, fails in another that shares the same code. You're about to do a big rewrite or a deep dive to force the current theory to work.
How to apply
After about two or three failed fixes, treat the premise as the suspect, not the code. Get an outside view from someone or something that sees the whole story and has no stake in your theory.
Chase the impossible-looking discrepancy. It points at the layer you're not looking at.
If your evidence for the premise is a missing log line, load logging-for-remote-diagnosis first: absence is not proof.
Worked example
A test is flaky. You add a retry, still flaky. You add a sleep, still flaky. You mock the clock, still flaky. Three reasoned fixes, all failed.
The premise was wrong. Another test in the suite mutates a shared global, and the run order decides the outcome. Every timing fix was reading the wrong layer entirely.
The tell was right there the whole time: it passed alone but failed in the suite. That impossible-looking symptom was pointing at the real layer.
Red flags
| Thought | Reality |
|---|---|
| "Just one more fix and it'll work" after 2–3 have failed | Suspect the premise instead. |
| "The data confirms my theory" | Data read inside a wrong frame confirms the frame. Check the layer. |
| "I'll just rewrite this module" | Before you've confirmed the bug is even in that module. |
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.
- 6d ago First seen · 39 lines · 28 tokens per session scan A 2c5fb6d2c0d9
question-the-premise is a skill published in the GitHub repository Fergius-Engineering/instincts (2 stars, last pushed 12d ago), licensed MIT. It adds 28 tokens to every session and 454 once invoked, about $0.0001 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
hns-lsel-curator
Local Self-Evolution Loop (LSEL) curator — the CLUSTER + drain engine for the GOOS-local PROPOSE→APPLY seam closure (SPEC-LSEL-LOCAL-EVOLUTION-001). Companion-offset drain of .moai/lessons-inbox.jsonl with a drain-side severity filter that drops the 65% Bash-timeout/sandbox noise, eventkey clustering with a frequency…
moai-workflow-ddd
Domain-Driven Development workflow specialist using ANALYZE-PRESERVE-IMPROVE cycle for behavior-preserving code transformation. Use when refactoring legacy code or reducing technical debt safely.
memstack-development-performance-audit
Use this skill when the user says 'performance audit', 'why is it slow', 'optimize performance', 'page speed', 'Core Web Vitals', 'lighthouse', 'load time', or needs to diagnose and fix frontend or backend performance issues. Do NOT use for code reviews or security audits.
moai-workflow-loop
Ralph Engine - Automated feedback loop with LSP diagnostics and AST-grep integration for continuous code quality improvement. Use when implementing error-driven development, automated fixing, or continuous quality validation workflows.
moai-workflow-testing
Use when writing tests, measuring coverage, or running characterization, performance, or PR-review QA. Comprehensive specialist combining DDD testing, characterization tests, performance profiling, and TRUST 5 quality-assurance validation.
eval-hooks
Audit Claude Code hooks defined in settings.json files for validity, performance safety, and correctness. Resolves each command against the filesystem, checks exit-code strategy for blocking hooks, flags missing timeouts, and reviews interactive vs async patterns. Use when setting up hooks for the first time…