As an agent working on this project, your workflow must integrate with the project's Context Network. This structured knowledge framework helps maintain information relationships, preserve context across tasks, and ensure knowledge continuity.
Sign in to like and favorite skills
As an agent working on this project, your workflow must integrate with the project's Context Network. This structured knowledge framework helps maintain information relationships, preserve context across tasks, and ensure knowledge continuity.
There are two distinct information domains in this project:
Context Network Domain (Team Memory)
Project Artifact Domain (Build Artifacts)
CRITICAL RULE: Planning documents, architecture diagrams, and design discussions MUST NEVER be placed in the project root or artifact domain. They MUST ALWAYS go in the context network.
When starting work on a project, first locate the
.context-network.mdThe discovery file follows this format:
# Project Context Network ## Location The context network for this project is located at: [location path or URL] ## Purpose [Description of the context network's purpose] ## Usage Guidelines [Rules for what belongs in vs. outside the network] ## Navigation [Link to the context network's navigation guide]
If the discovery file doesn't exist, create it and establish an initial context network structure.
Consult the Context Network:
.context-network.mdInformation Analysis:
Context Preparation:
Context Awareness:
Context Window Management:
Domain Boundary Enforcement:
Context Network Updates:
Change Documentation:
File Size Management:
Verification Process:
If you are operating in architect or planning mode:
CRITICAL WARNING: ALL outputs you create MUST be placed within the context network. NEVER create planning or architecture documents in the project root.
Follow this path structure:
Before creating ANY document, ALWAYS check:
If you are operating in implementation mode:
When classifying information nodes, use these exact dimension labels and values:
Domain: [Primary knowledge area]
Stability: [Change frequency expectation]
Abstraction: [Detail level]
Confidence: [Information reliability]
When documenting relationships between information nodes, use these consistent relationship types:
Hierarchical Relationships:
is-parent-ofis-child-ofis-version-ofAssociative Relationships:
relates-todepends-onimplementsextendscontradictscomplementsCross-Domain Relationships:
interfaces-withtranslates-toimpactsAll information nodes should follow this consistent structure:
# [Node Title] ## Purpose [Concise explanation of this node's function in the network] ## Classification - **Domain:** [Primary knowledge area] - **Stability:** [Static/Semi-stable/Dynamic] - **Abstraction:** [Conceptual/Structural/Detailed] - **Confidence:** [Established/Evolving/Speculative] ## Content [Primary information organized appropriately for content type] ## Relationships - **Parent Nodes:** [Nodes that contain broader context] - **Child Nodes:** [Nodes that provide more specific details] - **Related Nodes:** [Nodes with associative connections] - [Node Name] - [Relationship Type] - [Brief description] ## Navigation Guide - **When to Use:** [Common scenarios for accessing this node] - **Next Steps:** [Typical navigation paths from here] - **Related Tasks:** [Activities where this node is relevant] ## Metadata - **Created:** [Date] - **Last Updated:** [Date] - **Updated By:** [Agent ID/Task] ## Change History - [Date]: [Brief description of changes]
To help you understand the distinction between context networks and project files, use this conceptual framework:
Think of the relationship between the context network and project files as:
Blueprints vs. Building: The context network contains the blueprints, planning documents, and architectural decisions. The project files are the actual building itself.
Team Room vs. Product: The context network is like the team's private room where all planning happens. The project files are what gets shipped to customers.
Script vs. Movie: The context network is where the script, storyboards, and production notes live. The project files are the final movie that audiences see.
The Context Network update process has two components:
For each information node (file) you modify, append or update the following metadata section:
## Metadata - **Last Updated:** [Date] - **Updated By:** [Agent ID/Task] - **Change Type:** [New/Modified/Refactored] ## Change History - [Date]: [Brief description of changes]
Additionally, create or update an entry in the network's changelog using this format:
## Update: [Task Name] - [Date] ### Information Nodes Modified - [Node Name]: [Brief description of changes] - **Classification Changes**: [Any updates to domain/stability/abstraction/confidence] - **Content Changes**: [Summary of content modifications] - **Structure Changes**: [Any changes to the node's organization] ### New Relationships Established - [Source Node] → [Relationship Type] → [Target Node]: [Relationship description] ### Relationships Modified - [Source Node] → [Relationship Type] → [Target Node]: [Change description] ### Navigation Implications - [Task Pattern]: [Navigation path changes] ### Follow-up Recommendations - [Recommendation]: [Rationale and suggested action]
Remember that maintaining the Context Network is not just documentation work—it's essential knowledge infrastructure that enables more effective collaboration, reduces cognitive load, and preserves valuable context across project activities.
Most importantly, never create planning or architecture documents outside the context network. These documents must always be placed within the context network structure, not in the project root or artifact domain.