gcontext-ai 0.2.1__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- gcontext_ai-0.2.1/LICENSE +21 -0
- gcontext_ai-0.2.1/PKG-INFO +285 -0
- gcontext_ai-0.2.1/README.md +270 -0
- gcontext_ai-0.2.1/core/__init__.py +1 -0
- gcontext_ai-0.2.1/core/kind_specs.py +135 -0
- gcontext_ai-0.2.1/core/llms_gen.py +109 -0
- gcontext_ai-0.2.1/core/manifest.py +225 -0
- gcontext_ai-0.2.1/core/schemas.py +22 -0
- gcontext_ai-0.2.1/core/templates/module_features.md +9 -0
- gcontext_ai-0.2.1/core/templates/principles.md +29 -0
- gcontext_ai-0.2.1/core/templates/system.md +54 -0
- gcontext_ai-0.2.1/gcontext/__init__.py +1 -0
- gcontext_ai-0.2.1/gcontext/cli.py +574 -0
- gcontext_ai-0.2.1/gcontext/data/example/info.md +30 -0
- gcontext_ai-0.2.1/gcontext/data/example/llms.txt +6 -0
- gcontext_ai-0.2.1/gcontext/data/example/module.yaml +1 -0
- gcontext_ai-0.2.1/gcontext/data/secrets.md +16 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/PKG-INFO +285 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/SOURCES.txt +23 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/dependency_links.txt +1 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/entry_points.txt +2 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/requires.txt +3 -0
- gcontext_ai-0.2.1/gcontext_ai.egg-info/top_level.txt +2 -0
- gcontext_ai-0.2.1/pyproject.toml +26 -0
- gcontext_ai-0.2.1/setup.cfg +4 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Bleak
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,285 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: gcontext-ai
|
|
3
|
+
Version: 0.2.1
|
|
4
|
+
Summary: gcontext — file-based knowledge protocol for AI agents
|
|
5
|
+
License-Expression: MIT
|
|
6
|
+
Project-URL: Homepage, https://gcontext.ai
|
|
7
|
+
Project-URL: Repository, https://github.com/bleak-ai/gcontext
|
|
8
|
+
Requires-Python: >=3.11
|
|
9
|
+
Description-Content-Type: text/markdown
|
|
10
|
+
License-File: LICENSE
|
|
11
|
+
Requires-Dist: pydantic
|
|
12
|
+
Requires-Dist: pyyaml
|
|
13
|
+
Requires-Dist: simple-term-menu
|
|
14
|
+
Dynamic: license-file
|
|
15
|
+
|
|
16
|
+
# gcontext
|
|
17
|
+
|
|
18
|
+
**Context engineering for AI agents.**
|
|
19
|
+
|
|
20
|
+
Build context like you build code: modular, version-controlled, composable.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## The problem
|
|
25
|
+
|
|
26
|
+
AI agents fail for the same reason large codebases fail: **implicit state.**
|
|
27
|
+
|
|
28
|
+
Prompts become undocumented architecture. Instructions drift between conversations. Context duplicates across files. Memory becomes unreliable. Every session starts with "let me remind you how our deploy works."
|
|
29
|
+
|
|
30
|
+
This isn't a model problem. It's an engineering problem.
|
|
31
|
+
|
|
32
|
+
Most teams solve it by writing longer prompts, pasting more docs, or hoping the agent remembers. That works until it doesn't, and it stops working fast.
|
|
33
|
+
|
|
34
|
+
**gcontext treats context as infrastructure.**
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Before and after
|
|
39
|
+
|
|
40
|
+
**Without structured context:**
|
|
41
|
+
- Giant system prompts nobody maintains
|
|
42
|
+
- Copy-pasted docs that go stale
|
|
43
|
+
- "Remember, our Stripe webhook is at..." every session
|
|
44
|
+
- Agent hallucinates because it can't find what it needs
|
|
45
|
+
- Context bloat kills quality on long tasks
|
|
46
|
+
- Tribal knowledge lives in one person's prompt history
|
|
47
|
+
|
|
48
|
+
**With gcontext:**
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
context/
|
|
52
|
+
modules-repo/
|
|
53
|
+
stripe/ → API keys, webhooks, how to query invoices
|
|
54
|
+
postgres/ → schema, migrations, connection details
|
|
55
|
+
deploy-pipeline/ → step-by-step release to production
|
|
56
|
+
bug-triage/ → how to investigate and classify issues
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Each module is a self-contained unit of context. Load what the task needs, unload what it doesn't. The agent navigates to what's relevant. Nothing else enters the window.
|
|
60
|
+
|
|
61
|
+

|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## Install
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
curl -LsSf https://gcontext.ai/gcontext/install.sh | sh
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
<details>
|
|
72
|
+
<summary>Alternative methods</summary>
|
|
73
|
+
|
|
74
|
+
```bash
|
|
75
|
+
# Via uv
|
|
76
|
+
uv tool install gcontext
|
|
77
|
+
|
|
78
|
+
# Via pip
|
|
79
|
+
pip install gcontext
|
|
80
|
+
```
|
|
81
|
+
</details>
|
|
82
|
+
|
|
83
|
+
## Quick start
|
|
84
|
+
|
|
85
|
+
**1. Initialize your workspace**
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
$ gcontext init
|
|
89
|
+
|
|
90
|
+
context/
|
|
91
|
+
llms.txt
|
|
92
|
+
integrations/
|
|
93
|
+
workflows/
|
|
94
|
+
tasks/
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**2. Add an integration**
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
$ claude → "Add a postgres integration"
|
|
101
|
+
|
|
102
|
+
Creating context/integrations/postgres/
|
|
103
|
+
info.md ← context about the integration
|
|
104
|
+
llms.txt ← navigation for the agent
|
|
105
|
+
module.yaml ← secrets: [PG_URL]
|
|
106
|
+
✓ Module created. Requires PG_URL to populate.
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
**3. Provide the secret it needs**
|
|
110
|
+
|
|
111
|
+
```bash
|
|
112
|
+
# Add PG_URL to your .env file
|
|
113
|
+
echo "PG_URL=postgres://..." >> .env
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
**4. The agent fills in the context**
|
|
117
|
+
|
|
118
|
+
```
|
|
119
|
+
$ claude → "Explore the postgres integration and add the info to postgres/info.md"
|
|
120
|
+
|
|
121
|
+
Connecting with PG_URL...
|
|
122
|
+
Found 12 tables, 47 columns, 8 relationships
|
|
123
|
+
Writing schema to info.md
|
|
124
|
+
✓ Module ready. Agent knows your database.
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
**5. Query your data, add context anytime**
|
|
128
|
+
|
|
129
|
+
```
|
|
130
|
+
$ claude → "How many users signed up this week?"
|
|
131
|
+
|
|
132
|
+
Reads info.md → already knows users table has created_at
|
|
133
|
+
47 users. Free: 31, Pro: 12, Enterprise: 4
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
Need more context? The agent can add new modules anytime.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## How it works: composable context
|
|
141
|
+
|
|
142
|
+
gcontext introduces one core mechanic: **composable context**.
|
|
143
|
+
|
|
144
|
+
Modules are independent units of knowledge: an API integration, a deployment procedure, a bug investigation. Each contains plain markdown and a navigation index (`llms.txt`) the agent uses to find what it needs.
|
|
145
|
+
|
|
146
|
+
```
|
|
147
|
+
agent reads system.md
|
|
148
|
+
└─ follows llms.txt index
|
|
149
|
+
├─ stripe/llms.txt → "here's how Stripe works here"
|
|
150
|
+
├─ postgres/llms.txt → "here's the database"
|
|
151
|
+
└─ deploy/llms.txt → "here's how to ship"
|
|
152
|
+
└─ steps.md → the actual procedure
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
**Navigation, not retrieval.** The agent walks a knowledge tree. It doesn't search a vector space. Deterministic, inspectable, reproducible.
|
|
156
|
+
|
|
157
|
+
You version-control your code. You version-control your docs. Now version-control what your AI agent knows.
|
|
158
|
+
|
|
159
|
+
## Module kinds
|
|
160
|
+
|
|
161
|
+
| Kind | What it captures | Lifecycle | Example |
|
|
162
|
+
|------|-----------------|-----------|---------|
|
|
163
|
+
| **Integration** | How to use an external service, API, or database | Permanent: lives as long as the service does | Stripe, Postgres, GitHub, Slack |
|
|
164
|
+
| **Workflow** | A repeatable procedure that improves over time | Long-lived: gets better with each run | Deploy to prod, triage bugs, onboard a teammate |
|
|
165
|
+
| **Task** | A bounded piece of work with progress tracking | Disposable: done when the work is done | Fix billing bug, migrate auth, ship feature X |
|
|
166
|
+
|
|
167
|
+
Different shapes for different lifecycles. They coexist and compose.
|
|
168
|
+
|
|
169
|
+
---
|
|
170
|
+
|
|
171
|
+
## Real workflows
|
|
172
|
+
|
|
173
|
+
**Software engineering team**
|
|
174
|
+
|
|
175
|
+
```
|
|
176
|
+
context/
|
|
177
|
+
modules-repo/
|
|
178
|
+
postgres/ → schema, connection, query patterns
|
|
179
|
+
github/ → repo structure, PR conventions, CI
|
|
180
|
+
deploy-pipeline/ → release steps, rollback procedures
|
|
181
|
+
fix-billing-bug/ → task: reproduce, investigate, fix, verify
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
The agent reads the database schema, understands CI, follows the deploy playbook, and tracks progress on the billing fix, all from structured context.
|
|
185
|
+
|
|
186
|
+
**Support automation**
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
context/
|
|
190
|
+
modules-repo/
|
|
191
|
+
zendesk/ → API access, ticket categories, macros
|
|
192
|
+
stripe/ → subscription lookup, refund procedures
|
|
193
|
+
knowledge-base/ → product docs, known issues, FAQ
|
|
194
|
+
escalation/ → workflow: when and how to escalate
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
An agent triaging tickets reads the Zendesk integration, checks Stripe for billing context, references the KB, and follows escalation rules, without a 10,000-token system prompt.
|
|
198
|
+
|
|
199
|
+
**Content pipeline**
|
|
200
|
+
|
|
201
|
+
```
|
|
202
|
+
context/
|
|
203
|
+
modules-repo/
|
|
204
|
+
cms/ → API, content models, publishing flow
|
|
205
|
+
brand-voice/ → tone guidelines, examples, anti-patterns
|
|
206
|
+
analytics/ → what performs, audience segments
|
|
207
|
+
weekly-newsletter/ → task: this week's edition
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
**Claude Code / Cursor workflow**
|
|
211
|
+
|
|
212
|
+
```
|
|
213
|
+
context/
|
|
214
|
+
modules-repo/
|
|
215
|
+
codebase/ → architecture, conventions, key paths
|
|
216
|
+
cloudflare/ → DNS, workers, deployment targets
|
|
217
|
+
monitoring/ → Grafana dashboards, alert rules
|
|
218
|
+
ship-v2-auth/ → task: migrate auth with progress tracking
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
Point your coding agent at the workspace. It navigates to the module it needs per task: your codebase conventions when writing code, your deploy integration when shipping, your monitoring setup when debugging production.
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## What gcontext is not
|
|
226
|
+
|
|
227
|
+
gcontext is not:
|
|
228
|
+
|
|
229
|
+
- **A vector database.** No embeddings. The agent navigates a file tree, not a similarity search.
|
|
230
|
+
- **A memory model.** No implicit memory. Context is explicit, human-curated, version-controlled.
|
|
231
|
+
- **A replacement for RAG.** Complementary. gcontext structures the knowledge RAG can retrieve from.
|
|
232
|
+
- **An autonomous agent framework.** No agent runtime. Works with the agent you already use.
|
|
233
|
+
- **Another orchestration layer.** No workflow engine. Just structured, navigable knowledge.
|
|
234
|
+
|
|
235
|
+
**gcontext is a context engineering toolkit.** It gives your agent a composable knowledge base it can navigate itself.
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
## Why the filesystem
|
|
240
|
+
|
|
241
|
+
> "Why not just use a vector database / memory layer?"
|
|
242
|
+
|
|
243
|
+
| | Filesystem (gcontext) | Vector DB / Memory |
|
|
244
|
+
|---|---|---|
|
|
245
|
+
| **Version control** | `git diff`, `git blame`, full history | Requires custom versioning |
|
|
246
|
+
| **Inspectability** | Open a folder, read the files | Query an API, decode embeddings |
|
|
247
|
+
| **Determinism** | Same files = same context, every time | Similarity search varies |
|
|
248
|
+
| **Human readability** | It's markdown | It's vectors |
|
|
249
|
+
| **Composability** | Load/unload modules like imports | Rebuild index on every change |
|
|
250
|
+
| **Tooling** | Works with every editor, CI, linter | Needs specialized tooling |
|
|
251
|
+
| **Portability** | Copy the folder | Export, migrate, re-index |
|
|
252
|
+
|
|
253
|
+
The filesystem is the most universal, inspectable, composable storage layer that exists. Your agent's context should be as maintainable as the code it operates on.
|
|
254
|
+
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
## Commands
|
|
258
|
+
|
|
259
|
+
| Command | What it does |
|
|
260
|
+
|---------|-------------|
|
|
261
|
+
| `gcontext init` | Create a new workspace |
|
|
262
|
+
| `gcontext new <kind> <name>` | Scaffold a module |
|
|
263
|
+
| `gcontext load <name> [...]` | Activate modules in the workspace |
|
|
264
|
+
| `gcontext unload <name>` | Deactivate a module |
|
|
265
|
+
| `gcontext ls` | List all modules and their status |
|
|
266
|
+
| `gcontext env` | Check if required secrets are set |
|
|
267
|
+
| `gcontext validate [name]` | Verify module structure |
|
|
268
|
+
|
|
269
|
+
## Works with everything
|
|
270
|
+
|
|
271
|
+
gcontext produces plain markdown files with a navigable index. Any AI that reads files can use it:
|
|
272
|
+
|
|
273
|
+
Claude Code, Cursor, Windsurf, Copilot, ChatGPT, Codex. If it reads files, it reads gcontext.
|
|
274
|
+
|
|
275
|
+
## Secrets
|
|
276
|
+
|
|
277
|
+
Modules can declare required environment variables. Values go in `.env` (gitignored). Run `gcontext env` to check what's missing.
|
|
278
|
+
|
|
279
|
+
## gcontext Cloud
|
|
280
|
+
|
|
281
|
+
For a web UI with built-in AI chat, visual module editor, secrets management, and more, see [gcontext Cloud](https://gcontext.ai).
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
Built by [Bleak AI](https://bleakai.com) | [gcontext.ai](https://gcontext.ai)
|
|
@@ -0,0 +1,270 @@
|
|
|
1
|
+
# gcontext
|
|
2
|
+
|
|
3
|
+
**Context engineering for AI agents.**
|
|
4
|
+
|
|
5
|
+
Build context like you build code: modular, version-controlled, composable.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The problem
|
|
10
|
+
|
|
11
|
+
AI agents fail for the same reason large codebases fail: **implicit state.**
|
|
12
|
+
|
|
13
|
+
Prompts become undocumented architecture. Instructions drift between conversations. Context duplicates across files. Memory becomes unreliable. Every session starts with "let me remind you how our deploy works."
|
|
14
|
+
|
|
15
|
+
This isn't a model problem. It's an engineering problem.
|
|
16
|
+
|
|
17
|
+
Most teams solve it by writing longer prompts, pasting more docs, or hoping the agent remembers. That works until it doesn't, and it stops working fast.
|
|
18
|
+
|
|
19
|
+
**gcontext treats context as infrastructure.**
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Before and after
|
|
24
|
+
|
|
25
|
+
**Without structured context:**
|
|
26
|
+
- Giant system prompts nobody maintains
|
|
27
|
+
- Copy-pasted docs that go stale
|
|
28
|
+
- "Remember, our Stripe webhook is at..." every session
|
|
29
|
+
- Agent hallucinates because it can't find what it needs
|
|
30
|
+
- Context bloat kills quality on long tasks
|
|
31
|
+
- Tribal knowledge lives in one person's prompt history
|
|
32
|
+
|
|
33
|
+
**With gcontext:**
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
context/
|
|
37
|
+
modules-repo/
|
|
38
|
+
stripe/ → API keys, webhooks, how to query invoices
|
|
39
|
+
postgres/ → schema, migrations, connection details
|
|
40
|
+
deploy-pipeline/ → step-by-step release to production
|
|
41
|
+
bug-triage/ → how to investigate and classify issues
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Each module is a self-contained unit of context. Load what the task needs, unload what it doesn't. The agent navigates to what's relevant. Nothing else enters the window.
|
|
45
|
+
|
|
46
|
+

|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Install
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
curl -LsSf https://gcontext.ai/gcontext/install.sh | sh
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
<details>
|
|
57
|
+
<summary>Alternative methods</summary>
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
# Via uv
|
|
61
|
+
uv tool install gcontext
|
|
62
|
+
|
|
63
|
+
# Via pip
|
|
64
|
+
pip install gcontext
|
|
65
|
+
```
|
|
66
|
+
</details>
|
|
67
|
+
|
|
68
|
+
## Quick start
|
|
69
|
+
|
|
70
|
+
**1. Initialize your workspace**
|
|
71
|
+
|
|
72
|
+
```bash
|
|
73
|
+
$ gcontext init
|
|
74
|
+
|
|
75
|
+
context/
|
|
76
|
+
llms.txt
|
|
77
|
+
integrations/
|
|
78
|
+
workflows/
|
|
79
|
+
tasks/
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
**2. Add an integration**
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
$ claude → "Add a postgres integration"
|
|
86
|
+
|
|
87
|
+
Creating context/integrations/postgres/
|
|
88
|
+
info.md ← context about the integration
|
|
89
|
+
llms.txt ← navigation for the agent
|
|
90
|
+
module.yaml ← secrets: [PG_URL]
|
|
91
|
+
✓ Module created. Requires PG_URL to populate.
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
**3. Provide the secret it needs**
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
# Add PG_URL to your .env file
|
|
98
|
+
echo "PG_URL=postgres://..." >> .env
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
**4. The agent fills in the context**
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
$ claude → "Explore the postgres integration and add the info to postgres/info.md"
|
|
105
|
+
|
|
106
|
+
Connecting with PG_URL...
|
|
107
|
+
Found 12 tables, 47 columns, 8 relationships
|
|
108
|
+
Writing schema to info.md
|
|
109
|
+
✓ Module ready. Agent knows your database.
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
**5. Query your data, add context anytime**
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
$ claude → "How many users signed up this week?"
|
|
116
|
+
|
|
117
|
+
Reads info.md → already knows users table has created_at
|
|
118
|
+
47 users. Free: 31, Pro: 12, Enterprise: 4
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
Need more context? The agent can add new modules anytime.
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
## How it works: composable context
|
|
126
|
+
|
|
127
|
+
gcontext introduces one core mechanic: **composable context**.
|
|
128
|
+
|
|
129
|
+
Modules are independent units of knowledge: an API integration, a deployment procedure, a bug investigation. Each contains plain markdown and a navigation index (`llms.txt`) the agent uses to find what it needs.
|
|
130
|
+
|
|
131
|
+
```
|
|
132
|
+
agent reads system.md
|
|
133
|
+
└─ follows llms.txt index
|
|
134
|
+
├─ stripe/llms.txt → "here's how Stripe works here"
|
|
135
|
+
├─ postgres/llms.txt → "here's the database"
|
|
136
|
+
└─ deploy/llms.txt → "here's how to ship"
|
|
137
|
+
└─ steps.md → the actual procedure
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**Navigation, not retrieval.** The agent walks a knowledge tree. It doesn't search a vector space. Deterministic, inspectable, reproducible.
|
|
141
|
+
|
|
142
|
+
You version-control your code. You version-control your docs. Now version-control what your AI agent knows.
|
|
143
|
+
|
|
144
|
+
## Module kinds
|
|
145
|
+
|
|
146
|
+
| Kind | What it captures | Lifecycle | Example |
|
|
147
|
+
|------|-----------------|-----------|---------|
|
|
148
|
+
| **Integration** | How to use an external service, API, or database | Permanent: lives as long as the service does | Stripe, Postgres, GitHub, Slack |
|
|
149
|
+
| **Workflow** | A repeatable procedure that improves over time | Long-lived: gets better with each run | Deploy to prod, triage bugs, onboard a teammate |
|
|
150
|
+
| **Task** | A bounded piece of work with progress tracking | Disposable: done when the work is done | Fix billing bug, migrate auth, ship feature X |
|
|
151
|
+
|
|
152
|
+
Different shapes for different lifecycles. They coexist and compose.
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Real workflows
|
|
157
|
+
|
|
158
|
+
**Software engineering team**
|
|
159
|
+
|
|
160
|
+
```
|
|
161
|
+
context/
|
|
162
|
+
modules-repo/
|
|
163
|
+
postgres/ → schema, connection, query patterns
|
|
164
|
+
github/ → repo structure, PR conventions, CI
|
|
165
|
+
deploy-pipeline/ → release steps, rollback procedures
|
|
166
|
+
fix-billing-bug/ → task: reproduce, investigate, fix, verify
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
The agent reads the database schema, understands CI, follows the deploy playbook, and tracks progress on the billing fix, all from structured context.
|
|
170
|
+
|
|
171
|
+
**Support automation**
|
|
172
|
+
|
|
173
|
+
```
|
|
174
|
+
context/
|
|
175
|
+
modules-repo/
|
|
176
|
+
zendesk/ → API access, ticket categories, macros
|
|
177
|
+
stripe/ → subscription lookup, refund procedures
|
|
178
|
+
knowledge-base/ → product docs, known issues, FAQ
|
|
179
|
+
escalation/ → workflow: when and how to escalate
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
An agent triaging tickets reads the Zendesk integration, checks Stripe for billing context, references the KB, and follows escalation rules, without a 10,000-token system prompt.
|
|
183
|
+
|
|
184
|
+
**Content pipeline**
|
|
185
|
+
|
|
186
|
+
```
|
|
187
|
+
context/
|
|
188
|
+
modules-repo/
|
|
189
|
+
cms/ → API, content models, publishing flow
|
|
190
|
+
brand-voice/ → tone guidelines, examples, anti-patterns
|
|
191
|
+
analytics/ → what performs, audience segments
|
|
192
|
+
weekly-newsletter/ → task: this week's edition
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
**Claude Code / Cursor workflow**
|
|
196
|
+
|
|
197
|
+
```
|
|
198
|
+
context/
|
|
199
|
+
modules-repo/
|
|
200
|
+
codebase/ → architecture, conventions, key paths
|
|
201
|
+
cloudflare/ → DNS, workers, deployment targets
|
|
202
|
+
monitoring/ → Grafana dashboards, alert rules
|
|
203
|
+
ship-v2-auth/ → task: migrate auth with progress tracking
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
Point your coding agent at the workspace. It navigates to the module it needs per task: your codebase conventions when writing code, your deploy integration when shipping, your monitoring setup when debugging production.
|
|
207
|
+
|
|
208
|
+
---
|
|
209
|
+
|
|
210
|
+
## What gcontext is not
|
|
211
|
+
|
|
212
|
+
gcontext is not:
|
|
213
|
+
|
|
214
|
+
- **A vector database.** No embeddings. The agent navigates a file tree, not a similarity search.
|
|
215
|
+
- **A memory model.** No implicit memory. Context is explicit, human-curated, version-controlled.
|
|
216
|
+
- **A replacement for RAG.** Complementary. gcontext structures the knowledge RAG can retrieve from.
|
|
217
|
+
- **An autonomous agent framework.** No agent runtime. Works with the agent you already use.
|
|
218
|
+
- **Another orchestration layer.** No workflow engine. Just structured, navigable knowledge.
|
|
219
|
+
|
|
220
|
+
**gcontext is a context engineering toolkit.** It gives your agent a composable knowledge base it can navigate itself.
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
## Why the filesystem
|
|
225
|
+
|
|
226
|
+
> "Why not just use a vector database / memory layer?"
|
|
227
|
+
|
|
228
|
+
| | Filesystem (gcontext) | Vector DB / Memory |
|
|
229
|
+
|---|---|---|
|
|
230
|
+
| **Version control** | `git diff`, `git blame`, full history | Requires custom versioning |
|
|
231
|
+
| **Inspectability** | Open a folder, read the files | Query an API, decode embeddings |
|
|
232
|
+
| **Determinism** | Same files = same context, every time | Similarity search varies |
|
|
233
|
+
| **Human readability** | It's markdown | It's vectors |
|
|
234
|
+
| **Composability** | Load/unload modules like imports | Rebuild index on every change |
|
|
235
|
+
| **Tooling** | Works with every editor, CI, linter | Needs specialized tooling |
|
|
236
|
+
| **Portability** | Copy the folder | Export, migrate, re-index |
|
|
237
|
+
|
|
238
|
+
The filesystem is the most universal, inspectable, composable storage layer that exists. Your agent's context should be as maintainable as the code it operates on.
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
## Commands
|
|
243
|
+
|
|
244
|
+
| Command | What it does |
|
|
245
|
+
|---------|-------------|
|
|
246
|
+
| `gcontext init` | Create a new workspace |
|
|
247
|
+
| `gcontext new <kind> <name>` | Scaffold a module |
|
|
248
|
+
| `gcontext load <name> [...]` | Activate modules in the workspace |
|
|
249
|
+
| `gcontext unload <name>` | Deactivate a module |
|
|
250
|
+
| `gcontext ls` | List all modules and their status |
|
|
251
|
+
| `gcontext env` | Check if required secrets are set |
|
|
252
|
+
| `gcontext validate [name]` | Verify module structure |
|
|
253
|
+
|
|
254
|
+
## Works with everything
|
|
255
|
+
|
|
256
|
+
gcontext produces plain markdown files with a navigable index. Any AI that reads files can use it:
|
|
257
|
+
|
|
258
|
+
Claude Code, Cursor, Windsurf, Copilot, ChatGPT, Codex. If it reads files, it reads gcontext.
|
|
259
|
+
|
|
260
|
+
## Secrets
|
|
261
|
+
|
|
262
|
+
Modules can declare required environment variables. Values go in `.env` (gitignored). Run `gcontext env` to check what's missing.
|
|
263
|
+
|
|
264
|
+
## gcontext Cloud
|
|
265
|
+
|
|
266
|
+
For a web UI with built-in AI chat, visual module editor, secrets management, and more, see [gcontext Cloud](https://gcontext.ai).
|
|
267
|
+
|
|
268
|
+
---
|
|
269
|
+
|
|
270
|
+
Built by [Bleak AI](https://bleakai.com) | [gcontext.ai](https://gcontext.ai)
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
# empty package marker
|