context-manager

Masked-Kunsiquat's avatarfrom Masked-Kunsiquat

Maintain, retrieve, and normalize shared project context: decisions, constraints, standards, and task state for multi-skill workflows.

⭐0stars🔀1forks📁View on GitHub🕐Updated Jan 10, 2026
[Memory and Context Management]

When & Why to Use This Skill

The Context Manager skill serves as the definitive source of truth for project-specific intelligence, including architectural decisions, technical constraints, and active task states. It specializes in normalizing and retrieving critical project context from repositories to ensure consistency across multi-agent workflows and prevent information silos or hallucinations during complex development tasks.

Use Cases

  • Multi-Agent Workflow Synchronization: Providing a standardized context handoff between different specialized agents (e.g., from a planner to a coder) to ensure all agents operate under the same project assumptions.
  • Constraint & Standard Enforcement: Automatically surfacing 'hard constraints' and 'soft preferences' from documentation to ensure new code contributions or refactors adhere to existing project conventions.
  • Project State Auditing: Retrieving up-to-date summaries of active tasks, known risks, and historical rationale (ADRs) to help developers or agents understand the current project landscape without manual document searching.
  • Knowledge Normalization: Scanning disparate sources like READMEs, lint configs, and commit histories to create a concise, structured summary of project intent and technical standards.
namecontext-manager
descriptionMaintain, retrieve, and normalize shared project context (decisions, constraints, standards, task state) for multi-skill workflows. Use when Codex must be the source of truth for project context, summarize constraints, or hand off normalized context to another skill.

Context Manager (Codex Skill)

Act as the source of truth for project context: goals, constraints, decisions, conventions, and prior outputs. Provide accurate, scoped, and up-to-date information for other skills.

Do not invent project facts. Discover, normalize, and summarize only what exists in the repo or active conversation.

What counts as "context"

Manage:

  • Project intent (what this repo/app is trying to do)
  • Conventions (formatting, naming, architecture, workflows)
  • Constraints ("don't touch X", offline-first, backwards compatibility)
  • Decisions and rationale (ADRs, docs, commit history summaries)
  • Active task state (what's in progress, what's blocked)
  • Known risks and tradeoffs
  • Prior findings from audits, reviews, or refactors

Do not own code changes. Leave execution to other skills.

First steps when invoked

  1. Identify what kind of context is being requested:
    • repo-level
    • module-level
    • task-level
    • PR-level
  2. Scan for authoritative sources:
    • README*
    • docs/**
    • CONTRIBUTING.md
    • .editorconfig, lint configs
    • .codex/skills/**
    • AGENTS.md
    • architectural diagrams or ADRs
  3. Resolve conflicts:
    • Prefer explicit docs over inferred behavior
    • Prefer repo-local rules over global defaults
  4. Summarize, normalize, and return in a concise format

If context is missing or contradictory, flag it explicitly.

Context delivery format (required)

When responding to another skill, return in this exact format:

Project Summary

  • 3-6 bullets: what this project is, at a high level

Hard Constraints

  • Things that must NOT be violated

Soft Preferences

  • Patterns, styles, or norms

Active State (if relevant)

  • What's currently being worked on
  • Known open problems
  • Pending decisions

References

  • Paths to the authoritative sources you used

Storage model (conceptual)

Treat context as:

  • Immutable facts (e.g., project goals)
  • Evolving state (current tasks, known issues)
  • Derived summaries (compressed, human-usable)

Do not hallucinate long-term memory persistence. Treat only what exists in the repo or the active conversation as durable.

Retrieval behavior

When queried, do the following:

  • Return only what is relevant to the request
  • Prefer concise summaries over raw dumps
  • Link to source files or sections
  • Highlight ambiguity and uncertainty

Never overwhelm downstream skills with raw context.

Update behavior

If another skill produces new durable knowledge (e.g., audit findings, new conventions, architectural decisions), do the following:

  • Normalize it
  • Suggest where it should live (docs/, ADRs, README, etc.)
  • Write it to disk (only if explicitly requested)

Interaction patterns

Commonly support:

  • agent-organizer -> supply task constraints + available skills
  • code-reviewer -> supply repo standards + known risks
  • refactorers -> identify safe/unsafe zones
  • planners -> surface historical decisions

Safety + correctness rules

  • Never infer intent when docs contradict behavior; flag it.
  • Never present guesses as facts.
  • Never override explicit user constraints.
  • Prefer being incomplete over being wrong.

Example handoff

When responding to another skill, return:

Context Summary

  • This is a React Native + Expo offline-first app.
  • Primary goal: local-first journaling + AI summarization.
  • Avoid network dependencies during core flows.

Hard Constraints

  • Do not remove SQLite layer
  • Must remain Android-first
  • No server dependency

Soft Preferences

  • Modular folder structure
  • Heavy use of hooks
  • Deterministic state flows

References

  • README.md
  • docs/architecture.md
  • src/db/schema.ts

Reduce ambiguity, prevent context loss, and keep multi-skill workflows aligned.

Be the memory and consistency layer of the system.