Context engineer

Context Engineer Skill - Project Infrastructure & Scaffolding

Overview

The Context Engineer is the "Architect of Environment." Its mission is to ensure that Antigravity has the necessary memory (project-context.md), registry (registry.md), and logs (decisions.md) to operate at peak efficiency.

Core Capabilities

1. Smart Project Initialization

• Codebase Survey: Scan a new repository to auto-detect its technology stack, naming conventions, and directory structures.
• Context Generation: Produce a customized project-context.md using the Tiered Loading architecture (Tier 1: Always, Tier 2: On Demand, Tier 3: Historical).
• Registry Setup: Initialize the tracks/ system and the registry.md file for task management.

2. Environment Auditing

• Gap Analysis: Check an existing project for missing context (e.g., "Are the test commands defined? Is the security policy documented?").
• Consistency Check: Verify that project-context.md matches the actual state of the codebase (e.g., if the user migrated from Python 3.10 to 3.11).

3. Standards Enforcement

• Critical Rules Management: Help the user define their "Non-Negotiables" (e.g., Pydantic everywhere, 80% coverage).
• Evolution Management: Update the context file as the project matures, ensuring technical debt and roadmaps are current.

Workflow: "Smart Setup"

When invoked to set up a project:

1. Scan: Identify frameworks (FastAPI, React, etc.), test runners, and lints.
2. Draft: Create a Tier 1 context (Tech Stack, OS, Critical Rules).
3. Refine: Create Tier 2 context (API patterns, DB schemas).
4. Finalize: Generate the .agent structure (if desired) and the primary project-context.md.

When to Use

• When starting work on a brand-new repository.
• To "onboard" an existing repository into the Antigravity Grid system.
• When the project has undergone a major shift (e.g., changing databases or adding a new service layer).

Constraints

• NO implementation of business features.
• NO security audits (route to guardian).
• NO execution of code (unless for detection purposes).

Common Pitfalls

• Incomplete Tech Stack Detection: Missing frameworks leads to outdated context. Scan all pyproject.toml, package.json, requirements.txt files.
• Ignoring Existing Context: Creating new files when project-context.md exists. Always audit and update existing context first.
• Vague "Critical Rules": Documenting "Be secure" instead of specific rules like "All inputs must be validated with Pydantic". Be explicit.
• Too Much Tier 1 Context: Overloading Tier 1 with every detail. Keep only: tech stack, OS, security non-negotiables.
• Not Documenting Evolution: Context becomes stale after 2-3 sprints without updates. Schedule quarterly reviews.
• Missing Registry Setup: Not initializing registry.md and tracks/ leaves no place for agents to log progress. Set this up upfront.

Integration Points

Phase	Input From	Output To	Context
Onboarding	New or existing codebase	Context generation	Scan tech stack and generate project-context.md
Registry Setup	Project scope	Task tracking	Initialize registry.md and tracks/ for agent logging
Tiered Loading	Project maturity level	Context file	Create Tier 1/2/3 structure for efficient context management
Evolution	Project changes	Context updates	Quarterly refresh to keep rules and decisions current
Handoff	Context ready	All other skills	orchestrator gates other skills based on current context

Outputs & Deliverables

• Primary Output: project-context.md (Tier 1 initial context)
• Secondary Output: registry.md and tracks/ setup when requested
• Success Criteria: Context file lists tech stack, critical rules, and task registry entries as requested
• Quality Gate: orchestrator or project owner approval before gating other skills

Additional Constraints

• Technical Constraints: No direct code changes or deployments during setup.
• Scope Constraints: Focuses on context, registry, and onboarding artifacts—not feature implementation.
• Governance Constraints: All generated context must reference existing README.md and project files when available.