aicontexts 0.1.0__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.
- aicontexts-0.1.0/LICENSE +18 -0
- aicontexts-0.1.0/PKG-INFO +327 -0
- aicontexts-0.1.0/README.md +307 -0
- aicontexts-0.1.0/ai_contexts.py +5944 -0
- aicontexts-0.1.0/ai_contexts_test.py +4136 -0
- aicontexts-0.1.0/aicontexts.egg-info/PKG-INFO +327 -0
- aicontexts-0.1.0/aicontexts.egg-info/SOURCES.txt +10 -0
- aicontexts-0.1.0/aicontexts.egg-info/dependency_links.txt +1 -0
- aicontexts-0.1.0/aicontexts.egg-info/entry_points.txt +3 -0
- aicontexts-0.1.0/aicontexts.egg-info/top_level.txt +2 -0
- aicontexts-0.1.0/pyproject.toml +41 -0
- aicontexts-0.1.0/setup.cfg +4 -0
aicontexts-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
MIT No Attribution
|
|
2
|
+
|
|
3
|
+
Copyright 2026 Wayne C. Gramlich
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a
|
|
6
|
+
copy of this software and associated documentation files (the
|
|
7
|
+
"Software"), to deal in the Software without restriction, including
|
|
8
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
|
9
|
+
distribute, sublicense, and/or sell copies of the Software, and to
|
|
10
|
+
permit persons to whom the Software is furnished to do so.
|
|
11
|
+
|
|
12
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
13
|
+
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
14
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
|
|
15
|
+
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
|
|
16
|
+
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
|
|
17
|
+
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
|
|
18
|
+
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
@@ -0,0 +1,327 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: aicontexts
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Startup context for AI sessions: tasks, issues and rules that the AI loads
|
|
5
|
+
Author: Wayne C. Gramlich
|
|
6
|
+
License-Expression: MIT-0
|
|
7
|
+
Project-URL: Homepage, https://github.com/waynegramlich/aicontexts
|
|
8
|
+
Project-URL: Issues, https://github.com/waynegramlich/aicontexts/issues
|
|
9
|
+
Classifier: Development Status :: 4 - Beta
|
|
10
|
+
Classifier: Environment :: Console
|
|
11
|
+
Classifier: Intended Audience :: Developers
|
|
12
|
+
Classifier: Operating System :: OS Independent
|
|
13
|
+
Classifier: Programming Language :: Python :: 3
|
|
14
|
+
Classifier: Programming Language :: Python :: 3 :: Only
|
|
15
|
+
Classifier: Topic :: Software Development
|
|
16
|
+
Requires-Python: >=3.11
|
|
17
|
+
Description-Content-Type: text/markdown
|
|
18
|
+
License-File: LICENSE
|
|
19
|
+
Dynamic: license-file
|
|
20
|
+
|
|
21
|
+
# AI Contexts: Startup Context for AI Sessions
|
|
22
|
+
|
|
23
|
+
The `ai_contexts` program manages the context that an AI loads at session
|
|
24
|
+
start time. The context is broken into 3 broad categories:
|
|
25
|
+
|
|
26
|
+
* **Tasks:**
|
|
27
|
+
Tasks are chunks of work, such as a feature to add or a cleanup to do.
|
|
28
|
+
* **Issues:**
|
|
29
|
+
Issues include code bugs, feature requests, documentation, testing, etc.
|
|
30
|
+
Dealing with an issue may require multiple tasks.
|
|
31
|
+
* **Rules:**
|
|
32
|
+
Rules are instructions that an AI follows in every session, such as
|
|
33
|
+
version control or coding rules, which may be shared by several projects.
|
|
34
|
+
They are discussed in the section about Rules much further below.
|
|
35
|
+
|
|
36
|
+
With `ai_contexts`, you can easily switch your AI's context each time you
|
|
37
|
+
change your development focus, so that it loads only what is relevant.
|
|
38
|
+
This keeps the AI from being distracted by unrelated work and saves both time
|
|
39
|
+
and money.
|
|
40
|
+
|
|
41
|
+
Using `ai_contexts` is simple. You write a few lines describing a task, and
|
|
42
|
+
the AI does the bookkeeping. While the task is open, it keeps its working notes
|
|
43
|
+
in the task's directory, and when the task is done, it writes a short
|
|
44
|
+
summary and closes it. From then on, only that summary is loaded, so a
|
|
45
|
+
long-running project keeps its history without the AI having to wade
|
|
46
|
+
through it.
|
|
47
|
+
|
|
48
|
+
## Getting Started
|
|
49
|
+
|
|
50
|
+
The installation of `ai_contexts` is covered in "Installation" near the
|
|
51
|
+
end of this document.
|
|
52
|
+
|
|
53
|
+
Each category is a collection of Items that lives in its own directory
|
|
54
|
+
(e.g. `TASKS/`, `ISSUES/` and `RULES/`). A project can have other collections
|
|
55
|
+
as well (e.g. `IDEAS/`), as long as their names start with a unique letter.
|
|
56
|
+
|
|
57
|
+
These directories are manipulated by the `aic` command (which is
|
|
58
|
+
a symbolic link to the `ai_contexts.py` program). For example:
|
|
59
|
+
|
|
60
|
+
* `aic TASKS create` creates the `TASKS/` directory.
|
|
61
|
+
* `aic ISSUES create` creates the `ISSUES/` directory.
|
|
62
|
+
|
|
63
|
+
Each one asks before creating the directory, and marks it as a collection
|
|
64
|
+
with a hidden `.ai_contexts.json` file inside it. It also writes
|
|
65
|
+
`AI_Contexts_Rules.md` into the directory, which teaches the AI how to use
|
|
66
|
+
`aic`.
|
|
67
|
+
|
|
68
|
+
Next, tell the AI about them. For Claude Code, add these two lines to
|
|
69
|
+
the project's `CLAUDE.md` file:
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
@TASKS/AI_Contexts_Rules.md
|
|
73
|
+
@TASKS/Startup.md
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
`aic` rewrites both files every time it runs, so they always exist and
|
|
77
|
+
are always up to date: `AI_Contexts_Rules.md` matches the version of
|
|
78
|
+
`aic` you have, and `TASKS/Startup.md` loads the context of your tasks
|
|
79
|
+
and issues. (Every collection gets its own copy of
|
|
80
|
+
`AI_Contexts_Rules.md`, so you can import it from whichever collection
|
|
81
|
+
you have; import just one, so that it is not loaded twice.) `aic` also
|
|
82
|
+
warns you about any `@` import in `CLAUDE.md` whose file does not exist.
|
|
83
|
+
|
|
84
|
+
To create a task, give it a number and a title:
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
aic TASKS create 1 Write the README
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
This creates the `TASKS/1_Write_the_README/` sub-directory. The first
|
|
91
|
+
task is always number `1`, since numbers never have gaps (see below).
|
|
92
|
+
|
|
93
|
+
To see the tasks, run `aic TASKS ls`, which shows:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
1 Pending T.wr Write the README
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
What you see is:
|
|
100
|
+
|
|
101
|
+
* **`1`**: This is the task number.
|
|
102
|
+
(It can be hierarchical; see shortly below.)
|
|
103
|
+
* **`Pending`**: This is the initial task state.
|
|
104
|
+
* **`T.wr`**: This is the task tag. It is constructed by taking the
|
|
105
|
+
first letter of the collection name (i.e. `TASKS`) followed by a
|
|
106
|
+
period. The rest is constructed by taking the title (see next item),
|
|
107
|
+
dropping the words "a", "an", "of" and "the", and concatenating the
|
|
108
|
+
first letter of each remaining word in lower case. For example,
|
|
109
|
+
"Write the README" drops "the", leaving **W**rite **R**EADME, so the
|
|
110
|
+
tag is `T.wr`.
|
|
111
|
+
* **`Write the README`**: The full title is listed last.
|
|
112
|
+
|
|
113
|
+
Collection and command names can both be shortened to any unique
|
|
114
|
+
prefix, in any case, so `aic t ls` works as well, and `aic t op T.wr` is
|
|
115
|
+
short for `aic TASKS open T.wr`. (If a prefix is ambiguous, such as `c`
|
|
116
|
+
for `close` or `create`, `aic` lists the choices.) Tags can not be
|
|
117
|
+
shortened, so `T.wr` must be typed in full (though `t.wr` works too).
|
|
118
|
+
`aic` also works from anywhere inside the project: it looks for the
|
|
119
|
+
collections in the current directory, and then in each parent directory
|
|
120
|
+
in turn, stopping at the top of a git or Mercurial repository.
|
|
121
|
+
|
|
122
|
+
Numbers are hierarchical, so a task can be broken into smaller ones:
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
aic t create 1.1 Draft the introduction
|
|
126
|
+
aic t create 2 Publish the README
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Then `aic TASKS ls` lists:
|
|
130
|
+
|
|
131
|
+
```
|
|
132
|
+
1 Pending T.wr Write the README
|
|
133
|
+
1.1 Pending T.di Draft the introduction
|
|
134
|
+
2 Pending T.pr Publish the README
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
Hierarchical numbers:
|
|
138
|
+
|
|
139
|
+
* A hierarchical number is a sequence of positive integers separated by `.`
|
|
140
|
+
(e.g. `1.3.2`.)
|
|
141
|
+
* They can be sorted, but they are never allowed to have gaps.
|
|
142
|
+
Thus, task `1.3` can only be created after `1.1` and `1.2` exist.
|
|
143
|
+
* They change as tasks are added, moved, inserted and deleted. This is
|
|
144
|
+
why tags are typically used instead of hierarchical numbers.
|
|
145
|
+
* Text (and the AI) refers to a task by its tag followed by `~` and its
|
|
146
|
+
number at the time, such as `T.di~1.1`, so that its directory is easy
|
|
147
|
+
to find. The number is never updated afterwards, so it records what
|
|
148
|
+
the number was when the text was written. `aic` ignores the `~1.1`,
|
|
149
|
+
so `aic t open T.di~1.1` works too.
|
|
150
|
+
|
|
151
|
+
## Context Files
|
|
152
|
+
|
|
153
|
+
Each created sub-directory contains the following 4 files:
|
|
154
|
+
|
|
155
|
+
* **`Details.md`**:
|
|
156
|
+
This file is entirely edited by the User. It provides the description
|
|
157
|
+
of the Task/Issue. For a Task it describes the goal of the task. For
|
|
158
|
+
an Issue, it describes the Issue, but not necessarily how to fix it.
|
|
159
|
+
* **`Summary.md`**:
|
|
160
|
+
This is a file where the AI stores the context it needs once the
|
|
161
|
+
Task/Issue is closed.
|
|
162
|
+
* **`Context.md`**:
|
|
163
|
+
This file is where the AI stores the context it needs when working on it.
|
|
164
|
+
It is allowed to be quite detailed. However, the AI only sees the context
|
|
165
|
+
when the task or issue is in the Open (or Reference) state.
|
|
166
|
+
* **`.item.json`**:
|
|
167
|
+
This is a hidden file entirely managed by `aic` to keep track of things.
|
|
168
|
+
|
|
169
|
+
At AI startup, the AI is directed to read at most 2 of the 3 files
|
|
170
|
+
above:
|
|
171
|
+
|
|
172
|
+
* **`Details.md`**: This is read until the Task/Issue is closed.
|
|
173
|
+
* **`Context.md`**: This is read while the Task/Issue is open.
|
|
174
|
+
* **`Summary.md`**: This is read once the Task/Issue is closed.
|
|
175
|
+
|
|
176
|
+
Thus, the AI gets the context it needs to focus on individual Tasks
|
|
177
|
+
and/or Issues.
|
|
178
|
+
|
|
179
|
+
Prior to working on a task, first enter its details into `Details.md`,
|
|
180
|
+
then open it:
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
aic t open T.wr
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
The next AI session loads its `Details.md` and `Context.md`. When the
|
|
187
|
+
work is done, ask the AI to close the task: it writes the `Summary.md`
|
|
188
|
+
and it runs the `aic t close T.wr` command for you. In practice, you rarely
|
|
189
|
+
run `aic` yourself once the collections exist; you ask the AI to create,
|
|
190
|
+
open and close tasks and issues, and it runs the commands.
|
|
191
|
+
|
|
192
|
+
## States
|
|
193
|
+
|
|
194
|
+
A task (or issue) is always in one of these states:
|
|
195
|
+
|
|
196
|
+
* **Pending:** Not started yet. Every new task starts out Pending.
|
|
197
|
+
* **Open:** Being worked on. Its `Context.md` is loaded.
|
|
198
|
+
* **Reference:** Not being worked on, but its `Context.md` is still
|
|
199
|
+
loaded, so its notes stay available.
|
|
200
|
+
* **Suspended:** Put aside for now.
|
|
201
|
+
* **Closed:** Done. Only its `Summary.md` is loaded.
|
|
202
|
+
* **Rejected:** Decided against. It is treated like a Closed one.
|
|
203
|
+
|
|
204
|
+
The commands are named after the states (`pending`, `open`, `reference`,
|
|
205
|
+
`suspend`, `close` and `reject`), e.g. `aic t close T.wr`. `aic t ls`
|
|
206
|
+
leaves out Closed and Rejected tasks; `aic t ls -a` lists them all.
|
|
207
|
+
|
|
208
|
+
## Moving Things Around
|
|
209
|
+
|
|
210
|
+
* `aic t move T.di after 2` moves a task (and its children), and
|
|
211
|
+
`aic t create before 1 Outline the README` creates one in front of
|
|
212
|
+
another; the other tasks are renumbered to make room or close the gap.
|
|
213
|
+
* `aic t rename T.di to Draft the overview` changes a title. If that
|
|
214
|
+
changes the tag, `ai_contexts` offers to update the `.md` files that
|
|
215
|
+
use the old one, in the collections and directly in the project
|
|
216
|
+
directory (it suggests a `grep` command for anywhere else).
|
|
217
|
+
* `aic t transfer T.di issues` moves a task that turns out to be an issue
|
|
218
|
+
into `ISSUES/`, where its tag becomes `I.di`.
|
|
219
|
+
* `aic t delete T.di` deletes a task for good.
|
|
220
|
+
|
|
221
|
+
There is no undo, so keep the collections in a version control system.
|
|
222
|
+
Before a move, rename or transfer, if there has not been one for over an
|
|
223
|
+
hour, `ai_contexts` suggests taking a snapshot (e.g. `git commit`) first.
|
|
224
|
+
|
|
225
|
+
## Priorities
|
|
226
|
+
|
|
227
|
+
Issues can be given a priority once it is enabled for the collection
|
|
228
|
+
(`aic i enable priority`): 0 (catastrophic), 1 (high), 2 (medium) or 3
|
|
229
|
+
(low), set with `aic i priority I.dbzib 1`. `aic i ls` then lists the
|
|
230
|
+
issues by priority first.
|
|
231
|
+
|
|
232
|
+
## Other Conveniences
|
|
233
|
+
|
|
234
|
+
* A tag can stand in for its collection: `aic I.dbzib close` is the same
|
|
235
|
+
as `aic ISSUES close I.dbzib`.
|
|
236
|
+
* `aic T.wr show` shows everything about a task.
|
|
237
|
+
* `aic` with no arguments lists the collections, and `aic -h` lists all
|
|
238
|
+
of the commands.
|
|
239
|
+
* Every command checks the collections and tells you about anything that
|
|
240
|
+
needs fixing (such as a title edited by hand), and how to fix it.
|
|
241
|
+
|
|
242
|
+
## Rules Collections
|
|
243
|
+
|
|
244
|
+
A rules collection (e.g. `RULES/`) holds rules that the AI should load at
|
|
245
|
+
the start of every session, such as version control or coding rules
|
|
246
|
+
shared by several projects. Each rule is a file that can live anywhere,
|
|
247
|
+
and `ai_contexts` keeps a read-only copy of it in the project, as the
|
|
248
|
+
rule's `Details.md` (the AI may not import a file from outside the
|
|
249
|
+
project without approval):
|
|
250
|
+
|
|
251
|
+
The easiest way to get rules is to copy them from another project:
|
|
252
|
+
|
|
253
|
+
```
|
|
254
|
+
aic RULES create
|
|
255
|
+
aic r copy ../other_project/RULES
|
|
256
|
+
```
|
|
257
|
+
|
|
258
|
+
A collection named `RULES` is a rules collection from the start. (A
|
|
259
|
+
rules collection with another name is made with `aic NAME create`, and
|
|
260
|
+
then `aic n type rules` while it is still empty.)
|
|
261
|
+
x
|
|
262
|
+
`aic r copy` lists the other project's rules by number and title, and
|
|
263
|
+
asks which to copy:
|
|
264
|
+
|
|
265
|
+
```
|
|
266
|
+
Rules in ../other_project/RULES:
|
|
267
|
+
1 Code Marker Rules
|
|
268
|
+
2 Python Coding Rules
|
|
269
|
+
3 Version Control Rules
|
|
270
|
+
Copy which? (e.g. 1,3-5; empty for none) 2-3
|
|
271
|
+
1 InActive R.pcr Python Coding Rules
|
|
272
|
+
2 InActive R.vcr Version Control Rules
|
|
273
|
+
To use them: ai_contexts RULES activate 1-2
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
The choices are numbers and ranges, separated by commas or spaces, and
|
|
277
|
+
can also be given on the command line (`aic r copy ../other_project/RULES
|
|
278
|
+
2-3`). A rule you already have is marked `(have it)` and is not copied
|
|
279
|
+
again. The directory can also be any directory of rule files (e.g.
|
|
280
|
+
`../shared_rules/`), and a single file becomes a rule with `aic r create
|
|
281
|
+
1 ../shared_rules/Version_Control_Rules.md`. Either way, the rule's file
|
|
282
|
+
is its source, and `aic` keeps the copy up to date with it.
|
|
283
|
+
|
|
284
|
+
`aic` refuses to make a rule from a `CLAUDE.md` file, and asks before
|
|
285
|
+
using a file that looks like it is about the project (like `README.md`)
|
|
286
|
+
or that imports other files.
|
|
287
|
+
|
|
288
|
+
A new rule is InActive until it is activated. Every time `ai_contexts`
|
|
289
|
+
runs, it refreshes the copies from their source files and rewrites
|
|
290
|
+
`RULES/Active_Rules.md` to import the Active ones, so adding this line to
|
|
291
|
+
`CLAUDE.md` loads them:
|
|
292
|
+
|
|
293
|
+
```
|
|
294
|
+
@RULES/Active_Rules.md
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
## Installation
|
|
298
|
+
|
|
299
|
+
`ai_contexts` is a single Python program, `ai_contexts.py`, that needs
|
|
300
|
+
Python 3.11 or later and nothing beyond the standard library. Nothing
|
|
301
|
+
else needs to be installed: the rules it gives the AI are built in. To install
|
|
302
|
+
it:
|
|
303
|
+
|
|
304
|
+
1. Install the `aicontexts` package from PyPI, which gives you both the
|
|
305
|
+
`ai_contexts` and `aic` commands. With `uv` or `pipx`, it gets an
|
|
306
|
+
environment of its own:
|
|
307
|
+
|
|
308
|
+
```
|
|
309
|
+
uv tool install aicontexts
|
|
310
|
+
pipx install aicontexts
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
Or, without either, copy `ai_contexts.py` into a directory on your
|
|
314
|
+
`PATH`, and make a symbolic link to it named `aic`:
|
|
315
|
+
|
|
316
|
+
```
|
|
317
|
+
cp ai_contexts.py ~/bin/
|
|
318
|
+
ln -s ai_contexts.py ~/bin/aic
|
|
319
|
+
```
|
|
320
|
+
|
|
321
|
+
2. Check it with `aic --test`, which runs its tests in a temporary
|
|
322
|
+
directory.
|
|
323
|
+
|
|
324
|
+
3. Create the collections and set up `CLAUDE.md` as described in
|
|
325
|
+
"Getting Started".
|
|
326
|
+
|
|
327
|
+
`REFERENCE.md` has the details of how `ai_contexts` works.
|
|
@@ -0,0 +1,307 @@
|
|
|
1
|
+
# AI Contexts: Startup Context for AI Sessions
|
|
2
|
+
|
|
3
|
+
The `ai_contexts` program manages the context that an AI loads at session
|
|
4
|
+
start time. The context is broken into 3 broad categories:
|
|
5
|
+
|
|
6
|
+
* **Tasks:**
|
|
7
|
+
Tasks are chunks of work, such as a feature to add or a cleanup to do.
|
|
8
|
+
* **Issues:**
|
|
9
|
+
Issues include code bugs, feature requests, documentation, testing, etc.
|
|
10
|
+
Dealing with an issue may require multiple tasks.
|
|
11
|
+
* **Rules:**
|
|
12
|
+
Rules are instructions that an AI follows in every session, such as
|
|
13
|
+
version control or coding rules, which may be shared by several projects.
|
|
14
|
+
They are discussed in the section about Rules much further below.
|
|
15
|
+
|
|
16
|
+
With `ai_contexts`, you can easily switch your AI's context each time you
|
|
17
|
+
change your development focus, so that it loads only what is relevant.
|
|
18
|
+
This keeps the AI from being distracted by unrelated work and saves both time
|
|
19
|
+
and money.
|
|
20
|
+
|
|
21
|
+
Using `ai_contexts` is simple. You write a few lines describing a task, and
|
|
22
|
+
the AI does the bookkeeping. While the task is open, it keeps its working notes
|
|
23
|
+
in the task's directory, and when the task is done, it writes a short
|
|
24
|
+
summary and closes it. From then on, only that summary is loaded, so a
|
|
25
|
+
long-running project keeps its history without the AI having to wade
|
|
26
|
+
through it.
|
|
27
|
+
|
|
28
|
+
## Getting Started
|
|
29
|
+
|
|
30
|
+
The installation of `ai_contexts` is covered in "Installation" near the
|
|
31
|
+
end of this document.
|
|
32
|
+
|
|
33
|
+
Each category is a collection of Items that lives in its own directory
|
|
34
|
+
(e.g. `TASKS/`, `ISSUES/` and `RULES/`). A project can have other collections
|
|
35
|
+
as well (e.g. `IDEAS/`), as long as their names start with a unique letter.
|
|
36
|
+
|
|
37
|
+
These directories are manipulated by the `aic` command (which is
|
|
38
|
+
a symbolic link to the `ai_contexts.py` program). For example:
|
|
39
|
+
|
|
40
|
+
* `aic TASKS create` creates the `TASKS/` directory.
|
|
41
|
+
* `aic ISSUES create` creates the `ISSUES/` directory.
|
|
42
|
+
|
|
43
|
+
Each one asks before creating the directory, and marks it as a collection
|
|
44
|
+
with a hidden `.ai_contexts.json` file inside it. It also writes
|
|
45
|
+
`AI_Contexts_Rules.md` into the directory, which teaches the AI how to use
|
|
46
|
+
`aic`.
|
|
47
|
+
|
|
48
|
+
Next, tell the AI about them. For Claude Code, add these two lines to
|
|
49
|
+
the project's `CLAUDE.md` file:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
@TASKS/AI_Contexts_Rules.md
|
|
53
|
+
@TASKS/Startup.md
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
`aic` rewrites both files every time it runs, so they always exist and
|
|
57
|
+
are always up to date: `AI_Contexts_Rules.md` matches the version of
|
|
58
|
+
`aic` you have, and `TASKS/Startup.md` loads the context of your tasks
|
|
59
|
+
and issues. (Every collection gets its own copy of
|
|
60
|
+
`AI_Contexts_Rules.md`, so you can import it from whichever collection
|
|
61
|
+
you have; import just one, so that it is not loaded twice.) `aic` also
|
|
62
|
+
warns you about any `@` import in `CLAUDE.md` whose file does not exist.
|
|
63
|
+
|
|
64
|
+
To create a task, give it a number and a title:
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
aic TASKS create 1 Write the README
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
This creates the `TASKS/1_Write_the_README/` sub-directory. The first
|
|
71
|
+
task is always number `1`, since numbers never have gaps (see below).
|
|
72
|
+
|
|
73
|
+
To see the tasks, run `aic TASKS ls`, which shows:
|
|
74
|
+
|
|
75
|
+
```
|
|
76
|
+
1 Pending T.wr Write the README
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
What you see is:
|
|
80
|
+
|
|
81
|
+
* **`1`**: This is the task number.
|
|
82
|
+
(It can be hierarchical; see shortly below.)
|
|
83
|
+
* **`Pending`**: This is the initial task state.
|
|
84
|
+
* **`T.wr`**: This is the task tag. It is constructed by taking the
|
|
85
|
+
first letter of the collection name (i.e. `TASKS`) followed by a
|
|
86
|
+
period. The rest is constructed by taking the title (see next item),
|
|
87
|
+
dropping the words "a", "an", "of" and "the", and concatenating the
|
|
88
|
+
first letter of each remaining word in lower case. For example,
|
|
89
|
+
"Write the README" drops "the", leaving **W**rite **R**EADME, so the
|
|
90
|
+
tag is `T.wr`.
|
|
91
|
+
* **`Write the README`**: The full title is listed last.
|
|
92
|
+
|
|
93
|
+
Collection and command names can both be shortened to any unique
|
|
94
|
+
prefix, in any case, so `aic t ls` works as well, and `aic t op T.wr` is
|
|
95
|
+
short for `aic TASKS open T.wr`. (If a prefix is ambiguous, such as `c`
|
|
96
|
+
for `close` or `create`, `aic` lists the choices.) Tags can not be
|
|
97
|
+
shortened, so `T.wr` must be typed in full (though `t.wr` works too).
|
|
98
|
+
`aic` also works from anywhere inside the project: it looks for the
|
|
99
|
+
collections in the current directory, and then in each parent directory
|
|
100
|
+
in turn, stopping at the top of a git or Mercurial repository.
|
|
101
|
+
|
|
102
|
+
Numbers are hierarchical, so a task can be broken into smaller ones:
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
aic t create 1.1 Draft the introduction
|
|
106
|
+
aic t create 2 Publish the README
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
Then `aic TASKS ls` lists:
|
|
110
|
+
|
|
111
|
+
```
|
|
112
|
+
1 Pending T.wr Write the README
|
|
113
|
+
1.1 Pending T.di Draft the introduction
|
|
114
|
+
2 Pending T.pr Publish the README
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
Hierarchical numbers:
|
|
118
|
+
|
|
119
|
+
* A hierarchical number is a sequence of positive integers separated by `.`
|
|
120
|
+
(e.g. `1.3.2`.)
|
|
121
|
+
* They can be sorted, but they are never allowed to have gaps.
|
|
122
|
+
Thus, task `1.3` can only be created after `1.1` and `1.2` exist.
|
|
123
|
+
* They change as tasks are added, moved, inserted and deleted. This is
|
|
124
|
+
why tags are typically used instead of hierarchical numbers.
|
|
125
|
+
* Text (and the AI) refers to a task by its tag followed by `~` and its
|
|
126
|
+
number at the time, such as `T.di~1.1`, so that its directory is easy
|
|
127
|
+
to find. The number is never updated afterwards, so it records what
|
|
128
|
+
the number was when the text was written. `aic` ignores the `~1.1`,
|
|
129
|
+
so `aic t open T.di~1.1` works too.
|
|
130
|
+
|
|
131
|
+
## Context Files
|
|
132
|
+
|
|
133
|
+
Each created sub-directory contains the following 4 files:
|
|
134
|
+
|
|
135
|
+
* **`Details.md`**:
|
|
136
|
+
This file is entirely edited by the User. It provides the description
|
|
137
|
+
of the Task/Issue. For a Task it describes the goal of the task. For
|
|
138
|
+
an Issue, it describes the Issue, but not necessarily how to fix it.
|
|
139
|
+
* **`Summary.md`**:
|
|
140
|
+
This is a file where the AI stores the context it needs once the
|
|
141
|
+
Task/Issue is closed.
|
|
142
|
+
* **`Context.md`**:
|
|
143
|
+
This file is where the AI stores the context it needs when working on it.
|
|
144
|
+
It is allowed to be quite detailed. However, the AI only sees the context
|
|
145
|
+
when the task or issue is in the Open (or Reference) state.
|
|
146
|
+
* **`.item.json`**:
|
|
147
|
+
This is a hidden file entirely managed by `aic` to keep track of things.
|
|
148
|
+
|
|
149
|
+
At AI startup, the AI is directed to read at most 2 of the 3 files
|
|
150
|
+
above:
|
|
151
|
+
|
|
152
|
+
* **`Details.md`**: This is read until the Task/Issue is closed.
|
|
153
|
+
* **`Context.md`**: This is read while the Task/Issue is open.
|
|
154
|
+
* **`Summary.md`**: This is read once the Task/Issue is closed.
|
|
155
|
+
|
|
156
|
+
Thus, the AI gets the context it needs to focus on individual Tasks
|
|
157
|
+
and/or Issues.
|
|
158
|
+
|
|
159
|
+
Prior to working on a task, first enter its details into `Details.md`,
|
|
160
|
+
then open it:
|
|
161
|
+
|
|
162
|
+
```
|
|
163
|
+
aic t open T.wr
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
The next AI session loads its `Details.md` and `Context.md`. When the
|
|
167
|
+
work is done, ask the AI to close the task: it writes the `Summary.md`
|
|
168
|
+
and it runs the `aic t close T.wr` command for you. In practice, you rarely
|
|
169
|
+
run `aic` yourself once the collections exist; you ask the AI to create,
|
|
170
|
+
open and close tasks and issues, and it runs the commands.
|
|
171
|
+
|
|
172
|
+
## States
|
|
173
|
+
|
|
174
|
+
A task (or issue) is always in one of these states:
|
|
175
|
+
|
|
176
|
+
* **Pending:** Not started yet. Every new task starts out Pending.
|
|
177
|
+
* **Open:** Being worked on. Its `Context.md` is loaded.
|
|
178
|
+
* **Reference:** Not being worked on, but its `Context.md` is still
|
|
179
|
+
loaded, so its notes stay available.
|
|
180
|
+
* **Suspended:** Put aside for now.
|
|
181
|
+
* **Closed:** Done. Only its `Summary.md` is loaded.
|
|
182
|
+
* **Rejected:** Decided against. It is treated like a Closed one.
|
|
183
|
+
|
|
184
|
+
The commands are named after the states (`pending`, `open`, `reference`,
|
|
185
|
+
`suspend`, `close` and `reject`), e.g. `aic t close T.wr`. `aic t ls`
|
|
186
|
+
leaves out Closed and Rejected tasks; `aic t ls -a` lists them all.
|
|
187
|
+
|
|
188
|
+
## Moving Things Around
|
|
189
|
+
|
|
190
|
+
* `aic t move T.di after 2` moves a task (and its children), and
|
|
191
|
+
`aic t create before 1 Outline the README` creates one in front of
|
|
192
|
+
another; the other tasks are renumbered to make room or close the gap.
|
|
193
|
+
* `aic t rename T.di to Draft the overview` changes a title. If that
|
|
194
|
+
changes the tag, `ai_contexts` offers to update the `.md` files that
|
|
195
|
+
use the old one, in the collections and directly in the project
|
|
196
|
+
directory (it suggests a `grep` command for anywhere else).
|
|
197
|
+
* `aic t transfer T.di issues` moves a task that turns out to be an issue
|
|
198
|
+
into `ISSUES/`, where its tag becomes `I.di`.
|
|
199
|
+
* `aic t delete T.di` deletes a task for good.
|
|
200
|
+
|
|
201
|
+
There is no undo, so keep the collections in a version control system.
|
|
202
|
+
Before a move, rename or transfer, if there has not been one for over an
|
|
203
|
+
hour, `ai_contexts` suggests taking a snapshot (e.g. `git commit`) first.
|
|
204
|
+
|
|
205
|
+
## Priorities
|
|
206
|
+
|
|
207
|
+
Issues can be given a priority once it is enabled for the collection
|
|
208
|
+
(`aic i enable priority`): 0 (catastrophic), 1 (high), 2 (medium) or 3
|
|
209
|
+
(low), set with `aic i priority I.dbzib 1`. `aic i ls` then lists the
|
|
210
|
+
issues by priority first.
|
|
211
|
+
|
|
212
|
+
## Other Conveniences
|
|
213
|
+
|
|
214
|
+
* A tag can stand in for its collection: `aic I.dbzib close` is the same
|
|
215
|
+
as `aic ISSUES close I.dbzib`.
|
|
216
|
+
* `aic T.wr show` shows everything about a task.
|
|
217
|
+
* `aic` with no arguments lists the collections, and `aic -h` lists all
|
|
218
|
+
of the commands.
|
|
219
|
+
* Every command checks the collections and tells you about anything that
|
|
220
|
+
needs fixing (such as a title edited by hand), and how to fix it.
|
|
221
|
+
|
|
222
|
+
## Rules Collections
|
|
223
|
+
|
|
224
|
+
A rules collection (e.g. `RULES/`) holds rules that the AI should load at
|
|
225
|
+
the start of every session, such as version control or coding rules
|
|
226
|
+
shared by several projects. Each rule is a file that can live anywhere,
|
|
227
|
+
and `ai_contexts` keeps a read-only copy of it in the project, as the
|
|
228
|
+
rule's `Details.md` (the AI may not import a file from outside the
|
|
229
|
+
project without approval):
|
|
230
|
+
|
|
231
|
+
The easiest way to get rules is to copy them from another project:
|
|
232
|
+
|
|
233
|
+
```
|
|
234
|
+
aic RULES create
|
|
235
|
+
aic r copy ../other_project/RULES
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
A collection named `RULES` is a rules collection from the start. (A
|
|
239
|
+
rules collection with another name is made with `aic NAME create`, and
|
|
240
|
+
then `aic n type rules` while it is still empty.)
|
|
241
|
+
x
|
|
242
|
+
`aic r copy` lists the other project's rules by number and title, and
|
|
243
|
+
asks which to copy:
|
|
244
|
+
|
|
245
|
+
```
|
|
246
|
+
Rules in ../other_project/RULES:
|
|
247
|
+
1 Code Marker Rules
|
|
248
|
+
2 Python Coding Rules
|
|
249
|
+
3 Version Control Rules
|
|
250
|
+
Copy which? (e.g. 1,3-5; empty for none) 2-3
|
|
251
|
+
1 InActive R.pcr Python Coding Rules
|
|
252
|
+
2 InActive R.vcr Version Control Rules
|
|
253
|
+
To use them: ai_contexts RULES activate 1-2
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
The choices are numbers and ranges, separated by commas or spaces, and
|
|
257
|
+
can also be given on the command line (`aic r copy ../other_project/RULES
|
|
258
|
+
2-3`). A rule you already have is marked `(have it)` and is not copied
|
|
259
|
+
again. The directory can also be any directory of rule files (e.g.
|
|
260
|
+
`../shared_rules/`), and a single file becomes a rule with `aic r create
|
|
261
|
+
1 ../shared_rules/Version_Control_Rules.md`. Either way, the rule's file
|
|
262
|
+
is its source, and `aic` keeps the copy up to date with it.
|
|
263
|
+
|
|
264
|
+
`aic` refuses to make a rule from a `CLAUDE.md` file, and asks before
|
|
265
|
+
using a file that looks like it is about the project (like `README.md`)
|
|
266
|
+
or that imports other files.
|
|
267
|
+
|
|
268
|
+
A new rule is InActive until it is activated. Every time `ai_contexts`
|
|
269
|
+
runs, it refreshes the copies from their source files and rewrites
|
|
270
|
+
`RULES/Active_Rules.md` to import the Active ones, so adding this line to
|
|
271
|
+
`CLAUDE.md` loads them:
|
|
272
|
+
|
|
273
|
+
```
|
|
274
|
+
@RULES/Active_Rules.md
|
|
275
|
+
```
|
|
276
|
+
|
|
277
|
+
## Installation
|
|
278
|
+
|
|
279
|
+
`ai_contexts` is a single Python program, `ai_contexts.py`, that needs
|
|
280
|
+
Python 3.11 or later and nothing beyond the standard library. Nothing
|
|
281
|
+
else needs to be installed: the rules it gives the AI are built in. To install
|
|
282
|
+
it:
|
|
283
|
+
|
|
284
|
+
1. Install the `aicontexts` package from PyPI, which gives you both the
|
|
285
|
+
`ai_contexts` and `aic` commands. With `uv` or `pipx`, it gets an
|
|
286
|
+
environment of its own:
|
|
287
|
+
|
|
288
|
+
```
|
|
289
|
+
uv tool install aicontexts
|
|
290
|
+
pipx install aicontexts
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
Or, without either, copy `ai_contexts.py` into a directory on your
|
|
294
|
+
`PATH`, and make a symbolic link to it named `aic`:
|
|
295
|
+
|
|
296
|
+
```
|
|
297
|
+
cp ai_contexts.py ~/bin/
|
|
298
|
+
ln -s ai_contexts.py ~/bin/aic
|
|
299
|
+
```
|
|
300
|
+
|
|
301
|
+
2. Check it with `aic --test`, which runs its tests in a temporary
|
|
302
|
+
directory.
|
|
303
|
+
|
|
304
|
+
3. Create the collections and set up `CLAUDE.md` as described in
|
|
305
|
+
"Getting Started".
|
|
306
|
+
|
|
307
|
+
`REFERENCE.md` has the details of how `ai_contexts` works.
|