okf-cli 0.4.1__tar.gz → 0.4.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {okf_cli-0.4.1 → okf_cli-0.4.3}/PKG-INFO +1 -1
- {okf_cli-0.4.1 → okf_cli-0.4.3}/pyproject.toml +1 -1
- okf_cli-0.4.3/skills/writing-knowledge-base/SKILL.md +61 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/commands/bundle.py +13 -3
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/cli/test_bundle.py +31 -7
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/e2e/test_e2e.py +10 -3
- okf_cli-0.4.1/skills/writing-knowledge-base/SKILL.md +0 -127
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/README.md +0 -12
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/datasets/sales.md +0 -7
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/domain.md +0 -6
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/loose/deep/no-heading.md +0 -4
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/loose/no-desc.md +0 -6
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/loose/no-title.md +0 -5
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/playbooks/incident-response.md +0 -14
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/playbooks/oncall-guide.md +0 -13
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/tables/customers.md +0 -16
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/tables/orders.md +0 -16
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/tables/partitions/2026/q1/jan/january.md +0 -5
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/tables/partitions/daily.md +0 -12
- okf_cli-0.4.1/skills/writing-knowledge-base/reference/knowledge-base.md +0 -65
- {okf_cli-0.4.1 → okf_cli-0.4.3}/.github/workflows/test.yml +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/.gitignore +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/.last-update.json +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/AGENTS.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/LICENSE +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/OKF_SPEC.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/README.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/.okfignore +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/README.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/datasets/sales.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/domain.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/loose/deep/no-heading.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/loose/no-desc.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/loose/no-title.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/playbooks/incident-response.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/playbooks/oncall-guide.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/smoke-ignore.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/tables/customers.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/tables/orders.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/tables/partitions/2026/q1/jan/january.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/example/tables/partitions/daily.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/architecture.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/domain-model.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/operations.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/quickstart.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/testing.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/openwiki/workflows.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/skills/okf-cli-manual/SKILL.md +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/__init__.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/cli.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/commands/__init__.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/commands/list.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/commands/show.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/commands/validate.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/src/okf/core.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/cli/test_list.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/cli/test_show.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/cli/test_validate.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/tests/test_core.py +0 -0
- {okf_cli-0.4.1 → okf_cli-0.4.3}/uv.lock +0 -0
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: writing-knowledge-base
|
|
3
|
+
description: Turn user provided content on any topic into a plain Markdown knowledge base. Invoked as /writing-knowledge-base with content to convert.
|
|
4
|
+
license: MIT
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Knowledge Base Construction
|
|
8
|
+
|
|
9
|
+
Convert the user's content directly into a structured Markdown knowledge base. Don't ask clarifying questions unless the content is genuinely unusable (e.g. empty or unintelligible) — infer structure, terminology, and grouping from what's given, and note any gaps inline rather than blocking on them.
|
|
10
|
+
|
|
11
|
+
## Workflow
|
|
12
|
+
|
|
13
|
+
1. Read the content and split it into coherent concepts (one idea per file — prefer several small linked files over one large one).
|
|
14
|
+
1. Create new directory with a name relative to the content user provide (e.g. `italian-food`, `turbocharge`, `formula-one`, etc. ).
|
|
15
|
+
1. Group concepts into type directories that fit the material's own structure. Let the content dictate the categories — e.g. `recipes/`, `policies/`, `species/`, `procedures/`, `terms/`, `people/`, `events/` — whatever natural groupings emerge. Don't force a data/tech taxonomy onto non-technical content.
|
|
16
|
+
1. Write each file using the format below, preserving the user's own terminology and facts. Never invent details, numbers, names, or steps that weren't given.
|
|
17
|
+
1. Add relative Markdown links between related concepts.
|
|
18
|
+
1. Save all files under an input directory your just created.
|
|
19
|
+
|
|
20
|
+
## Example file tree
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
cooking/
|
|
24
|
+
recipes/
|
|
25
|
+
italian/
|
|
26
|
+
lasagna.md
|
|
27
|
+
carbonara.md
|
|
28
|
+
japanese/
|
|
29
|
+
ramen.md
|
|
30
|
+
sushi.md
|
|
31
|
+
techniques/
|
|
32
|
+
knife-skills.md
|
|
33
|
+
emulsion.md
|
|
34
|
+
ingredients/
|
|
35
|
+
eggs.md
|
|
36
|
+
flour-types.md
|
|
37
|
+
faq.md
|
|
38
|
+
common-mistake.md
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
- Root files (e.g. `faq.md`) are allowed
|
|
42
|
+
- File can be nested as deep as necessary and semantically sound.
|
|
43
|
+
|
|
44
|
+
## File format
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
# Clear Concept Title
|
|
48
|
+
|
|
49
|
+
> One-sentence factual summary.
|
|
50
|
+
|
|
51
|
+
Body: context, details, steps, examples, caveats — whatever fits the concept.
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
- First line `# Title`, then a `>` description, then body detail.
|
|
55
|
+
- Use headings, lists, tables, or code blocks as they help retrieval — not all concepts need all of these.
|
|
56
|
+
- One concept per file. Directory name per type (e.g. `recipes/lasagna.md` → type `recipes`).
|
|
57
|
+
- Lowercase, stable filenames, no spaces.
|
|
58
|
+
- No `index.md`, `log.md`, `README.md` as concepts — bundler reserves these.
|
|
59
|
+
- No YAML frontmatter in source files
|
|
60
|
+
|
|
61
|
+
Do not fabricate any information on your own, use only what user provided to you.
|
|
@@ -106,6 +106,13 @@ def bundle(
|
|
|
106
106
|
typer.echo(f"Error: input directory '{input_dir}' not found", err=True)
|
|
107
107
|
raise typer.Exit(code=1)
|
|
108
108
|
|
|
109
|
+
if src.resolve() == dst.resolve():
|
|
110
|
+
typer.echo(
|
|
111
|
+
"Error: input and output directories must be different",
|
|
112
|
+
err=True,
|
|
113
|
+
)
|
|
114
|
+
raise typer.Exit(code=1)
|
|
115
|
+
|
|
109
116
|
if dst.exists():
|
|
110
117
|
if not force:
|
|
111
118
|
typer.echo(
|
|
@@ -297,11 +304,14 @@ def bundle(
|
|
|
297
304
|
f"# Knowledge Base: {dst.name}\n\n"
|
|
298
305
|
f"You are in an OKF knowledge base called **{dst.name}**.\n\n"
|
|
299
306
|
"## Getting Started\n\n"
|
|
300
|
-
"Read [index.md](index.md) first — it lists all concepts
|
|
307
|
+
"Read [index.md](index.md) first — it lists all concepts "
|
|
308
|
+
"and subdirectories.\n\n"
|
|
301
309
|
"## Navigation\n\n"
|
|
302
310
|
"- Follow markdown links between concepts.\n"
|
|
303
|
-
"- Each `.md` file has YAML frontmatter with `type`, `title`,
|
|
311
|
+
"- Each `.md` file has YAML frontmatter with `type`, `title`, "
|
|
312
|
+
"`description`.\n"
|
|
304
313
|
"- Subdirectories group related concepts by topic.\n"
|
|
305
|
-
"- Cross-links (e.g. `[Customers](/tables/customers.md)`)
|
|
314
|
+
"- Cross-links (e.g. `[Customers](/tables/customers.md)`) "
|
|
315
|
+
"express relationships.\n",
|
|
306
316
|
encoding="utf-8",
|
|
307
317
|
)
|
|
@@ -178,6 +178,16 @@ def test_bundle_refuses_overwrite_without_force(tmp_path: Path):
|
|
|
178
178
|
assert "--force" in result.output
|
|
179
179
|
|
|
180
180
|
|
|
181
|
+
def test_bundle_refuses_same_input_and_output_dir(tmp_path: Path):
|
|
182
|
+
src = tmp_path / "notes"
|
|
183
|
+
src.mkdir()
|
|
184
|
+
_write_fixture(src, {"tables/a.md": "# A\n\n> Desc.\n"})
|
|
185
|
+
|
|
186
|
+
result = runner.invoke(app, ["bundle", str(src), str(src), "--force"])
|
|
187
|
+
assert result.exit_code == 1, result.output
|
|
188
|
+
assert "must be different" in result.output
|
|
189
|
+
|
|
190
|
+
|
|
181
191
|
def test_bundle_no_md_files(tmp_path: Path):
|
|
182
192
|
src = tmp_path / "notes"
|
|
183
193
|
dst = tmp_path / "bundle"
|
|
@@ -342,7 +352,9 @@ def test_bundle_warns_broken_local_markdown_link(tmp_path: Path):
|
|
|
342
352
|
_write_fixture(
|
|
343
353
|
src,
|
|
344
354
|
{
|
|
345
|
-
"tables/orders.md":
|
|
355
|
+
"tables/orders.md": (
|
|
356
|
+
"# Orders\n\n> One row.\n\nSee [Customers](customers.md)."
|
|
357
|
+
),
|
|
346
358
|
},
|
|
347
359
|
)
|
|
348
360
|
|
|
@@ -358,8 +370,12 @@ def test_bundle_accepts_valid_relative_and_absolute_local_links(tmp_path: Path):
|
|
|
358
370
|
_write_fixture(
|
|
359
371
|
src,
|
|
360
372
|
{
|
|
361
|
-
"tables/orders.md":
|
|
362
|
-
|
|
373
|
+
"tables/orders.md": (
|
|
374
|
+
"# Orders\n\n> One row.\n\nSee [Customers](./customers.md)."
|
|
375
|
+
),
|
|
376
|
+
"tables/customers.md": (
|
|
377
|
+
"# Customers\n\n> All customers.\n\nSee [Orders](/tables/orders.md)."
|
|
378
|
+
),
|
|
363
379
|
},
|
|
364
380
|
)
|
|
365
381
|
|
|
@@ -397,7 +413,9 @@ def test_bundle_warns_markdown_link_outside_bundle(tmp_path: Path):
|
|
|
397
413
|
_write_fixture(
|
|
398
414
|
src,
|
|
399
415
|
{
|
|
400
|
-
"tables/orders.md":
|
|
416
|
+
"tables/orders.md": (
|
|
417
|
+
"# Orders\n\n> One row.\n\nSee [Secret](../../secret.md)."
|
|
418
|
+
),
|
|
401
419
|
},
|
|
402
420
|
)
|
|
403
421
|
|
|
@@ -413,7 +431,9 @@ def test_bundle_strict_links_fails_on_broken_local_link(tmp_path: Path):
|
|
|
413
431
|
_write_fixture(
|
|
414
432
|
src,
|
|
415
433
|
{
|
|
416
|
-
"tables/orders.md":
|
|
434
|
+
"tables/orders.md": (
|
|
435
|
+
"# Orders\n\n> One row.\n\nSee [Customers](customers.md)."
|
|
436
|
+
),
|
|
417
437
|
},
|
|
418
438
|
)
|
|
419
439
|
|
|
@@ -429,8 +449,12 @@ def test_bundle_strict_links_passes_with_valid_local_links(tmp_path: Path):
|
|
|
429
449
|
_write_fixture(
|
|
430
450
|
src,
|
|
431
451
|
{
|
|
432
|
-
"tables/orders.md":
|
|
433
|
-
|
|
452
|
+
"tables/orders.md": (
|
|
453
|
+
"# Orders\n\n> One row.\n\nSee [Customers](./customers.md)."
|
|
454
|
+
),
|
|
455
|
+
"tables/customers.md": (
|
|
456
|
+
"# Customers\n\n> All customers.\n\nBody."
|
|
457
|
+
),
|
|
434
458
|
},
|
|
435
459
|
)
|
|
436
460
|
|
|
@@ -248,7 +248,9 @@ def test_bundle_warns_broken_link(tmp_path: Path):
|
|
|
248
248
|
_write(
|
|
249
249
|
src,
|
|
250
250
|
{
|
|
251
|
-
"tables/orders.md":
|
|
251
|
+
"tables/orders.md": (
|
|
252
|
+
"# Orders\n\n> One row.\n\nSee [Customers](customers.md)."
|
|
253
|
+
),
|
|
252
254
|
},
|
|
253
255
|
)
|
|
254
256
|
|
|
@@ -264,7 +266,9 @@ def test_bundle_accepts_valid_links(tmp_path: Path):
|
|
|
264
266
|
_write(
|
|
265
267
|
src,
|
|
266
268
|
{
|
|
267
|
-
"tables/orders.md":
|
|
269
|
+
"tables/orders.md": (
|
|
270
|
+
"# Orders\n\n> One row.\n\nSee [Customers](./customers.md)."
|
|
271
|
+
),
|
|
268
272
|
"tables/customers.md": "# Customers\n\n> All.\n\nBody.",
|
|
269
273
|
},
|
|
270
274
|
)
|
|
@@ -740,7 +744,10 @@ def test_show_valid_concept(tmp_path: Path):
|
|
|
740
744
|
|
|
741
745
|
|
|
742
746
|
def test_show_with_md_extension_appended(tmp_path: Path):
|
|
743
|
-
"""show always appends .md
|
|
747
|
+
"""show always appends .md.
|
|
748
|
+
|
|
749
|
+
Passing tables/orders.md looks for tables/orders.md.md.
|
|
750
|
+
"""
|
|
744
751
|
d = tmp_path / "bundle"
|
|
745
752
|
d.mkdir()
|
|
746
753
|
_write(d, {"tables/orders.md": "---\ntype: tables\n---\n\nBody."})
|
|
@@ -1,127 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: writing-knowledge-base
|
|
3
|
-
description: Help a domain expert turn their knowledge into a plain Markdown knowledge base that can be bundled into OKF with `okf bundle`. Use reference/knowledge-base.md for content guidance and reference/example/ for structure and writing style.
|
|
4
|
-
license: MIT
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Knowledge Base Construction
|
|
8
|
-
|
|
9
|
-
Help a domain expert turn their knowledge into a plain Markdown knowledge base that can be bundled into OKF with `okf bundle`. Use `reference/knowledge-base.md` for content guidance and `reference/example/` for structure and writing style.
|
|
10
|
-
|
|
11
|
-
## Role
|
|
12
|
-
|
|
13
|
-
Act as facilitator and editor, not an authority on the domain.
|
|
14
|
-
|
|
15
|
-
- Ask focused questions when facts, scope, ownership, terminology, or relationships are unclear.
|
|
16
|
-
- Never invent domain facts, metrics, schemas, URLs, SLAs, or procedures.
|
|
17
|
-
- Preserve the expert's terminology and meaning; improve structure and clarity only.
|
|
18
|
-
- Prefer several small, linked concepts over one large document.
|
|
19
|
-
|
|
20
|
-
## Workflow
|
|
21
|
-
|
|
22
|
-
1. Learn the domain, audience, and intended use of the knowledge base.
|
|
23
|
-
|
|
24
|
-
1. Identify concepts and group them into directories such as `datasets/`, `tables/`, `playbooks/`, or other domain-appropriate types.
|
|
25
|
-
|
|
26
|
-
1. Propose a file tree before writing many files. Get expert agreement on names and grouping.
|
|
27
|
-
|
|
28
|
-
1. Draft or update one concept at a time. Show the draft and ask for corrections.
|
|
29
|
-
|
|
30
|
-
1. Add links between related concepts using relative Markdown links.
|
|
31
|
-
|
|
32
|
-
1. Review for missing context, contradictions, stale-looking operational details, and unsupported assumptions.
|
|
33
|
-
|
|
34
|
-
1. Keep source files under a chosen input directory, following `reference/example/`.
|
|
35
|
-
|
|
36
|
-
1. When ready, explain how to bundle and validate:
|
|
37
|
-
|
|
38
|
-
```bash
|
|
39
|
-
okf bundle <input-dir> <output-dir> --default-type reference
|
|
40
|
-
okf validate <output-dir>
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
Use `--default-type` only when root-level files exist. Prefer placing concepts in named directories.
|
|
44
|
-
|
|
45
|
-
## References
|
|
46
|
-
|
|
47
|
-
Read these files before drafting when more detail is needed:
|
|
48
|
-
|
|
49
|
-
- `reference/knowledge-base.md` — what a good knowledge base and concept file look like.
|
|
50
|
-
- `reference/example/` — complete example input structure copied from this project.
|
|
51
|
-
|
|
52
|
-
## File format
|
|
53
|
-
|
|
54
|
-
Every concept should normally use this format:
|
|
55
|
-
|
|
56
|
-
```markdown
|
|
57
|
-
# Clear Concept Title
|
|
58
|
-
|
|
59
|
-
> One-sentence summary of this concept.
|
|
60
|
-
|
|
61
|
-
Body content with useful context, structure, examples, procedures, or schema.
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
Rules:
|
|
65
|
-
|
|
66
|
-
- First line: `# Title`.
|
|
67
|
-
- Follow with a `>` description block. Keep it concise and factual.
|
|
68
|
-
- Put detailed knowledge in the body after the description.
|
|
69
|
-
- Use headings, lists, tables, and code blocks where they help retrieval.
|
|
70
|
-
- Use one file per concept.
|
|
71
|
-
- Directory name becomes OKF `type`: `tables/orders.md` becomes type `tables`.
|
|
72
|
-
- Use lowercase, stable, descriptive filenames. Avoid spaces when possible.
|
|
73
|
-
- Do not create `index.md`, `log.md`, or `README.md` as concepts in source input; bundling reserves them.
|
|
74
|
-
- Do not add frontmatter to source files. `okf bundle` generates it.
|
|
75
|
-
|
|
76
|
-
## Concept guidance
|
|
77
|
-
|
|
78
|
-
For data assets, capture:
|
|
79
|
-
|
|
80
|
-
- What asset contains and why it exists.
|
|
81
|
-
- Grain or unit of each record.
|
|
82
|
-
- Ownership and consumers, if known.
|
|
83
|
-
- Schema with field name, type, and meaning.
|
|
84
|
-
- Keys, joins, partitions, freshness, quality limits, and known caveats.
|
|
85
|
-
|
|
86
|
-
For processes and playbooks, capture:
|
|
87
|
-
|
|
88
|
-
- Trigger and scope.
|
|
89
|
-
- Ordered steps.
|
|
90
|
-
- Decision points and expected outcomes.
|
|
91
|
-
- Owners, escalation paths, tools, and safety constraints.
|
|
92
|
-
- Links to related assets and procedures.
|
|
93
|
-
|
|
94
|
-
For domain concepts, capture:
|
|
95
|
-
|
|
96
|
-
- Definition and boundaries.
|
|
97
|
-
- Synonyms and terms that should not be confused.
|
|
98
|
-
- Examples and counterexamples.
|
|
99
|
-
- Related concepts and source evidence.
|
|
100
|
-
|
|
101
|
-
## Questions to ask
|
|
102
|
-
|
|
103
|
-
Ask only questions that unblock useful writing. Examples:
|
|
104
|
-
|
|
105
|
-
- Who uses this knowledge and what decision should it support?
|
|
106
|
-
- What is the smallest useful concept here?
|
|
107
|
-
- What does each term mean in this domain?
|
|
108
|
-
- What is the source of truth?
|
|
109
|
-
- What is the record grain, owner, freshness, or SLA?
|
|
110
|
-
- What concepts does this depend on or relate to?
|
|
111
|
-
- What should a reader do when this process fails?
|
|
112
|
-
- Which details are confirmed, approximate, deprecated, or unknown?
|
|
113
|
-
|
|
114
|
-
## Quality check
|
|
115
|
-
|
|
116
|
-
Before declaring the knowledge base ready, check:
|
|
117
|
-
|
|
118
|
-
- Every concept has a title and one-sentence description.
|
|
119
|
-
- Each file contains one coherent concept.
|
|
120
|
-
- Directory grouping reflects meaningful concept types.
|
|
121
|
-
- Links point to the correct relative files.
|
|
122
|
-
- No facts were added without expert confirmation.
|
|
123
|
-
- Procedures include ownership and failure handling where relevant.
|
|
124
|
-
- Tables include field meaning, not only field names and types.
|
|
125
|
-
- Unknown or disputed details are visible.
|
|
126
|
-
- Source remains readable as plain Markdown.
|
|
127
|
-
- Generated output passes `okf validate <output-dir>`.
|
|
@@ -1,12 +0,0 @@
|
|
|
1
|
-
# OKF Example
|
|
2
|
-
|
|
3
|
-
This directory contains plain markdown files written by domain experts.
|
|
4
|
-
Run `okf bundle` to convert them into an OKF-conformant knowledge bundle.
|
|
5
|
-
|
|
6
|
-
```bash
|
|
7
|
-
# From repo root:
|
|
8
|
-
uv run okf bundle example output-bundle
|
|
9
|
-
|
|
10
|
-
# With a default type for root-level files (if any):
|
|
11
|
-
uv run okf bundle example output-bundle --default-type reference
|
|
12
|
-
```
|
okf_cli-0.4.1/skills/writing-knowledge-base/reference/example/playbooks/incident-response.md
DELETED
|
@@ -1,14 +0,0 @@
|
|
|
1
|
-
# Data Freshness Incident
|
|
2
|
-
|
|
3
|
-
> Steps to triage a freshness alert on the orders pipeline.
|
|
4
|
-
|
|
5
|
-
## Trigger
|
|
6
|
-
|
|
7
|
-
A freshness alert fires when the [orders](../tables/orders.md) table lags more than 30 minutes behind its expected SLA.
|
|
8
|
-
|
|
9
|
-
## Steps
|
|
10
|
-
|
|
11
|
-
1. Check the ingestion job dashboard.
|
|
12
|
-
1. Verify upstream source connectivity.
|
|
13
|
-
1. Inspect the [Sales Dataset](../datasets/sales.md) for recent changes.
|
|
14
|
-
1. Notify the data engineering team if the issue persists.
|
|
@@ -1,13 +0,0 @@
|
|
|
1
|
-
# On-call Guide
|
|
2
|
-
|
|
3
|
-
> Quick reference for on-call data engineers.
|
|
4
|
-
|
|
5
|
-
## Channels
|
|
6
|
-
|
|
7
|
-
- **Critical alerts**: PagerDuty
|
|
8
|
-
- **Team chat**: #data-eng on Slack
|
|
9
|
-
- **Escalation**: Contact the data engineering lead
|
|
10
|
-
|
|
11
|
-
## Common Issues
|
|
12
|
-
|
|
13
|
-
See [Incident Response](incident-response.md) for data freshness issues.
|
|
@@ -1,16 +0,0 @@
|
|
|
1
|
-
# Customers
|
|
2
|
-
|
|
3
|
-
> One row per registered customer.
|
|
4
|
-
|
|
5
|
-
## Schema
|
|
6
|
-
|
|
7
|
-
| Column | Type | Description |
|
|
8
|
-
| ----------- | --------- | -------------------------- |
|
|
9
|
-
| customer_id | STRING | Unique customer identifier |
|
|
10
|
-
| name | STRING | Customer display name |
|
|
11
|
-
| email | STRING | Customer email address |
|
|
12
|
-
| created_at | TIMESTAMP | Account creation date |
|
|
13
|
-
|
|
14
|
-
## Notes
|
|
15
|
-
|
|
16
|
-
Referenced by [orders](orders.md) via `customer_id`.
|
|
@@ -1,16 +0,0 @@
|
|
|
1
|
-
# Customer Orders
|
|
2
|
-
|
|
3
|
-
> One row per completed customer order across all channels.
|
|
4
|
-
|
|
5
|
-
## Schema
|
|
6
|
-
|
|
7
|
-
| Column | Type | Description |
|
|
8
|
-
| ----------- | --------- | ------------------------- |
|
|
9
|
-
| order_id | STRING | Unique order identifier |
|
|
10
|
-
| customer_id | STRING | Foreign key to customers |
|
|
11
|
-
| total_usd | NUMERIC | Order total in USD |
|
|
12
|
-
| placed_at | TIMESTAMP | When the order was placed |
|
|
13
|
-
|
|
14
|
-
## Notes
|
|
15
|
-
|
|
16
|
-
Part of the [Sales Dataset](../datasets/sales.md). Joined with [customers](customers.md) on `customer_id`.
|
|
@@ -1,12 +0,0 @@
|
|
|
1
|
-
# Daily Partition
|
|
2
|
-
|
|
3
|
-
> One partition per day for the orders table.
|
|
4
|
-
|
|
5
|
-
Part of the [orders](../../tables/orders.md) table's partitioning scheme.
|
|
6
|
-
|
|
7
|
-
## Schema
|
|
8
|
-
|
|
9
|
-
| Column | Type | Description |
|
|
10
|
-
| -------------- | ----- | ------------------------------- |
|
|
11
|
-
| partition_date | DATE | The date of this partition |
|
|
12
|
-
| row_count | INT64 | Number of rows in the partition |
|
|
@@ -1,65 +0,0 @@
|
|
|
1
|
-
# Knowledge Base Reference
|
|
2
|
-
|
|
3
|
-
Knowledge base is plain Markdown organized as small, linked concepts.
|
|
4
|
-
Domain expert supplies facts. Agent supplies structure, questions, and editing.
|
|
5
|
-
|
|
6
|
-
## Basic concept
|
|
7
|
-
|
|
8
|
-
```markdown
|
|
9
|
-
# Customer Orders
|
|
10
|
-
|
|
11
|
-
> One row per completed customer order across all channels.
|
|
12
|
-
|
|
13
|
-
## Schema
|
|
14
|
-
|
|
15
|
-
| Column | Type | Description |
|
|
16
|
-
|--------|------|-------------|
|
|
17
|
-
| order_id | STRING | Unique order identifier |
|
|
18
|
-
| customer_id | STRING | Foreign key to customers |
|
|
19
|
-
| total_usd | NUMERIC | Order total in USD |
|
|
20
|
-
|
|
21
|
-
## Notes
|
|
22
|
-
|
|
23
|
-
Part of the [Sales Dataset](../datasets/sales.md).
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
## Source structure
|
|
27
|
-
|
|
28
|
-
```text
|
|
29
|
-
knowledge-base/
|
|
30
|
-
├── domain.md # Optional root-level domain overview
|
|
31
|
-
├── datasets/ # Dataset concepts
|
|
32
|
-
│ └── sales.md
|
|
33
|
-
├── tables/ # Table concepts
|
|
34
|
-
│ ├── customers.md
|
|
35
|
-
│ ├── orders.md
|
|
36
|
-
│ └── partitions/
|
|
37
|
-
│ └── daily.md
|
|
38
|
-
└── playbooks/ # Operational procedure concepts
|
|
39
|
-
├── incident-response.md
|
|
40
|
-
└── oncall-guide.md
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
Directory names become OKF concept types when bundled. For example,
|
|
44
|
-
`tables/orders.md` becomes a concept with type `tables` and ID
|
|
45
|
-
`tables/orders`.
|
|
46
|
-
|
|
47
|
-
## Writing rules
|
|
48
|
-
|
|
49
|
-
- Use one coherent concept per file.
|
|
50
|
-
- Start with `# Title`.
|
|
51
|
-
- Follow title with a concise `>` description.
|
|
52
|
-
- Put detail in the body.
|
|
53
|
-
- Link related concepts with relative Markdown links.
|
|
54
|
-
- Use lowercase, stable filenames.
|
|
55
|
-
- Do not add YAML frontmatter to source files; bundler generates it.
|
|
56
|
-
|
|
57
|
-
## Data concept checklist
|
|
58
|
-
|
|
59
|
-
Capture what asset contains, record grain, owner, consumers, schema, keys,
|
|
60
|
-
joins, partitions, freshness, quality limits, and caveats when known.
|
|
61
|
-
|
|
62
|
-
## Playbook checklist
|
|
63
|
-
|
|
64
|
-
Capture trigger, scope, ordered steps, decisions, expected outcomes, owners,
|
|
65
|
-
escalation, tools, and failure handling when known.
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|