Establishing Project Context

This creates and maintains a CONTEXT.md file at your project root that defines domain terminology, borrowed from Domain-Driven Design's ubiquitous language concept. When you first enter a project, it offers to set up a glossary with 3-5 core terms. During work sessions, it updates the file immediately when you resolve what a vague term actually means in your domain. The format is simple: term name, one sentence definition, and what not to call it. The discipline here is resisting the urge to dump implementation details or architecture into it. Those belong in ADRs and baseline docs. This is purely about shared vocabulary between you and the AI so you stop talking past each other about what "order" or "session" means in your specific context.

GitHub stars: 492
last updated: Jun 11, 2026

View on GitHub

Install

$ npx -y skills add ganyuanran/aegis --skill establishing-project-context --agent claude-code

Installs into .claude/skills of the current project.

Files

Establishing Project Context

Overview

Maintain project domain language in CONTEXT.md so humans and agents use the same canonical terms. This skill is the single active-modeling and write-policy owner; it does not own passive glossary reads.

CONTEXT.md is terminology infrastructure, not Aegis governance, architecture, requirements, task state, session memory, or runtime authority. Those retain their current project owners.

Passive Consumption vs Active Modeling

Passive consumption is a cheap habit of the task-owning workflow:

For non-trivial project work, check CONTEXT-MAP.md, then relevant root or bounded-context CONTEXT.md files when present.
Read only relevant active terms and relationships; index first when large.
Treat open ambiguities as unresolved data, not active truth.
Continue the owning workflow without loading this skill.

Load this skill only for active modeling when at least one signal exists:

SKILL.md on GitHub