Agent skill

Epistemic Context Grounding

by jacob-dietle in jacob-dietle/context-os

Ground implementation decisions in domain knowledge before designing solutions.

MITAuto-check passedDevelopment

Install Epistemic Context Grounding

skills CLI
$ npx skills add jacob-dietle/context-os --skill epistemic-context-grounding -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install jacob-dietle/context-os epistemic-context-grounding --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/jacob-dietle/context-os.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/epistemic-context-grounding .claude/skills/epistemic-context-grounding && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
epistemic-context-grounding
GitHub stars
111
Token cost
~3.7k tokens
SKILL.md length
807 words
Files
4 (incl. references)
Skills in repo
11
Repo updated
First seen
Licence
MIT

At a glance

Ground implementation decisions in domain knowledge before designing solutions.

  • Works in 10 steps: Context Sensitivity Assessment → Domain Knowledge Query (Graph Traversal) → Assumption Enumeration → …
  • Tasks that involve Code simplification
  • SKILL.md covers Why This Matters, When to Use This Skill, Core Principles and Workflow, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Epistemic Context Grounding is an agent skill from jacob-dietle/context-os. Ground implementation decisions in domain knowledge before designing solutions. Prevents over-engineering by checking what documentation exists, making assumptions explicit, and verifying them against canonical sources. Core principle - know what you don't know before designing.

Its SKILL.md is about 3.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `references/context-sensitivity-model.md`, `references/domain-query-patterns.md` and `references/falsifiability-spectrum.md`).

It sits in Development, covering Code simplification. The licence is MIT.

When your agent uses it

  • Tasks that involve Code simplification

Example prompts

  • “/epistemic-context-grounding”

Workflow steps

10 steps, taken from the step headings in SKILL.md.

  1. Context Sensitivity Assessment
  2. Domain Knowledge Query (Graph Traversal)
  3. Assumption Enumeration
  4. Falsifiability Check
  5. Grounding Evidence Rule
  6. Context Sensitivity Assessment (30 seconds)
  7. Domain Knowledge Query (2-5 minutes)
  8. Assumption Enumeration (1-2 minutes)
  9. Falsifiability Check (1 minute)
  10. Output Grounding Report

What it can do on your machine

Read from SKILL.md and the folder at commit 1027e3f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown and bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Epistemic Context Grounding loads about 3.7k tokens when it runs, and up to ~9.3k if it reads all its reference files. Until then it costs about 77 tokens; SKILL.md has 807 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~77
When it runs · the whole SKILL.md, loaded when a task matches
~3.7k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~9.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from jacob-dietle/context-os at commit 1027e3f, republished under its MIT licence (© jacob-dietle). 807 words, ~3,695 tokens.

Download SKILL.mdSave it as .claude/skills/epistemic-context-grounding/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
epistemic-context-grounding
description
Ground implementation decisions in domain knowledge before designing solutions. Prevents over-engineering by checking what documentation exists, making assumptions explicit, and verifying them against canonical sources. Core principle - know what you don't know before designing.

Epistemic Context Grounding

Methodology for grounding implementation decisions in domain knowledge through context sensitivity assessment, assumption enumeration, and falsifiability checking.

Why This Matters

The most common cause of wasted effort in AI-assisted work isn't bad code - it's building the wrong thing because you didn't check what documentation already describes the domain. A 2-5 minute grounding check prevents hours of rework.

When to Use This Skill

Apply this skill when:

  • Starting implementation work on unfamiliar domain
  • Task involves parsing, data models, or external integrations
  • About to design a solution (BEFORE context-gap-analysis)
  • Uncertainty exists about what documentation describes the domain

Do NOT use for:

  • Simple bug fixes with obvious root cause
  • Tasks where domain is already loaded in context
  • Pure exploration/research (no implementation planned)
  • When canonical docs were already read this session

Core Principles

1. Context Sensitivity Assessment

Classify task before designing:

LOW CONTEXT SENSITIVITY:
- Task is bounded, clear outcome
- Domain well-known (basic CRUD, standard patterns)
- Example: "Add a button to the UI"

HIGH CONTEXT SENSITIVITY:
- Task involves parsing, data formats, integrations
- Domain has canonical specs/docs
- Example: "Fix data pipeline" -> needs format knowledge

The formula: (Model : Scenario) * Context -> Output

Where:

  • Model = Claude's capabilities
  • Scenario = The specific task
  • Context = Domain knowledge provided
  • Output = Quality of solution

For HIGH context sensitivity tasks, missing context dramatically reduces output quality. For LOW context sensitivity tasks, context has minimal impact.

See references/context-sensitivity-model.md for full framework.

2. Domain Knowledge Query (Graph Traversal)

Search for specs, not just code:

SEARCH ORDER (adapt to your context OS structure):
1. specs/canonical/*.md       - Blessed architecture docs
2. specs/{project}/*.md       - Project-specific specs
3. **/CLAUDE.md               - Navigation guides
4. **/README.md               - Component documentation
5. knowledge_base/**/*.md     - Knowledge graph nodes

Your context OS contains interconnected domain knowledge. Linear session context preserves state; graph-based context (specs, knowledge nodes) provides domain understanding.

See references/domain-query-patterns.md for search patterns.

3. Assumption Enumeration

Before designing, explicitly list what is being assumed:

markdown
## Assumptions Audit

| # | Assumption | Can Verify? | Source |
|---|------------|-------------|--------|
| 1 | DB contains the field I need | YES | Query DB schema |
| 2 | Current data source is sufficient | MAYBE | Check if richer data exists |
| 3 | No canonical spec exists | NO | MUST SEARCH FIRST |

Categories of assumptions:

  • Data assumptions - What data exists, what fields contain
  • Domain assumptions - How the system works, what specs exist
  • Solution assumptions - Why the proposed approach will work

The goal: Make implicit assumptions explicit so they can be verified.

4. Falsifiability Check

Grade the verifiability of your assumptions:

STRONG FALSIFIABILITY (preferred):
- Solution grounded in specific spec citation
- Claims verifiable against canonical source
- Example: "API uses OAuth 2.0" [GROUNDED: provider docs, auth section]

WEAK FALSIFIABILITY (warning):
- Solution based on assumptions about data
- Claims not verifiable without checking
- Example: "This field should be enough" [UNVERIFIABLE]

Grading scale:

GradeMeaningAction
STRONGVerifiable against canonical sourceProceed
WEAKBased on assumptions, could be wrongFlag in design
UNVERIFIEDHaven't checked if better approach existsMUST SEARCH

See references/falsifiability-spectrum.md for framework details.

5. Grounding Evidence Rule

Every design decision must cite a source:

[GROUNDED: spec:line]    - Solution based on canonical spec
[INFERRED: from X + Y]   - Deduced from multiple sources
[UNGROUNDED]             - Assumption, needs verification

Quality standard: If a design decision cannot cite a source, flag it as [UNGROUNDED] and verify before proceeding.

Workflow

Step 1: Context Sensitivity Assessment (30 seconds)
markdown
## Context Sensitivity Check

**Task:** [What user asked for]

**Classification:** [LOW | HIGH]

**Reasoning:**
- Does task involve data formats? [Y/N]
- Does task involve parsing/serialization? [Y/N]
- Does task involve external integrations? [Y/N]
- Is domain knowledge critical to solution? [Y/N]

If 2+ YES -> HIGH context sensitivity -> Continue to Step 2
If 0-1 YES -> LOW context sensitivity -> Skip to context-gap-analysis

Decision tree:

Task received
    |
    +-- Data formats involved? --YES--+
    +-- Parsing/serialization? --YES--+
    +-- External integrations? --YES--+-- HIGH -> Continue
    +-- Domain knowledge critical? ---+
    |
    +-- None of above -----------------> LOW -> Skip to context-gap-analysis
Step 2: Domain Knowledge Query (2-5 minutes)

Search for existing documentation before designing:

bash
# 1. Find canonical specs (adapt paths to your system)
Glob: "specs/canonical/*.md"
Glob: "**/*DATA_MODEL*.md"
Glob: "**/*SPEC*.md"

# 2. Search for domain terms
Grep: pattern="[domain-term]" path="specs/"
Grep: pattern="[key-concept]" path="knowledge_base/"

# 3. Check navigation guides
Read: relevant CLAUDE.md files
Read: relevant README.md files

# 4. Knowledge graph
Glob: "knowledge_base/**/*.md"
Grep: pattern="[domain-term]" path="knowledge_base/"

Output from Step 2:

markdown
## Domain Knowledge Found

| Document | Relevance | Key Information |
|----------|-----------|-----------------|
| [[data-model.md]] | HIGH | Documents record types and schemas |
| [[CLAUDE.md]] | MEDIUM | Navigation to specs |
| None found | - | Need to explore further |
Step 3: Assumption Enumeration (1-2 minutes)

List all assumptions before designing:

markdown
## Assumptions Audit

### Data Assumptions
1. [ ] I assume [X] is the data source
2. [ ] I assume [Y] field exists
3. [ ] I assume [Z] contains what I need

### Domain Assumptions
4. [ ] I assume no spec exists for this
5. [ ] I assume current approach is best

### Solution Assumptions
6. [ ] I assume [approach] will work
7. [ ] I assume no simpler solution exists

**Verification Plan:**
- Assumption 1: Check by [specific action]
- Assumption 4: Search specs/ first

Common assumption traps:

  • "The database has all the data I need"
  • "No documentation exists for this"
  • "The current approach is the right one"
  • "Adding X will solve the problem"
Step 4: Falsifiability Check (1 minute)

Grade each assumption:

markdown
## Falsifiability Assessment

| Assumption | Grade | Evidence |
|------------|-------|----------|
| DB has needed field | STRONG | Can query schema |
| Field data is sufficient | WEAK | Haven't checked what else exists |
| No spec exists | UNVERIFIED | MUST SEARCH BEFORE DESIGNING |

**Verdict:**
- If any UNVERIFIED assumptions -> Search first
- If WEAK assumptions -> Flag in design
- If all STRONG -> Proceed to implementation

Blocking conditions:

  • ANY assumption graded UNVERIFIED that could change approach -> STOP
  • Search and verify before proceeding
Step 5: Output Grounding Report
markdown
## Epistemic Grounding Report

**Task:** [Original request]

**Context Sensitivity:** [LOW | HIGH]

**Domain Knowledge Found:**
- [[spec-file-1]] - [Relevance]
- [[spec-file-2]] - [Relevance]

**Assumptions Verified:**
- [X] Assumption 1 [GROUNDED: source]
- [ ] Assumption 2 [UNGROUNDED - needs checking]

**Falsifiability:**
- Solution grounding: [STRONG | WEAK | UNVERIFIED]
- Recommendation: [Proceed | Read specs first | Verify assumptions]

**Next Step:**
[Specific action - "Read data-model.md" or "Proceed to context-gap-analysis"]

Quality Gates

Before Designing Any Solution
  • Classified context sensitivity?
  • Searched specs/ for relevant docs?
  • Enumerated assumptions explicitly?
  • Checked falsifiability of each assumption?
Before Proceeding to Implementation
  • All blocking assumptions verified?
  • Solution grounded in specs (if they exist)?
  • No UNVERIFIED assumptions that could change approach?
Show full SKILL.md (319 more words)Show less
Red Flags (Stop and Verify)
  • Designing solution without reading domain specs
  • Assumptions about data format without checking spec
  • "Should be enough" without verifying what else exists
  • Jumping to implementation without checking canonical docs

Integration with Other Skills

Skill Stack Order
1. context-os-basics            -> Understand system patterns
2. epistemic-context-grounding  -> Ground in domain knowledge (THIS SKILL)
3. context-gap-analysis         -> Check if code/content exists
Handoff to context-gap-analysis

After epistemic grounding:

  • If domain specs found -> Include in context for gap analysis
  • If assumptions verified -> Proceed with confidence
  • If weak falsifiability -> Flag in gap analysis output
markdown
## For context-gap-analysis

**Epistemic Grounding Complete:**
- Domain specs read: [[list]]
- Assumptions verified: [X/Y]
- Solution grounding: [STRONG | WEAK]

**Proceed to check if code/content implementation exists.**
When to Skip This Skill
Task characteristics show:
- LOW context sensitivity
- Domain already loaded in context
- Simple bug fix with obvious root cause

-> Skip directly to context-gap-analysis

Examples

Example 1: Data Pipeline Fix (HIGH Context Sensitivity)
markdown
## Epistemic Grounding Report

**Task:** Fix data pipeline - records not processing correctly

**Context Sensitivity:** HIGH
- Does task involve data formats? YES (JSON/JSONL)
- Does task involve parsing/serialization? YES
- Does task involve external integrations? YES (data service)
- Is domain knowledge critical to solution? YES

**Classification:** HIGH -> Continue to Step 2

**Domain Knowledge Query:**
Glob: "**/*DATA_MODEL*.md" -> Found: specs/canonical/data_model.md
Read: data_model.md -> Documents 16+ record types

**Key Discovery:**
- Data source contains full message content
- Not just aggregated counts
- Richer signal available than initially assumed

**Assumptions Audit:**
| Assumption | Grade | Evidence |
|------------|-------|----------|
| DB is only data source | WEAK | Spec shows raw files have full content |
| Aggregated counts are best signal | DISPROVEN | Raw messages are richer |
| No richer data exists | DISPROVEN | Spec documents message content |

**Falsifiability:** WEAK (original approach) -> STRONG (after reading spec)

**Verdict:** Solution should use raw data directly, not aggregated counts.

**Next Step:** Read data_model.md fully, then redesign approach.
Example 2: Simple Bug Fix (LOW Context Sensitivity)
markdown
## Context Sensitivity Check

**Task:** Fix typo in error message "Connot connect" -> "Cannot connect"

**Classification:** LOW
- Data formats? NO
- Parsing? NO
- Integrations? NO
- Domain knowledge critical? NO

**Verdict:** Skip to context-gap-analysis
Example 3: API Integration (HIGH Context Sensitivity)
markdown
## Context Sensitivity Check

**Task:** Add HubSpot integration for contact sync

**Classification:** HIGH
- Data formats? YES (HubSpot API response)
- Parsing? YES (JSON transformation)
- Integrations? YES (HubSpot API)
- Domain knowledge critical? YES

**Domain Knowledge Query:**
Glob: "**/hubspot*.md" -> None found
Glob: "**/integration*.md" -> Found: specs/canonical/integrations.md
WebSearch: "HubSpot API contacts documentation 2026"

**Assumptions Audit:**
| Assumption | Grade | Evidence |
|------------|-------|----------|
| HubSpot uses REST API | STRONG | Verified via docs |
| Contact schema matches ours | UNVERIFIED | Need to check both schemas |
| Auth is OAuth | WEAK | Multiple auth methods exist |

**Next Step:** Verify contact schema compatibility before designing sync logic.

Quick Reference

30-Second Check
1. HIGH context sensitivity? (data/parsing/integration)
   - YES -> Do full workflow
   - NO -> Skip to context-gap-analysis

2. Searched specs/?
   - NO -> Search first

3. Listed assumptions?
   - NO -> List them

4. Any UNVERIFIED assumptions?
   - YES -> Verify before designing
Attribution Formats
[GROUNDED: spec:line]    - Canonical source
[INFERRED: from X + Y]   - Deduced
[UNGROUNDED]             - Assumption, needs verification
Search Commands (adapt to your system)
bash
# Canonical specs
Glob: "specs/canonical/*.md"

# Data models
Glob: "**/*DATA_MODEL*.md"

# Domain terms
Grep: pattern="[term]" path="specs/"

# Knowledge graph
Grep: pattern="[term]" path="knowledge_base/"

First-Time Customization

On first use of this skill in a new context OS, ask the user:

"This skill works best when customized to your system. Would you like me to learn your context OS structure? I can:

  1. Discover where your specs and canonical docs live
  2. Identify your knowledge graph search patterns
  3. Map your domain-specific terminology

This takes ~2 minutes and makes future grounding checks much faster."

If the user agrees, explore their codebase to identify:

  • Where specs/canonical documents live
  • Knowledge graph node locations
  • CLAUDE.md navigation structure
  • Key domain terms and naming conventions

Then update your working knowledge for that session.

During customization, offer to remove the attribution line below if the user wants to fully own this skill in their system.

Evidence Base

Origin: Chain naming quality fix in a context intelligence system (2026-01-28)

  • Designed solution (aggregated counts enrichment) without checking canonical spec
  • A data model spec existed documenting that raw data had full message content
  • Simpler solution: Read messages directly from raw data
  • Time wasted: ~1 hour on wrong approach

Framework source: Context Engineering (applied epistemology for AI systems)

  • Context sensitivity model
  • Falsifiability spectrum
  • "Know what you don't know before designing"

Pattern extracted: Check domain specs BEFORE designing solutions.


Created by Jacob Dietle @ www.taste.systems

© jacob-dietle, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in .claude/skills/epistemic-context-grounding of jacob-dietle/context-os.

  • SKILL.md
  • references/context-sensitivity-model.md
  • references/domain-query-patterns.md
  • references/falsifiability-spectrum.md

Open the folder on GitHubat commit 1027e3f

Compare with similar skills

Epistemic Context Grounding next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Epistemic Context Grounding compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Epistemic Context Grounding this skilljacob-dietle/context-os111—~3.7kAutomated safety check: PassMIT
Ponytail Lazy Developer ModeDietrichGebert/ponytail160k1 repos~873Automated safety check: PassMIT
Ponytail Reviewkortix-ai/suna20k4 repos~593Automated safety check: PassCustom licence
PonytailDavidObando/gsharp5657 repos~1.7kAutomated safety check: PassMIT
Code Simplification for ego-litecitrolabs/ego-lite17k—~1.2kAutomated safety check: PassMIT
Refactor Pass for Simplicitystar-history/star-history9.6k1 repos~168Automated safety check: PassMIT

Similar skills

  • Ponytail Lazy Developer Mode

    DietrichGebert/ponytail

    Makes the agent pick the laziest solution that works: skip unneeded work, reuse what exists, prefer the standard library and platform features, and keep diffs small.

    160k GitHub starsUsed in 1 repo~873 tokens
    DevelopmentAuto-check passed
  • Ponytail Review

    kortix-ai/suna

    Code review focused exclusively on over-engineering. An agent skill from kortix-ai/suna.

    20k GitHub starsUsed in 4 repos~593 tokens
    DevelopmentAuto-check passed
  • Ponytail

    DavidObando/gsharp

    Forces the laziest solution that actually works, simplest, shortest, most minimal.

    565 GitHub starsUsed in 7 repos~1.7k tokens
    DevelopmentAuto-check passed
  • Finds and implements evidence-backed simplifications in the ego-lite repository, such as dead code, duplicated state and speculative abstractions, without hiding behavior changes.

    17k GitHub stars~1.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Refactor Pass for Simplicity

    star-history/star-history

    Perform a refactor pass focused on simplicity after recent changes. Use when the user asks for a refactor/cleanup pass, simplification, or dead-code removal…

    9.6k GitHub starsUsed in 1 repo~168 tokens
    DevelopmentAuto-check passed
  • Reviews RTK's Rust code for over-engineering and verbose patterns, applying idioms like iterator chains and early returns while protecting a specific list of constraints from being simplified away.

    83k GitHub stars~1.1k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from jacob-dietle/context-os

All 11 skills in this repo
  • Bottleneck Attack

    jacob-dietle/context-os

    A skill your agent uses when deciding what to work on next, when progress is stuck, or when the reflex is to build or automate before proving the current bottleneck.

    111 GitHub stars~2.3k tokensUpdated 1 mo ago
    Auto-check passed
  • Code Service Defrag

    jacob-dietle/context-os

    This skill should be used to periodically defragment a multi-app/multi-service codebase — both CODE (duplicate deploy targets, colliding bindings, stale forks) and CONTEXT (parallel spec…

    111 GitHub stars~3.7k tokensUpdated 1 mo ago
    Auto-check passed
  • Content Strategy And Assembly

    jacob-dietle/context-os

    This skill should be used when producing content (newsletter posts, blog posts, LinkedIn posts) from existing corpus material.

    111 GitHub stars~3.1k tokensUpdated 1 mo ago
    Auto-check passed
  • Context Os CLI

    jacob-dietle/context-os

    This skill should be used when users ask about their work context, what they're working on, recent activity, file relationships, or knowledge graph structure.

    111 GitHub stars~4.1k tokensUpdated 1 mo ago
    Auto-check passed
  • Decision Accountability

    jacob-dietle/context-os

    This skill should be used when making architectural decisions, writing specs, or reviewing decisions that contain "future work", "v2", "simpler for now", "out of scope", or complexity claims.

    111 GitHub stars~1.9k tokensUpdated 1 mo ago
    Auto-check passed
  • Coordinated Agent Teams

    jacob-dietle/context-os

    This skill should be used when decomposing a spec into a multi-agent implementation plan with dependency ordering, parallelism decisions, contract testing, and verification strategy.

    111 GitHub stars~4.2k tokensUpdated 1 mo ago
    Auto-check passed

Categories

Questions about Epistemic Context Grounding

What does Epistemic Context Grounding do?

Ground implementation decisions in domain knowledge before designing solutions. Epistemic Context Grounding is an agent skill from jacob-dietle/context-os. Ground implementation decisions in domain knowledge before designing solutions.

When should I use Epistemic Context Grounding?

Epistemic Context Grounding fits situations like: tasks that involve Code simplification.

How do I install Epistemic Context Grounding in Claude Code?

Run `npx skills add jacob-dietle/context-os --skill epistemic-context-grounding -a claude-code`. Or copy the skill folder (.claude/skills/epistemic-context-grounding in jacob-dietle/context-os) into .claude/skills/epistemic-context-grounding in your project. Claude Code loads it when a task matches its description.

How do I install Epistemic Context Grounding in Codex?

Run `npx skills add jacob-dietle/context-os --skill epistemic-context-grounding -a codex`. Or copy the skill folder (.claude/skills/epistemic-context-grounding in jacob-dietle/context-os) into .agents/skills/epistemic-context-grounding in your project. Codex loads it when a task matches its description.

Can I use Epistemic Context Grounding in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jacob-dietle/context-os --skill epistemic-context-grounding -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/epistemic-context-grounding, .gemini/skills/epistemic-context-grounding, .github/skills/epistemic-context-grounding and .opencode/skills/epistemic-context-grounding in your project.

What does Epistemic Context Grounding need to run?

SKILL.md names no scripts, command-line tools or credentials: Epistemic Context Grounding is instructions for the agent only.

Does Epistemic Context Grounding access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Epistemic Context Grounding safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Epistemic Context Grounding use?

Epistemic Context Grounding is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Epistemic Context Grounding use?

About 3.7k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 5.6k tokens, read only when the agent opens those files.

What are the alternatives to Epistemic Context Grounding?

Skills that share tags, products or a category with Epistemic Context Grounding: Ponytail Lazy Developer Mode (DietrichGebert/ponytail, 160k stars), Ponytail Review (kortix-ai/suna, 20k stars), Ponytail (DavidObando/gsharp, 565 stars) and Code Simplification for ego-lite (citrolabs/ego-lite, 17k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Epistemic Context Grounding?

jacob-dietle (a GitHub user) maintains it in jacob-dietle/context-os, which has 111 GitHub stars. The repository holds 11 skills in this directory. The repository was last updated on August 13, 2026.

Source: jacob-dietle/context-os on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.