@interf/compiler 0.1.8
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/LICENSE +183 -0
- package/README.md +1008 -0
- package/TRADEMARKS.md +19 -0
- package/dist/bin.d.ts +3 -0
- package/dist/bin.d.ts.map +1 -0
- package/dist/bin.js +30 -0
- package/dist/bin.js.map +1 -0
- package/dist/commands/benchmark.d.ts +3 -0
- package/dist/commands/benchmark.d.ts.map +1 -0
- package/dist/commands/benchmark.js +400 -0
- package/dist/commands/benchmark.js.map +1 -0
- package/dist/commands/compile.d.ts +3 -0
- package/dist/commands/compile.d.ts.map +1 -0
- package/dist/commands/compile.js +139 -0
- package/dist/commands/compile.js.map +1 -0
- package/dist/commands/create.d.ts +49 -0
- package/dist/commands/create.d.ts.map +1 -0
- package/dist/commands/create.js +813 -0
- package/dist/commands/create.js.map +1 -0
- package/dist/commands/default.d.ts +3 -0
- package/dist/commands/default.d.ts.map +1 -0
- package/dist/commands/default.js +52 -0
- package/dist/commands/default.js.map +1 -0
- package/dist/commands/doctor.d.ts +3 -0
- package/dist/commands/doctor.d.ts.map +1 -0
- package/dist/commands/doctor.js +146 -0
- package/dist/commands/doctor.js.map +1 -0
- package/dist/commands/init.d.ts +3 -0
- package/dist/commands/init.d.ts.map +1 -0
- package/dist/commands/init.js +235 -0
- package/dist/commands/init.js.map +1 -0
- package/dist/commands/list.d.ts +3 -0
- package/dist/commands/list.d.ts.map +1 -0
- package/dist/commands/list.js +32 -0
- package/dist/commands/list.js.map +1 -0
- package/dist/commands/reset.d.ts +3 -0
- package/dist/commands/reset.d.ts.map +1 -0
- package/dist/commands/reset.js +136 -0
- package/dist/commands/reset.js.map +1 -0
- package/dist/commands/status.d.ts +3 -0
- package/dist/commands/status.d.ts.map +1 -0
- package/dist/commands/status.js +67 -0
- package/dist/commands/status.js.map +1 -0
- package/dist/commands/verify.d.ts +3 -0
- package/dist/commands/verify.d.ts.map +1 -0
- package/dist/commands/verify.js +112 -0
- package/dist/commands/verify.js.map +1 -0
- package/dist/index.d.ts +30 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +18 -0
- package/dist/index.js.map +1 -0
- package/dist/lib/agents.d.ts +59 -0
- package/dist/lib/agents.d.ts.map +1 -0
- package/dist/lib/agents.js +760 -0
- package/dist/lib/agents.js.map +1 -0
- package/dist/lib/benchmark.d.ts +30 -0
- package/dist/lib/benchmark.d.ts.map +1 -0
- package/dist/lib/benchmark.js +325 -0
- package/dist/lib/benchmark.js.map +1 -0
- package/dist/lib/config.d.ts +6 -0
- package/dist/lib/config.d.ts.map +1 -0
- package/dist/lib/config.js +15 -0
- package/dist/lib/config.js.map +1 -0
- package/dist/lib/discovery.d.ts +8 -0
- package/dist/lib/discovery.d.ts.map +1 -0
- package/dist/lib/discovery.js +80 -0
- package/dist/lib/discovery.js.map +1 -0
- package/dist/lib/executors.d.ts +33 -0
- package/dist/lib/executors.d.ts.map +1 -0
- package/dist/lib/executors.js +44 -0
- package/dist/lib/executors.js.map +1 -0
- package/dist/lib/filesystem.d.ts +4 -0
- package/dist/lib/filesystem.d.ts.map +1 -0
- package/dist/lib/filesystem.js +61 -0
- package/dist/lib/filesystem.js.map +1 -0
- package/dist/lib/interf.d.ts +37 -0
- package/dist/lib/interf.d.ts.map +1 -0
- package/dist/lib/interf.js +1104 -0
- package/dist/lib/interf.js.map +1 -0
- package/dist/lib/local-workflows.d.ts +35 -0
- package/dist/lib/local-workflows.d.ts.map +1 -0
- package/dist/lib/local-workflows.js +149 -0
- package/dist/lib/local-workflows.js.map +1 -0
- package/dist/lib/parse.d.ts +9 -0
- package/dist/lib/parse.d.ts.map +1 -0
- package/dist/lib/parse.js +51 -0
- package/dist/lib/parse.js.map +1 -0
- package/dist/lib/registry.d.ts +28 -0
- package/dist/lib/registry.d.ts.map +1 -0
- package/dist/lib/registry.js +80 -0
- package/dist/lib/registry.js.map +1 -0
- package/dist/lib/runtime.d.ts +59 -0
- package/dist/lib/runtime.d.ts.map +1 -0
- package/dist/lib/runtime.js +615 -0
- package/dist/lib/runtime.js.map +1 -0
- package/dist/lib/schema.d.ts +705 -0
- package/dist/lib/schema.d.ts.map +1 -0
- package/dist/lib/schema.js +443 -0
- package/dist/lib/schema.js.map +1 -0
- package/dist/lib/state.d.ts +49 -0
- package/dist/lib/state.d.ts.map +1 -0
- package/dist/lib/state.js +633 -0
- package/dist/lib/state.js.map +1 -0
- package/dist/lib/summarize-plan.d.ts +16 -0
- package/dist/lib/summarize-plan.d.ts.map +1 -0
- package/dist/lib/summarize-plan.js +112 -0
- package/dist/lib/summarize-plan.js.map +1 -0
- package/dist/lib/user-config.d.ts +6 -0
- package/dist/lib/user-config.d.ts.map +1 -0
- package/dist/lib/user-config.js +16 -0
- package/dist/lib/user-config.js.map +1 -0
- package/dist/lib/validate.d.ts +149 -0
- package/dist/lib/validate.d.ts.map +1 -0
- package/dist/lib/validate.js +838 -0
- package/dist/lib/validate.js.map +1 -0
- package/dist/lib/workflow-definitions.d.ts +79 -0
- package/dist/lib/workflow-definitions.d.ts.map +1 -0
- package/dist/lib/workflow-definitions.js +565 -0
- package/dist/lib/workflow-definitions.js.map +1 -0
- package/dist/lib/workflows.d.ts +125 -0
- package/dist/lib/workflows.d.ts.map +1 -0
- package/dist/lib/workflows.js +1107 -0
- package/dist/lib/workflows.js.map +1 -0
- package/package.json +73 -0
- package/skills/benchmark/SKILL.md +129 -0
- package/skills/interface/analyze/SKILL.md +140 -0
- package/skills/interface/compile/SKILL.md +153 -0
- package/skills/interface/compile/references/output-format.md +48 -0
- package/skills/interface/create/SKILL.md +264 -0
- package/skills/interface/create/references/compile-plan-format.md +109 -0
- package/skills/interface/create/references/workflows.md +50 -0
- package/skills/interface/query/SKILL.md +34 -0
- package/skills/interface/retrieve/SKILL.md +166 -0
- package/skills/knowledge-base/compile/SKILL.md +220 -0
- package/skills/knowledge-base/compile/references/output-format.md +48 -0
- package/skills/knowledge-base/compile/references/stage-claims.md +60 -0
- package/skills/knowledge-base/compile/references/stage-entities.md +46 -0
- package/skills/knowledge-base/query/SKILL.md +33 -0
- package/skills/knowledge-base/summarize/SKILL.md +122 -0
- package/skills/workflow/create/SKILL.md +126 -0
- package/templates/interface/README.md +158 -0
- package/templates/interface/interfaces.md +99 -0
- package/templates/knowledge-base/README.md +138 -0
- package/templates/knowledge-base/interfignore +19 -0
- package/templates/knowledge-base/registry.md +118 -0
|
@@ -0,0 +1,264 @@
|
|
|
1
|
+
---
|
|
2
|
+
{
|
|
3
|
+
"name": "interface/create",
|
|
4
|
+
"description": "Create a new Interf interface. Analyzes a knowledge base to generate an interf.json config and execution plan (compile-plan.md). Use when asked to create an interface, new interface, build a view, or set up a briefing, research, or audit interface."
|
|
5
|
+
}
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Create Interface
|
|
9
|
+
|
|
10
|
+
Creates a new interface connected to an existing knowledge base. The LLM analyzes the knowledge base to draft the initial runtime hypothesis for the use case: ontology, taxonomy, retrieval strategy, and output shape.
|
|
11
|
+
|
|
12
|
+
Local runtime reference:
|
|
13
|
+
- active stage contract: `.interf/stage-contract.json`
|
|
14
|
+
- active run ledger: `.interf/run.json`
|
|
15
|
+
- local config: `interf.json`
|
|
16
|
+
- local plan target: `compile-plan.md`
|
|
17
|
+
- local instruction docs: the files listed by `.interf/stage-contract.json`
|
|
18
|
+
|
|
19
|
+
When this skill is embedded into a generated interface, do not try to open SDK repo docs or source files outside the current workspace. The local contract and local docs are the source of truth for this run.
|
|
20
|
+
|
|
21
|
+
Harness role:
|
|
22
|
+
- This skill is an internal harness step normally invoked by `interf create interface`.
|
|
23
|
+
- For standard operation, prefer the CLI or another higher-level tool over calling this skill directly.
|
|
24
|
+
|
|
25
|
+
If `.interf/stage-contract.json` exists, treat it as the authoritative stage contract for this run. It defines the interface use case, knowledge-base connection, and which files the harness expects this step to update.
|
|
26
|
+
|
|
27
|
+
## Wizard checklist
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
Create interface:
|
|
31
|
+
- [ ] 1. Select knowledge base
|
|
32
|
+
- [ ] 2. Define use case
|
|
33
|
+
- [ ] 3. Analyze knowledge base
|
|
34
|
+
- [ ] 4. Update interf.json
|
|
35
|
+
- [ ] 5. Generate compile-plan.md
|
|
36
|
+
- [ ] 6. Update interface structure
|
|
37
|
+
- [ ] 7. Register
|
|
38
|
+
- [ ] 8. Show next steps
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### 1. Select knowledge base
|
|
42
|
+
|
|
43
|
+
Ask: which knowledge base should this interface read from?
|
|
44
|
+
|
|
45
|
+
Read `~/.interf/registry.json` for available knowledge bases. If only one knowledge base exists, confirm it.
|
|
46
|
+
|
|
47
|
+
### 2. Define use case
|
|
48
|
+
|
|
49
|
+
If the caller already provided `Selected workflow: ...`, treat that as the chosen workflow and do not re-decide it.
|
|
50
|
+
|
|
51
|
+
If a known workflow exists: use it as the starting point and adapt it to the actual knowledge base.
|
|
52
|
+
If no known workflow fits: ask the user:
|
|
53
|
+
- What questions should this interface answer?
|
|
54
|
+
- What's the use case? (briefing, research, audit, etc.)
|
|
55
|
+
|
|
56
|
+
### 3. Analyze knowledge base
|
|
57
|
+
|
|
58
|
+
Read the knowledge base's `summaries/` frontmatter and high-level `knowledge/` layer to understand available data:
|
|
59
|
+
- Category distribution
|
|
60
|
+
- People mentioned
|
|
61
|
+
- Date range
|
|
62
|
+
- Evidence-tier / truth-mode distribution
|
|
63
|
+
- Entity and claim coverage in knowledge/
|
|
64
|
+
|
|
65
|
+
The knowledge base is at `knowledge_base.path` from `interf.json` (typically `../..`). Knowledge-base summaries are at `{knowledge_base.path}/summaries/`.
|
|
66
|
+
If a coding agent is sandboxed to its current working tree, prefer launching it from the source folder or another root that can reach both the knowledge base and the source folder.
|
|
67
|
+
If `../../.interf/source-access.json` exists, use it as the quick check for whether raw paths are actually reachable from this session before assuming raw fallback will work.
|
|
68
|
+
|
|
69
|
+
This analysis informs the config and compile plan.
|
|
70
|
+
|
|
71
|
+
### 4. Update interf.json
|
|
72
|
+
|
|
73
|
+
`interf.json` is minimal. It stores only `type`, `name`, `workflow`, and the knowledge-base path (`knowledge_base.path`). No filter criteria, no output specs, no validation rules — all of that belongs in `compile-plan.md`.
|
|
74
|
+
|
|
75
|
+
If the CLI already created the scaffold, confirm the existing `interf.json` is correct:
|
|
76
|
+
|
|
77
|
+
```json
|
|
78
|
+
{
|
|
79
|
+
"type": "interface",
|
|
80
|
+
"name": "{name}",
|
|
81
|
+
"workflow": "{workflow}",
|
|
82
|
+
"knowledge_base": {
|
|
83
|
+
"path": "../.."
|
|
84
|
+
}
|
|
85
|
+
}
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Do not add `filter:`, `outputs:`, or `validation:` sections to `interf.json`. Those belong in `compile-plan.md`.
|
|
89
|
+
|
|
90
|
+
### 5. Generate compile-plan.md
|
|
91
|
+
|
|
92
|
+
This is the execution plan for compiling THIS interface. The LLM writes it based on the knowledge-base analysis and use case.
|
|
93
|
+
|
|
94
|
+
The plan defines the initial runtime hypothesis for the selected workflow stage graph.
|
|
95
|
+
Start from the existing scaffolded `compile-plan.md`. Preserve the workflow stage headings and required subsection labels already present in that starter plan, then refine the bullet contents and wording for the actual use case.
|
|
96
|
+
For each workflow stage:
|
|
97
|
+
- name the stage exactly as the workflow labels it
|
|
98
|
+
- explain what that stage must accomplish for this use case
|
|
99
|
+
- include contract-appropriate detail for retrieval, analysis, or output stages
|
|
100
|
+
|
|
101
|
+
### 6. Update interface structure
|
|
102
|
+
|
|
103
|
+
The CLI creates the scaffold before invoking this skill. The expected structure is:
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
{name}/
|
|
107
|
+
├── interf.json
|
|
108
|
+
├── compile-plan.md execution plan (git-tracked)
|
|
109
|
+
├── AGENTS.md
|
|
110
|
+
├── CLAUDE.md
|
|
111
|
+
├── workflow/
|
|
112
|
+
│ ├── workflow.json
|
|
113
|
+
│ ├── README.md
|
|
114
|
+
│ ├── create/
|
|
115
|
+
│ │ └── SKILL.md
|
|
116
|
+
│ ├── use/
|
|
117
|
+
│ │ └── query/
|
|
118
|
+
│ │ └── SKILL.md
|
|
119
|
+
│ └── compile/
|
|
120
|
+
│ └── stages/
|
|
121
|
+
│ └── {workflow stage folders}/
|
|
122
|
+
├── .gitignore
|
|
123
|
+
├── .interf/state.json runtime only (gitignored)
|
|
124
|
+
└── home.md
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
**AGENTS.md:**
|
|
128
|
+
```markdown
|
|
129
|
+
# {Name}
|
|
130
|
+
|
|
131
|
+
{One-line description: what this interface is for and what questions it answers.}
|
|
132
|
+
|
|
133
|
+
## How this interface works
|
|
134
|
+
|
|
135
|
+
This is an Interf interface — a focused local context shell built on top of a knowledge base.
|
|
136
|
+
|
|
137
|
+
- `interf.json` — minimal config. Defines type, name, and knowledge-base path only.
|
|
138
|
+
- `compile-plan.md` — execution plan. Defines the selected workflow's compile stages. Generated by LLM, customized for this specific interface. This is the initial runtime hypothesis, not the final word.
|
|
139
|
+
- `knowledge/` — this interface's local entities, claims, and indexes. Built during compile.
|
|
140
|
+
- `briefs/` — hero documents for this use case.
|
|
141
|
+
- `summaries/` — periodic summaries.
|
|
142
|
+
- `workflow/` — local workflow package for create, query, and compile-stage docs.
|
|
143
|
+
- `workflow/use/query/` — interface-local manual query rules. If local artifacts are insufficient, this should defer to the parent KB query loop at `../../workflow/use/query/SKILL.md`.
|
|
144
|
+
- `home.md` — start here. Overview of what's built.
|
|
145
|
+
- The knowledge base is at `../../`. Knowledge-base summaries are at `../../summaries/`.
|
|
146
|
+
- The knowledge-base raw-file quick check is at `../../.interf/source-access.json`.
|
|
147
|
+
- Agent access hierarchy for this interface is: local interface artifacts -> parent knowledge-base artifacts -> raw source files only when needed.
|
|
148
|
+
- If your coding agent is sandboxed, prefer opening the source folder as the session root, then navigate to this interface from there.
|
|
149
|
+
- In Obsidian, browse this interface from the parent knowledge-base vault. Do not assume a standalone interface vault can resolve parent links.
|
|
150
|
+
|
|
151
|
+
## Manual access checklist
|
|
152
|
+
|
|
153
|
+
Use this checklist on the first substantive manual question so you do not get stuck later in the session:
|
|
154
|
+
|
|
155
|
+
1. Read this `AGENTS.md` and then local `workflow/use/query/SKILL.md`.
|
|
156
|
+
2. Confirm the local interface surface is reachable: `home.md`, `knowledge/`, `briefs/`, and any local `summaries/`.
|
|
157
|
+
3. Confirm the parent knowledge base is reachable: `../../AGENTS.md`, `../../home.md`, and parent summaries.
|
|
158
|
+
4. Run the raw-source preflight through `../../.interf/source-access.json` immediately. If the environment asks for permission, request it right away.
|
|
159
|
+
5. After that preflight, start the answer with exactly `Raw access: confirmed` or `Raw access: unavailable`.
|
|
160
|
+
|
|
161
|
+
## Preferred operation
|
|
162
|
+
|
|
163
|
+
Use the Interf CLI:
|
|
164
|
+
```
|
|
165
|
+
interf verify interface-plan --json # immediately after scaffold creation
|
|
166
|
+
interf compile
|
|
167
|
+
interf verify retrieve --json # after retrieve before analyze/compile
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
## Raw skills (fallback / internal harness)
|
|
171
|
+
|
|
172
|
+
Run the compile chain:
|
|
173
|
+
```
|
|
174
|
+
interface/retrieve retrieval contract: prove coverage and select relevant files
|
|
175
|
+
interface/analyze analysis contract: extract entities, claims, and refinements
|
|
176
|
+
interface/compile output contract: create local outputs and validate them
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
## For agents without bundled skills
|
|
180
|
+
|
|
181
|
+
Read `AGENTS.md` first. Then read `workflow/use/query/SKILL.md` for manual questions or the relevant `workflow/compile/stages/<stage>/SKILL.md` when doing compile work. `interf.json` and `compile-plan.md` provide the config and execution plan.
|
|
182
|
+
|
|
183
|
+
To answer questions: start with `home.md`, follow wikilinks to local entities, claims, and indexes in `knowledge/`, then use `briefs/` and local `summaries/` for high-level entry points. If you need deeper evidence, follow links into knowledge-base summaries at `../../summaries/`, then raw files only when necessary.
|
|
184
|
+
Preserve the scaffold router and checklist. Do not replace this file with a shorter template that drops the manual access checklist, raw-source gate, or parent knowledge-base handoff.
|
|
185
|
+
If local docs are listed by the stage contract, read them before creating the interface. They may `extend` or `override` the bundled workflow instructions for later stages, but they do not bypass the stage contract.
|
|
186
|
+
Do not answer from the knowledge base until retrieval coverage is proved via `.interf/coverage.json` and `.interf/relevant.json`.
|
|
187
|
+
|
|
188
|
+
## Rules
|
|
189
|
+
|
|
190
|
+
- Do not modify anything in the knowledge base — it is read-only.
|
|
191
|
+
- All outputs are local to this interface.
|
|
192
|
+
- Follow prose-as-title: filenames are claims, not slugs.
|
|
193
|
+
- Follow wiki-link-as-prose: links read as sentences.
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
When updating `AGENTS.md`, edit the existing scaffold in place. Keep the manual access checklist, router guidance, and parent knowledge-base handoff sections. Only refine the interface-specific description and lines that need to reflect this use case.
|
|
197
|
+
|
|
198
|
+
**.gitignore:**
|
|
199
|
+
```
|
|
200
|
+
knowledge/
|
|
201
|
+
briefs/
|
|
202
|
+
summaries/
|
|
203
|
+
.interf/
|
|
204
|
+
```
|
|
205
|
+
Add any output directories from compile-plan.md.
|
|
206
|
+
|
|
207
|
+
**CLAUDE.md:**
|
|
208
|
+
- Generate it from the final `AGENTS.md` content so Claude Code picks up the same interface instructions automatically.
|
|
209
|
+
- Add a short header telling users to edit `AGENTS.md`, not `CLAUDE.md`.
|
|
210
|
+
|
|
211
|
+
**.interf/state.json:**
|
|
212
|
+
```json
|
|
213
|
+
{
|
|
214
|
+
"version": 1,
|
|
215
|
+
"retrieve_complete": false,
|
|
216
|
+
"analyze_complete": false,
|
|
217
|
+
"compile_complete": false,
|
|
218
|
+
"coverage_complete": false,
|
|
219
|
+
"frontmatter_scanned": 0,
|
|
220
|
+
"candidate_count": 0,
|
|
221
|
+
"abstracts_read": 0,
|
|
222
|
+
"expansion_passes": 0,
|
|
223
|
+
"relevant_count": 0,
|
|
224
|
+
"rejected_count": 0,
|
|
225
|
+
"delta_count": 0,
|
|
226
|
+
"delta_files": [],
|
|
227
|
+
"last_retrieve": null,
|
|
228
|
+
"last_analyze": null,
|
|
229
|
+
"last_compile": null,
|
|
230
|
+
"knowledge_base_summary_count_at_last_compile": 0,
|
|
231
|
+
"extracted_entities": 0,
|
|
232
|
+
"extracted_claims": 0,
|
|
233
|
+
"entity_count": 0,
|
|
234
|
+
"claim_count": 0,
|
|
235
|
+
"output_count": 0,
|
|
236
|
+
"warning_count": 0,
|
|
237
|
+
"error_count": 0
|
|
238
|
+
}
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
**home.md:**
|
|
242
|
+
```markdown
|
|
243
|
+
# {Name} — Home
|
|
244
|
+
|
|
245
|
+
Not yet compiled. Run `interf compile` to start interface compilation.
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
### 7. Register
|
|
249
|
+
|
|
250
|
+
Add to `~/.interf/registry.json` interfaces[]. Create registry if it doesn't exist.
|
|
251
|
+
|
|
252
|
+
### 8. Show next steps
|
|
253
|
+
|
|
254
|
+
```
|
|
255
|
+
Done — interface "{name}" created at {path}
|
|
256
|
+
Connected to knowledge base "{knowledge-base-name}"
|
|
257
|
+
|
|
258
|
+
Next: cd {path} && interf compile
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
## What this skill does NOT do
|
|
262
|
+
|
|
263
|
+
- Does not compile the interface (use `interf compile` from inside the interface, or the raw stage skills)
|
|
264
|
+
- Does not create knowledge bases (use CLI `interf create knowledge-base`)
|
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
# Interface Compile Plan Format
|
|
2
|
+
|
|
3
|
+
When creating an interface, generate a `compile-plan.md` that follows the selected workflow's stage graph. The examples below show the built-in `Retrieve -> Analyze -> Compile` shape. For custom workflows, repeat the same section pattern for each workflow-defined stage label and contract type. This file lives in the interface root and is git-tracked.
|
|
4
|
+
|
|
5
|
+
## Format
|
|
6
|
+
|
|
7
|
+
```markdown
|
|
8
|
+
# {Interface Name} — Compile Plan
|
|
9
|
+
|
|
10
|
+
## Stage 1: Retrieve
|
|
11
|
+
|
|
12
|
+
Filter criteria for knowledge-base summaries/:
|
|
13
|
+
- Categories: {list of relevant categories}
|
|
14
|
+
- Priority evidence tiers: {which source/evidence tiers matter most}
|
|
15
|
+
- Truth modes to prioritize or downweight: {fact vs proposal vs brainstorm etc.}
|
|
16
|
+
- Key entities: {people/companies to prioritize}
|
|
17
|
+
- Date range: {if relevant}
|
|
18
|
+
|
|
19
|
+
Expected relevant file count: ~{estimate}
|
|
20
|
+
Coverage loop:
|
|
21
|
+
- scan all summary frontmatter
|
|
22
|
+
- read abstracts for every candidate file
|
|
23
|
+
- expand through links until the selected set is stable
|
|
24
|
+
- persist selected and rejected files with reasons
|
|
25
|
+
|
|
26
|
+
## Stage 2: Analyze
|
|
27
|
+
|
|
28
|
+
For each relevant summary, extract:
|
|
29
|
+
- {entity type 1}: {what to look for}
|
|
30
|
+
- {entity type 2}: {what to look for}
|
|
31
|
+
- Claims: {what patterns/decisions/risks to detect}
|
|
32
|
+
- Runtime refinements: {when to add missing ontology/taxonomy/relationship structure}
|
|
33
|
+
|
|
34
|
+
Working-set budget: ~{fraction or token budget} of model context window per batch.
|
|
35
|
+
Subagent instruction: "{what each subagent should return}"
|
|
36
|
+
|
|
37
|
+
## Stage 3: Compile
|
|
38
|
+
|
|
39
|
+
Output files to create/update:
|
|
40
|
+
|
|
41
|
+
### {Output 1, e.g., briefs/Company.md}
|
|
42
|
+
Purpose: {what question this answers}
|
|
43
|
+
Sections: {structure}
|
|
44
|
+
Evidence: {what sources to cite}
|
|
45
|
+
|
|
46
|
+
### {Output 2, e.g., knowledge/entities/*.md}
|
|
47
|
+
{same format}
|
|
48
|
+
|
|
49
|
+
### home.md
|
|
50
|
+
Links to: {key outputs}
|
|
51
|
+
Status: {counts, last compile}
|
|
52
|
+
Agent navigation: {how an agent should move from AGENTS.md into the rest of this interface}
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Example: Research Briefing interface
|
|
56
|
+
|
|
57
|
+
```markdown
|
|
58
|
+
# Research Briefing — Compile Plan
|
|
59
|
+
|
|
60
|
+
## Stage 1: Retrieve
|
|
61
|
+
|
|
62
|
+
Filter criteria for knowledge-base summaries/:
|
|
63
|
+
- Categories: papers, notes, repos, datasets, experiments
|
|
64
|
+
- Priority evidence tiers: tier_1_authoritative, tier_2_direct_record, tier_3_working_material
|
|
65
|
+
- Truth modes to prioritize or downweight: prioritize fact/reported_fact/measurement, downweight brainstorm and speculation
|
|
66
|
+
- Key entities: methods, datasets, benchmarks, authors, projects
|
|
67
|
+
- Date range: all (for landscape), last 90 days (for recent developments)
|
|
68
|
+
|
|
69
|
+
Expected relevant file count: ~220 of 900
|
|
70
|
+
Coverage loop:
|
|
71
|
+
- scan all 900 summary frontmatter blocks
|
|
72
|
+
- read abstracts for the full candidate set
|
|
73
|
+
- follow adjacency links for methods, datasets, and benchmark clusters until retrieval closure
|
|
74
|
+
- persist selected and rejected files with reasons in coverage proof
|
|
75
|
+
|
|
76
|
+
## Stage 2: Analyze
|
|
77
|
+
|
|
78
|
+
For each relevant summary, extract:
|
|
79
|
+
- Methods: goals, assumptions, strengths, weaknesses
|
|
80
|
+
- Datasets: scope, quality issues, benchmark relevance
|
|
81
|
+
- Claims: what is being asserted and with what level of support
|
|
82
|
+
- Contradictions: disagreements across sources, benchmarks, or interpretations
|
|
83
|
+
- Open questions: what the knowledge base still does not explain well
|
|
84
|
+
- Runtime refinements: add missing method families, benchmark clusters, and claim groupings when evidence supports them
|
|
85
|
+
|
|
86
|
+
Working-set budget: ~40% of model context window per batch.
|
|
87
|
+
Subagent instruction: "Extract entities, claims, contradictions, and open questions relevant to this research briefing. Return structured JSON."
|
|
88
|
+
|
|
89
|
+
## Stage 3: Compile
|
|
90
|
+
|
|
91
|
+
### briefs/Themes.md
|
|
92
|
+
Purpose: "What themes define this knowledge base right now?"
|
|
93
|
+
Sections: major themes, strongest evidence, changes over time
|
|
94
|
+
Evidence: prefer primary and direct-record sources
|
|
95
|
+
|
|
96
|
+
### briefs/Contradictions.md
|
|
97
|
+
Purpose: "Where do sources disagree or look unresolved?"
|
|
98
|
+
Sections: contradiction, supporting evidence, counterevidence, next check
|
|
99
|
+
Evidence: cite both sides explicitly
|
|
100
|
+
|
|
101
|
+
### briefs/Open-Questions.md
|
|
102
|
+
Purpose: "What should we read or verify next?"
|
|
103
|
+
Sections: question, why it matters, missing evidence, suggested next sources
|
|
104
|
+
Evidence: link back to the gaps in the reviewed set
|
|
105
|
+
|
|
106
|
+
### home.md
|
|
107
|
+
Links to: all briefs notes, latest summary, entity/claim counts
|
|
108
|
+
Agent navigation: AGENTS.md -> home.md -> briefs/ -> knowledge/ -> knowledge-base summaries
|
|
109
|
+
```
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Interface Workflows
|
|
2
|
+
|
|
3
|
+
Pre-designed interface methodologies. Use them as starting points and adapt them to the actual knowledge-base data.
|
|
4
|
+
|
|
5
|
+
## briefing
|
|
6
|
+
|
|
7
|
+
Current-state briefing. Best when the agent needs the latest truth, recent changes, and immediate next steps.
|
|
8
|
+
|
|
9
|
+
**Questions it answers:**
|
|
10
|
+
- What is true right now?
|
|
11
|
+
- What changed recently?
|
|
12
|
+
- What should happen next?
|
|
13
|
+
|
|
14
|
+
**Filter:** current-state docs, changelogs, decisions, updates
|
|
15
|
+
**Outputs:** Current-State.md, Changes.md, Next-Steps.md
|
|
16
|
+
|
|
17
|
+
## research
|
|
18
|
+
|
|
19
|
+
Research synthesis. Best when the agent needs themes, claims, contradictions, and open questions from a dense knowledge base.
|
|
20
|
+
|
|
21
|
+
**Questions it answers:**
|
|
22
|
+
- What are the strongest recurring themes?
|
|
23
|
+
- Where do sources agree or disagree?
|
|
24
|
+
- What questions still need more evidence?
|
|
25
|
+
|
|
26
|
+
**Filter:** primary sources, papers, notes, datasets, experiments, repos
|
|
27
|
+
**Outputs:** Themes.md, Contradictions.md, Open-Questions.md
|
|
28
|
+
|
|
29
|
+
## audit
|
|
30
|
+
|
|
31
|
+
Audit and gap-finding. Best when the agent needs to improve knowledge-base quality, surface contradictions, and plan follow-up work.
|
|
32
|
+
|
|
33
|
+
**Questions it answers:**
|
|
34
|
+
- What is missing or weakly covered?
|
|
35
|
+
- Which facts or claims look inconsistent?
|
|
36
|
+
- What should be verified or added next?
|
|
37
|
+
|
|
38
|
+
**Filter:** canonical records, requirements, policies, status docs, recent changes
|
|
39
|
+
**Outputs:** Gaps.md, Contradictions.md, Follow-Ups.md
|
|
40
|
+
|
|
41
|
+
## Create new workflow
|
|
42
|
+
|
|
43
|
+
Create a new reusable local workflow from the wizard when the shipped workflows are not enough.
|
|
44
|
+
|
|
45
|
+
The wizard asks:
|
|
46
|
+
1. What questions should this interface answer?
|
|
47
|
+
2. What categories or entities matter?
|
|
48
|
+
3. What output documents should it maintain?
|
|
49
|
+
|
|
50
|
+
Then it saves a named local workflow under `interf/workflows/interface/` and generates `interf.json` plus `compile-plan.md` from knowledge-base analysis.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
{
|
|
3
|
+
"name": "interface/query",
|
|
4
|
+
"description": "Manual-use skill for answering questions from inside an interface. Navigates AGENTS.md, home.md, local knowledge/briefs/summaries, parent knowledge-base summaries, backlinks, and raw sources only when reachable. Use when a user opens an agent inside an interface and asks questions against it."
|
|
5
|
+
}
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Interface Query
|
|
9
|
+
|
|
10
|
+
Use this skill in manual agent sessions inside a compiled interface.
|
|
11
|
+
|
|
12
|
+
Start with:
|
|
13
|
+
- `AGENTS.md`
|
|
14
|
+
- `home.md`
|
|
15
|
+
- local `knowledge/`
|
|
16
|
+
- `briefs/`
|
|
17
|
+
- local `summaries/`
|
|
18
|
+
|
|
19
|
+
Default loop:
|
|
20
|
+
- answer from local interface outputs first
|
|
21
|
+
- follow wikilinks and backlinks outward before treating one note as complete
|
|
22
|
+
- climb to parent knowledge-base summaries in `../../summaries/` when you need stronger evidence
|
|
23
|
+
- use raw source files only when needed for verification, direct quotes, ambiguity, or missing context
|
|
24
|
+
|
|
25
|
+
Raw-source gate:
|
|
26
|
+
- inspect `../../.interf/source-access.json`
|
|
27
|
+
- verify one `suggested_checks` path is actually readable from this session before claiming raw-file verification
|
|
28
|
+
- if the path is not reachable or permission is not granted, say the answer is based on interface and parent knowledge-base artifacts only
|
|
29
|
+
|
|
30
|
+
When confidence is low:
|
|
31
|
+
- expand outward through linked briefs, claims, entities, and parent summaries
|
|
32
|
+
- do not stop at the first local note if linked evidence exists above it
|
|
33
|
+
|
|
34
|
+
This skill is for manual question-answering behavior. It does not change retrieve, analyze, or compile runtime contracts.
|
|
@@ -0,0 +1,166 @@
|
|
|
1
|
+
---
|
|
2
|
+
{
|
|
3
|
+
"name": "interface/retrieve",
|
|
4
|
+
"description": "Interface retrieval contract. Identifies relevant files from the connected knowledge base. Scans knowledge-base summaries metadata, applies filters from compile-plan.md, computes delta since last compile. Use when asked to retrieve from the knowledge base, find relevant files, or run a retrieval stage inside interface compile."
|
|
5
|
+
}
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Interface Compile — Retrieve
|
|
9
|
+
|
|
10
|
+
Read `interf.json` (must have `type: interface`) and `compile-plan.md` for filter criteria.
|
|
11
|
+
|
|
12
|
+
Local runtime reference:
|
|
13
|
+
- active stage contract: `.interf/stage-contract.json`
|
|
14
|
+
- active run ledger: `.interf/run.json`
|
|
15
|
+
- local config: `interf.json`
|
|
16
|
+
- local plan: `compile-plan.md`
|
|
17
|
+
- local instruction docs: the files listed by `.interf/stage-contract.json`
|
|
18
|
+
|
|
19
|
+
When this skill is embedded into a generated interface, do not try to open SDK repo docs or source files outside the current workspace. The local contract and local docs are the source of truth for this run.
|
|
20
|
+
|
|
21
|
+
This skill identifies which files in the knowledge base are relevant to this interface and which are new since last compile.
|
|
22
|
+
|
|
23
|
+
Retrieve is coverage-gated. The goal is not to guess a relevant set quickly. The goal is to prove that the routing layer scanned the full summary set, reviewed the candidate abstracts, and persisted both selected and rejected files before analysis begins.
|
|
24
|
+
The runtime in `compile-plan.md` is an initial hypothesis. Retrieve may discover missing entities, categories, or relationship clusters that should shape later interface refinement.
|
|
25
|
+
|
|
26
|
+
Important proof semantics:
|
|
27
|
+
- `proof.scanned` is the full summary set scanned at the frontmatter-routing layer
|
|
28
|
+
- `proof.reviewed` is the narrower candidate set whose abstracts were reviewed
|
|
29
|
+
- `proof.retrieved` plus `proof.excluded` should partition the scanned summary set
|
|
30
|
+
|
|
31
|
+
The knowledge base is located at `knowledge_base.path` from `interf.json` (typically `../..`). Knowledge-base summaries are at `{knowledge_base.path}/summaries/`.
|
|
32
|
+
If a coding agent is sandboxed to its current working tree, prefer launching it from the source folder or another root that can reach both the knowledge base and the source folder.
|
|
33
|
+
If `../../.interf/source-access.json` exists, use it as the quick check for whether raw paths are actually reachable from this session before assuming raw fallback will work.
|
|
34
|
+
If local docs are listed by the stage contract, read them before retrieving. They may `extend` or `override` the bundled workflow instructions for this stage, but they do not bypass coverage proof or the stage contract.
|
|
35
|
+
|
|
36
|
+
Harness role:
|
|
37
|
+
- This skill is an internal harness step normally invoked by `interf compile` from inside an interface.
|
|
38
|
+
- For standard operation, prefer the CLI or another higher-level tool over calling this skill directly.
|
|
39
|
+
|
|
40
|
+
## Runtime contract
|
|
41
|
+
|
|
42
|
+
When invoked by the CLI, honor any explicit execution instructions in the prompt. In particular:
|
|
43
|
+
- if `.interf/stage-contract.json` exists, treat it as the authoritative stage contract for this run
|
|
44
|
+
- if the prompt gives an expected summary-set size, use it as the source of truth for progress reporting
|
|
45
|
+
- if the prompt requires `.interf/relevant.json`, write it
|
|
46
|
+
- keep `.interf/health.json` consistent with the latest `.interf/state.json` if you update state directly
|
|
47
|
+
- only emit user-facing lines that start with `STATUS:`, `DONE:`, `BLOCKED:`, or `ERROR:`
|
|
48
|
+
|
|
49
|
+
## Steps
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
Retrieve:
|
|
53
|
+
- [ ] 1. Read config and plan
|
|
54
|
+
- [ ] 2. Scan knowledge-base frontmatter
|
|
55
|
+
- [ ] 3. Review candidate abstracts
|
|
56
|
+
- [ ] 4. Expand through links if needed
|
|
57
|
+
- [ ] 5. Compute delta
|
|
58
|
+
- [ ] 6. Update state
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### 1. Read config and plan
|
|
62
|
+
|
|
63
|
+
- `interf.json` → `knowledge_base.path` to locate the knowledge base
|
|
64
|
+
- `compile-plan.md` → this stage's section: categories, priority evidence tiers, truth modes, key entities, date range
|
|
65
|
+
- `.interf/state.json` → `last_compile`, `knowledge_base_summary_count_at_last_compile`
|
|
66
|
+
- `../../.interf/source-access.json` → sample raw paths and suggested access checks when raw fallback is needed
|
|
67
|
+
- local instruction docs listed by the stage contract
|
|
68
|
+
|
|
69
|
+
Resolve `knowledge_base.path` from config and verify the knowledge base exists (has `summaries/`).
|
|
70
|
+
|
|
71
|
+
### 2. Scan knowledge-base frontmatter
|
|
72
|
+
|
|
73
|
+
Read all files in `{knowledge_base.path}/summaries/` frontmatter (fast — no full file reads):
|
|
74
|
+
- source
|
|
75
|
+
- source_kind
|
|
76
|
+
- evidence tier / truth mode / state
|
|
77
|
+
- abstract
|
|
78
|
+
|
|
79
|
+
Build a summary-set map: total files, source-kind distribution, evidence distribution.
|
|
80
|
+
|
|
81
|
+
### 3. Review candidate abstracts
|
|
82
|
+
|
|
83
|
+
From compile-plan.md filter criteria, identify a candidate set. Then read the abstract block for every candidate file before final selection.
|
|
84
|
+
|
|
85
|
+
### 4. Expand through links if needed
|
|
86
|
+
|
|
87
|
+
If candidate abstracts point to adjacent summaries that may materially change the answer, follow those links, review their abstracts, and repeat until the retrieved set is coverage-complete for the interface question.
|
|
88
|
+
Track emergent clusters that suggest the initial interface runtime is missing concepts, relationships, or taxonomy branches.
|
|
89
|
+
|
|
90
|
+
### 5. Compute delta
|
|
91
|
+
|
|
92
|
+
- First run (`last_compile` is null): ALL relevant files are new
|
|
93
|
+
- Subsequent runs: compare `knowledge_base_summary_count_at_last_compile` vs current count, identify new files by date
|
|
94
|
+
|
|
95
|
+
### 6. Update state
|
|
96
|
+
|
|
97
|
+
Write the full retrieved set to `.interf/relevant.json`:
|
|
98
|
+
|
|
99
|
+
```json
|
|
100
|
+
{
|
|
101
|
+
"version": 1,
|
|
102
|
+
"generated_at": "2026-03-30T20:00:00Z",
|
|
103
|
+
"knowledge_base_summary_count": 2500,
|
|
104
|
+
"relevant_files": ["summaries/file1.md", "summaries/file2.md"],
|
|
105
|
+
"delta_files": ["summaries/file1.md", "summaries/file2.md"]
|
|
106
|
+
}
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
File paths in `relevant_files` and `delta_files` are relative to the knowledge base.
|
|
110
|
+
|
|
111
|
+
Write retrieval proof to `.interf/coverage.json`:
|
|
112
|
+
|
|
113
|
+
```json
|
|
114
|
+
{
|
|
115
|
+
"version": 1,
|
|
116
|
+
"run_id": "run_abc123",
|
|
117
|
+
"interface": "briefing",
|
|
118
|
+
"generated_at": "2026-03-30T20:00:00Z",
|
|
119
|
+
"knowledge_base_summary_total": 3,
|
|
120
|
+
"frontmatter_scanned": 3,
|
|
121
|
+
"candidates_after_frontmatter": 2,
|
|
122
|
+
"abstracts_reviewed": 2,
|
|
123
|
+
"expansion_passes": 2,
|
|
124
|
+
"relevant_selected": 1,
|
|
125
|
+
"rejected": 2,
|
|
126
|
+
"coverage_complete": true,
|
|
127
|
+
"proof": {
|
|
128
|
+
"scanned": ["summaries/file1.md", "summaries/file2.md", "summaries/file3.md"],
|
|
129
|
+
"reviewed": ["summaries/file1.md", "summaries/file2.md"],
|
|
130
|
+
"retrieved": ["summaries/file1.md"],
|
|
131
|
+
"excluded": ["summaries/file2.md", "summaries/file3.md"]
|
|
132
|
+
}
|
|
133
|
+
}
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
Write retrieve results to `.interf/state.json`:
|
|
137
|
+
|
|
138
|
+
```json
|
|
139
|
+
{
|
|
140
|
+
"retrieve_complete": true,
|
|
141
|
+
"coverage_complete": true,
|
|
142
|
+
"frontmatter_scanned": 2500,
|
|
143
|
+
"candidate_count": 1200,
|
|
144
|
+
"abstracts_read": 1200,
|
|
145
|
+
"expansion_passes": 2,
|
|
146
|
+
"relevant_count": 1200,
|
|
147
|
+
"rejected_count": 1300,
|
|
148
|
+
"delta_count": 12,
|
|
149
|
+
"delta_files": ["summaries/file1.md", "summaries/file2.md"],
|
|
150
|
+
"last_retrieve": "2026-03-30T20:00:00Z"
|
|
151
|
+
}
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
Refresh `.interf/health.json` after state is updated. The health file is a computed verification surface for compile status and key metrics, not a prose summary.
|
|
155
|
+
If the retrieve stage reveals clear runtime gaps, preserve that signal for later stages via `.interf/analysis.json` or the next stage handoff rather than silently discarding it.
|
|
156
|
+
|
|
157
|
+
Report to user with status-style lines:
|
|
158
|
+
```
|
|
159
|
+
STATUS: loaded retrieve plan 2500 summary files.
|
|
160
|
+
STATUS: scanned 2500/2500
|
|
161
|
+
STATUS: reviewed 1200 abstracts, 2 expansion passes
|
|
162
|
+
STATUS: selected 1200 relevant, 1300 rejected, 12 delta
|
|
163
|
+
DONE: retrieve complete
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
When the retrieval proof, relevant set, state, and health files are written, emit the required `DONE:` line and stop. Do not keep exploring once retrieval closure is recorded.
|