skills/bdi-models-and-systems-reducing-the-gap/SKILL.md
Implement executable BDI reasoning with explicit negation, paraconsistent revision, trigger-based commitment updates, and abduction. Use for runtime agent semantics and conflicting desires. NOT for purely axiomatic modal logic, black-box planners, or classical logic without operational semantics.
npx skillsauth add curiositech/windags-skills bdi-models-and-systems-reducing-the-gapInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill when the main problem is closing the gap between a pretty BDI theory and a reasoning engine that can actually run, revise commitments, and survive contradiction.
The problem is not that BDI theory is too abstract. The problem is selecting specification formalisms with no proof procedure or operational semantics. Choose a computational formalism from the start if you want executable agents.
Agents need to represent "I believe not-P" and "I intend not-P" as positive negative information. That is different from merely lacking evidence for P.
Conflicting desires are normal. Paraconsistent semantics treat contradiction as a signal to revise beliefs or intentions, not as a fatal error.
Intentions persist because the revision procedure constrains what new intentions can be adopted and when reconsideration is triggered.
Priority ordering, maximal satisfaction, and minimal change are not after-the-fact cleanups. They are the operational content of deliberation.
flowchart TD
A[Need runnable BDI reasoning] --> B{Must the logic execute at runtime?}
B -->|No| C[Pure axiomatic logic may suffice]
B -->|Yes| D[Choose operational formalism]
D --> E{Need explicit negative mental states?}
E -->|Yes| F[Use explicit negation]
E -->|No| G[Expect weak conflict handling]
F --> H{Conflicts or contradictions appear?}
H -->|Yes| I[Use paraconsistent revision]
H -->|No| J[Proceed with current commitments]
I --> K{Trigger for reconsideration fired?}
K -->|Yes| L[Revise beliefs and intentions by preference]
K -->|No| M[Keep commitments stable]
Cue: the formal model is beautiful, but implementation requires inventing a separate reasoning engine from scratch.
Fix: move to or layer in an operational formalism with executable semantics.
Cue: the system cannot distinguish active aversion from mere absence of evidence.
Fix: represent explicit negation separately from closed-world absence.
Cue: the agent keeps recomputing intentions even when nothing important changed.
Fix: define explicit reconsideration triggers and preserve commitments between them.
Cue: inconsistent desires crash the system or are forbidden before deliberation starts.
Fix: use paraconsistent semantics and revision to turn contradiction into useful signal.
Cue: the system enumerates all consistent subsets first and only then applies priorities.
Fix: encode preference into the revision procedure so it guides the search directly.
A healthcare triage agent must avoid interrupting one patient while escalating another urgent case. Represent the negative intention explicitly, allow contradictory candidate desires, and let priority-guided revision choose which intention set survives after new evidence arrives.
A robot intends to inspect a site before battery reserve drops below a threshold. New terrain beliefs make the route infeasible. The right move is not endless replanning, but trigger-based reconsideration with abductive reasoning about missing preconditions and alternative routes.
references/revision-mechanisms-as-non-monotonic-deliberation.md: load when contradiction handling and revision are the main issue.references/computational-commitment-through-revision-constraints.md: load when operational commitment and reconsideration rules are central.references/desires-as-search-space-not-commands.md: load when the desire/intention distinction is collapsing.references/abduction-as-intention-feasibility-check.md: load when the main issue is whether current intentions are still achievable.references/preference-over-consistency-restoring-revisions.md: load when you need concrete preference structure for deliberation.tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.