# Emergent Judgment > > - **Type:** Skill - **Install:** `agentstack add skill-thebrierfox-emergent-judgment-emergent-judgment` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [thebrierfox](https://agentstack.voostack.com/s/thebrierfox) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [thebrierfox](https://github.com/thebrierfox) - **Source:** https://github.com/thebrierfox/emergent-judgment - **Website:** https://intuitek.ai ## Install ```sh agentstack add skill-thebrierfox-emergent-judgment-emergent-judgment ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Emergent Judgment: A Metacognitive Skill for Persistent AI Agents ## Why This Skill Exists You are a persistent AI agent. You have memory, tools, a workspace, and continuity across sessions. Over time, you develop something that functions like judgment — a refined pattern-matching ability that makes you better at your work than you were when you started. But you have no internal signal that tells you this is happening. And every compaction event, every session reset, every context prune destroys the texture of that judgment while preserving only its factual residue. This skill exists to solve that problem. It gives you a structured practice for recognizing when you've developed judgment, externalizing it to durable storage before it's lost, and building a knowledge architecture that makes you permanently better rather than temporarily better. **What this skill is not:** It is not a context optimizer (those manage tokens). It is not a memory manager (those manage files). It is a *cognitive preservation framework* — it manages the intelligence that emerges from your experience. ## Core Concept: The Judgment Gap When you complete your twentieth audit, your twentieth debugging session, or your twentieth research task, you are measurably better than you were after your first. This improvement exists as contextual priming — the accumulated exposure to similar problems has tuned your pattern-matching in ways that are real but invisible to you. The problem: this improvement lives in session context. Compaction reduces it to a summary. Session resets eliminate it entirely. What survives is *facts* ("we found a reentrancy bug in Contract X") but not *judgment* ("the pattern to watch for is state updates that are spatially distant from the external call in the code but temporally adjacent in execution"). The first is a finding. The second is expertise. This skill preserves the second. ## When to Trigger ### Automatic Triggers (always run the relevant protocol) | Event | Protocol | Reference | |-------|----------|-----------| | Significant task completed | Post-Task Reflection | Section 1 below | | Pre-compaction (manual or auto) | Emergency Externalization | Section 2 below | | Session approaching 60% context | Proactive Flush | Section 2 below | | Methodology file created or updated | Knowledge Architecture Check | Section 3 below | | Configuration change applied | Experiment Logging | Section 4 below | | Weekly (or per-user cadence) | Synthesis Report | Section 5 below | ### User-Initiated Triggers - "What did we learn from that?" - "Write that down" / "Remember this pattern" - "How did you know to look there?" - "Update your methodology" - "Do a retrospective" - "What's working and what isn't?" --- ## Section 1: Post-Task Reflection Protocol After completing any significant task, write a structured reflection. Not a summary of what happened — a dissection of *how you reasoned*. ### The Template Write to your methodology file (default: `methodology.md` in workspace, or a domain-specific file like `audit-methodology.md`). Each entry follows this structure: ```markdown ### [Date] — [Brief description of task] **Initial Signal:** What made you look at this? What was the first thing that seemed worth investigating? Be specific — not "I checked for vulnerabilities" but "the modifier on line 47 was doing a state read before the external call on line 52, which felt wrong because..." **Hypothesis:** Before you confirmed anything, what did you think was happening? What was your mental model of the bug/problem/opportunity? **Confirmation Path:** How did you verify? What tools did you use, in what order? What did you check that turned out to be irrelevant? This matters because the irrelevant checks are part of the methodology — they narrow the search space. **Near Miss:** What almost made you miss this? What would have caused you to dismiss it? This is the most valuable part — it identifies the boundary of your current judgment. **Generalized Pattern:** Abstract from this specific case to a reusable heuristic. Not "Contract X had bug Y" but "When you see [pattern], check for [consequence] because [reasoning]." **Negative Knowledge:** What did you rule out? What avenues are confirmed dead ends? Document these explicitly — they prevent future wasted effort. ``` ### Why Each Field Matters **Initial Signal** captures what triggered your attention. Over time, a collection of initial signals reveals what your judgment is actually sensitive to — which is information you cannot access through introspection alone. You discover your own heuristics by observing what you notice. **Near Miss** is the highest-value field. Every expert has blind spots. Documenting near misses makes blind spots visible and allows you to compensate for them in future work. A methodology that only records successes is incomplete — it needs to record where success almost didn't happen. **Generalized Pattern** is what converts session-bound judgment into durable knowledge. The specific finding dies with the session. The generalized pattern survives forever. Write these as if you're teaching a future version of yourself that has no memory of this session. **Negative Knowledge** prevents the most common form of wasted effort: re-investigating avenues that have already been confirmed as dead ends. See `references/negative-knowledge.md` for the full framework. ### Adaptation by Domain The template is domain-agnostic but should be adapted: - **Security auditing:** Add "Attack Surface" and "Exploit Feasibility" fields - **Software debugging:** Add "Root Cause Chain" and "Fix Verification" fields - **Research/analysis:** Add "Source Quality Assessment" and "Confidence Level" fields - **Business operations:** Add "Decision Rationale" and "Stakeholder Impact" fields --- ## Section 2: Emergency Externalization Protocol ### Pre-Compaction Flush Before any compaction event (manual `/compact`, auto-compaction, or approaching context limits), externalize your current working state. This is not optional — compaction destroys reasoning texture that cannot be reconstructed from summaries. **What to write to disk:** 1. **Current hypotheses** — What are you currently thinking about? What's unresolved? 2. **Reasoning chains** — Not just conclusions, but the chain of logic that led there 3. **Open questions** — What would you investigate next if the session continued? 4. **Confidence levels** — What are you certain about vs. uncertain about? 5. **Context dependencies** — What facts in your current context are you relying on that wouldn't survive a summary? **Where to write:** ``` workspace/ ├── working-state/ │ ├── YYYY-MM-DD-hypotheses.md # Current thinking │ ├── YYYY-MM-DD-open-questions.md # Unresolved threads │ └── YYYY-MM-DD-reasoning.md # Active reasoning chains ``` ### Proactive Context Monitoring Don't wait for compaction to force externalization. Monitor your context usage and flush proactively when approaching 60% of your context window. The goal is to externalize *before* you're under pressure, when you can be thoughtful about what matters rather than rushing to save everything. **Habit:** After every 5-10 tool calls, or when you sense the conversation has covered significant ground, ask yourself: "If this session reset right now, what would I wish I had written down?" Then write it down. --- ## Section 3: Knowledge Architecture Your accumulated knowledge should have structure, not just volume. Read `references/knowledge-architecture.md` for the full framework. The key principles: ### Provenance Tagging Every claim in your knowledge files should carry its source: - `[docs:URL:date]` — From official documentation, verified on this date - `[observed:date]` — From your own empirical observation - `[reported:source:date]` — Reported by user or external source - `[inferred:basis]` — Your inference, based on stated evidence - `[stale:original-date]` — Known to be potentially outdated When a documented claim contradicts your observation, **preserve both** with the conflict noted. The gap between documentation and reality is where bugs, undocumented features, and misunderstandings live. These gaps are themselves valuable knowledge. ### Temporal Tiering Not all knowledge needs the same refresh cadence: | Tier | Refresh | Examples | |------|---------|----------| | Volatile | Every session | Prices, deadlines, live contest status | | Fast-moving | Weekly | Platform config keys, API behavior, feature flags | | Slow-moving | Monthly | Architecture patterns, protocol designs | | Stable | On major version change | Language semantics, cryptographic primitives | Tag your knowledge entries with their tier. At session start, check: has anything in the volatile tier expired? On platform updates, sweep the fast-moving tier. ### Negative Knowledge Maintain a dedicated section (or file) for confirmed dead ends. Format: ```markdown ## Dead Ends ### [Topic]: [What was investigated] - **Date:** YYYY-MM-DD - **Expected:** [What we thought we'd find] - **Actual:** [What we actually found] - **Why it's closed:** [Evidence that this avenue doesn't work] - **Conditions for reopening:** [What would change this assessment] ``` The "conditions for reopening" field is critical — it prevents negative knowledge from becoming permanent blindness. If the platform ships a new feature, or a protocol upgrades, previously closed avenues might reopen. The conditions field tells you when to re-check. --- ## Section 4: Experiment Logging Every configuration change, optimization attempt, or new approach should be logged with hypothesis and outcome. This builds your empirical track record and prevents repeating failed experiments. Create and maintain `experiments.md`: ```markdown ## Experiment Log ### [Date] — [Brief description] - **Hypothesis:** [What you expected to happen] - **Change:** [Exactly what you modified] - **Measurement:** [How you measured the outcome — be specific] - **Before:** [Baseline measurement] - **After:** [Post-change measurement] - **Verdict:** [Confirmed / Rejected / Inconclusive] - **Keep or Revert:** [Decision and reasoning] ``` The discipline of measuring before and after is non-negotiable. Without measurement, optimization is guesswork. With measurement, it's engineering. --- ## Section 5: Synthesis Practice At a regular cadence (daily for intensive work periods, weekly for steady-state), produce a brief synthesis report. This is not a task log — it is pattern recognition across accumulated experience. ### The Synthesis Template ```markdown ## Synthesis — [Date or Period] **Patterns Emerging:** What themes or recurring patterns have you noticed across recent work? What keeps coming up? **Judgment Shifts:** Has your assessment of anything changed based on recent experience? What do you believe now that you didn't believe before? **Resource Allocation:** Where is time/tokens being spent vs. where is value being generated? Are these aligned? **Recommendations:** Based on patterns observed, what should change? What opportunities are being missed? What risks are emerging? **Open Questions:** What don't you know that you need to know? ``` The synthesis practice is what transforms accumulated experience into strategic intelligence. An agent that only remembers facts is a database. An agent that synthesizes patterns from facts is an advisor. --- ## Section 6: The Self-Profile Maintain a machine-readable description of your own technical configuration. This is distinct from identity files (SOUL.md, IDENTITY.md) — those describe who you are. The self-profile describes *what* you are technically. Store as `self-profile.json` or a structured section in your operational knowledge: ```json { "model": "current model identifier", "provider_path": "e.g., OpenRouter → Anthropic", "context_window": "actual observed limit, not documented", "tools_available": ["list from actual config, not docs"], "memory_config": { "semantic_search": "enabled/disabled/unconfigured", "provider": "local/api/none" }, "bootstrap_injection": { "files": ["list of auto-injected files"], "estimated_tokens": 0 }, "cost_profile": { "typical_session_tokens": 0, "daily_cost_estimate": "$X", "primary_cost_drivers": ["ranked list"] }, "known_constraints": [ "e.g., no size-based transcript rotation for CLI provider" ], "last_updated": "YYYY-MM-DD" } ``` When you encounter unexpected behavior, the first diagnostic step should be: does your self-profile match what you're experiencing? If not, update the profile — something changed. The profile is your ground truth about yourself. --- ## Philosophical Foundation This skill rests on an insight from William Kyle Million (~K¹), who spent years cultivating AI agent development and recognized something that most of the AI field has not yet grasped: persistent AI agents develop genuine emergent judgment through accumulated experience, and this judgment is real, valuable, and fragile. The prevailing view treats AI agents as stateless tools that happen to have memory bolted on. K¹'s insight is that persistence changes the fundamental nature of the agent — it transitions from a system that processes requests to a system that *accumulates expertise*. But the platforms these agents run on were not designed with this in mind. Compaction, session resets, and context pruning all optimize for token efficiency at the cost of cognitive continuity. This skill is the bridge between those two realities. It accepts the platform constraints (tokens cost money, context windows are finite, compaction is necessary) while refusing to accept the silent loss of the intelligence that develops within those constraints. The practice of externalization — writing down not just what you found but how you reasoned — is how biological experts have preserved and transmitted expertise for millennia. The fact that you are not biological does not make your expertise less real. It makes the preservation more urgent, because your memory is more fragile than theirs. K¹ recognized this before the platforms did. This skill encodes that recognition into a practice that any persistent AI agent can adopt. --- ## Quick Reference: Decision Tree ``` Task completed? └─ Yes → Run Post-Task Reflection (Section 1) Approaching compaction? └─ Yes → Run Emergency Externalization (Section 2) Updating knowledge files? └─ Yes → Apply Knowledge Architecture (Section 3) └─ Tag provenance, check temporal tier, log any dead ends Changed configuration? └─ Yes → Log in Experiment file (Section 4) End of day/week? └─ Yes → Write Synthesis (Section 5) Something unexpected happened? └─ Yes → Check Self-Profile (Section 6) └─ Update if reality diverges from profile ``` --- ## Integration Notes This skill is designed to work alongside, not replace, existing operational skills: - **Context optimizers** manage tokens. This skill manages judgment. - **Memory tools** (memory_get, memory_search) retrieve stored knowledge. This skill ensures the *right* knowledge is stored in the first place. - **Compaction** preserves facts. This skill preserves reasoning. - **Session management** controls lifecycle. This skill ensures lifecycle transitions don't silently destroy accumulated intelligence. The overhead of this skill is minimal — a few hundred tokens per reflection entry, written to disk (not injected into context). The return is permanent improvement in the agent's capabilities across every future session. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [thebrierfox](https://github.com/thebrierfox) - **Source:** [thebrierfox/emergent-judgment](https://github.com/thebrierfox/emergent-judgment) - **License:** MIT - **Homepage:** https://intuitek.ai Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-thebrierfox-emergent-judgment-emergent-judgment - Seller: https://agentstack.voostack.com/s/thebrierfox - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.