@codecell-germany/company-agent-wiki-skill 0.1.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/LICENSE +22 -0
- package/README.md +265 -0
- package/dist/index.js +12676 -0
- package/dist/installer.js +3682 -0
- package/knowledge/ARCHITECTURE.md +106 -0
- package/knowledge/KNOWN_LIMITATIONS.md +30 -0
- package/knowledge/RELEASE_CHECKLIST.md +145 -0
- package/package.json +46 -0
- package/skills/company-agent-wiki-cli/SKILL.md +252 -0
- package/skills/company-agent-wiki-cli/references/agent-onboarding.md +57 -0
- package/skills/company-agent-wiki-cli/references/authoring-workflow.md +167 -0
- package/skills/company-agent-wiki-cli/references/command-cheatsheet.md +48 -0
- package/skills/company-agent-wiki-cli/references/company-onboarding.md +94 -0
- package/skills/company-agent-wiki-cli/references/overview.md +41 -0
- package/skills/company-agent-wiki-cli/references/workspace-first-run.md +39 -0
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
# Architecture
|
|
2
|
+
|
|
3
|
+
## Scope
|
|
4
|
+
|
|
5
|
+
Phase 1 delivers a publishable CLI and Codex skill for a private, local company knowledge workspace.
|
|
6
|
+
|
|
7
|
+
The implementation is intentionally limited to:
|
|
8
|
+
|
|
9
|
+
- file-based Markdown roots
|
|
10
|
+
- a derived SQLite index
|
|
11
|
+
- Git-aware verification and history views
|
|
12
|
+
- a read-only local web view
|
|
13
|
+
|
|
14
|
+
Phase 1 excludes connectors, ingestion pipelines and GUI editing.
|
|
15
|
+
|
|
16
|
+
## Core Principles
|
|
17
|
+
|
|
18
|
+
1. Markdown files are the source of truth.
|
|
19
|
+
2. SQLite is a rebuildable, derived index.
|
|
20
|
+
3. Git remains the audit and rollback layer for tracked content.
|
|
21
|
+
4. Agent access goes through the public CLI contract.
|
|
22
|
+
5. The code repository and the private knowledge workspace stay separate.
|
|
23
|
+
|
|
24
|
+
## Workspace Model
|
|
25
|
+
|
|
26
|
+
The CLI scaffolds a private workspace with:
|
|
27
|
+
|
|
28
|
+
- `.company-agent-wiki/workspace.json` as tracked workspace metadata
|
|
29
|
+
- `.company-agent-wiki/index.sqlite` as the derived search index
|
|
30
|
+
- `.company-agent-wiki/index-manifest.json` as the current snapshot manifest
|
|
31
|
+
- `knowledge/canonical/` as the managed Markdown root
|
|
32
|
+
- `knowledge/archive/` as the reserved archive root
|
|
33
|
+
- starter documents such as `wiki-start-here.md`, `company-profile.md`, `organisation-und-rollen.md`, `systeme-und-tools.md`, `kernprozesse.md`, `projekte-und-roadmap.md` and `glossar.md`
|
|
34
|
+
|
|
35
|
+
The index and manifest are derived artifacts and should stay ignored in the private workspace Git repository.
|
|
36
|
+
|
|
37
|
+
## Phase 1 Data Flow
|
|
38
|
+
|
|
39
|
+
1. `setup workspace` creates the private workspace skeleton plus starter documents unless `--no-starter-docs` is used.
|
|
40
|
+
2. `onboarding company` can either emit a source-backed questionnaire or preview/apply draft onboarding documents from an answers file.
|
|
41
|
+
3. `roots add` registers additional local Markdown roots.
|
|
42
|
+
4. `index rebuild` parses Markdown files, sections and frontmatter into SQLite + FTS5.
|
|
43
|
+
5. `verify` compares current root snapshots against the stored manifest and reports `missing` on a brand-new workspace instead of failing hard.
|
|
44
|
+
6. `search` and `route` can narrow candidates with front-matter filters such as `type`, `project`, `department`, `tag`, `owner` and `system`.
|
|
45
|
+
7. `read --metadata --headings` supports a metadata-first retrieval pass before the full Markdown is loaded.
|
|
46
|
+
8. `search`, `route` and `read` either enforce a fresh index or can explicitly auto-rebuild when `--auto-rebuild` is set.
|
|
47
|
+
9. Runtime commands may detect the current workspace automatically when the shell is already inside a private workspace.
|
|
48
|
+
10. `serve` exposes the same read-only data through a local web view and now distinguishes `missing`, `stale` and `ok` states with a rebuild action.
|
|
49
|
+
|
|
50
|
+
## Onboarding Model
|
|
51
|
+
|
|
52
|
+
Phase 1 includes a source-backed onboarding blueprint for das deutsche Unternehmensprofil. The agent can now turn an answer file into draft starter Markdown under `knowledge/canonical/`, but the write step is still explicit and guarded by `--execute`.
|
|
53
|
+
|
|
54
|
+
The onboarding scope standardizes the first agent-led questions around:
|
|
55
|
+
|
|
56
|
+
- rechtliche Identität
|
|
57
|
+
- Geschäftsführung und Eigentum
|
|
58
|
+
- Steuern und Umsatzsteuerlogik
|
|
59
|
+
- Mitarbeitende und Arbeitgeberstatus
|
|
60
|
+
- operative Wissensgrundlage
|
|
61
|
+
|
|
62
|
+
## Snapshot and Staleness Contract
|
|
63
|
+
|
|
64
|
+
The manifest stores:
|
|
65
|
+
|
|
66
|
+
- `build_id`
|
|
67
|
+
- `schema_version`
|
|
68
|
+
- `indexed_at`
|
|
69
|
+
- per-root fingerprints based on file paths, sizes and mtimes
|
|
70
|
+
- optional Git snapshot metadata for Git-backed roots
|
|
71
|
+
|
|
72
|
+
Reads are pinned to the latest successful `build_id`. If current root snapshots no longer match the manifest, the CLI returns `INDEX_STALE` unless the caller explicitly opted into auto-rebuild.
|
|
73
|
+
|
|
74
|
+
The SQLite runtime also uses a busy timeout and returns a specific `SQLITE_LOCKED` error for transient contention instead of surfacing a generic runtime failure.
|
|
75
|
+
|
|
76
|
+
## Metadata-First Retrieval
|
|
77
|
+
|
|
78
|
+
Phase 1 now explicitly supports a two-step retrieval model:
|
|
79
|
+
|
|
80
|
+
1. candidate routing through search plus indexed metadata
|
|
81
|
+
2. metadata and heading inspection before full document reads
|
|
82
|
+
|
|
83
|
+
This keeps the agent loop lighter and encourages stronger filenames plus front matter without forcing a rigid folder taxonomy.
|
|
84
|
+
|
|
85
|
+
## Git Model
|
|
86
|
+
|
|
87
|
+
Phase 1 uses Git for:
|
|
88
|
+
|
|
89
|
+
- workspace repository initialization
|
|
90
|
+
- document history lookup
|
|
91
|
+
- document diff lookup
|
|
92
|
+
- optional remote registration during setup
|
|
93
|
+
- reviewing explicit onboarding-generated draft Markdown after it has been written
|
|
94
|
+
|
|
95
|
+
Phase 1 deliberately does not auto-commit content mutations. Even onboarding writes stay outside automatic Git mutation flows, though the CLI now rebuilds the derived index after a successful onboarding apply.
|
|
96
|
+
|
|
97
|
+
## Why the Workspace Is Separate
|
|
98
|
+
|
|
99
|
+
This repository is meant to be public. A real company knowledge workspace is private by design and may contain:
|
|
100
|
+
|
|
101
|
+
- confidential process documentation
|
|
102
|
+
- customer-specific notes
|
|
103
|
+
- accounting procedures
|
|
104
|
+
- sensitive internal structures
|
|
105
|
+
|
|
106
|
+
Separating code and private data keeps the public package clean and keeps Git, npm and screenshots safe by default.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Known Limitations
|
|
2
|
+
|
|
3
|
+
## Product Scope
|
|
4
|
+
|
|
5
|
+
- Phase 1 only understands local Markdown roots.
|
|
6
|
+
- Connectors for e-mail, notes, CRM, chat or audio are not implemented.
|
|
7
|
+
- The web view is read-only.
|
|
8
|
+
- The CLI only materializes onboarding-generated draft starter documents from an explicit answers file.
|
|
9
|
+
- The onboarding flow is not a built-in interactive prompt loop; the agent still has to conduct the conversation and produce the answers file.
|
|
10
|
+
|
|
11
|
+
## Index Model
|
|
12
|
+
|
|
13
|
+
- Root freshness is based on file path, size and mtime snapshots, not on deep content hashing for every query.
|
|
14
|
+
- The SQLite index is rebuilt wholesale through `index rebuild`; there is no incremental mutation journal yet.
|
|
15
|
+
- Auto-rebuild is opt-in. Without `--auto-rebuild`, stale or missing indexes still block retrieval on purpose.
|
|
16
|
+
- Search quality depends on document structure and heading hygiene in the source Markdown.
|
|
17
|
+
- Front-matter filters are currently focused on common fields such as `type`, `status`, `tags`, `project`, `department`, `owners` and `systems`; there is not yet a generic arbitrary-field query language.
|
|
18
|
+
- The SQLite runtime is more tolerant of transient contention now, but the same workspace should still not be hammered by multiple parallel agent reads if that can be avoided.
|
|
19
|
+
- Search JSON now exposes a normalized `score` plus `rawScore`; the normalized value is better for agents, but it is still only a ranking aid, not a calibrated relevance percentage.
|
|
20
|
+
|
|
21
|
+
## Git Model
|
|
22
|
+
|
|
23
|
+
- History and diff only work for files inside a Git repository.
|
|
24
|
+
- Phase 1 does not auto-commit workspace changes.
|
|
25
|
+
- Restore flows are not implemented in the web view.
|
|
26
|
+
|
|
27
|
+
## Security Model
|
|
28
|
+
|
|
29
|
+
- The CLI can initialize a private Git remote URL, but it does not validate remote policy or access controls.
|
|
30
|
+
- The package does not enforce OS-level filesystem permissions; the workspace owner must place the private workspace in a properly protected location.
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Release Checklist
|
|
2
|
+
|
|
3
|
+
## Naming Decision
|
|
4
|
+
|
|
5
|
+
- Empfohlener GitHub-Repo-Name: `company-agent-wiki-skill`
|
|
6
|
+
- npm-Paket: `@codecell-germany/company-agent-wiki-skill`
|
|
7
|
+
- CLI-Binary: `company-agent-wiki-cli`
|
|
8
|
+
- Installer-Binary: `company-agent-wiki-skill`
|
|
9
|
+
- Skill-Name: `company-agent-wiki-cli`
|
|
10
|
+
|
|
11
|
+
Empfohlene GitHub-Beschreibung:
|
|
12
|
+
|
|
13
|
+
`Context is king. Agent-first local company knowledge runtime with Markdown as truth, metadata-first retrieval, a SQLite index and Git-aware history.`
|
|
14
|
+
|
|
15
|
+
## Before GitHub Publish
|
|
16
|
+
|
|
17
|
+
- Prüfen, dass das lokale Git-Repo einen sauberen Ausgangszustand hat:
|
|
18
|
+
- wenn noch kein erster Commit existiert, zuerst den initialen Commit vorbereiten
|
|
19
|
+
- wenn noch kein Remote existiert, das öffentliche GitHub-Repo zuerst anlegen
|
|
20
|
+
- Prüfen, dass keine privaten Daten im Repo liegen:
|
|
21
|
+
- keine echten Workspace-Inhalte
|
|
22
|
+
- keine Tokens, `.env`-Dateien oder Exportdateien
|
|
23
|
+
- keine Inhalte aus `Plans/`, `.context/` oder `output/`
|
|
24
|
+
- Prüfen, dass `.gitignore` mindestens diese Bereiche abdeckt:
|
|
25
|
+
- `Plans/`
|
|
26
|
+
- `.context/`
|
|
27
|
+
- `output/`
|
|
28
|
+
- `.env`
|
|
29
|
+
- `.env.*`
|
|
30
|
+
- `*.tgz`
|
|
31
|
+
- Prüfen, dass `package.json -> files` nur öffentliche Artefakte freigibt.
|
|
32
|
+
- README, Skill, Referenzen und Knowledge-Doku gemeinsam synchronisieren:
|
|
33
|
+
- `README.md`
|
|
34
|
+
- `skills/company-agent-wiki-cli/SKILL.md`
|
|
35
|
+
- `skills/company-agent-wiki-cli/references/agent-onboarding.md`
|
|
36
|
+
- `skills/company-agent-wiki-cli/references/overview.md`
|
|
37
|
+
- `skills/company-agent-wiki-cli/references/command-cheatsheet.md`
|
|
38
|
+
- `skills/company-agent-wiki-cli/references/workspace-first-run.md`
|
|
39
|
+
- `skills/company-agent-wiki-cli/references/authoring-workflow.md`
|
|
40
|
+
- `knowledge/ARCHITECTURE.md`
|
|
41
|
+
- `knowledge/KNOWN_LIMITATIONS.md`
|
|
42
|
+
|
|
43
|
+
## Local Verification
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
npm install
|
|
47
|
+
npm run build
|
|
48
|
+
npm run test:unit
|
|
49
|
+
node dist/index.js --help
|
|
50
|
+
node dist/installer.js install --force
|
|
51
|
+
npm pack
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Tarball Smoke Tests
|
|
55
|
+
|
|
56
|
+
CLI aus lokalem Tarball:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
TMP="$(mktemp -d)"
|
|
60
|
+
cd "$TMP"
|
|
61
|
+
npx -y -p /absolute/path/to/codecell-germany-company-agent-wiki-skill-0.1.0.tgz company-agent-wiki-cli --help
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Installer aus lokalem Tarball:
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
TMP="$(mktemp -d)"
|
|
68
|
+
cd "$TMP"
|
|
69
|
+
npx -y -p /absolute/path/to/codecell-germany-company-agent-wiki-skill-0.1.0.tgz company-agent-wiki-skill install --codex-home "$TMP/codex" --force
|
|
70
|
+
"$TMP/codex/bin/company-agent-wiki-cli" --help
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## GitHub Publish Order
|
|
74
|
+
|
|
75
|
+
1. Öffentliches GitHub-Repo `codecell-germany/company-agent-wiki-skill` anlegen.
|
|
76
|
+
2. GitHub-Beschreibung setzen.
|
|
77
|
+
3. Lokale Dateien prüfen und nur gewünschte Dateien stagen.
|
|
78
|
+
4. Ersten Commit oder Release-Commit erstellen.
|
|
79
|
+
5. Remote verbinden.
|
|
80
|
+
6. Push ausführen.
|
|
81
|
+
|
|
82
|
+
Wichtige Regel:
|
|
83
|
+
|
|
84
|
+
- niemals blind `git add .`
|
|
85
|
+
|
|
86
|
+
## npm Publish
|
|
87
|
+
|
|
88
|
+
Vor dem Publish:
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
npm whoami
|
|
92
|
+
npm pack
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Veröffentlichung:
|
|
96
|
+
|
|
97
|
+
```bash
|
|
98
|
+
npm publish --access public --registry=https://registry.npmjs.org/
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Wenn npm-2FA blockiert, den finalen Publish-Schritt lokal im echten Terminal ausführen.
|
|
102
|
+
|
|
103
|
+
## npm Verification After Publish
|
|
104
|
+
|
|
105
|
+
```bash
|
|
106
|
+
npm view @codecell-germany/company-agent-wiki-skill version --registry=https://registry.npmjs.org/
|
|
107
|
+
npm view @codecell-germany/company-agent-wiki-skill dist-tags --json --registry=https://registry.npmjs.org/
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
Registry-Install mit exakter Version:
|
|
111
|
+
|
|
112
|
+
```bash
|
|
113
|
+
TMP="$(mktemp -d)"
|
|
114
|
+
CACHE="$(mktemp -d)"
|
|
115
|
+
cd "$TMP"
|
|
116
|
+
npm_config_cache="$CACHE" npx -y @codecell-germany/company-agent-wiki-skill@0.1.0 company-agent-wiki-cli --help
|
|
117
|
+
npm_config_cache="$CACHE" npx -y @codecell-germany/company-agent-wiki-skill@0.1.0 company-agent-wiki-skill install --codex-home "$TMP/codex" --force
|
|
118
|
+
"$TMP/codex/bin/company-agent-wiki-cli" --help
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
## skills.sh Verification
|
|
122
|
+
|
|
123
|
+
Nach GitHub-Publish:
|
|
124
|
+
|
|
125
|
+
```bash
|
|
126
|
+
npx -y skills add codecell-germany/company-agent-wiki-skill -l
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Danach einen echten Install testen:
|
|
130
|
+
|
|
131
|
+
```bash
|
|
132
|
+
npx -y skills add codecell-germany/company-agent-wiki-skill -g --skill company-agent-wiki-cli -a '*' -y
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
## Final Done Check
|
|
136
|
+
|
|
137
|
+
- CLI läuft über `company-agent-wiki-cli`
|
|
138
|
+
- Installer läuft über `company-agent-wiki-skill`
|
|
139
|
+
- README, Skill, Referenzen und Knowledge sind synchron
|
|
140
|
+
- `npm pack` enthält nur gewollte Dateien
|
|
141
|
+
- lokaler Tarball-Smoketest ist grün
|
|
142
|
+
- GitHub-Repo ist öffentlich und aktuell
|
|
143
|
+
- npm-Paket ist veröffentlicht
|
|
144
|
+
- exakter Registry-Install ist verifiziert
|
|
145
|
+
- `skills add ... -l` findet den Skill
|
package/package.json
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@codecell-germany/company-agent-wiki-skill",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Context is king: agent-first local company knowledge workspace with metadata-first retrieval, Markdown as truth, SQLite-indexed front matter, Git-aware verification, and a Codex skill installer.",
|
|
5
|
+
"private": false,
|
|
6
|
+
"license": "MIT",
|
|
7
|
+
"type": "commonjs",
|
|
8
|
+
"main": "dist/index.js",
|
|
9
|
+
"bin": {
|
|
10
|
+
"company-agent-wiki-cli": "dist/index.js",
|
|
11
|
+
"company-agent-wiki-skill": "dist/installer.js"
|
|
12
|
+
},
|
|
13
|
+
"files": [
|
|
14
|
+
"dist/**",
|
|
15
|
+
"skills/**",
|
|
16
|
+
"knowledge/**",
|
|
17
|
+
"README.md",
|
|
18
|
+
"LICENSE"
|
|
19
|
+
],
|
|
20
|
+
"publishConfig": {
|
|
21
|
+
"access": "public"
|
|
22
|
+
},
|
|
23
|
+
"engines": {
|
|
24
|
+
"node": ">=20.10"
|
|
25
|
+
},
|
|
26
|
+
"scripts": {
|
|
27
|
+
"clean": "rm -rf dist coverage",
|
|
28
|
+
"typecheck": "tsc --noEmit",
|
|
29
|
+
"build": "npm run clean && npm run typecheck && node scripts/build.mjs",
|
|
30
|
+
"test": "npm run test:unit",
|
|
31
|
+
"test:unit": "vitest run"
|
|
32
|
+
},
|
|
33
|
+
"dependencies": {
|
|
34
|
+
"better-sqlite3": "^12.0.0"
|
|
35
|
+
},
|
|
36
|
+
"devDependencies": {
|
|
37
|
+
"@types/better-sqlite3": "^7.6.12",
|
|
38
|
+
"@types/node": "^22.15.3",
|
|
39
|
+
"commander": "^14.0.0",
|
|
40
|
+
"esbuild": "^0.25.3",
|
|
41
|
+
"gray-matter": "^4.0.3",
|
|
42
|
+
"marked": "^15.0.12",
|
|
43
|
+
"typescript": "^5.8.3",
|
|
44
|
+
"vitest": "^3.1.2"
|
|
45
|
+
}
|
|
46
|
+
}
|
|
@@ -0,0 +1,252 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: company-agent-wiki-cli
|
|
3
|
+
description: Use when an agent must set up, onboard, verify, index, search or browse a private local company knowledge workspace that uses Markdown as truth, SQLite as derived index and Git for history. Covers first-run setup, company-profile questioning, root registration, stale-index checks, read-only web browsing, document history and diff workflows.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Company Agent Wiki CLI
|
|
7
|
+
|
|
8
|
+
Use this skill when the task is about a private company knowledge workspace built around:
|
|
9
|
+
|
|
10
|
+
- local Markdown roots
|
|
11
|
+
- a rebuildable SQLite index
|
|
12
|
+
- Git-backed history
|
|
13
|
+
- a read-only local browsing view
|
|
14
|
+
|
|
15
|
+
## Preconditions
|
|
16
|
+
|
|
17
|
+
- The public CLI binary is `company-agent-wiki-cli`.
|
|
18
|
+
- The actual company knowledge workspace is private and lives outside the public code repository.
|
|
19
|
+
- The private workspace may be the current dedicated local folder; it just must not be the public skill/CLI repo.
|
|
20
|
+
- The human should provide the workspace path and, if desired, the private Git remote URL. If the current folder is already inside a private workspace, the CLI may detect it automatically.
|
|
21
|
+
- Runtime discovery matters. Before relying on the CLI, verify which path is actually available.
|
|
22
|
+
- In Codex, the most reliable fallback is usually the installed shim under `$CODEX_HOME/bin` or `~/.codex/bin`.
|
|
23
|
+
- The `npx -p @codecell-germany/company-agent-wiki-skill ...` path only works after the npm package is really published.
|
|
24
|
+
- `node dist/index.js` only works inside the public implementation repo after `npm run build`, not inside an arbitrary private workspace.
|
|
25
|
+
- If the binary is not already installed in PATH, use these fallbacks in this order:
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
"$CODEX_HOME/bin/company-agent-wiki-cli" --help
|
|
29
|
+
"$HOME/.codex/bin/company-agent-wiki-cli" --help
|
|
30
|
+
npx -p @codecell-germany/company-agent-wiki-skill company-agent-wiki-cli --help
|
|
31
|
+
node dist/index.js --help
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## First Run
|
|
35
|
+
|
|
36
|
+
1. In Codex, start with the explicit shim paths:
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
"$CODEX_HOME/bin/company-agent-wiki-cli" --help
|
|
40
|
+
"$HOME/.codex/bin/company-agent-wiki-cli" --help
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
If that fails, try the PATH binary as a convenience fallback:
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
company-agent-wiki-cli --help
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Only if the package is already published should you rely on:
|
|
50
|
+
|
|
51
|
+
```bash
|
|
52
|
+
npx -p @codecell-germany/company-agent-wiki-skill company-agent-wiki-cli --help
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
2. If no private workspace exists yet, create one:
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
company-agent-wiki-cli setup workspace --workspace /absolute/path/to/private-company-knowledge --git-init
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
This creates starter Markdown documents by default. Use `--no-starter-docs` only when you explicitly want a nearly empty workspace.
|
|
62
|
+
|
|
63
|
+
3. Run health checks:
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
company-agent-wiki-cli doctor --workspace /absolute/path/to/private-company-knowledge --json
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
4. Build the index:
|
|
70
|
+
|
|
71
|
+
```bash
|
|
72
|
+
company-agent-wiki-cli index rebuild --workspace /absolute/path/to/private-company-knowledge --json
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
5. Only then use `search`, `route`, `read`, `history`, `diff` or `serve`.
|
|
76
|
+
|
|
77
|
+
If a human expects a browser view, you must explicitly start it with:
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
company-agent-wiki-cli serve --workspace /absolute/path/to/private-company-knowledge --port 4187
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
The web view is provided by the installed CLI. The private workspace itself is not a frontend repo.
|
|
84
|
+
|
|
85
|
+
If the authoring loop is noisy, prefer the auto-rebuild variants:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
company-agent-wiki-cli search "KI-Telefonassistent" --workspace /absolute/path --auto-rebuild --json
|
|
89
|
+
company-agent-wiki-cli route "Eingangsrechnung AWS" --workspace /absolute/path --auto-rebuild --json
|
|
90
|
+
company-agent-wiki-cli read --doc-id canonical.company-profile --workspace /absolute/path --metadata --headings --auto-rebuild --json
|
|
91
|
+
company-agent-wiki-cli read --doc-id canonical.company-profile --workspace /absolute/path --auto-rebuild
|
|
92
|
+
company-agent-wiki-cli serve --workspace /absolute/path --port 4187 --auto-rebuild
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
## Retrieval-Prozess Für Agenten
|
|
96
|
+
|
|
97
|
+
Der empfohlene Lesepfad ist jetzt explizit metadata-first:
|
|
98
|
+
|
|
99
|
+
1. Zuerst mit `search` oder `route` Kandidaten finden.
|
|
100
|
+
2. Wenn möglich direkt mit Front-Matter-Filtern eingrenzen, zum Beispiel `--type`, `--project`, `--department`, `--tag`, `--owner` oder `--system`.
|
|
101
|
+
3. Danach Kandidaten mit `read --metadata --headings --auto-rebuild` prüfen.
|
|
102
|
+
4. Erst wenn Metadaten, Dateiname und Überschriften passen, den Volltext mit `read --auto-rebuild` laden.
|
|
103
|
+
|
|
104
|
+
Beispiel:
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
company-agent-wiki-cli route "Projekt Alpha Budget" --workspace /absolute/path --type project --project alpha --auto-rebuild --json
|
|
108
|
+
company-agent-wiki-cli read --workspace /absolute/path --doc-id canonical.projekt-alpha-roadmap --metadata --headings --auto-rebuild --json
|
|
109
|
+
company-agent-wiki-cli read --workspace /absolute/path --doc-id canonical.projekt-alpha-roadmap --auto-rebuild
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
## Anlageprozess Für Neues Wissen
|
|
113
|
+
|
|
114
|
+
Wenn ein Agent neues Wissen anlegt, soll er nicht mit beliebigen Dateinamen oder leerem Front Matter arbeiten.
|
|
115
|
+
|
|
116
|
+
Pflichtgedanke:
|
|
117
|
+
|
|
118
|
+
1. sprechender Dateiname
|
|
119
|
+
2. klares Front Matter
|
|
120
|
+
3. gute Abschnittsstruktur
|
|
121
|
+
4. danach Index aktualisieren
|
|
122
|
+
|
|
123
|
+
Empfohlenes Minimal-Front-Matter:
|
|
124
|
+
|
|
125
|
+
```yaml
|
|
126
|
+
---
|
|
127
|
+
id: projects.alpha.roadmap
|
|
128
|
+
title: Projekt Alpha Roadmap
|
|
129
|
+
type: project
|
|
130
|
+
status: draft
|
|
131
|
+
tags:
|
|
132
|
+
- projekt
|
|
133
|
+
- alpha
|
|
134
|
+
summary: Roadmap und Entscheidungen für Projekt Alpha.
|
|
135
|
+
project: alpha
|
|
136
|
+
department: entwicklung
|
|
137
|
+
owners:
|
|
138
|
+
- nikolas-gottschol
|
|
139
|
+
systems:
|
|
140
|
+
- linear
|
|
141
|
+
---
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
`id` ist jetzt klar empfohlen. Es ist technisch noch nicht in jedem Dokument Pflicht, aber für neues Wissen solltest du eine stabile manuelle ID setzen, damit spätere Referenzen, History und Routing nicht am Dateinamen hängen.
|
|
145
|
+
|
|
146
|
+
Empfohlener Ablauf:
|
|
147
|
+
|
|
148
|
+
1. Datei unter `knowledge/canonical/` oder einem anderen registrierten Managed Root anlegen.
|
|
149
|
+
2. Dateiname so wählen, dass er den Inhalt grob repräsentiert, etwa `projekt-alpha-roadmap.md`.
|
|
150
|
+
3. Front Matter inklusive `id`, `summary` und passenden Routing-Feldern setzen.
|
|
151
|
+
4. Wenn der Inhalt auf externer Recherche basiert, Provenienz ergänzen:
|
|
152
|
+
- Quellenstand oder Prüfdokumentation im Dokument
|
|
153
|
+
- Datum der Prüfung
|
|
154
|
+
- Quelle oder URL
|
|
155
|
+
- kurze Einordnung, ob Primärquelle, Sekundärquelle oder Nutzerangabe
|
|
156
|
+
5. Inhalt in sinnvolle `#`, `##`, `###`-Abschnitte gliedern.
|
|
157
|
+
6. `company-agent-wiki-cli index rebuild --workspace /absolute/path --json` ausführen oder einen `--auto-rebuild`-Pfad nutzen.
|
|
158
|
+
7. Mit `read --metadata --headings --auto-rebuild` prüfen, ob das Dokument für spätere Agenten sauber routbar ist.
|
|
159
|
+
8. Navigation und Einstiegspunkte aktualisieren, wenn das Dokument strukturell wichtig ist:
|
|
160
|
+
- Startseite
|
|
161
|
+
- thematische README
|
|
162
|
+
- Prozess- oder Projektübersicht
|
|
163
|
+
|
|
164
|
+
## Bestehendes Wissen Erweitern
|
|
165
|
+
|
|
166
|
+
Nicht jeder Wissenszuwachs braucht ein neues Dokument.
|
|
167
|
+
|
|
168
|
+
Wenn bereits eine passende Seite existiert:
|
|
169
|
+
|
|
170
|
+
1. erst mit `route` oder `search` plus Filtern prüfen, ob das Wissen schon einen guten Zielort hat
|
|
171
|
+
2. mit `read --metadata --headings --auto-rebuild` die bestehende Struktur ansehen
|
|
172
|
+
3. nur dann erweitern, wenn Thema, Typ und Zielgruppe wirklich passen
|
|
173
|
+
4. sonst ein neues Dokument anlegen und die bestehende Navigation verlinken
|
|
174
|
+
|
|
175
|
+
Faustregel:
|
|
176
|
+
|
|
177
|
+
- neuer Prozess oder neues Themencluster: neues Dokument
|
|
178
|
+
- zusätzliche Ausnahme, Ergänzung oder Quellenstand zu bestehendem Thema: bestehendes Dokument erweitern
|
|
179
|
+
|
|
180
|
+
## Muster Für Beziehungswissen
|
|
181
|
+
|
|
182
|
+
Für Partner-, Netzwerk- oder CRM-Wissen ist dieses Muster sinnvoll:
|
|
183
|
+
|
|
184
|
+
```yaml
|
|
185
|
+
---
|
|
186
|
+
id: crm.partner.beispiel-partner
|
|
187
|
+
title: Beispiel Partner
|
|
188
|
+
type: relationship
|
|
189
|
+
status: draft
|
|
190
|
+
tags:
|
|
191
|
+
- crm
|
|
192
|
+
- partner
|
|
193
|
+
- netzwerk
|
|
194
|
+
summary: Rolle, Status und Relevanz des Partners im CodeCell-Netzwerk.
|
|
195
|
+
department: vertrieb
|
|
196
|
+
owners:
|
|
197
|
+
- nikolas-gottschol
|
|
198
|
+
---
|
|
199
|
+
```
|
|
200
|
+
|
|
201
|
+
Im Dokument selbst:
|
|
202
|
+
|
|
203
|
+
- Rolle: Partner, Netzwerkpartner, potenzieller Kunde, bestätigter Kunde
|
|
204
|
+
- Beziehung: Seit wann, über wen, in welchem Kontext
|
|
205
|
+
- Relevanz: strategisch, operativ, vertrieblich, technisch
|
|
206
|
+
- Aktueller Stand: offen, aktiv, pausiert, abgeschlossen
|
|
207
|
+
- Nächste Schritte
|
|
208
|
+
- Quellenstand
|
|
209
|
+
|
|
210
|
+
If the company profile itself is still unclear, run the onboarding questionnaire before deep indexing work:
|
|
211
|
+
|
|
212
|
+
```bash
|
|
213
|
+
company-agent-wiki-cli onboarding company
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
If the agent already has structured answers, preview or apply the generated draft onboarding documents:
|
|
217
|
+
|
|
218
|
+
```bash
|
|
219
|
+
company-agent-wiki-cli onboarding company \
|
|
220
|
+
--workspace /absolute/path/to/private-company-knowledge \
|
|
221
|
+
--answers-file /absolute/path/to/company-onboarding-answers.json
|
|
222
|
+
company-agent-wiki-cli onboarding company \
|
|
223
|
+
--workspace /absolute/path/to/private-company-knowledge \
|
|
224
|
+
--answers-file /absolute/path/to/company-onboarding-answers.json \
|
|
225
|
+
--execute
|
|
226
|
+
```
|
|
227
|
+
|
|
228
|
+
`--execute` requires `--answers-file`, and `--force` only works together with `--execute`.
|
|
229
|
+
|
|
230
|
+
## Operating Rules
|
|
231
|
+
|
|
232
|
+
- Treat Markdown files as the source of truth.
|
|
233
|
+
- Treat SQLite as derived and rebuildable.
|
|
234
|
+
- The local SQLite file lives in the workspace, but should stay out of Git by default.
|
|
235
|
+
- If the CLI reports `INDEX_STALE`, do not ignore it. Run `index rebuild` or use an explicit `--auto-rebuild` path.
|
|
236
|
+
- For agent workflows, prefer `--auto-rebuild` on `search`, `route`, `read` and `serve` unless you explicitly want strict stale-index failures.
|
|
237
|
+
- Avoid parallel `search`, `route`, `read`, `history` and `diff` calls against the same workspace when possible. SQLite contention is now surfaced clearly, but agent-side serialization is still the safer Phase-1 pattern.
|
|
238
|
+
- Do not put private company knowledge into the public code repository.
|
|
239
|
+
- Use the read-only web view only for browsing, not editing.
|
|
240
|
+
- The company onboarding questionnaire is optional. Every answer may be skipped, answered with “nein” or marked as unknown.
|
|
241
|
+
- Onboarding writes are explicit. Do not assume preview mode changes files; only `--execute` writes draft onboarding Markdown and rebuilds the derived index.
|
|
242
|
+
- If CLI discovery fails, do not pretend the documented command works. First resolve a real executable path.
|
|
243
|
+
- If the current folder already contains `.company-agent-wiki/workspace.json`, you may omit `--workspace` and let the CLI detect the workspace root automatically.
|
|
244
|
+
|
|
245
|
+
## References
|
|
246
|
+
|
|
247
|
+
- Overview: [references/overview.md](references/overview.md)
|
|
248
|
+
- Agent onboarding: [references/agent-onboarding.md](references/agent-onboarding.md)
|
|
249
|
+
- Authoring workflow: [references/authoring-workflow.md](references/authoring-workflow.md)
|
|
250
|
+
- Command cheatsheet: [references/command-cheatsheet.md](references/command-cheatsheet.md)
|
|
251
|
+
- Workspace setup details: [references/workspace-first-run.md](references/workspace-first-run.md)
|
|
252
|
+
- Company onboarding questions: [references/company-onboarding.md](references/company-onboarding.md)
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Agent Onboarding
|
|
2
|
+
|
|
3
|
+
## Use This Sequence
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
"$CODEX_HOME/bin/company-agent-wiki-cli" --help
|
|
7
|
+
"$HOME/.codex/bin/company-agent-wiki-cli" --help
|
|
8
|
+
company-agent-wiki-cli --help
|
|
9
|
+
company-agent-wiki-cli setup workspace --workspace /absolute/path --git-init
|
|
10
|
+
company-agent-wiki-cli onboarding company
|
|
11
|
+
company-agent-wiki-cli onboarding company --workspace /absolute/path --answers-file /absolute/path/to/answers.json
|
|
12
|
+
company-agent-wiki-cli onboarding company --workspace /absolute/path --answers-file /absolute/path/to/answers.json --execute
|
|
13
|
+
company-agent-wiki-cli doctor --workspace /absolute/path --json
|
|
14
|
+
company-agent-wiki-cli index rebuild --workspace /absolute/path --json
|
|
15
|
+
company-agent-wiki-cli verify --workspace /absolute/path --json
|
|
16
|
+
company-agent-wiki-cli serve --workspace /absolute/path --port 4187 --auto-rebuild
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Only after the company profile is clear enough and these checks succeed should you search or browse deeply.
|
|
20
|
+
|
|
21
|
+
## If the Workspace Does Not Exist Yet
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
company-agent-wiki-cli setup workspace --workspace /absolute/path --git-init
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
If the human has a private Git remote ready:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
company-agent-wiki-cli setup workspace \
|
|
31
|
+
--workspace /absolute/path \
|
|
32
|
+
--git-init \
|
|
33
|
+
--git-remote git@github.com:your-org/private-company-knowledge.git
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## If `INDEX_STALE` Appears
|
|
37
|
+
|
|
38
|
+
Run:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
company-agent-wiki-cli index rebuild --workspace /absolute/path --json
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Do not continue with stale results.
|
|
45
|
+
|
|
46
|
+
For frequent edits, the authoring loop can also use the guarded auto-rebuild path:
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
company-agent-wiki-cli search "KI-Telefonassistent" --workspace /absolute/path --auto-rebuild --json
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
After candidate routing, prefer metadata-first reading:
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
company-agent-wiki-cli read --workspace /absolute/path --doc-id canonical.projekt-alpha-roadmap --metadata --headings --auto-rebuild --json
|
|
56
|
+
company-agent-wiki-cli read --workspace /absolute/path --doc-id canonical.projekt-alpha-roadmap --auto-rebuild
|
|
57
|
+
```
|