skillwiki 0.2.1-beta.2 → 0.2.1-beta.21
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/dist/chunk-TPS5XD2J.js +19 -0
- package/dist/cli.js +3654 -350
- package/dist/git-M4WGJ5G3.js +9 -0
- package/package.json +3 -2
- package/skills/.claude-plugin/plugin.json +2 -3
- package/skills/package.json +1 -2
- package/skills/proj-decide/SKILL.md +1 -0
- package/skills/proj-distill/SKILL.md +1 -0
- package/skills/proj-init/SKILL.md +2 -1
- package/skills/proj-work/SKILL.md +1 -0
- package/skills/using-skillwiki/SKILL.md +24 -5
- package/skills/wiki-adapter-prd/SKILL.md +1 -0
- package/skills/wiki-add-task/SKILL.md +119 -0
- package/skills/wiki-archive/SKILL.md +1 -0
- package/skills/wiki-audit/SKILL.md +1 -0
- package/skills/wiki-canvas/SKILL.md +57 -0
- package/skills/wiki-crystallize/SKILL.md +1 -0
- package/skills/wiki-ingest/SKILL.md +1 -0
- package/skills/wiki-init/SKILL.md +1 -0
- package/skills/wiki-lint/SKILL.md +1 -0
- package/skills/wiki-query/SKILL.md +1 -0
- package/skills/wiki-reingest/SKILL.md +1 -0
- package/skills/wiki-sync/SKILL.md +91 -0
- package/templates/index.md +3 -0
- package/templates/project-README.md +6 -0
package/package.json
CHANGED
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "skillwiki",
|
|
3
|
-
"version": "0.2.1-beta.
|
|
4
|
-
"version": "0.2.1-beta.2",
|
|
3
|
+
"version": "0.2.1-beta.21",
|
|
5
4
|
"type": "module",
|
|
6
5
|
"bin": {
|
|
7
6
|
"skillwiki": "dist/cli.js"
|
|
@@ -20,6 +19,8 @@
|
|
|
20
19
|
"prepublishOnly": "npm run build"
|
|
21
20
|
},
|
|
22
21
|
"dependencies": {
|
|
22
|
+
"@aws-sdk/client-s3": "^3.1045.0",
|
|
23
|
+
"@aws-sdk/credential-provider-env": "^3.972.34",
|
|
23
24
|
"commander": "^12.1.0",
|
|
24
25
|
"js-yaml": "^4.1.0",
|
|
25
26
|
"zod": "^3.23.0"
|
|
@@ -1,9 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "skillwiki",
|
|
3
|
-
"version": "0.2.1-beta.
|
|
4
|
-
"version": "0.2.1-beta.2",
|
|
3
|
+
"version": "0.2.1-beta.21",
|
|
5
4
|
"skills": "./",
|
|
6
|
-
"description": "Project-aware Karpathy-style knowledge base for Claude Code:
|
|
5
|
+
"description": "Project-aware Karpathy-style knowledge base for Claude Code: 17 prompt-only skills (wiki-*, proj-*, using-skillwiki) backed by the deterministic `skillwiki` CLI.",
|
|
7
6
|
"author": {
|
|
8
7
|
"name": "karlorz",
|
|
9
8
|
"url": "https://github.com/karlorz"
|
package/skills/package.json
CHANGED
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
+
version: 0.2.1
|
|
2
3
|
name: proj-init
|
|
3
4
|
description: Bootstrap a project workspace at projects/{slug}/ with README, requirements/, architecture/, work/, compound/.
|
|
4
5
|
---
|
|
@@ -18,7 +19,7 @@ Standard four reads (vault SCHEMA, index, log) — no project context yet.
|
|
|
18
19
|
## Steps
|
|
19
20
|
1. Verify `projects/{slug}/` does not exist.
|
|
20
21
|
2. Create folders: `projects/{slug}/{requirements,architecture,work,compound}/`.
|
|
21
|
-
3. Render `projects/{slug}/README.md` from `project-README.md` template, filling `{{slug}}` and `{{date}}`.
|
|
22
|
+
3. Render `projects/{slug}/README.md` from `project-README.md` template, filling `{{slug}}` and `{{date}}`. The template includes a `## Knowledge Pages` section with a placeholder; agents populate it on first ingest via `skillwiki project-index`.
|
|
22
23
|
4. Update vault `index.md` "Projects" section: add `- [[projects/{slug}]]`.
|
|
23
24
|
5. Append vault `log.md` entry: "Project {slug} initialized."
|
|
24
25
|
|
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
+
version: 0.2.1
|
|
2
3
|
name: using-skillwiki
|
|
3
4
|
description: Invoke at session start or when knowledge-base tasks arise — maps all wiki-*/proj-* skills and teaches the skillwiki CLI workflow
|
|
4
5
|
---
|
|
@@ -20,22 +21,25 @@ Invoke a skillwiki skill when the user:
|
|
|
20
21
|
- Wants a health check or lint on their vault
|
|
21
22
|
- Mentions crystallizing a session into a note
|
|
22
23
|
- Talks about project workspaces, ADRs, or distillation
|
|
24
|
+
- Wants to quickly capture an idea, bug, task, or note without interrupting their workflow
|
|
23
25
|
- Wants to archive or clean up old vault pages
|
|
24
26
|
- Needs to detect source drift or re-ingest updated content
|
|
25
27
|
- Has a spec/plan in a non-skillwiki format (CodeStable, RFC, AIDE)
|
|
26
28
|
- Asks about their skillwiki configuration or setup health
|
|
29
|
+
- Wants to sync vault changes to/from a git remote
|
|
30
|
+
- Wants to visualize the vault graph as an Obsidian Canvas
|
|
27
31
|
|
|
28
32
|
## Vault Structure
|
|
29
33
|
|
|
30
|
-
A skillwiki vault has
|
|
34
|
+
A skillwiki vault has three layers. The canonical architecture lives in `SCHEMA.md` at the vault root — read it before creating any new directories.
|
|
31
35
|
|
|
32
|
-
**Layer 1 — Raw (`raw/`):** Immutable source material. Never modify after ingest.
|
|
36
|
+
**Layer 1 — Raw (`raw/`):** Immutable source material. Never modify after ingest. `raw/transcripts/` doubles as the ad-hoc capture point for meeting notes and unprocessed ideas.
|
|
33
37
|
|
|
34
38
|
```
|
|
35
39
|
raw/
|
|
36
40
|
├── articles/ # Web articles, clippings
|
|
37
41
|
├── papers/ # PDFs, arxiv papers
|
|
38
|
-
├── transcripts/ # Meeting notes, interviews
|
|
42
|
+
├── transcripts/ # Meeting notes, interviews, ad-hoc captures
|
|
39
43
|
└── assets/ # Images, diagrams referenced by sources
|
|
40
44
|
```
|
|
41
45
|
|
|
@@ -48,7 +52,19 @@ sha256: # computed by skillwiki hash over body bytes after closing ---
|
|
|
48
52
|
---
|
|
49
53
|
```
|
|
50
54
|
|
|
51
|
-
**Layer 2 —
|
|
55
|
+
**Layer 2 — Typed Knowledge:** `entities/`, `concepts/`, `comparisons/`, `queries/`, `meta/`. Agent-owned pages with `^[raw/...]` citation markers at paragraph-end. Global scope — project association via `provenance_projects:` frontmatter, not directory nesting.
|
|
56
|
+
|
|
57
|
+
**Layer 3 — Project Workspaces (`projects/{slug}/`):** Per-project lifecycle directories with `work/` (spec + plan + retro), `compound/` (distilled lessons/patterns), `architecture/` (ADRs), and `history/` (archived specs/plans).
|
|
58
|
+
|
|
59
|
+
**No `inbox/` directory.** Ad-hoc captures go to `raw/transcripts/` or directly into a project work item via `proj-work`. Do not invent new top-level directories — extend Layer 2 via SCHEMA.md tag taxonomy if needed.
|
|
60
|
+
|
|
61
|
+
### Ad-hoc capture: three entry points
|
|
62
|
+
|
|
63
|
+
| Entry | When | What happens |
|
|
64
|
+
|-------|------|-------------|
|
|
65
|
+
| `/wiki-add-task <text>` | You're in a Claude session | Creates `raw/transcripts/YYYY-MM-DD-{type}-{slug}.md` with ad-hoc capture frontmatter |
|
|
66
|
+
| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create/edit any `.md` file in `raw/transcripts/` — dev-loop discovers it on next cycle |
|
|
67
|
+
| Dev-loop discovery | Automatic, next cycle | Scans `raw/transcripts/` for new files since last cycle, surfaces as claimable work |
|
|
52
68
|
|
|
53
69
|
## Skill Map
|
|
54
70
|
|
|
@@ -62,17 +78,20 @@ sha256: # computed by skillwiki hash over body bytes after closing ---
|
|
|
62
78
|
| `wiki-audit` | Verify raw provenance references and source frontmatter integrity |
|
|
63
79
|
| `wiki-archive` | Archive a typed-knowledge page — move to `_archive/`, remove from index |
|
|
64
80
|
| `wiki-reingest` | Detect drift in raw sources (sha256 comparison) and re-ingest updated content |
|
|
81
|
+
| `wiki-add-task` | Quick-capture ideas, bugs, tasks, notes into `raw/transcripts/` without leaving the current workflow |
|
|
65
82
|
| `wiki-adapter-prd` | Map foreign PRD formats (CodeStable, RFC, AIDE, Hermes) into vault pages |
|
|
66
83
|
| `proj-init` | Bootstrap a project workspace (README, requirements, architecture) |
|
|
67
84
|
| `proj-work` | Open or run a work item under a project's work/ directory |
|
|
68
85
|
| `proj-distill` | Distill project compound entries into vault concept pages |
|
|
86
|
+
| `wiki-sync` | Safely sync vault git repository — push/pull with lint guards and conflict resolution |
|
|
87
|
+
| `wiki-canvas` | Generate Obsidian Canvas visualization from vault graph data |
|
|
69
88
|
| `proj-decide` | Write an Architectural Decision Record (ADR) |
|
|
70
89
|
|
|
71
90
|
## CLI Backbone
|
|
72
91
|
|
|
73
92
|
All skills are backed by the `skillwiki` CLI — a deterministic tool with no LLM calls. It handles path resolution, config management, validation, and linting. Skills invoke it via Bash for the mechanical parts and use Claude for the creative parts.
|
|
74
93
|
|
|
75
|
-
Key CLI subcommands: `init`, `lint`, `config`, `doctor`, `path`, `lang`, `install`, `graph build`, `archive`, `drift`.
|
|
94
|
+
Key CLI subcommands: `init`, `lint`, `config`, `doctor`, `path`, `lang`, `install`, `graph build`, `archive`, `drift`, `compound`, `tag-sync`, `sync status`, `seed`, `stale`, `observe`, `canvas generate`.
|
|
76
95
|
|
|
77
96
|
Run `skillwiki doctor` to diagnose setup issues. Run `skillwiki config list` to see current configuration.
|
|
78
97
|
|
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 0.2.1
|
|
3
|
+
name: wiki-add-task
|
|
4
|
+
description: Capture ad-hoc ideas, bugs, tasks, or notes into the vault with ad-hoc capture frontmatter and descriptive filenames.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# wiki-add-task
|
|
8
|
+
|
|
9
|
+
Capture ad-hoc ideas, bugs, tasks, and notes into the vault. Three entry points depending on where you are:
|
|
10
|
+
|
|
11
|
+
| Entry | When | What happens |
|
|
12
|
+
|-------|------|-------------|
|
|
13
|
+
| `/wiki-add-task <text>` | You're in a Claude session | Creates `raw/transcripts/YYYY-MM-DD-{type}-{slug}.md` with ad-hoc capture frontmatter |
|
|
14
|
+
| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create any `.md` file in `raw/transcripts/` using the vault template — dev-loop discovers it on next cycle |
|
|
15
|
+
| Dev-loop discovery | Automatic, next cycle | Scans `raw/transcripts/` for new files since last cycle, surfaces as claimable work |
|
|
16
|
+
|
|
17
|
+
## When This Skill Activates
|
|
18
|
+
|
|
19
|
+
- User invokes `/wiki-add-task` with a description.
|
|
20
|
+
- User says "add task", "capture this", "note this", "remember this", "log this idea", or similar.
|
|
21
|
+
- User provides a short text description and optionally a type tag.
|
|
22
|
+
|
|
23
|
+
## Output language
|
|
24
|
+
|
|
25
|
+
Run `skillwiki lang` at the start. Entry prose and `--human` summaries use the resolved language. Frontmatter keys, file names, and structural markers stay English.
|
|
26
|
+
|
|
27
|
+
## Steps
|
|
28
|
+
|
|
29
|
+
0. **Resolve vault and language.** Run `skillwiki path` (fail if NO_VAULT_CONFIGURED) and `skillwiki lang`.
|
|
30
|
+
1. **Parse arguments.** Extract from the user's message:
|
|
31
|
+
- `text` — the idea/bug/task/note content (required)
|
|
32
|
+
- `type` — one of: `idea`, `bug`, `task`, `note` (default: `idea`)
|
|
33
|
+
- `project` — optional project slug to cross-reference (e.g., `llm-wiki`)
|
|
34
|
+
2. **Build filename.** Derive a slug from the first ~6 words of the text (lowercased, hyphens for spaces, non-alphanumeric stripped). The capture file is `raw/transcripts/YYYY-MM-DD-{type}-{slug}.md`. Each capture gets its own file — never append to an existing file.
|
|
35
|
+
3. **Write frontmatter.** Create the file with ad-hoc capture frontmatter:
|
|
36
|
+
```yaml
|
|
37
|
+
---
|
|
38
|
+
source_url:
|
|
39
|
+
ingested: YYYY-MM-DD
|
|
40
|
+
kind: {type}
|
|
41
|
+
project: "[[{slug}]]"
|
|
42
|
+
---
|
|
43
|
+
```
|
|
44
|
+
- Set `kind` to the parsed type (`idea`, `bug`, `task`, `note`).
|
|
45
|
+
- If a `project` slug was provided, set `project: "[[slug]]"`.
|
|
46
|
+
- If no project, omit the `project` field entirely.
|
|
47
|
+
- `source_url` is null (these are locally originated captures).
|
|
48
|
+
- No `sha256` — ad-hoc captures are mutable working notes, not immutable sources.
|
|
49
|
+
4. **Write body.** Below the frontmatter, write:
|
|
50
|
+
```markdown
|
|
51
|
+
# {type}: {text}
|
|
52
|
+
|
|
53
|
+
{text}
|
|
54
|
+
```
|
|
55
|
+
Use the resolved output language for any prose. The type label and frontmatter stay English.
|
|
56
|
+
5. **Cross-reference (optional).** If a `project` slug was provided:
|
|
57
|
+
- Check that `projects/{slug}/` exists in the vault.
|
|
58
|
+
- Append a one-line reference to the project's compound notes:
|
|
59
|
+
`- [YYYY-MM-DD] capture: [text (first 60 chars)] → raw/transcripts/YYYY-MM-DD-{type}-{slug}.md`
|
|
60
|
+
- Do NOT create a full work item (that's `proj-work`'s job).
|
|
61
|
+
6. **Update log.md.** Append: `## [YYYY-MM-DD] capture | [type]: [text (first 60 chars)]`
|
|
62
|
+
7. **Confirm to user.** Report what was captured and where. Suggest next steps:
|
|
63
|
+
- If `type: idea` → "Consider ingesting related sources to develop this idea."
|
|
64
|
+
- If `type: bug` → "Use proj-work to create a bug-fix work item."
|
|
65
|
+
- If `type: task` → "Use proj-work to track this task through the dev loop."
|
|
66
|
+
- If `type: note` → "Will be available for future wiki-query searches."
|
|
67
|
+
|
|
68
|
+
## Capture file format
|
|
69
|
+
|
|
70
|
+
Each capture is a standalone file with ad-hoc capture frontmatter:
|
|
71
|
+
|
|
72
|
+
```yaml
|
|
73
|
+
---
|
|
74
|
+
source_url:
|
|
75
|
+
ingested: 2026-05-08
|
|
76
|
+
kind: idea
|
|
77
|
+
project: "[[llm-wiki]]"
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
# idea: Fix the template mismatch
|
|
81
|
+
|
|
82
|
+
Fix the template mismatch between wiki-add-task and the vault template.
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
The `kind` field uses the capture type and must be one of: `idea`, `bug`, `task`, `note` (plus the existing `postmortem`, `session-log`, `meeting-notes`, `other` for non-capture raw sources).
|
|
86
|
+
|
|
87
|
+
The `project` and `kind` fields can be set independently — they do not require `work_item`. The `work_item` field is only used when the raw source is directly tied to a project work item (set by `proj-work`).
|
|
88
|
+
|
|
89
|
+
Ad-hoc captures omit `sha256` — they are mutable working notes, not immutable sources. The `sha256` field is reserved for ingested raw sources that require integrity verification.
|
|
90
|
+
|
|
91
|
+
## Stop conditions
|
|
92
|
+
|
|
93
|
+
- `skillwiki path` returns NO_VAULT_CONFIGURED.
|
|
94
|
+
- No `text` provided (prompt user once, then stop).
|
|
95
|
+
- Target file already exists (use a different slug or add a suffix).
|
|
96
|
+
|
|
97
|
+
## Forbidden
|
|
98
|
+
|
|
99
|
+
- Creating an `inbox/` directory. All captures go to `raw/transcripts/`.
|
|
100
|
+
- Appending to existing capture files — each capture gets its own file.
|
|
101
|
+
- Creating a work item — this is capture-only. Use `proj-work` for full work items.
|
|
102
|
+
- Writing to any Layer 2 or Layer 3 location. Captures are Layer 1 (raw).
|
|
103
|
+
|
|
104
|
+
## Filesystem drop (offline capture)
|
|
105
|
+
|
|
106
|
+
When you're not in a Claude session, drop files directly into `raw/transcripts/`:
|
|
107
|
+
|
|
108
|
+
1. Create a `.md` file in `raw/transcripts/` — name it descriptively (e.g., `2026-05-08-idea-fix-template.md`)
|
|
109
|
+
2. Use ad-hoc capture frontmatter: `source_url:`, `ingested:`, `kind:`, and optionally `project:`
|
|
110
|
+
3. Write your idea/bug/task/note below the frontmatter
|
|
111
|
+
|
|
112
|
+
No special format required — the dev-loop QUERY step will discover new files on the next cycle and surface them as claimable work. Mark the type with a heading like `## idea`, `## bug`, `## task`, or just write freeform.
|
|
113
|
+
|
|
114
|
+
## Dev-loop discovery
|
|
115
|
+
|
|
116
|
+
When the dev-loop QUERY step runs, it should scan `raw/transcripts/` for files with `ingested:` date newer than the last cycle. New files are surfaced as claimable work items. The agent then decides whether to:
|
|
117
|
+
- Create a work item via `proj-work` (for tasks and bugs)
|
|
118
|
+
- Ingest as a knowledge page via `wiki-ingest` (for ideas with sources)
|
|
119
|
+
- Leave in place (for notes that don't need action yet)
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 0.2.1
|
|
3
|
+
name: wiki-canvas
|
|
4
|
+
description: Generate an Obsidian Canvas visualization of the vault graph. Runs skillwiki graph build then skillwiki canvas generate.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# wiki-canvas
|
|
8
|
+
|
|
9
|
+
## When This Skill Activates
|
|
10
|
+
|
|
11
|
+
- User wants a visual map of their vault structure.
|
|
12
|
+
- User asks to see how pages are connected.
|
|
13
|
+
- After significant ingestion or restructuring, user wants an updated overview.
|
|
14
|
+
- User mentions Obsidian Canvas or visual vault exploration.
|
|
15
|
+
|
|
16
|
+
## Pre-orientation reads
|
|
17
|
+
|
|
18
|
+
Standard four reads (SCHEMA, index, log, project context if applicable).
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
0. Resolve vault: `skillwiki path`.
|
|
23
|
+
1. Run `skillwiki graph build <vault>` to produce the adjacency graph at `<vault>/.skillwiki/graph.json`. If graph.json already exists and the vault has not changed, this step can be skipped — but regenerate after any ingestion, reingest, archive, or restructuring to keep the canvas current.
|
|
24
|
+
2. Run `skillwiki canvas generate <vault>`. This reads graph.json and writes `<vault>/vault-graph.canvas`.
|
|
25
|
+
3. Present the result to the user: node count, edge count, and the output path.
|
|
26
|
+
4. Advise the user on opening the canvas:
|
|
27
|
+
- In Obsidian, open the vault folder and click `vault-graph.canvas` in the file explorer, or use the Quick Switcher (`Cmd/Ctrl+O`) and search for "vault-graph".
|
|
28
|
+
- Nodes are arranged in columns by type: **entities** (red), **concepts** (green), **comparisons** (orange), **queries** (cyan), **meta** (purple). Unclassified pages appear in yellow in the comparisons column.
|
|
29
|
+
- Edges represent wikilink connections. Click any node to jump to the source page; drag to rearrange.
|
|
30
|
+
- Zoom and pan with mouse/trackpad to explore large vaults.
|
|
31
|
+
5. Append one `log.md` entry noting the canvas generation (node/edge counts).
|
|
32
|
+
|
|
33
|
+
## When to regenerate
|
|
34
|
+
|
|
35
|
+
Regenerate the canvas after any of these events:
|
|
36
|
+
- One or more `wiki-ingest` runs that added new pages.
|
|
37
|
+
- `wiki-reingest` or `wiki-archive` that changed or removed pages.
|
|
38
|
+
- Manual restructuring of the vault directories.
|
|
39
|
+
- After running `wiki-lint` and fixing structural issues.
|
|
40
|
+
|
|
41
|
+
Stale canvases are not harmful, but they will not reflect new or removed pages until regenerated.
|
|
42
|
+
|
|
43
|
+
## Future: Bases view
|
|
44
|
+
|
|
45
|
+
Obsidian Bases (`.base` files) offer tabular data views of vault content. A Bases generation capability may be added in a future version to complement the graph canvas with filterable, sortable table layouts. For now, the canvas is the primary visualization.
|
|
46
|
+
|
|
47
|
+
## Stop conditions
|
|
48
|
+
|
|
49
|
+
- `skillwiki graph build` returns a non-zero exit code — investigate before continuing.
|
|
50
|
+
- `graph.json` is missing or invalid — the canvas command will surface the error; direct the user to run `skillwiki graph build` first.
|
|
51
|
+
- User cancels before generation.
|
|
52
|
+
|
|
53
|
+
## Forbidden
|
|
54
|
+
|
|
55
|
+
- Modifying `vault-graph.canvas` by hand after generation — regenerate it instead.
|
|
56
|
+
- Regenating the canvas without first regenerating graph.json when the vault has changed.
|
|
57
|
+
- Deleting the previous canvas without generating a replacement.
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 0.2.1
|
|
3
|
+
name: wiki-sync
|
|
4
|
+
description: Safely sync the vault git repository. Runs skillwiki sync status, then guides push or pull with lint guards and conflict resolution.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# wiki-sync
|
|
8
|
+
|
|
9
|
+
## When This Skill Activates
|
|
10
|
+
|
|
11
|
+
- User wants to push local vault changes to the remote.
|
|
12
|
+
- User wants to pull remote changes into their local vault.
|
|
13
|
+
- User asks about vault sync status, git state, or multi-device coordination.
|
|
14
|
+
- Periodic maintenance before or after editing sessions.
|
|
15
|
+
|
|
16
|
+
## Pre-orientation reads
|
|
17
|
+
|
|
18
|
+
Standard four reads.
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
0. Resolve vault: `skillwiki path` (record source for context).
|
|
23
|
+
1. Run `skillwiki sync status <vault>`. Read the JSON output.
|
|
24
|
+
- Exit code 0: vault is clean (nothing to sync).
|
|
25
|
+
- Exit code 22: warnings — dirty/ahead/behind (needs action).
|
|
26
|
+
2. Present the current state: `status`, `dirty`, `ahead`, `behind`, `last_commit`.
|
|
27
|
+
3. Ask the user which operation they want: **push**, **pull**, or **both** (pull then push).
|
|
28
|
+
|
|
29
|
+
### Push workflow
|
|
30
|
+
|
|
31
|
+
4. If vault is dirty, ask the user to review uncommitted changes before proceeding.
|
|
32
|
+
5. Run `skillwiki lint <vault>`. If errors exist, stop and report — do not push lint errors to remote.
|
|
33
|
+
6. If lint passes (errors = 0), stage and commit:
|
|
34
|
+
- `git -C <vault> add -A`
|
|
35
|
+
- `git -C <vault> commit -m "sync: vault update $(date -u +%Y-%m-%dT%H:%MZ)"`
|
|
36
|
+
7. Run `git -C <vault> push origin HEAD`. Report result.
|
|
37
|
+
8. Append one `log.md` entry summarizing: files pushed, lint result, commit hash.
|
|
38
|
+
|
|
39
|
+
### Pull workflow
|
|
40
|
+
|
|
41
|
+
9. If vault is dirty, stash first: `git -C <vault> stash push -m "auto-stash before pull $(date -u +%Y-%m-%dT%H:%MZ)"`.
|
|
42
|
+
10. Run `git -C <vault> pull --rebase origin HEAD`. Report result.
|
|
43
|
+
11. If a stash was created, pop it: `git -C <vault> stash pop`.
|
|
44
|
+
12. If conflicts occur during stash pop, identify them and present to the user for resolution (see Conflict Resolution below).
|
|
45
|
+
13. Run `skillwiki lint <vault>` after pull to verify vault integrity.
|
|
46
|
+
14. Append one `log.md` entry summarizing: commits pulled, lint result, any conflicts.
|
|
47
|
+
|
|
48
|
+
### Pull-then-push workflow
|
|
49
|
+
|
|
50
|
+
15. Execute the pull workflow (steps 9-13) first.
|
|
51
|
+
16. Then execute the push workflow (steps 4-8).
|
|
52
|
+
|
|
53
|
+
## Conflict Resolution
|
|
54
|
+
|
|
55
|
+
When merge conflicts are detected:
|
|
56
|
+
|
|
57
|
+
- **Frontmatter conflicts:**
|
|
58
|
+
- For `updated:` fields: always take the newer timestamp (compare both sides, keep the later one).
|
|
59
|
+
- For all other frontmatter fields: present both versions to the user and ask which to keep.
|
|
60
|
+
- **Body conflicts:**
|
|
61
|
+
- Do not auto-resolve body conflicts.
|
|
62
|
+
- Mark unresolved regions with `???` on a line by itself between the conflicting versions, so the user can see both sides and decide.
|
|
63
|
+
- Example:
|
|
64
|
+
```
|
|
65
|
+
Content from local version
|
|
66
|
+
???
|
|
67
|
+
Content from remote version
|
|
68
|
+
```
|
|
69
|
+
- After resolving conflicts, run `skillwiki lint <vault>` to verify before committing.
|
|
70
|
+
|
|
71
|
+
## Multi-device coordination
|
|
72
|
+
|
|
73
|
+
When the user mentions editing from Obsidian desktop and Claude Code on a server (or any two-device setup):
|
|
74
|
+
|
|
75
|
+
- Recommend pulling before every editing session on each device.
|
|
76
|
+
- Recommend pushing after every editing session on each device.
|
|
77
|
+
- If both devices edit the same page between syncs, conflicts are inevitable — the Conflict Resolution section handles this.
|
|
78
|
+
- Suggest enabling auto-commit in Obsidian (Community Plugins: `obsidian-git`) to reduce dirty-state drift.
|
|
79
|
+
|
|
80
|
+
## Stop conditions
|
|
81
|
+
|
|
82
|
+
- `skillwiki sync status` reports `not_a_repo` — the vault is not a git repository. Advise the user to initialize one.
|
|
83
|
+
- Lint errors are found before a push — do not push until resolved.
|
|
84
|
+
- `git push` or `git pull` fails with a network error — report and stop.
|
|
85
|
+
|
|
86
|
+
## Forbidden
|
|
87
|
+
|
|
88
|
+
- Pushing when lint errors exist.
|
|
89
|
+
- Auto-resolving body conflicts without user review.
|
|
90
|
+
- Force-pushing (`git push --force`).
|
|
91
|
+
- Modifying files in `raw/` to resolve conflicts (N9 — archive and re-ingest instead).
|
package/templates/index.md
CHANGED
|
@@ -12,3 +12,9 @@
|
|
|
12
12
|
- `architecture/` — how it's designed (incl. ADRs).
|
|
13
13
|
- `work/YYYY-MM-DD-{slug}/` — per-work-item folders containing `spec.md`, `plan.md`, `log.md`.
|
|
14
14
|
- `compound/` — project-local concrete learnings.
|
|
15
|
+
|
|
16
|
+
## Knowledge Pages
|
|
17
|
+
|
|
18
|
+
> Auto-populated: concept and entity pages with `provenance_projects: [[{{slug}}]]` are listed here.
|
|
19
|
+
|
|
20
|
+
Run `skillwiki project-index {{slug}} --apply` to generate `knowledge.md` listing all Layer 2 pages that reference `[[{{slug}}]]` in their provenance_projects.
|