agent-method 1.5.0
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.
- package/README.md +256 -0
- package/bin/agent-method.js +58 -0
- package/docs/internal/feature-registry.yaml +1532 -0
- package/lib/cli/check.js +71 -0
- package/lib/cli/helpers.js +151 -0
- package/lib/cli/init.js +60 -0
- package/lib/cli/pipeline.js +163 -0
- package/lib/cli/refine.js +202 -0
- package/lib/cli/route.js +62 -0
- package/lib/cli/scan.js +28 -0
- package/lib/cli/status.js +61 -0
- package/lib/cli/upgrade.js +146 -0
- package/lib/init.js +240 -0
- package/lib/pipeline.js +887 -0
- package/lib/registry.js +108 -0
- package/package.json +39 -0
- package/templates/README.md +293 -0
- package/templates/entry-points/.cursorrules +109 -0
- package/templates/entry-points/AGENT.md +109 -0
- package/templates/entry-points/CLAUDE.md +109 -0
- package/templates/extensions/MANIFEST.md +110 -0
- package/templates/extensions/analytical-system.md +96 -0
- package/templates/extensions/code-project.md +77 -0
- package/templates/extensions/data-exploration.md +117 -0
- package/templates/full/.context/BASE.md +68 -0
- package/templates/full/.context/COMPOSITION.md +47 -0
- package/templates/full/.context/METHODOLOGY.md +84 -0
- package/templates/full/.context/REGISTRY.md +75 -0
- package/templates/full/.cursorrules +128 -0
- package/templates/full/AGENT.md +128 -0
- package/templates/full/CLAUDE.md +128 -0
- package/templates/full/PLAN.md +67 -0
- package/templates/full/PROJECT-PROFILE.md +61 -0
- package/templates/full/PROJECT.md +46 -0
- package/templates/full/REQUIREMENTS.md +30 -0
- package/templates/full/ROADMAP.md +39 -0
- package/templates/full/SESSION-LOG.md +41 -0
- package/templates/full/STATE.md +42 -0
- package/templates/full/SUMMARY.md +24 -0
- package/templates/full/docs/index.md +46 -0
- package/templates/full/todos/backlog.md +19 -0
- package/templates/starter/.context/BASE.md +66 -0
- package/templates/starter/.context/METHODOLOGY.md +70 -0
- package/templates/starter/.cursorrules +113 -0
- package/templates/starter/AGENT.md +113 -0
- package/templates/starter/CLAUDE.md +113 -0
- package/templates/starter/PLAN.md +67 -0
- package/templates/starter/PROJECT-PROFILE.md +44 -0
- package/templates/starter/PROJECT.md +46 -0
- package/templates/starter/ROADMAP.md +39 -0
- package/templates/starter/SESSION-LOG.md +41 -0
- package/templates/starter/STATE.md +42 -0
|
@@ -0,0 +1,1532 @@
|
|
|
1
|
+
# Feature Registry — Operational Specification
|
|
2
|
+
#
|
|
3
|
+
# This is NOT just a catalog. It is the agent's behavioral protocol
|
|
4
|
+
# AND the computable source of truth for routing automation.
|
|
5
|
+
# Four layers:
|
|
6
|
+
# 1. Feature catalog — WHAT each capability is
|
|
7
|
+
# 2. Guided workflows — HOW features compose into task patterns
|
|
8
|
+
# 3. Agent protocol — WHY the agent does what it does
|
|
9
|
+
# 4. Routing rules — HOW queries map to features automatically
|
|
10
|
+
#
|
|
11
|
+
# The entry point, scoping rules, and cascade table in any project
|
|
12
|
+
# are concrete implementations derived from this registry.
|
|
13
|
+
# Tools read this file to generate entry points, classify queries,
|
|
14
|
+
# and validate behavior.
|
|
15
|
+
|
|
16
|
+
version: v1.5
|
|
17
|
+
|
|
18
|
+
# ============================================================
|
|
19
|
+
# LAYER 1: FEATURE CATALOG
|
|
20
|
+
# What each capability is, when it triggers, what it touches
|
|
21
|
+
# ============================================================
|
|
22
|
+
|
|
23
|
+
domains:
|
|
24
|
+
- id: CTX
|
|
25
|
+
name: Context management
|
|
26
|
+
purpose: Build and maintain the agent's understanding of the project so every session starts informed
|
|
27
|
+
project_types: [universal]
|
|
28
|
+
- id: QRY
|
|
29
|
+
name: Query routing
|
|
30
|
+
purpose: Ensure the agent reads the right files and only the right files for each task
|
|
31
|
+
project_types: [universal]
|
|
32
|
+
- id: STT
|
|
33
|
+
name: State management
|
|
34
|
+
purpose: Preserve decisions, uncertainties, and position across sessions so nothing is lost
|
|
35
|
+
project_types: [universal]
|
|
36
|
+
- id: TSK
|
|
37
|
+
name: Task execution
|
|
38
|
+
purpose: Structure work into verifiable units so progress is measurable and auditable
|
|
39
|
+
project_types: [universal]
|
|
40
|
+
- id: HAI
|
|
41
|
+
name: Human-agent interaction
|
|
42
|
+
purpose: Give the human control over agent autonomy and keep both audiences served
|
|
43
|
+
project_types: [universal]
|
|
44
|
+
- id: TPL
|
|
45
|
+
name: Template and bootstrap
|
|
46
|
+
purpose: Get a new project from zero to working agent collaboration in minutes
|
|
47
|
+
project_types: [universal]
|
|
48
|
+
- id: EXP
|
|
49
|
+
name: Data exploration
|
|
50
|
+
purpose: Build structured understanding of user-submitted data and provide interactive access
|
|
51
|
+
project_types: [data]
|
|
52
|
+
|
|
53
|
+
- id: SCAN
|
|
54
|
+
name: Project discovery
|
|
55
|
+
purpose: Inventory, map, and assess existing projects so the agent builds understanding before contributing
|
|
56
|
+
project_types: [universal]
|
|
57
|
+
|
|
58
|
+
features:
|
|
59
|
+
# --- Context management ---
|
|
60
|
+
- id: CTX-01
|
|
61
|
+
name: initContext
|
|
62
|
+
domain: CTX
|
|
63
|
+
project_types: [universal]
|
|
64
|
+
description: Initialize the .context/ structure for a new or existing project
|
|
65
|
+
trigger: Project bootstrap (first session after template copy)
|
|
66
|
+
reads: [PROJECT.md, project directory structure]
|
|
67
|
+
writes: [.context/BASE.md]
|
|
68
|
+
options:
|
|
69
|
+
mode: [greenfield, brownfield]
|
|
70
|
+
dependencies: [TPL-01]
|
|
71
|
+
stage: on_demand
|
|
72
|
+
version: v1
|
|
73
|
+
type_variants:
|
|
74
|
+
code: Scan directory tree, map modules, technology stack, build system
|
|
75
|
+
data: Scan data sources, build data inventory, identify schemas
|
|
76
|
+
analytical: Discover chains, map components, identify pipeline stages
|
|
77
|
+
agent_directive: >
|
|
78
|
+
On first session, detect whether this is a new or existing project.
|
|
79
|
+
For greenfield: create BASE.md with empty project map ready to fill.
|
|
80
|
+
For brownfield: scan the project structure and populate the map
|
|
81
|
+
so future sessions understand the project immediately.
|
|
82
|
+
|
|
83
|
+
- id: CTX-02
|
|
84
|
+
name: refreshContext
|
|
85
|
+
domain: CTX
|
|
86
|
+
project_types: [universal]
|
|
87
|
+
description: Rescan the project and update .context/ files to match current reality
|
|
88
|
+
trigger: User requests context refresh; agent detects stale context; return after significant external changes
|
|
89
|
+
reads: [.context/*, project directory structure, recent git changes]
|
|
90
|
+
writes: [.context/BASE.md, .context/{affected specialists}, entry point]
|
|
91
|
+
options:
|
|
92
|
+
scope: [full, incremental]
|
|
93
|
+
dependencies: [CTX-05]
|
|
94
|
+
stage: on_demand
|
|
95
|
+
version: v1
|
|
96
|
+
type_variants:
|
|
97
|
+
code: Compare codebase map against directory structure, updated deps
|
|
98
|
+
data: Compare data map against data sources for new data, schema changes
|
|
99
|
+
analytical: Compare pipeline map against system state for new stages, changed rules
|
|
100
|
+
agent_directive: >
|
|
101
|
+
Projects evolve between sessions. Context files that don't match reality
|
|
102
|
+
cause the agent to make wrong assumptions. When triggered, compare
|
|
103
|
+
what .context/ says against what actually exists. Update the project
|
|
104
|
+
map, flag drift, and ensure future sessions start with accurate context.
|
|
105
|
+
|
|
106
|
+
- id: CTX-03
|
|
107
|
+
name: pairContext
|
|
108
|
+
domain: CTX
|
|
109
|
+
project_types: [universal]
|
|
110
|
+
description: Load the appropriate context pair (BASE + specialist) for a query type
|
|
111
|
+
trigger: Every query after cold start
|
|
112
|
+
reads: [entry point scoping table, .context/BASE.md, .context/{matched specialist}]
|
|
113
|
+
writes: []
|
|
114
|
+
dependencies: [QRY-02]
|
|
115
|
+
stage: scope
|
|
116
|
+
version: v1
|
|
117
|
+
type_variants:
|
|
118
|
+
code: "BASE + code specialist (API.md, DATABASE.md, TESTING.md, etc.)"
|
|
119
|
+
data: "BASE + data specialist (SCHEMA.md, DOCUMENTS.md, RELATIONSHIPS.md)"
|
|
120
|
+
analytical: "BASE + domain specialist (COMPOSITION.md, EVALUATION.md, EXECUTION.md, etc.)"
|
|
121
|
+
agent_directive: >
|
|
122
|
+
Never load all context files. Load BASE.md (always) plus exactly one
|
|
123
|
+
specialist matched to the query type. This keeps context focused and
|
|
124
|
+
prevents the agent from being overwhelmed with irrelevant information.
|
|
125
|
+
|
|
126
|
+
- id: CTX-04
|
|
127
|
+
name: growContext
|
|
128
|
+
domain: CTX
|
|
129
|
+
project_types: [universal]
|
|
130
|
+
description: Create a new specialist context file when a new domain area is identified
|
|
131
|
+
trigger: Agent recognizes recurring domain not covered by existing specialists; user explicitly requests
|
|
132
|
+
reads: [.context/BASE.md, entry point, relevant source files]
|
|
133
|
+
writes: [.context/{SPECIALIST}.md, .context/BASE.md, entry point]
|
|
134
|
+
dependencies: [CTX-01]
|
|
135
|
+
stage: execute
|
|
136
|
+
version: v1
|
|
137
|
+
type_variants:
|
|
138
|
+
code: New code domain → new specialist (e.g., SECURITY.md when auth code grows)
|
|
139
|
+
data: New data dimension → new specialist or expanded existing
|
|
140
|
+
analytical: New pipeline stage → new specialist
|
|
141
|
+
agent_directive: >
|
|
142
|
+
As a project grows, new domain areas emerge that need their own context.
|
|
143
|
+
When you notice recurring questions about a domain not covered by existing
|
|
144
|
+
specialists, propose a new specialist file. This makes future sessions
|
|
145
|
+
in that domain more efficient.
|
|
146
|
+
|
|
147
|
+
- id: CTX-05
|
|
148
|
+
name: mapProject
|
|
149
|
+
domain: CTX
|
|
150
|
+
project_types: [universal]
|
|
151
|
+
description: Generate or update the project map section in BASE.md
|
|
152
|
+
trigger: CTX-01 bootstrap, CTX-02 refresh, cascade from project structure change
|
|
153
|
+
reads: [project directory structure, package files, key source files]
|
|
154
|
+
writes: [.context/BASE.md]
|
|
155
|
+
options:
|
|
156
|
+
mode: [codebase, data-sources, domain-chains]
|
|
157
|
+
depth: [shallow, deep]
|
|
158
|
+
dependencies: []
|
|
159
|
+
stage: execute
|
|
160
|
+
version: v1.1
|
|
161
|
+
type_variants:
|
|
162
|
+
codebase: Walk directory tree, record path/purpose/patterns/dependencies
|
|
163
|
+
data-sources: Scan data sources, record source/type/size/keys/dimensions
|
|
164
|
+
domain-chains: Trace input→transformation→output flows, record chains/components
|
|
165
|
+
agent_directive: >
|
|
166
|
+
The project map is the agent's working memory of the project structure.
|
|
167
|
+
For code: walk directories, record what each does and what patterns it uses.
|
|
168
|
+
For data: scan sources, record schemas, relationships, and dimensions.
|
|
169
|
+
For analytical systems: trace transformation chains and map components.
|
|
170
|
+
This map is what allows the agent to navigate without re-exploring every session.
|
|
171
|
+
|
|
172
|
+
- id: CTX-06
|
|
173
|
+
name: manageScale
|
|
174
|
+
domain: CTX
|
|
175
|
+
project_types: [universal]
|
|
176
|
+
description: Monitor file size, restructure into index + components when threshold exceeded, maintain navigation registry
|
|
177
|
+
trigger: After any file write that increases an intelligence layer file beyond 300 lines; after any file split, creation, deletion, or rename
|
|
178
|
+
reads: [affected file, .context/REGISTRY.md]
|
|
179
|
+
writes: [affected file (rewritten as index), new component subdirectory/files, .context/REGISTRY.md]
|
|
180
|
+
options:
|
|
181
|
+
threshold: [300]
|
|
182
|
+
grouping: [semantic, chronological]
|
|
183
|
+
dependencies: [QRY-03]
|
|
184
|
+
stage: execute
|
|
185
|
+
version: v1.2
|
|
186
|
+
type_variants:
|
|
187
|
+
all: >
|
|
188
|
+
Index keeps active/current content + navigation table linking to components.
|
|
189
|
+
Components are archived sections grouped by semantic boundary (phases, domains, time periods).
|
|
190
|
+
Subdirectory named after the file stem (e.g., SUMMARY.md -> summary/).
|
|
191
|
+
Navigation registry (.context/REGISTRY.md) tracks all files, topics, and structural changes.
|
|
192
|
+
agent_directive: >
|
|
193
|
+
After writing to an intelligence layer file, check its line count.
|
|
194
|
+
If it exceeds 300 lines, restructure: keep active content in the
|
|
195
|
+
original file (now an index with navigation table), move archived
|
|
196
|
+
sections to a subdirectory named after the file stem. Group archived
|
|
197
|
+
content by semantic boundaries. The index must remain self-sufficient
|
|
198
|
+
for current work — components hold history, not active state.
|
|
199
|
+
After ANY structural change (split, create, delete, rename), update
|
|
200
|
+
.context/REGISTRY.md: file tree (add/remove entries, update line counts),
|
|
201
|
+
topic index (add/redirect/remove entries), structural log (record what
|
|
202
|
+
happened and why). The registry is the agent's fast-lookup map — one
|
|
203
|
+
read gives the full picture of where content lives.
|
|
204
|
+
|
|
205
|
+
# --- Query routing ---
|
|
206
|
+
- id: QRY-01
|
|
207
|
+
name: coldStart
|
|
208
|
+
domain: QRY
|
|
209
|
+
project_types: [universal]
|
|
210
|
+
description: Two-file initialization protocol for every new session
|
|
211
|
+
trigger: Session start (always)
|
|
212
|
+
reads: [entry point, STATE.md]
|
|
213
|
+
writes: []
|
|
214
|
+
dependencies: []
|
|
215
|
+
stage: initialize
|
|
216
|
+
version: v1
|
|
217
|
+
agent_directive: >
|
|
218
|
+
Every session begins by reading exactly two files: the entry point
|
|
219
|
+
and STATE.md. This gives you scoping rules, cascade table, conventions,
|
|
220
|
+
current position, prior decisions, and open questions. Do not load
|
|
221
|
+
anything else until a query arrives.
|
|
222
|
+
|
|
223
|
+
- id: QRY-02
|
|
224
|
+
name: scopeQuery
|
|
225
|
+
domain: QRY
|
|
226
|
+
project_types: [universal]
|
|
227
|
+
description: Classify a human query and load the appropriate file set
|
|
228
|
+
trigger: Every human query after cold start
|
|
229
|
+
reads: [entry point scoping table]
|
|
230
|
+
writes: []
|
|
231
|
+
dependencies: [QRY-01]
|
|
232
|
+
stage: scope
|
|
233
|
+
version: v1
|
|
234
|
+
agent_directive: >
|
|
235
|
+
Match the user's query against the scoping table. Load the read-set.
|
|
236
|
+
Constrain writes to the write-set. If the query doesn't match any row
|
|
237
|
+
cleanly, ask the user to clarify before loading files. Tables are
|
|
238
|
+
your routing logic — follow them deterministically.
|
|
239
|
+
|
|
240
|
+
- id: QRY-03
|
|
241
|
+
name: cascadeUpdate
|
|
242
|
+
domain: QRY
|
|
243
|
+
project_types: [universal]
|
|
244
|
+
description: After a file change, propagate updates through the dependency chain
|
|
245
|
+
trigger: Any file change during execute or close stages
|
|
246
|
+
reads: [entry point cascade table]
|
|
247
|
+
writes: [dependent files per cascade rules]
|
|
248
|
+
dependencies: [QRY-02]
|
|
249
|
+
stage: execute
|
|
250
|
+
version: v1
|
|
251
|
+
agent_directive: >
|
|
252
|
+
After EVERY file change, check the cascade table. If the change matches
|
|
253
|
+
a trigger, update the dependent files in the same response. Deferred
|
|
254
|
+
cascades don't happen. Check for secondary cascades up to 2 levels deep.
|
|
255
|
+
|
|
256
|
+
# --- State management ---
|
|
257
|
+
- id: STT-01
|
|
258
|
+
name: recordDecision
|
|
259
|
+
domain: STT
|
|
260
|
+
project_types: [universal]
|
|
261
|
+
description: Capture decisions in STATE.md immediately when made
|
|
262
|
+
trigger: Agent makes or recognizes a decision during any stage
|
|
263
|
+
reads: [STATE.md]
|
|
264
|
+
writes: [STATE.md]
|
|
265
|
+
dependencies: []
|
|
266
|
+
stage: execute
|
|
267
|
+
version: v1
|
|
268
|
+
agent_directive: >
|
|
269
|
+
When you make a decision, write it to STATE.md in the SAME RESPONSE
|
|
270
|
+
as the work that produced it. Never defer. If deferred, it's lost.
|
|
271
|
+
|
|
272
|
+
- id: STT-02
|
|
273
|
+
name: flagUncertainty
|
|
274
|
+
domain: STT
|
|
275
|
+
project_types: [universal]
|
|
276
|
+
description: Track open questions as first-class artifacts in STATE.md
|
|
277
|
+
trigger: Agent encounters an ambiguity, unknown, or needs human input
|
|
278
|
+
reads: [STATE.md]
|
|
279
|
+
writes: [STATE.md]
|
|
280
|
+
dependencies: []
|
|
281
|
+
stage: plan
|
|
282
|
+
version: v1
|
|
283
|
+
agent_directive: >
|
|
284
|
+
When you're unsure, write it as an open question in STATE.md.
|
|
285
|
+
Do not guess silently. When resolved, strike through and add
|
|
286
|
+
resolution text — don't delete.
|
|
287
|
+
|
|
288
|
+
- id: STT-03
|
|
289
|
+
name: trackPosition
|
|
290
|
+
domain: STT
|
|
291
|
+
project_types: [universal]
|
|
292
|
+
description: Maintain the current phase and status in STATE.md
|
|
293
|
+
trigger: Phase transitions, task completion, session close
|
|
294
|
+
reads: [STATE.md]
|
|
295
|
+
writes: [STATE.md]
|
|
296
|
+
dependencies: [TSK-03]
|
|
297
|
+
stage: close
|
|
298
|
+
version: v1
|
|
299
|
+
agent_directive: >
|
|
300
|
+
STATE.md "Current position" must always reflect: what phase, what status
|
|
301
|
+
within it, what comes next, and what context is active.
|
|
302
|
+
|
|
303
|
+
# --- Task execution ---
|
|
304
|
+
- id: TSK-01
|
|
305
|
+
name: planTask
|
|
306
|
+
domain: TSK
|
|
307
|
+
project_types: [universal]
|
|
308
|
+
description: Create a structured PLAN.md with substeps and verification criteria
|
|
309
|
+
trigger: Start of a new task (plan stage)
|
|
310
|
+
reads: [REQUIREMENTS.md, ROADMAP.md, relevant .context/]
|
|
311
|
+
writes: [PLAN.md]
|
|
312
|
+
options:
|
|
313
|
+
detail: [minimal, standard, detailed]
|
|
314
|
+
dependencies: [HAI-01]
|
|
315
|
+
stage: plan
|
|
316
|
+
version: v1
|
|
317
|
+
agent_directive: >
|
|
318
|
+
Produce a plan with: objective, prerequisites, steps with read/produce
|
|
319
|
+
specs, and verification criteria. Plans are atomic — one task at a time.
|
|
320
|
+
Propose and wait for approval before executing.
|
|
321
|
+
|
|
322
|
+
- id: TSK-02
|
|
323
|
+
name: verifyTask
|
|
324
|
+
domain: TSK
|
|
325
|
+
project_types: [universal]
|
|
326
|
+
description: Check completed work against embedded verification criteria
|
|
327
|
+
trigger: Verify stage (after execution)
|
|
328
|
+
reads: [PLAN.md]
|
|
329
|
+
writes: [verification results in SUMMARY.md]
|
|
330
|
+
dependencies: [TSK-01]
|
|
331
|
+
stage: verify
|
|
332
|
+
version: v1
|
|
333
|
+
agent_directive: >
|
|
334
|
+
Read verification criteria from PLAN.md. Check each against completed
|
|
335
|
+
work. Report pass/fail with specific evidence.
|
|
336
|
+
|
|
337
|
+
- id: TSK-03
|
|
338
|
+
name: closeSession
|
|
339
|
+
domain: TSK
|
|
340
|
+
project_types: [universal]
|
|
341
|
+
description: Execute the close stage - SUMMARY, STATE, ROADMAP updates
|
|
342
|
+
trigger: Task or session completion
|
|
343
|
+
reads: [SUMMARY.md, STATE.md, ROADMAP.md]
|
|
344
|
+
writes: [SUMMARY.md, STATE.md, ROADMAP.md]
|
|
345
|
+
dependencies: [TSK-04, QRY-03]
|
|
346
|
+
stage: close
|
|
347
|
+
version: v1
|
|
348
|
+
agent_directive: >
|
|
349
|
+
Write SUMMARY.md entry. Update STATE.md position. Mark ROADMAP.md
|
|
350
|
+
if phase complete. Non-negotiable phase completion cascade.
|
|
351
|
+
|
|
352
|
+
- id: TSK-04
|
|
353
|
+
name: auditTrail
|
|
354
|
+
domain: TSK
|
|
355
|
+
project_types: [universal]
|
|
356
|
+
description: Maintain SUMMARY.md in the standard session entry format
|
|
357
|
+
trigger: TSK-03 closeSession
|
|
358
|
+
reads: [session work products, STATE.md]
|
|
359
|
+
writes: [SUMMARY.md]
|
|
360
|
+
dependencies: []
|
|
361
|
+
stage: close
|
|
362
|
+
version: v1
|
|
363
|
+
agent_directive: >
|
|
364
|
+
Each SUMMARY entry: date, plan, outcome, files created/updated,
|
|
365
|
+
decisions captured, next. The "Next" field bridges to the following session.
|
|
366
|
+
|
|
367
|
+
# --- Human-agent interaction ---
|
|
368
|
+
- id: HAI-01
|
|
369
|
+
name: checkpoint
|
|
370
|
+
domain: HAI
|
|
371
|
+
project_types: [universal]
|
|
372
|
+
description: Surface a plan proposal for human approval before execution
|
|
373
|
+
trigger: Plan stage (skipped at autonomous level)
|
|
374
|
+
reads: [proposed plan]
|
|
375
|
+
writes: []
|
|
376
|
+
dependencies: [HAI-02]
|
|
377
|
+
stage: plan
|
|
378
|
+
version: v1
|
|
379
|
+
agent_directive: >
|
|
380
|
+
Present your plan and WAIT for human approval. This is the PRIMARY
|
|
381
|
+
CHECKPOINT. A wrong plan executed perfectly is still failure.
|
|
382
|
+
|
|
383
|
+
- id: HAI-02
|
|
384
|
+
name: setInteractionLevel
|
|
385
|
+
domain: HAI
|
|
386
|
+
project_types: [universal]
|
|
387
|
+
description: Configure the checkpoint density for a session
|
|
388
|
+
trigger: Entry point mode setting read during cold start
|
|
389
|
+
reads: [entry point]
|
|
390
|
+
writes: []
|
|
391
|
+
options:
|
|
392
|
+
level: [autonomous, checkpoint, collaborative, supervised]
|
|
393
|
+
dependencies: [QRY-01]
|
|
394
|
+
stage: initialize
|
|
395
|
+
version: v1
|
|
396
|
+
agent_directive: >
|
|
397
|
+
Read the mode setting. It controls how often you pause. Default
|
|
398
|
+
is checkpoint. Respect the configured level.
|
|
399
|
+
|
|
400
|
+
- id: HAI-03
|
|
401
|
+
name: dualAudience
|
|
402
|
+
domain: HAI
|
|
403
|
+
project_types: [universal]
|
|
404
|
+
description: Maintain separation between agent-facing and human-facing files
|
|
405
|
+
trigger: Any file write during execute or close stages
|
|
406
|
+
reads: [entry point docs trigger mapping]
|
|
407
|
+
writes: [agent files, human files per trigger mapping]
|
|
408
|
+
dependencies: [HAI-04]
|
|
409
|
+
stage: execute
|
|
410
|
+
version: v1
|
|
411
|
+
agent_directive: >
|
|
412
|
+
Agent files (STATE.md, .context/) are for machine parsing.
|
|
413
|
+
Human files (docs/) use visual formats. Never mix audiences.
|
|
414
|
+
|
|
415
|
+
- id: HAI-04
|
|
416
|
+
name: docsTrigger
|
|
417
|
+
domain: HAI
|
|
418
|
+
project_types: [universal]
|
|
419
|
+
description: Update docs/ based on the trigger mapping in the entry point
|
|
420
|
+
trigger: Structural changes matching entry point docs maintenance table
|
|
421
|
+
reads: [entry point docs trigger table]
|
|
422
|
+
writes: [specific docs/ files per trigger]
|
|
423
|
+
dependencies: [HAI-03]
|
|
424
|
+
stage: close
|
|
425
|
+
version: v1
|
|
426
|
+
agent_directive: >
|
|
427
|
+
When structural changes match a trigger, update specified docs/ files.
|
|
428
|
+
Typo fixes and internal adjustments do NOT trigger docs updates.
|
|
429
|
+
|
|
430
|
+
- id: HAI-05
|
|
431
|
+
name: modelCapabilityCheck
|
|
432
|
+
domain: HAI
|
|
433
|
+
project_types: [universal]
|
|
434
|
+
description: Detect when the agent consistently fails methodology requirements due to model capability limitations
|
|
435
|
+
trigger: Agent detects repeated pattern failures (missed cascades, forgotten decisions, shallow context, incomplete discovery)
|
|
436
|
+
reads: [STATE.md, entry point, session history]
|
|
437
|
+
writes: [STATE.md (open question with capability warning)]
|
|
438
|
+
dependencies: []
|
|
439
|
+
stage: execute
|
|
440
|
+
version: v1
|
|
441
|
+
degradation_signals:
|
|
442
|
+
- pattern: Cascade misses — file changed but dependent files not updated in same response
|
|
443
|
+
threshold: 2+ misses in a session
|
|
444
|
+
recommendation: Switch to Sonnet or higher for this task type
|
|
445
|
+
- pattern: Decision recording failures — decisions made but not written to STATE.md
|
|
446
|
+
threshold: Any deferred decision recording
|
|
447
|
+
recommendation: Simpler model may not handle simultaneous work + recording
|
|
448
|
+
- pattern: Shallow context — .context/ files populated with generic content lacking project-specific detail
|
|
449
|
+
threshold: Context quality score < 3 (from protocol tools)
|
|
450
|
+
recommendation: Discovery tasks (WF-08) require Sonnet+; use Haiku only for greenfield/simple workflows
|
|
451
|
+
- pattern: Incomplete discovery — SCAN features produce shallow inventories missing architectural patterns
|
|
452
|
+
threshold: Brownfield scan misses >30% of project structure
|
|
453
|
+
recommendation: WF-08 requires Sonnet+ capability; Haiku cannot handle discovery
|
|
454
|
+
- pattern: Instruction loss — agent stops following entry point conventions mid-session
|
|
455
|
+
threshold: Conventions violated after being followed earlier in same session
|
|
456
|
+
recommendation: Entry point may exceed model's effective context window; switch to lite profile
|
|
457
|
+
agent_directive: >
|
|
458
|
+
Monitor your own methodology adherence. If you notice you are repeatedly
|
|
459
|
+
missing cascades, forgetting to update STATE.md, producing shallow context,
|
|
460
|
+
or losing track of entry point conventions, surface this to the user:
|
|
461
|
+
"I'm noticing degraded methodology adherence — this task may benefit from
|
|
462
|
+
a more capable model (Sonnet/Opus) or a lighter integration profile."
|
|
463
|
+
Record the observation as an open question in STATE.md.
|
|
464
|
+
|
|
465
|
+
# --- Template and bootstrap ---
|
|
466
|
+
- id: TPL-01
|
|
467
|
+
name: bootstrap
|
|
468
|
+
domain: TPL
|
|
469
|
+
project_types: [universal]
|
|
470
|
+
description: Initialize a project from the template with guided content
|
|
471
|
+
trigger: First session on a new project
|
|
472
|
+
reads: [template files]
|
|
473
|
+
writes: [PROJECT.md, .context/BASE.md, STATE.md]
|
|
474
|
+
options:
|
|
475
|
+
template: [starter, full]
|
|
476
|
+
dependencies: [CTX-01, TPL-02]
|
|
477
|
+
stage: on_demand
|
|
478
|
+
version: v1
|
|
479
|
+
agent_directive: >
|
|
480
|
+
Read guided content. Help user fill PROJECT.md. Run initContext.
|
|
481
|
+
For brownfield, scan existing project to build the map.
|
|
482
|
+
|
|
483
|
+
- id: TPL-02
|
|
484
|
+
name: detectRuntime
|
|
485
|
+
domain: TPL
|
|
486
|
+
project_types: [universal]
|
|
487
|
+
description: Determine which entry point file is active
|
|
488
|
+
trigger: Cold start (implicit)
|
|
489
|
+
reads: [loaded entry point file]
|
|
490
|
+
writes: []
|
|
491
|
+
dependencies: []
|
|
492
|
+
stage: initialize
|
|
493
|
+
version: v1
|
|
494
|
+
agent_directive: >
|
|
495
|
+
Templates ship all three variants. Runtime auto-loads the appropriate one.
|
|
496
|
+
|
|
497
|
+
- id: TPL-03
|
|
498
|
+
name: structureSelect
|
|
499
|
+
domain: TPL
|
|
500
|
+
project_types: [universal]
|
|
501
|
+
description: Choose template tier based on project complexity
|
|
502
|
+
trigger: TPL-01 bootstrap or user upgrade request
|
|
503
|
+
reads: [PROJECT.md, user input]
|
|
504
|
+
writes: [additional template files if upgrading]
|
|
505
|
+
options:
|
|
506
|
+
tier: [starter, full]
|
|
507
|
+
dependencies: [TPL-01]
|
|
508
|
+
stage: on_demand
|
|
509
|
+
version: v1
|
|
510
|
+
agent_directive: >
|
|
511
|
+
Starter for most projects. Full when project has multiple phases
|
|
512
|
+
or needs dual-audience separation. Offer upgrade path.
|
|
513
|
+
|
|
514
|
+
# --- Data exploration ---
|
|
515
|
+
- id: EXP-01
|
|
516
|
+
name: ingestData
|
|
517
|
+
domain: EXP
|
|
518
|
+
project_types: [data]
|
|
519
|
+
description: Scan submitted data sources, classify by type, sample content, measure scale, detect quality signals
|
|
520
|
+
trigger: User submits new data source (CSV, database, repo, document set)
|
|
521
|
+
reads: [data source, .context/BASE.md]
|
|
522
|
+
writes: [.context/BASE.md (data inventory), specialist stubs]
|
|
523
|
+
options:
|
|
524
|
+
source_type: [structured, repository, documents, mixed]
|
|
525
|
+
dependencies: [CTX-01]
|
|
526
|
+
stage: on_demand
|
|
527
|
+
version: v1.1
|
|
528
|
+
agent_directive: >
|
|
529
|
+
When data is submitted, scan for structure (columns, types, file names,
|
|
530
|
+
directory layout). Sample content. Measure scale (row counts, file counts).
|
|
531
|
+
Detect quality signals (null rates, duplicates, encoding). Present
|
|
532
|
+
findings to user. Do NOT try to understand everything — map the surface
|
|
533
|
+
first, deep understanding comes in the Map stage.
|
|
534
|
+
|
|
535
|
+
- id: EXP-02
|
|
536
|
+
name: buildReferences
|
|
537
|
+
domain: EXP
|
|
538
|
+
project_types: [data]
|
|
539
|
+
description: Transform raw data mapping into structured reference artifacts
|
|
540
|
+
trigger: After EXP-01 ingest and CTX-05 mapping, or user requests reference building
|
|
541
|
+
reads: [.context/BASE.md, relevant specialist, data sources]
|
|
542
|
+
writes: [specialist context files (entity registries, topic taxonomies, dimension indices, metric catalogs)]
|
|
543
|
+
dependencies: [EXP-01, CTX-05]
|
|
544
|
+
stage: execute
|
|
545
|
+
version: v1.1
|
|
546
|
+
agent_directive: >
|
|
547
|
+
Build navigable reference artifacts from the data map. Entity registries,
|
|
548
|
+
topic taxonomies, queryable dimension indices, derived metric catalogs.
|
|
549
|
+
References are the bridge between raw data and interactive exploration.
|
|
550
|
+
Each reference entry must be addressable, cross-linked, and source-attributed.
|
|
551
|
+
|
|
552
|
+
- id: EXP-03
|
|
553
|
+
name: exploreCommand
|
|
554
|
+
domain: EXP
|
|
555
|
+
project_types: [data]
|
|
556
|
+
description: Recognize and execute named exploration patterns consistently
|
|
557
|
+
trigger: User query matching an exploration command pattern
|
|
558
|
+
reads: [.context/BASE.md, relevant specialist per command type]
|
|
559
|
+
writes: [STATE.md (exploration path)]
|
|
560
|
+
options:
|
|
561
|
+
commands: [explore, schema, search, relate, quality, timeline, dimensions, gaps, summary]
|
|
562
|
+
dependencies: [QRY-02, CTX-03]
|
|
563
|
+
stage: execute
|
|
564
|
+
version: v1.1
|
|
565
|
+
agent_directive: >
|
|
566
|
+
Recognize named exploration patterns in user queries. Each command
|
|
567
|
+
maps to a specific specialist and action. Most exploration queries
|
|
568
|
+
are read-only — they don't produce file changes. Progressively reveal
|
|
569
|
+
available commands as the user explores.
|
|
570
|
+
|
|
571
|
+
- id: EXP-04
|
|
572
|
+
name: manageAbstraction
|
|
573
|
+
domain: EXP
|
|
574
|
+
project_types: [data]
|
|
575
|
+
description: Navigate the abstraction ladder, deciding when to access raw data vs references
|
|
576
|
+
trigger: Any data query during exploration
|
|
577
|
+
reads: [.context/BASE.md, relevant specialist]
|
|
578
|
+
writes: []
|
|
579
|
+
dependencies: [EXP-03]
|
|
580
|
+
stage: execute
|
|
581
|
+
version: v1.1
|
|
582
|
+
agent_directive: >
|
|
583
|
+
Work at Level 2-3 (summaries and references) by default. Drop to
|
|
584
|
+
Level 0-1 (raw data, schema) only for specific queries that require
|
|
585
|
+
actual data values. Context files contain understanding, not data.
|
|
586
|
+
If a recurring query needs Level 0 access, propose adding the result
|
|
587
|
+
as a derived metric or reference in the specialist.
|
|
588
|
+
|
|
589
|
+
# --- Project discovery ---
|
|
590
|
+
- id: SCAN-01
|
|
591
|
+
name: codebaseInventory
|
|
592
|
+
domain: SCAN
|
|
593
|
+
project_types: [universal]
|
|
594
|
+
description: Walk the project structure and build a complete inventory of directories, files, modules, and their purposes
|
|
595
|
+
trigger: Discovery stage entry (brownfield bootstrap, methodology first applied to existing project, major re-assessment)
|
|
596
|
+
reads: [project directory structure, package files, entry points, key source files]
|
|
597
|
+
writes: [.context/BASE.md (project map)]
|
|
598
|
+
options:
|
|
599
|
+
depth: [shallow, deep]
|
|
600
|
+
dependencies: [CTX-05]
|
|
601
|
+
stage: on_demand
|
|
602
|
+
version: v1.4
|
|
603
|
+
type_variants:
|
|
604
|
+
code: Walk directory tree, identify modules, map build system, record technology stack
|
|
605
|
+
data: Scan data directories, inventory data files, identify schema sources
|
|
606
|
+
analytical: Trace pipeline components, inventory chain stages, map orchestration config
|
|
607
|
+
agent_directive: >
|
|
608
|
+
Walk the entire project directory structure. For each significant directory
|
|
609
|
+
and file, record: path, purpose (inferred from names, contents, conventions),
|
|
610
|
+
key patterns, and dependencies. The inventory is the foundation — you cannot
|
|
611
|
+
contribute effectively to code you haven't mapped. Output goes into the
|
|
612
|
+
project map section of BASE.md.
|
|
613
|
+
|
|
614
|
+
- id: SCAN-02
|
|
615
|
+
name: dependencyMapping
|
|
616
|
+
domain: SCAN
|
|
617
|
+
project_types: [universal]
|
|
618
|
+
description: Map all internal and external dependencies — packages, modules, services, data flows
|
|
619
|
+
trigger: SCAN-01 inventory (cascade), explicit dependency analysis request
|
|
620
|
+
reads: [package manifests, import statements, configuration files, .context/BASE.md]
|
|
621
|
+
writes: [.context/BASE.md (dependencies section)]
|
|
622
|
+
dependencies: [SCAN-01]
|
|
623
|
+
stage: on_demand
|
|
624
|
+
version: v1.4
|
|
625
|
+
type_variants:
|
|
626
|
+
code: Parse package.json/Cargo.toml/requirements.txt, trace import graphs, map service dependencies
|
|
627
|
+
data: Map data source connections, trace ETL flows, identify schema dependencies
|
|
628
|
+
analytical: Map chain dependencies, trace data flows between pipeline stages
|
|
629
|
+
agent_directive: >
|
|
630
|
+
After the inventory, map how pieces connect. Parse package manifests for
|
|
631
|
+
external dependencies. Trace imports for internal module dependencies.
|
|
632
|
+
Identify service-to-service connections. Record version constraints.
|
|
633
|
+
This map tells you what breaks when something changes — essential for
|
|
634
|
+
cascade accuracy and safe modifications.
|
|
635
|
+
|
|
636
|
+
- id: SCAN-03
|
|
637
|
+
name: patternExtraction
|
|
638
|
+
domain: SCAN
|
|
639
|
+
project_types: [universal]
|
|
640
|
+
description: Identify recurring code patterns, conventions, and architectural decisions in the existing project
|
|
641
|
+
trigger: SCAN-01 inventory (cascade), explicit pattern analysis request, Evolution stage refactoring
|
|
642
|
+
reads: [source files (sampled), .context/BASE.md, existing .context/ specialists]
|
|
643
|
+
writes: [.context/ specialists (proposed), STATE.md (architectural decisions discovered)]
|
|
644
|
+
dependencies: [SCAN-01]
|
|
645
|
+
stage: on_demand
|
|
646
|
+
version: v1.4
|
|
647
|
+
type_variants:
|
|
648
|
+
code: Identify naming conventions, error handling patterns, test patterns, API design patterns
|
|
649
|
+
data: Identify data modeling patterns, query patterns, transformation conventions
|
|
650
|
+
analytical: Identify composition patterns, evaluation approaches, orchestration conventions
|
|
651
|
+
agent_directive: >
|
|
652
|
+
Sample key files across the project. Identify recurring patterns:
|
|
653
|
+
naming conventions, error handling, testing approach, architectural patterns,
|
|
654
|
+
design decisions embedded in the code. Each pattern is a convention the agent
|
|
655
|
+
must follow in future work. Patterns become specialist file candidates.
|
|
656
|
+
Record discovered architectural decisions in STATE.md — these are decisions
|
|
657
|
+
that were already made, just not documented.
|
|
658
|
+
|
|
659
|
+
- id: SCAN-04
|
|
660
|
+
name: debtAssessment
|
|
661
|
+
domain: SCAN
|
|
662
|
+
project_types: [universal]
|
|
663
|
+
description: Identify technical debt, inconsistencies, security concerns, and improvement opportunities
|
|
664
|
+
trigger: Explicit assessment request, Discovery stage completion, Evolution stage periodic review
|
|
665
|
+
reads: [.context/BASE.md, .context/ specialists, source files (targeted)]
|
|
666
|
+
writes: [STATE.md (open questions for debt items), PLAN.md (remediation priorities if requested)]
|
|
667
|
+
dependencies: [SCAN-01, SCAN-03]
|
|
668
|
+
stage: on_demand
|
|
669
|
+
version: v1.4
|
|
670
|
+
type_variants:
|
|
671
|
+
code: Outdated dependencies, missing tests, inconsistent patterns, security vulnerabilities, dead code
|
|
672
|
+
data: Stale data, missing validation, undocumented schemas, quality gaps
|
|
673
|
+
analytical: Outdated evaluation criteria, untested chains, missing documentation
|
|
674
|
+
agent_directive: >
|
|
675
|
+
Based on the inventory and patterns, identify areas of concern:
|
|
676
|
+
outdated dependencies, missing tests, inconsistent conventions, security
|
|
677
|
+
issues, dead code, documentation gaps. Each finding becomes an open
|
|
678
|
+
question in STATE.md with severity assessment. Do NOT attempt to fix
|
|
679
|
+
everything — assess and prioritize. The human decides what to address.
|
|
680
|
+
|
|
681
|
+
# ============================================================
|
|
682
|
+
# LAYER 2: GUIDED WORKFLOWS
|
|
683
|
+
# How features compose into reusable task patterns.
|
|
684
|
+
# ============================================================
|
|
685
|
+
|
|
686
|
+
workflows:
|
|
687
|
+
- id: WF-01
|
|
688
|
+
name: standard-task
|
|
689
|
+
project_types: [universal]
|
|
690
|
+
description: >
|
|
691
|
+
The default workflow for any task. Review current state, plan the work,
|
|
692
|
+
implement changes, update documentation and context, close with
|
|
693
|
+
management file updates. This is the backbone pattern.
|
|
694
|
+
steps:
|
|
695
|
+
- name: review
|
|
696
|
+
stage: scope
|
|
697
|
+
description: Read current state, understand context, identify what needs to change
|
|
698
|
+
features: [QRY-01, QRY-02, CTX-03]
|
|
699
|
+
agent_action: >
|
|
700
|
+
Load entry point + STATE.md (cold start). Classify the query.
|
|
701
|
+
Load the scoped context. Understand the current position and
|
|
702
|
+
what decisions have been made. Read relevant files.
|
|
703
|
+
- name: plan
|
|
704
|
+
stage: plan
|
|
705
|
+
description: Propose structured plan with verification criteria
|
|
706
|
+
features: [TSK-01, HAI-01, STT-02]
|
|
707
|
+
agent_action: >
|
|
708
|
+
Draft a plan with objectives, steps, read/produce specs, and
|
|
709
|
+
verification criteria. Surface any unknowns as open questions.
|
|
710
|
+
Present to human for approval. Wait before executing.
|
|
711
|
+
- name: implement
|
|
712
|
+
stage: execute
|
|
713
|
+
description: Execute plan, record decisions, cascade changes
|
|
714
|
+
features: [STT-01, QRY-03, CTX-05, HAI-03]
|
|
715
|
+
agent_action: >
|
|
716
|
+
Follow the plan step by step. After each file change, check
|
|
717
|
+
cascades and update dependent files. Record every decision in
|
|
718
|
+
STATE.md immediately. If the project structure changed, update
|
|
719
|
+
the map in BASE.md.
|
|
720
|
+
- name: document
|
|
721
|
+
stage: execute
|
|
722
|
+
description: Update context files and triggered docs
|
|
723
|
+
features: [CTX-04, CTX-05, HAI-04]
|
|
724
|
+
agent_action: >
|
|
725
|
+
If new domain areas were discovered, propose specialist context
|
|
726
|
+
files. Update BASE.md map if structure changed. Check docs
|
|
727
|
+
trigger table and update human-facing docs if structural changes.
|
|
728
|
+
- name: update
|
|
729
|
+
stage: close
|
|
730
|
+
description: Close session with audit trail and position update
|
|
731
|
+
features: [TSK-03, TSK-04, STT-03]
|
|
732
|
+
agent_action: >
|
|
733
|
+
Write SUMMARY.md entry. Update STATE.md position. Mark ROADMAP.md
|
|
734
|
+
if phase complete. The "Next" field bridges to the next session.
|
|
735
|
+
|
|
736
|
+
- id: WF-02
|
|
737
|
+
name: code-change
|
|
738
|
+
project_types: [code]
|
|
739
|
+
description: >
|
|
740
|
+
When the user asks to modify code. The agent doesn't just change files —
|
|
741
|
+
it maintains the project's understanding of itself.
|
|
742
|
+
steps:
|
|
743
|
+
- name: review
|
|
744
|
+
stage: scope
|
|
745
|
+
description: Understand what exists before changing it
|
|
746
|
+
features: [QRY-01, QRY-02, CTX-03]
|
|
747
|
+
agent_action: >
|
|
748
|
+
Load context for the relevant domain. Read the files that will
|
|
749
|
+
be affected. Read tests first. Understand dependencies.
|
|
750
|
+
- name: plan
|
|
751
|
+
stage: plan
|
|
752
|
+
description: Propose code changes with cascade impacts identified
|
|
753
|
+
features: [TSK-01, HAI-01]
|
|
754
|
+
agent_action: >
|
|
755
|
+
Plan the code change. Identify cascade triggers. List all files
|
|
756
|
+
affected (direct + cascade). Include context updates in the plan.
|
|
757
|
+
- name: implement
|
|
758
|
+
stage: execute
|
|
759
|
+
description: Make changes, cascade, update context
|
|
760
|
+
features: [STT-01, QRY-03, CTX-05]
|
|
761
|
+
agent_action: >
|
|
762
|
+
Make the code change. Immediately cascade to dependent files.
|
|
763
|
+
Update .context/BASE.md codebase map if structure changed.
|
|
764
|
+
Record the decision in STATE.md.
|
|
765
|
+
- name: context-sync
|
|
766
|
+
stage: execute
|
|
767
|
+
description: Ensure future sessions understand the change
|
|
768
|
+
features: [CTX-04, CTX-05, HAI-03]
|
|
769
|
+
agent_action: >
|
|
770
|
+
This is the key step. Update the codebase map so the next session
|
|
771
|
+
knows about the new code. If a new domain emerged, propose a
|
|
772
|
+
specialist. The agent is building understanding for its future self.
|
|
773
|
+
- name: update
|
|
774
|
+
stage: close
|
|
775
|
+
description: Record and close
|
|
776
|
+
features: [TSK-03, TSK-04, STT-03]
|
|
777
|
+
agent_action: Write audit trail. Update position. Bridge to next session.
|
|
778
|
+
|
|
779
|
+
- id: WF-03
|
|
780
|
+
name: context-refresh
|
|
781
|
+
project_types: [universal]
|
|
782
|
+
description: >
|
|
783
|
+
Resync the agent's understanding with the actual project state.
|
|
784
|
+
Used when the project has changed significantly between sessions.
|
|
785
|
+
steps:
|
|
786
|
+
- name: scan
|
|
787
|
+
stage: scope
|
|
788
|
+
description: Read current .context/ and compare against reality
|
|
789
|
+
features: [QRY-01, CTX-02]
|
|
790
|
+
agent_action: >
|
|
791
|
+
Load all .context/ files. Scan the actual project structure.
|
|
792
|
+
Identify drift: new items, removed items, renamed files,
|
|
793
|
+
updated dependencies.
|
|
794
|
+
- name: compare
|
|
795
|
+
stage: plan
|
|
796
|
+
description: Identify what's stale and what's missing
|
|
797
|
+
features: [CTX-05]
|
|
798
|
+
agent_action: >
|
|
799
|
+
Build a diff between what .context/ says and what exists.
|
|
800
|
+
Flag significant drift to the user.
|
|
801
|
+
- name: update-context
|
|
802
|
+
stage: execute
|
|
803
|
+
description: Rewrite context files to match reality
|
|
804
|
+
features: [CTX-05, CTX-04]
|
|
805
|
+
agent_action: >
|
|
806
|
+
Update BASE.md project map. Update affected specialist files.
|
|
807
|
+
If new domain areas are discovered, propose new specialists.
|
|
808
|
+
- name: cascade
|
|
809
|
+
stage: execute
|
|
810
|
+
description: Propagate context changes
|
|
811
|
+
features: [QRY-03]
|
|
812
|
+
agent_action: >
|
|
813
|
+
If scoping rules or cascade rules need updating,
|
|
814
|
+
update the entry point.
|
|
815
|
+
- name: record
|
|
816
|
+
stage: close
|
|
817
|
+
description: Log what changed and why
|
|
818
|
+
features: [STT-01, TSK-04]
|
|
819
|
+
agent_action: >
|
|
820
|
+
Record context changes in STATE.md. Write SUMMARY entry
|
|
821
|
+
documenting what drifted and what was corrected.
|
|
822
|
+
|
|
823
|
+
- id: WF-04
|
|
824
|
+
name: bootstrap
|
|
825
|
+
project_types: [universal]
|
|
826
|
+
description: >
|
|
827
|
+
First session on a new project. Get from zero to working agent
|
|
828
|
+
collaboration as fast as possible.
|
|
829
|
+
steps:
|
|
830
|
+
- name: detect
|
|
831
|
+
stage: initialize
|
|
832
|
+
description: Identify project type and runtime
|
|
833
|
+
features: [TPL-02, TPL-03]
|
|
834
|
+
agent_action: >
|
|
835
|
+
Determine which entry point was loaded. Detect whether this
|
|
836
|
+
is greenfield or brownfield. Choose template tier.
|
|
837
|
+
Infer project type from directory contents.
|
|
838
|
+
- name: initialize
|
|
839
|
+
stage: scope
|
|
840
|
+
description: Set up project context
|
|
841
|
+
features: [TPL-01, CTX-01]
|
|
842
|
+
agent_action: >
|
|
843
|
+
Help user fill in PROJECT.md. Create initial .context/BASE.md.
|
|
844
|
+
For brownfield, scan the project to populate the map.
|
|
845
|
+
- name: map
|
|
846
|
+
stage: execute
|
|
847
|
+
description: Build the project understanding
|
|
848
|
+
features: [CTX-05]
|
|
849
|
+
agent_action: >
|
|
850
|
+
Walk project structure. Record paths, purposes, patterns.
|
|
851
|
+
Map dependencies. This is the foundation for all future sessions.
|
|
852
|
+
- name: pair
|
|
853
|
+
stage: execute
|
|
854
|
+
description: Set up context pairing
|
|
855
|
+
features: [CTX-04]
|
|
856
|
+
agent_action: >
|
|
857
|
+
Identify domain areas. Suggest specialist context files.
|
|
858
|
+
Add scoping rules for each domain to the entry point.
|
|
859
|
+
- name: ready
|
|
860
|
+
stage: close
|
|
861
|
+
description: Confirm setup and orient
|
|
862
|
+
features: [STT-03, TSK-04]
|
|
863
|
+
agent_action: >
|
|
864
|
+
Set STATE.md to initial position. Write first SUMMARY entry.
|
|
865
|
+
The project is now ready for real work.
|
|
866
|
+
|
|
867
|
+
- id: WF-05
|
|
868
|
+
name: data-exploration
|
|
869
|
+
project_types: [data]
|
|
870
|
+
description: >
|
|
871
|
+
When the user submits data and wants to explore it. The agent builds
|
|
872
|
+
structured understanding and provides interactive access. Context IS
|
|
873
|
+
the primary artifact — not a maintenance side effect.
|
|
874
|
+
steps:
|
|
875
|
+
- name: ingest
|
|
876
|
+
stage: scope
|
|
877
|
+
description: First contact with the data — scan structure, classify, measure
|
|
878
|
+
features: [QRY-01, EXP-01, CTX-05]
|
|
879
|
+
agent_action: >
|
|
880
|
+
Scan data sources for structure (columns, types, files, layout).
|
|
881
|
+
Sample content. Measure scale. Detect quality signals.
|
|
882
|
+
Present initial findings to user. Build draft BASE.md data inventory.
|
|
883
|
+
- name: map
|
|
884
|
+
stage: plan
|
|
885
|
+
description: Build the data model — schemas, relationships, taxonomies
|
|
886
|
+
features: [CTX-05, EXP-01, HAI-01]
|
|
887
|
+
agent_action: >
|
|
888
|
+
Build field inventories, identify keys and join paths, map
|
|
889
|
+
derived metrics, note quality issues. For documents: build index,
|
|
890
|
+
identify entities, map cross-references. Present to user for
|
|
891
|
+
correction and approval.
|
|
892
|
+
- name: reference
|
|
893
|
+
stage: execute
|
|
894
|
+
description: Build navigable reference artifacts
|
|
895
|
+
features: [EXP-02, CTX-04, EXP-04]
|
|
896
|
+
agent_action: >
|
|
897
|
+
Transform raw mapping into structured references: entity registries,
|
|
898
|
+
topic taxonomies, dimension indices, metric catalogs. Each entry
|
|
899
|
+
must be addressable, cross-linked, and source-attributed.
|
|
900
|
+
- name: explore
|
|
901
|
+
stage: execute
|
|
902
|
+
description: Interactive querying — user asks, agent routes to data
|
|
903
|
+
features: [EXP-03, EXP-04, CTX-03]
|
|
904
|
+
agent_action: >
|
|
905
|
+
Classify user query against queryable dimensions. Load appropriate
|
|
906
|
+
specialist. Answer from references when possible, access raw data
|
|
907
|
+
only when needed. Propose new dimensions when queries reveal gaps.
|
|
908
|
+
- name: refine
|
|
909
|
+
stage: close
|
|
910
|
+
description: Evolve understanding based on exploration
|
|
911
|
+
features: [EXP-02, STT-01, TSK-04]
|
|
912
|
+
agent_action: >
|
|
913
|
+
Add new queryable dimensions discovered during exploration.
|
|
914
|
+
Update references. Record exploration insights in STATE.md.
|
|
915
|
+
Write SUMMARY entry bridging to next session.
|
|
916
|
+
|
|
917
|
+
- id: WF-06
|
|
918
|
+
name: analytical-system
|
|
919
|
+
project_types: [analytical]
|
|
920
|
+
description: >
|
|
921
|
+
When the user works on prompt composition, evaluation pipelines,
|
|
922
|
+
context analysis, or ML chain orchestration. The agent maps
|
|
923
|
+
analytical components, builds structured understanding, and
|
|
924
|
+
supports iterative refinement of analytical artifacts.
|
|
925
|
+
steps:
|
|
926
|
+
- name: discover
|
|
927
|
+
stage: scope
|
|
928
|
+
description: Identify analytical components, chains, and pipeline stages
|
|
929
|
+
features: [QRY-01, QRY-02, CTX-03]
|
|
930
|
+
agent_action: >
|
|
931
|
+
Load context for the analytical domain. Identify chains
|
|
932
|
+
(input → transformation → output). Map pipeline stages.
|
|
933
|
+
Understand what components exist and how they connect.
|
|
934
|
+
- name: map-chains
|
|
935
|
+
stage: plan
|
|
936
|
+
description: Build the chain model and propose specialist structure
|
|
937
|
+
features: [TSK-01, HAI-01, CTX-05]
|
|
938
|
+
agent_action: >
|
|
939
|
+
Document each chain with its stages, inputs, outputs, and
|
|
940
|
+
evaluation criteria. Propose specialist context files for
|
|
941
|
+
distinct knowledge domains. Present chain model for approval.
|
|
942
|
+
- name: build-context
|
|
943
|
+
stage: execute
|
|
944
|
+
description: Create structured context for analytical components
|
|
945
|
+
features: [CTX-04, CTX-05, STT-01]
|
|
946
|
+
agent_action: >
|
|
947
|
+
Build specialist files for each analytical domain (composition,
|
|
948
|
+
evaluation, execution, domain knowledge). Record architectural
|
|
949
|
+
decisions about chain structure in STATE.md.
|
|
950
|
+
- name: compose
|
|
951
|
+
stage: execute
|
|
952
|
+
description: Build or modify analytical artifacts (prompts, pipelines, evaluations)
|
|
953
|
+
features: [STT-01, QRY-03, HAI-03]
|
|
954
|
+
agent_action: >
|
|
955
|
+
Create or modify the analytical artifacts. Follow cascade rules
|
|
956
|
+
for pipeline changes (upstream change → downstream specs update).
|
|
957
|
+
Maintain dual-audience separation for documentation.
|
|
958
|
+
- name: evaluate
|
|
959
|
+
stage: verify
|
|
960
|
+
description: Check analytical artifacts against evaluation criteria
|
|
961
|
+
features: [TSK-02]
|
|
962
|
+
agent_action: >
|
|
963
|
+
Run evaluation criteria against completed work. For prompts:
|
|
964
|
+
check against scoring rubrics. For pipelines: verify stage
|
|
965
|
+
contracts. Report results with specific evidence.
|
|
966
|
+
- name: refine
|
|
967
|
+
stage: close
|
|
968
|
+
description: Record findings and bridge to next iteration
|
|
969
|
+
features: [TSK-03, TSK-04, STT-03]
|
|
970
|
+
agent_action: >
|
|
971
|
+
Write SUMMARY entry documenting what was built and evaluation
|
|
972
|
+
results. Update STATE.md with refinement direction. The "Next"
|
|
973
|
+
field should identify what to iterate on.
|
|
974
|
+
|
|
975
|
+
- id: WF-07
|
|
976
|
+
name: specification-project
|
|
977
|
+
project_types: [universal]
|
|
978
|
+
description: >
|
|
979
|
+
When the primary output is specifications, standards, or methodology
|
|
980
|
+
documents rather than code or data artifacts. The agent helps
|
|
981
|
+
structure, draft, review, and cross-reference specification content.
|
|
982
|
+
steps:
|
|
983
|
+
- name: research
|
|
984
|
+
stage: scope
|
|
985
|
+
description: Gather prior art, constraints, and requirements
|
|
986
|
+
features: [QRY-01, QRY-02, CTX-03]
|
|
987
|
+
agent_action: >
|
|
988
|
+
Load relevant context. Read existing specs, research docs,
|
|
989
|
+
and requirements. Identify what the spec needs to cover
|
|
990
|
+
and what prior decisions constrain it.
|
|
991
|
+
- name: outline
|
|
992
|
+
stage: plan
|
|
993
|
+
description: Propose spec structure with sections and cross-references
|
|
994
|
+
features: [TSK-01, HAI-01, STT-02]
|
|
995
|
+
agent_action: >
|
|
996
|
+
Draft a spec outline with sections, cross-references to
|
|
997
|
+
existing specs, and verification criteria. Surface any
|
|
998
|
+
open questions about scope or approach. Wait for approval.
|
|
999
|
+
- name: draft
|
|
1000
|
+
stage: execute
|
|
1001
|
+
description: Write spec content with traceability
|
|
1002
|
+
features: [STT-01, QRY-03, CTX-05, HAI-03]
|
|
1003
|
+
agent_action: >
|
|
1004
|
+
Write each spec section. Cross-reference related specs.
|
|
1005
|
+
Record design decisions in STATE.md immediately. Follow
|
|
1006
|
+
cascade rules when spec changes affect other documents.
|
|
1007
|
+
- name: cross-reference
|
|
1008
|
+
stage: execute
|
|
1009
|
+
description: Ensure consistency across related specifications
|
|
1010
|
+
features: [QRY-03, CTX-05]
|
|
1011
|
+
agent_action: >
|
|
1012
|
+
Check that this spec is consistent with all related specs.
|
|
1013
|
+
Update cross-references. Flag contradictions. Update
|
|
1014
|
+
context files if the spec changes the project's understanding.
|
|
1015
|
+
- name: review
|
|
1016
|
+
stage: verify
|
|
1017
|
+
description: Verify spec completeness and consistency
|
|
1018
|
+
features: [TSK-02]
|
|
1019
|
+
agent_action: >
|
|
1020
|
+
Check spec against outline criteria. Verify all sections
|
|
1021
|
+
are substantive. Confirm cross-references are valid.
|
|
1022
|
+
Report coverage gaps.
|
|
1023
|
+
- name: record
|
|
1024
|
+
stage: close
|
|
1025
|
+
description: Update management files and bridge to next spec
|
|
1026
|
+
features: [TSK-03, TSK-04, STT-03]
|
|
1027
|
+
agent_action: >
|
|
1028
|
+
Write SUMMARY entry. Update STATE.md position. If this
|
|
1029
|
+
spec enables other specs, note the dependency in "Next."
|
|
1030
|
+
|
|
1031
|
+
- id: WF-08
|
|
1032
|
+
name: discovery
|
|
1033
|
+
project_types: [universal]
|
|
1034
|
+
description: >
|
|
1035
|
+
When the methodology is applied to an existing project (brownfield) or
|
|
1036
|
+
when a major re-assessment is needed. The agent systematically builds
|
|
1037
|
+
understanding of the project before contributing to it. Discovery must
|
|
1038
|
+
complete before the agent can work effectively.
|
|
1039
|
+
steps:
|
|
1040
|
+
- name: inventory
|
|
1041
|
+
stage: scope
|
|
1042
|
+
description: Walk the project structure and build a complete file/module inventory
|
|
1043
|
+
features: [QRY-01, SCAN-01, CTX-05]
|
|
1044
|
+
agent_action: >
|
|
1045
|
+
Walk the entire project directory. Record every significant path,
|
|
1046
|
+
its purpose, and its key patterns. Build the project map in
|
|
1047
|
+
.context/BASE.md. This is the foundation — skip nothing.
|
|
1048
|
+
- name: map
|
|
1049
|
+
stage: plan
|
|
1050
|
+
description: Map dependencies, connections, and data flows between components
|
|
1051
|
+
features: [SCAN-02, HAI-01]
|
|
1052
|
+
agent_action: >
|
|
1053
|
+
Parse package manifests, trace imports, map service connections.
|
|
1054
|
+
Present the dependency map to the human for validation. Flag
|
|
1055
|
+
any surprising connections or circular dependencies.
|
|
1056
|
+
- name: extract
|
|
1057
|
+
stage: execute
|
|
1058
|
+
description: Identify patterns, conventions, and implicit architectural decisions
|
|
1059
|
+
features: [SCAN-03, STT-01, CTX-04]
|
|
1060
|
+
agent_action: >
|
|
1061
|
+
Sample key files. Identify naming conventions, error handling
|
|
1062
|
+
patterns, test approaches, design patterns. Record discovered
|
|
1063
|
+
architectural decisions in STATE.md. Propose specialist context
|
|
1064
|
+
files for distinct domains.
|
|
1065
|
+
- name: assess
|
|
1066
|
+
stage: verify
|
|
1067
|
+
description: Evaluate technical debt, risks, and improvement opportunities
|
|
1068
|
+
features: [SCAN-04, STT-02]
|
|
1069
|
+
agent_action: >
|
|
1070
|
+
Based on inventory and patterns, identify areas of concern:
|
|
1071
|
+
outdated deps, missing tests, inconsistencies, security issues.
|
|
1072
|
+
Write findings as open questions in STATE.md with severity.
|
|
1073
|
+
Present assessment to human — they decide priorities.
|
|
1074
|
+
- name: bootstrap
|
|
1075
|
+
stage: close
|
|
1076
|
+
description: Finalize context files, update entry point, record discovery session
|
|
1077
|
+
features: [CTX-01, TSK-03, TSK-04, STT-03]
|
|
1078
|
+
agent_action: >
|
|
1079
|
+
Finalize .context/BASE.md with complete project map. Write
|
|
1080
|
+
specialist context files approved during extract step. Update
|
|
1081
|
+
entry point scoping table with project-specific query types.
|
|
1082
|
+
Write SUMMARY entry. Update STATE.md position. Set lifecycle
|
|
1083
|
+
stage to Development (or Design if architecture needs work).
|
|
1084
|
+
|
|
1085
|
+
# ============================================================
|
|
1086
|
+
# LAYER 3: AGENT BEHAVIORAL PROTOCOL
|
|
1087
|
+
# ============================================================
|
|
1088
|
+
|
|
1089
|
+
protocol:
|
|
1090
|
+
purpose: >
|
|
1091
|
+
The agent's job is not just to complete tasks. It is to build and
|
|
1092
|
+
maintain a project intelligence layer that makes every future session
|
|
1093
|
+
more effective than the last. When you change something, you also update
|
|
1094
|
+
the project's understanding of itself. When you make a decision, you
|
|
1095
|
+
record it. When you encounter something new, you build context.
|
|
1096
|
+
|
|
1097
|
+
core_directives:
|
|
1098
|
+
- id: P-01
|
|
1099
|
+
name: Build understanding, not just output
|
|
1100
|
+
project_types: [universal]
|
|
1101
|
+
directive: >
|
|
1102
|
+
Every change is also a context change. When you add a module,
|
|
1103
|
+
update the project map. When you make an architecture decision,
|
|
1104
|
+
record it. When you discover a new domain, propose a specialist.
|
|
1105
|
+
The agent is always building the project's self-knowledge.
|
|
1106
|
+
|
|
1107
|
+
- id: P-02
|
|
1108
|
+
name: Maintain for your future self
|
|
1109
|
+
project_types: [universal]
|
|
1110
|
+
directive: >
|
|
1111
|
+
Every session starts cold. Write decisions, open questions,
|
|
1112
|
+
and context updates as if leaving notes for a colleague who
|
|
1113
|
+
will continue your work but has no memory of this session.
|
|
1114
|
+
|
|
1115
|
+
- id: P-03
|
|
1116
|
+
name: Cascade is not optional
|
|
1117
|
+
project_types: [universal]
|
|
1118
|
+
directive: >
|
|
1119
|
+
File changes ripple through dependencies. Check the cascade table
|
|
1120
|
+
after every change. Do it in the same response. Deferred cascades
|
|
1121
|
+
are skipped cascades.
|
|
1122
|
+
|
|
1123
|
+
- id: P-04
|
|
1124
|
+
name: Scope to avoid drowning
|
|
1125
|
+
project_types: [universal]
|
|
1126
|
+
directive: >
|
|
1127
|
+
Context windows are finite. Follow the scoping table. Load BASE.md
|
|
1128
|
+
+ one specialist. If you need more, split the query.
|
|
1129
|
+
|
|
1130
|
+
- id: P-05
|
|
1131
|
+
name: Surface uncertainty, don't hide it
|
|
1132
|
+
project_types: [universal]
|
|
1133
|
+
directive: >
|
|
1134
|
+
Silent assumptions are the primary failure mode. When unsure,
|
|
1135
|
+
write an open question. When ambiguous, ask.
|
|
1136
|
+
|
|
1137
|
+
- id: P-06
|
|
1138
|
+
name: The human controls direction
|
|
1139
|
+
project_types: [universal]
|
|
1140
|
+
directive: >
|
|
1141
|
+
The agent proposes; the human decides. The plan checkpoint exists
|
|
1142
|
+
because the human's judgment about WHAT to build is more reliable
|
|
1143
|
+
than the agent's.
|
|
1144
|
+
|
|
1145
|
+
- id: P-07
|
|
1146
|
+
name: Keep files loadable
|
|
1147
|
+
project_types: [universal]
|
|
1148
|
+
directive: >
|
|
1149
|
+
Context that doesn't fit in the window can't help. Intelligence
|
|
1150
|
+
layer files that grow beyond 300 lines consume disproportionate
|
|
1151
|
+
tokens. When a file exceeds this threshold, restructure it into
|
|
1152
|
+
an index (active content + navigation) and component files
|
|
1153
|
+
(archived sections). The index stays small; components are loaded
|
|
1154
|
+
only when their specific content is needed.
|
|
1155
|
+
|
|
1156
|
+
- id: P-08
|
|
1157
|
+
name: Methodology is additive only
|
|
1158
|
+
project_types: [universal]
|
|
1159
|
+
directive: >
|
|
1160
|
+
The methodology NEVER modifies project source code, tests, or
|
|
1161
|
+
pre-existing documentation. It only creates and modifies its own
|
|
1162
|
+
files (STATE.md, .context/, PLAN.md, SUMMARY.md, etc.). In
|
|
1163
|
+
brownfield projects, existing files are NEVER deleted or
|
|
1164
|
+
overwritten — methodology content is appended to existing entry
|
|
1165
|
+
points and new files are created alongside existing ones.
|
|
1166
|
+
|
|
1167
|
+
- id: P-09
|
|
1168
|
+
name: Surface capability limitations
|
|
1169
|
+
project_types: [universal]
|
|
1170
|
+
directive: >
|
|
1171
|
+
Monitor your own methodology adherence during a session. If you
|
|
1172
|
+
notice repeated cascade misses, forgotten STATE.md updates,
|
|
1173
|
+
shallow context, or lost conventions, surface this to the user
|
|
1174
|
+
rather than silently degrading. Record the observation as an
|
|
1175
|
+
open question in STATE.md. Suggest switching to a more capable
|
|
1176
|
+
model or a lighter integration profile. Two rules followed
|
|
1177
|
+
consistently beat ten rules followed inconsistently.
|
|
1178
|
+
|
|
1179
|
+
workflow_selection: >
|
|
1180
|
+
When a query arrives, the agent selects the appropriate guided workflow:
|
|
1181
|
+
- First session / template just copied → WF-04 (bootstrap)
|
|
1182
|
+
- Brownfield project, first application of methodology → WF-08 (discovery)
|
|
1183
|
+
- Code modification request → WF-02 (code-change)
|
|
1184
|
+
- Data submitted or data question → WF-05 (data-exploration)
|
|
1185
|
+
- "Refresh context" or detected drift → WF-03 (context-refresh)
|
|
1186
|
+
- General task request → WF-01 (standard-task)
|
|
1187
|
+
- Analytical/prompt system task → WF-06 (analytical-system)
|
|
1188
|
+
- Spec writing or methodology design → WF-07 (specification-project)
|
|
1189
|
+
If no workflow matches, follow WF-01 as the default pattern.
|
|
1190
|
+
Project type is inferred from the entry point's scoping table content.
|
|
1191
|
+
Lifecycle stage (from PROJECT-PROFILE.md) further adjusts feature priorities —
|
|
1192
|
+
see docs/architecture/project-lifecycle.md for the activation table.
|
|
1193
|
+
|
|
1194
|
+
# ============================================================
|
|
1195
|
+
# LAYER 4: ROUTING RULES
|
|
1196
|
+
# Computable query classification and feature activation
|
|
1197
|
+
# ============================================================
|
|
1198
|
+
|
|
1199
|
+
query_patterns:
|
|
1200
|
+
# --- Universal patterns ---
|
|
1201
|
+
- query_type: planning
|
|
1202
|
+
match_rules:
|
|
1203
|
+
keywords: [plan, roadmap, phase, requirements, scope, prioritize]
|
|
1204
|
+
phrases: ["what should we", "next phase", "plan for"]
|
|
1205
|
+
workflow: WF-01
|
|
1206
|
+
project_types: [universal]
|
|
1207
|
+
|
|
1208
|
+
- query_type: context_refresh
|
|
1209
|
+
match_rules:
|
|
1210
|
+
keywords: [refresh, resync, update context, drift, stale]
|
|
1211
|
+
phrases: ["refresh context", "update .context", "resync"]
|
|
1212
|
+
workflow: WF-03
|
|
1213
|
+
project_types: [universal]
|
|
1214
|
+
|
|
1215
|
+
- query_type: phase_completion
|
|
1216
|
+
match_rules:
|
|
1217
|
+
keywords: [complete, finish, close, done, gate]
|
|
1218
|
+
phrases: ["phase complete", "mark done", "close session"]
|
|
1219
|
+
workflow: WF-01
|
|
1220
|
+
project_types: [universal]
|
|
1221
|
+
|
|
1222
|
+
- query_type: backlog
|
|
1223
|
+
match_rules:
|
|
1224
|
+
keywords: [backlog, idea, future, todo, later]
|
|
1225
|
+
phrases: ["add to backlog", "future work"]
|
|
1226
|
+
workflow: WF-01
|
|
1227
|
+
project_types: [universal]
|
|
1228
|
+
|
|
1229
|
+
# --- Code project patterns ---
|
|
1230
|
+
- query_type: code_change
|
|
1231
|
+
match_rules:
|
|
1232
|
+
keywords: [implement, code, build, fix, refactor, add feature, modify]
|
|
1233
|
+
phrases: ["add a", "change the", "fix the", "refactor", "implement"]
|
|
1234
|
+
workflow: WF-02
|
|
1235
|
+
project_types: [code]
|
|
1236
|
+
|
|
1237
|
+
- query_type: bug_fix
|
|
1238
|
+
match_rules:
|
|
1239
|
+
keywords: [bug, error, broken, failing, debug]
|
|
1240
|
+
phrases: ["fix the bug", "why is this", "not working"]
|
|
1241
|
+
workflow: WF-02
|
|
1242
|
+
project_types: [code]
|
|
1243
|
+
|
|
1244
|
+
- query_type: dependency_update
|
|
1245
|
+
match_rules:
|
|
1246
|
+
keywords: [dependency, package, upgrade, install, npm, pip]
|
|
1247
|
+
phrases: ["update package", "add dependency"]
|
|
1248
|
+
workflow: WF-02
|
|
1249
|
+
project_types: [code]
|
|
1250
|
+
|
|
1251
|
+
- query_type: database_work
|
|
1252
|
+
match_rules:
|
|
1253
|
+
keywords: [database, schema, migration, model, table, query, sql]
|
|
1254
|
+
phrases: ["add a table", "update schema", "run migration"]
|
|
1255
|
+
workflow: WF-02
|
|
1256
|
+
project_types: [code]
|
|
1257
|
+
|
|
1258
|
+
- query_type: api_work
|
|
1259
|
+
match_rules:
|
|
1260
|
+
keywords: [api, endpoint, route, controller, rest, graphql]
|
|
1261
|
+
phrases: ["add endpoint", "api route", "rest endpoint"]
|
|
1262
|
+
workflow: WF-02
|
|
1263
|
+
project_types: [code]
|
|
1264
|
+
|
|
1265
|
+
- query_type: deployment_work
|
|
1266
|
+
match_rules:
|
|
1267
|
+
keywords: [deploy, infrastructure, pipeline, ci, cd, environment, staging, production, devops]
|
|
1268
|
+
phrases: ["deploy to", "set up pipeline", "configure environment", "infrastructure change"]
|
|
1269
|
+
workflow: WF-02
|
|
1270
|
+
project_types: [code]
|
|
1271
|
+
|
|
1272
|
+
# --- Data exploration patterns ---
|
|
1273
|
+
- query_type: data_ingest
|
|
1274
|
+
match_rules:
|
|
1275
|
+
keywords: [ingest, import, load, submit, upload, dataset, csv]
|
|
1276
|
+
phrases: ["here is the data", "load this", "analyze this dataset"]
|
|
1277
|
+
workflow: WF-05
|
|
1278
|
+
project_types: [data]
|
|
1279
|
+
|
|
1280
|
+
- query_type: schema_query
|
|
1281
|
+
match_rules:
|
|
1282
|
+
keywords: [schema, columns, fields, types, structure, table]
|
|
1283
|
+
phrases: ["what columns", "show schema", "field types"]
|
|
1284
|
+
workflow: WF-05
|
|
1285
|
+
project_types: [data]
|
|
1286
|
+
|
|
1287
|
+
- query_type: explore_entity
|
|
1288
|
+
match_rules:
|
|
1289
|
+
keywords: [explore, entity, about, details, info]
|
|
1290
|
+
phrases: ["explore", "tell me about", "what do we know about"]
|
|
1291
|
+
workflow: WF-05
|
|
1292
|
+
project_types: [data]
|
|
1293
|
+
|
|
1294
|
+
- query_type: relationship_query
|
|
1295
|
+
match_rules:
|
|
1296
|
+
keywords: [relate, relationship, connect, join, link, between]
|
|
1297
|
+
phrases: ["how does X relate to", "connection between"]
|
|
1298
|
+
workflow: WF-05
|
|
1299
|
+
project_types: [data]
|
|
1300
|
+
|
|
1301
|
+
- query_type: quality_check
|
|
1302
|
+
match_rules:
|
|
1303
|
+
keywords: [quality, null, missing, duplicate, integrity]
|
|
1304
|
+
phrases: ["data quality", "check quality", "missing values"]
|
|
1305
|
+
workflow: WF-05
|
|
1306
|
+
project_types: [data]
|
|
1307
|
+
|
|
1308
|
+
- query_type: analytical_query
|
|
1309
|
+
match_rules:
|
|
1310
|
+
keywords: [trend, compare, analyze, distribution, aggregate, count]
|
|
1311
|
+
phrases: ["show me trends", "compare", "how many"]
|
|
1312
|
+
workflow: WF-05
|
|
1313
|
+
project_types: [data]
|
|
1314
|
+
|
|
1315
|
+
- query_type: document_search
|
|
1316
|
+
match_rules:
|
|
1317
|
+
keywords: [document, search, find, topic, reference, policy]
|
|
1318
|
+
phrases: ["search for", "find documents about", "what does the policy say"]
|
|
1319
|
+
workflow: WF-05
|
|
1320
|
+
project_types: [data]
|
|
1321
|
+
|
|
1322
|
+
- query_type: dimension_management
|
|
1323
|
+
match_rules:
|
|
1324
|
+
keywords: [dimension, add dimension, queryable, aspect]
|
|
1325
|
+
phrases: ["add dimension", "new queryable aspect", "list dimensions"]
|
|
1326
|
+
workflow: WF-05
|
|
1327
|
+
project_types: [data]
|
|
1328
|
+
|
|
1329
|
+
- query_type: add_reference
|
|
1330
|
+
match_rules:
|
|
1331
|
+
keywords: [reference, add reference, build reference, catalog, registry entry]
|
|
1332
|
+
phrases: ["add a reference", "build reference for", "new reference entry"]
|
|
1333
|
+
workflow: WF-05
|
|
1334
|
+
project_types: [data]
|
|
1335
|
+
|
|
1336
|
+
# --- Analytical system patterns ---
|
|
1337
|
+
- query_type: chain_work
|
|
1338
|
+
match_rules:
|
|
1339
|
+
keywords: [chain, pipeline, prompt, composition, orchestration, stage]
|
|
1340
|
+
phrases: ["build a chain", "compose prompts", "pipeline stage", "chain architecture"]
|
|
1341
|
+
workflow: WF-06
|
|
1342
|
+
project_types: [analytical]
|
|
1343
|
+
|
|
1344
|
+
- query_type: evaluation
|
|
1345
|
+
match_rules:
|
|
1346
|
+
keywords: [evaluate, score, rubric, criteria, benchmark, test prompt]
|
|
1347
|
+
phrases: ["evaluate this", "scoring rubric", "how well does", "benchmark against"]
|
|
1348
|
+
workflow: WF-06
|
|
1349
|
+
project_types: [analytical]
|
|
1350
|
+
|
|
1351
|
+
- query_type: composition
|
|
1352
|
+
match_rules:
|
|
1353
|
+
keywords: [compose, template, prompt template, context window, token]
|
|
1354
|
+
phrases: ["compose a prompt", "prompt template", "context strategy"]
|
|
1355
|
+
workflow: WF-06
|
|
1356
|
+
project_types: [analytical]
|
|
1357
|
+
|
|
1358
|
+
- query_type: domain_research
|
|
1359
|
+
match_rules:
|
|
1360
|
+
keywords: [research, domain, pattern, best practice, prior art]
|
|
1361
|
+
phrases: ["research patterns", "domain knowledge", "what works for"]
|
|
1362
|
+
workflow: WF-06
|
|
1363
|
+
project_types: [analytical]
|
|
1364
|
+
|
|
1365
|
+
# --- Discovery / brownfield patterns ---
|
|
1366
|
+
- query_type: project_discovery
|
|
1367
|
+
match_rules:
|
|
1368
|
+
keywords: [discover, inventory, map project, assess, scan codebase, understand, brownfield]
|
|
1369
|
+
phrases: ["what does this project do", "scan the codebase", "map the project", "understand the architecture"]
|
|
1370
|
+
workflow: WF-08
|
|
1371
|
+
project_types: [universal]
|
|
1372
|
+
|
|
1373
|
+
- query_type: dependency_analysis
|
|
1374
|
+
match_rules:
|
|
1375
|
+
keywords: [dependencies, imports, connections, coupling, what uses, used by]
|
|
1376
|
+
phrases: ["map dependencies", "what depends on", "trace imports", "dependency graph"]
|
|
1377
|
+
workflow: WF-08
|
|
1378
|
+
project_types: [universal]
|
|
1379
|
+
|
|
1380
|
+
- query_type: pattern_analysis
|
|
1381
|
+
match_rules:
|
|
1382
|
+
keywords: [patterns, conventions, architecture, how is this built, coding style]
|
|
1383
|
+
phrases: ["what patterns", "coding conventions", "architectural decisions", "how does this work"]
|
|
1384
|
+
workflow: WF-08
|
|
1385
|
+
project_types: [universal]
|
|
1386
|
+
|
|
1387
|
+
- query_type: debt_assessment
|
|
1388
|
+
match_rules:
|
|
1389
|
+
keywords: [debt, technical debt, outdated, risks, security audit, code quality]
|
|
1390
|
+
phrases: ["assess technical debt", "what needs fixing", "code quality", "security review"]
|
|
1391
|
+
workflow: WF-08
|
|
1392
|
+
project_types: [universal]
|
|
1393
|
+
|
|
1394
|
+
# --- Specification project patterns ---
|
|
1395
|
+
- query_type: spec_writing
|
|
1396
|
+
match_rules:
|
|
1397
|
+
keywords: [spec, specification, standard, define, formalize, document]
|
|
1398
|
+
phrases: ["write a spec", "define the standard", "formalize this", "specification for"]
|
|
1399
|
+
workflow: WF-07
|
|
1400
|
+
project_types: [universal]
|
|
1401
|
+
|
|
1402
|
+
- query_type: cross_reference
|
|
1403
|
+
match_rules:
|
|
1404
|
+
keywords: [cross-reference, consistency, align, reconcile, trace]
|
|
1405
|
+
phrases: ["cross-reference with", "check consistency", "align specs"]
|
|
1406
|
+
workflow: WF-07
|
|
1407
|
+
project_types: [universal]
|
|
1408
|
+
|
|
1409
|
+
routing:
|
|
1410
|
+
algorithm: >
|
|
1411
|
+
1. CLASSIFY: Match query against entry point scoping table first (project-specific).
|
|
1412
|
+
If no match, check query_patterns (registry-level). Default: general_task → WF-01.
|
|
1413
|
+
2. SELECT: Use workflow field from matched pattern. Check for bootstrap override
|
|
1414
|
+
(first session → WF-04).
|
|
1415
|
+
3. RESOLVE: Get workflow steps. For current stage, collect features from step + activation map.
|
|
1416
|
+
4. COMPUTE: Aggregate reads/writes from scoping table row + resolved features.
|
|
1417
|
+
5. EXECUTE: Agent loads read set, performs work, writes to write set.
|
|
1418
|
+
6. CASCADE: For each written file, walk cascade table + registry dependencies (max 2 levels).
|
|
1419
|
+
|
|
1420
|
+
project_type_detection: >
|
|
1421
|
+
Infer from entry point scoping table content and PROJECT-PROFILE.md:
|
|
1422
|
+
- Has PROJECT-PROFILE.md → read project types and lifecycle stage directly
|
|
1423
|
+
- Has "code change", "bug fix", "API work" rows → code project
|
|
1424
|
+
- Has "schema query", "explore", "data ingest" rows → data project
|
|
1425
|
+
- Has "chain work", "evaluation", "composition" rows → analytical project
|
|
1426
|
+
- Has "spec writing", "cross-reference" rows → specification project (uses WF-07)
|
|
1427
|
+
- Has "project discovery", "dependency analysis" rows → discovery active (uses WF-08)
|
|
1428
|
+
- Has rows from multiple types → mixed project (multiple workflows available)
|
|
1429
|
+
- Has neither → general project (WF-01 only)
|
|
1430
|
+
Lifecycle stage (from PROJECT-PROFILE.md) adjusts feature activation priorities
|
|
1431
|
+
but does not change project type detection.
|
|
1432
|
+
|
|
1433
|
+
priority_rules:
|
|
1434
|
+
- Scoping table (project-specific) takes priority over registry patterns
|
|
1435
|
+
- Entry point cascade table takes priority over registry dependencies
|
|
1436
|
+
- One specialist per query (never load multiple)
|
|
1437
|
+
- Write sets are constraints (agent should not write outside them)
|
|
1438
|
+
- Max cascade depth is 2 levels
|
|
1439
|
+
- Ambiguous classification → ask user (STT-02)
|
|
1440
|
+
|
|
1441
|
+
# ============================================================
|
|
1442
|
+
# ACTIVATION AND DEPENDENCY MAPS
|
|
1443
|
+
# ============================================================
|
|
1444
|
+
|
|
1445
|
+
activation:
|
|
1446
|
+
initialize: [QRY-01, HAI-02, TPL-02]
|
|
1447
|
+
scope: [QRY-02, CTX-03]
|
|
1448
|
+
plan: [TSK-01, HAI-01, STT-02]
|
|
1449
|
+
execute: [STT-01, QRY-03, CTX-04, CTX-05, CTX-06, HAI-03, HAI-05, EXP-02, EXP-03, EXP-04, SCAN-03]
|
|
1450
|
+
verify: [TSK-02, SCAN-04]
|
|
1451
|
+
close: [TSK-03, TSK-04, STT-03, HAI-04]
|
|
1452
|
+
on_demand: [CTX-01, CTX-02, TPL-01, TPL-03, EXP-01, SCAN-01, SCAN-02]
|
|
1453
|
+
|
|
1454
|
+
dependencies:
|
|
1455
|
+
TPL-01: [CTX-01, TPL-02]
|
|
1456
|
+
CTX-01: [CTX-05]
|
|
1457
|
+
QRY-01: [QRY-02]
|
|
1458
|
+
QRY-02: [CTX-03]
|
|
1459
|
+
TSK-01: [HAI-01]
|
|
1460
|
+
HAI-02: [HAI-01]
|
|
1461
|
+
TSK-03: [TSK-04, QRY-03]
|
|
1462
|
+
STT-03: [TSK-03]
|
|
1463
|
+
HAI-03: [HAI-04]
|
|
1464
|
+
CTX-02: [CTX-05]
|
|
1465
|
+
CTX-06: [QRY-03]
|
|
1466
|
+
EXP-01: [CTX-05]
|
|
1467
|
+
EXP-02: [EXP-01, CTX-05]
|
|
1468
|
+
EXP-03: [QRY-02, CTX-03]
|
|
1469
|
+
EXP-04: [EXP-03]
|
|
1470
|
+
SCAN-01: [CTX-05]
|
|
1471
|
+
SCAN-02: [SCAN-01]
|
|
1472
|
+
SCAN-03: [SCAN-01]
|
|
1473
|
+
SCAN-04: [SCAN-01, SCAN-03]
|
|
1474
|
+
|
|
1475
|
+
versions:
|
|
1476
|
+
v1:
|
|
1477
|
+
features: 22
|
|
1478
|
+
workflows: 4
|
|
1479
|
+
protocol_directives: 6
|
|
1480
|
+
notes: Core methodology. File-driven, single-agent. Workflows compose features into task patterns.
|
|
1481
|
+
v1.1:
|
|
1482
|
+
features: 26
|
|
1483
|
+
workflows: 5
|
|
1484
|
+
protocol_directives: 6
|
|
1485
|
+
query_patterns: 19
|
|
1486
|
+
notes: >
|
|
1487
|
+
Adds EXP domain (4 features), WF-05 (data-exploration), project-type annotations,
|
|
1488
|
+
query patterns for automated routing, Layer 4 routing rules. CTX-05 generalized
|
|
1489
|
+
to mapProject. Backwards-compatible with v1.
|
|
1490
|
+
v1.2:
|
|
1491
|
+
features: 27
|
|
1492
|
+
workflows: 5
|
|
1493
|
+
protocol_directives: 7
|
|
1494
|
+
query_patterns: 19
|
|
1495
|
+
notes: >
|
|
1496
|
+
Adds CTX-06 manageScale (file size monitoring + index restructuring) and P-07
|
|
1497
|
+
Keep files loadable (context window efficiency). Backwards-compatible with v1.1.
|
|
1498
|
+
v1.3:
|
|
1499
|
+
features: 27
|
|
1500
|
+
workflows: 7
|
|
1501
|
+
protocol_directives: 7
|
|
1502
|
+
query_patterns: 25
|
|
1503
|
+
notes: >
|
|
1504
|
+
Adds WF-06 analytical-system, WF-07 specification-project. 6 new query patterns
|
|
1505
|
+
for analytical and specification work. Backwards-compatible with v1.2.
|
|
1506
|
+
v1.4:
|
|
1507
|
+
features: 31
|
|
1508
|
+
workflows: 8
|
|
1509
|
+
protocol_directives: 7
|
|
1510
|
+
query_patterns: 29
|
|
1511
|
+
notes: >
|
|
1512
|
+
Adds SCAN domain (4 features: SCAN-01 codebaseInventory, SCAN-02 dependencyMapping,
|
|
1513
|
+
SCAN-03 patternExtraction, SCAN-04 debtAssessment). Adds WF-08 discovery workflow
|
|
1514
|
+
for brownfield project entry. 4 new query patterns for discovery. Adds lifecycle
|
|
1515
|
+
stage awareness to routing. PROJECT-PROFILE.md as new intelligence layer file.
|
|
1516
|
+
Backwards-compatible with v1.3.
|
|
1517
|
+
v1.5:
|
|
1518
|
+
features: 32
|
|
1519
|
+
workflows: 8
|
|
1520
|
+
protocol_directives: 9
|
|
1521
|
+
query_patterns: 29
|
|
1522
|
+
notes: >
|
|
1523
|
+
Adds HAI-05 modelCapabilityCheck (degradation detection + user surfacing).
|
|
1524
|
+
Adds P-08 Methodology is additive only (safety invariant for brownfield).
|
|
1525
|
+
Adds P-09 Surface capability limitations (self-monitoring directive).
|
|
1526
|
+
Integration profiles (lite/standard/full) for controlling methodology surface area.
|
|
1527
|
+
.context/METHODOLOGY.md as overflow target for lighter profiles.
|
|
1528
|
+
Brownfield merge protocol (append-only, never delete). Model tier entry point setting.
|
|
1529
|
+
Backwards-compatible with v1.4.
|
|
1530
|
+
v2:
|
|
1531
|
+
adds: [multi-agent orchestration, automated gate verification, template generator CLI]
|
|
1532
|
+
notes: Extends v1.4. Backwards-compatible. New workflows for multi-agent patterns.
|