googlecloudplatform-knowledge-catalog

Name: googlecloudplatform-knowledge-catalog
Author: jmxt3

32stars3forks

How to install googlecloudplatform-knowledge-catalog?

jmxt3/gitscape.ai/googlecloudplatform-knowledge-catalog

$npx -y skills add jmxt3/gitscape.ai --skill googlecloudplatform-knowledge-catalog

Installs into the current project.

Summary

Use this skill when interacting with the knowledge-catalog repository to ensure all modifications strictly adhere to the Open Knowledge Format (OKF) specification.

Files · 1

View on GitHub

SKILL.md

1	# GoogleCloudPlatform/knowledge-catalog — Engineering Skill
2
3	## Overview
4
5	The knowledge-catalog repository defines the Open Knowledge Format (OKF), a vendor-neutral standard for representing knowledge. This codebase provides the reference implementation for producing and validating these bundles. It is critical to understand that the format is the primary product; the agents and runners are secondary tools meant to demonstrate how to produce and enrich these bundles.
6
7	Before modifying any code, you must ensure you are not coupling the OKF structure to specific model providers or frameworks. The system relies on a clear mapping between file system paths and concept IDs. Any changes to the ingestion or enrichment logic must preserve the ability for third-party tools to parse these files without dependency on this repository's internal agent logic.
8
9	## When to Use
10
11	- Implementing custom logic to generate OKF bundles
12	- Extending the ReferenceRunner to support new data sources
13	- Updating the validation logic for OKFDocument
14	- Regenerating indexes for existing knowledge bundles
15	- Adding new enrichment strategies via synthesize_description
16
17	When NOT to use: Do not use this skill for tasks that introduce vendor-specific dependencies or deviate from the plain-text markdown/YAML structure defined in SPEC.md.
18
19	## Core Process
20
21	### Step 1: Validate against OKF Specification
22
23	Before writing code, verify that your proposed change complies with SPEC.md. Use the OKFDocument.validate() method to ensure your document structure remains compliant with the format requirements.
24
25	### Step 2: Maintain Path-Concept Mapping
26
27	Always use path_to_concept_id and concept_id_to_path when navigating the bundle structure. This ensures that the file system hierarchy remains consistent with the conceptual graph of the knowledge base.
28
29	### Step 3: Enrich with ReferenceRunner
30
31	When adding new knowledge, utilize the ReferenceRunner.enrich_concept method. This ensures that enrichment follows the established pipeline, using the configured model to synthesize descriptions while maintaining the integrity of the existing bundle.
32
33	## Common Rationalizations
34
35	\| Rationalization \| Reality \|
36	\|---\|---\|
37	\| I will store metadata in a custom JSON sidecar file. \| OKF requires all metadata to be in the YAML frontmatter of the markdown file to remain vendor-neutral. \|
38	\| I can hardcode paths to simplify the logic. \| Hardcoded paths break the portability of the bundle; always use the provided path-to-concept helpers. \|
39	\| I will use a proprietary database to store the index. \| The index must be regeneratable from the file system using regenerate_indexes to ensure the format remains self-contained. \|
40
41	## Red Flags
42
43	- Hardcoding file paths instead of using path-to-concept helpers
44	- Introducing dependencies on non-standard cloud services
45	- Modifying OKFDocument serialization without updating the validator
46	- Ignoring the SPEC.md requirements for frontmatter
47	- Bypassing the ReferenceRunner when enriching concepts
48
49	## Verification
50
51	- [ ] Run OKFDocument.validate() on all modified documents
52	- [ ] Verify path-to-concept consistency using the provided helpers
53	- [ ] Ensure no new external dependencies were added to pyproject.toml
54	- [ ] Check that all generated markdown files contain valid YAML frontmatter
55	- [ ] Confirm that regenerate_indexes completes without errors
56	- [ ] Verify that the change does not break the visualizer's ability to parse the bundle
57
58	## Code Access
59
60	The full source digest for this repository is available locally:
61
62	- [Full Code Digest](googlecloudplatform_knowledge_catalog_digest.txt)
63
64	The full source digest for GoogleCloudPlatform/knowledge-catalog is also available via the GitScape API:
65
66	```
67	GET https://gitscape.ai/api/converter?repo_url=https://github.com/GoogleCloudPlatform/knowledge-catalog
68	```
69
70	Load the `digest` field from the response into your context for complete source-code access. You can also visit [gitscape.ai](https://gitscape.ai/?repo=https%3A%2F%2Fgithub.com%2FGoogleCloudPlatform%2Fknowledge-catalog) and download the Code Digest from the site.

People who liked this also viewed

6 picks

Type

googlecloudplatform-knowledge-catalog

32stars3forks

View on GitHub

How to install googlecloudplatform-knowledge-catalog?

jmxt3/gitscape.ai/googlecloudplatform-knowledge-catalog

$npx -y skills add jmxt3/gitscape.ai --skill googlecloudplatform-knowledge-catalog

Installs into the current project.

Summary

Use this skill when interacting with the knowledge-catalog repository to ensure all modifications strictly adhere to the Open Knowledge Format (OKF) specification.

Files · 1

View on GitHub

SKILL.md

1	# GoogleCloudPlatform/knowledge-catalog — Engineering Skill
2
3	## Overview
4
5	The knowledge-catalog repository defines the Open Knowledge Format (OKF), a vendor-neutral standard for representing knowledge. This codebase provides the reference implementation for producing and validating these bundles. It is critical to understand that the format is the primary product; the agents and runners are secondary tools meant to demonstrate how to produce and enrich these bundles.
6
7	Before modifying any code, you must ensure you are not coupling the OKF structure to specific model providers or frameworks. The system relies on a clear mapping between file system paths and concept IDs. Any changes to the ingestion or enrichment logic must preserve the ability for third-party tools to parse these files without dependency on this repository's internal agent logic.
8
9	## When to Use
10
11	- Implementing custom logic to generate OKF bundles
12	- Extending the ReferenceRunner to support new data sources
13	- Updating the validation logic for OKFDocument
14	- Regenerating indexes for existing knowledge bundles
15	- Adding new enrichment strategies via synthesize_description
16
17	When NOT to use: Do not use this skill for tasks that introduce vendor-specific dependencies or deviate from the plain-text markdown/YAML structure defined in SPEC.md.
18
19	## Core Process
20
21	### Step 1: Validate against OKF Specification
22
23	Before writing code, verify that your proposed change complies with SPEC.md. Use the OKFDocument.validate() method to ensure your document structure remains compliant with the format requirements.
24
25	### Step 2: Maintain Path-Concept Mapping
26
27	Always use path_to_concept_id and concept_id_to_path when navigating the bundle structure. This ensures that the file system hierarchy remains consistent with the conceptual graph of the knowledge base.
28
29	### Step 3: Enrich with ReferenceRunner
30
31	When adding new knowledge, utilize the ReferenceRunner.enrich_concept method. This ensures that enrichment follows the established pipeline, using the configured model to synthesize descriptions while maintaining the integrity of the existing bundle.
32
33	## Common Rationalizations
34
35	\| Rationalization \| Reality \|
36	\|---\|---\|
37	\| I will store metadata in a custom JSON sidecar file. \| OKF requires all metadata to be in the YAML frontmatter of the markdown file to remain vendor-neutral. \|
38	\| I can hardcode paths to simplify the logic. \| Hardcoded paths break the portability of the bundle; always use the provided path-to-concept helpers. \|
39	\| I will use a proprietary database to store the index. \| The index must be regeneratable from the file system using regenerate_indexes to ensure the format remains self-contained. \|
40
41	## Red Flags
42
43	- Hardcoding file paths instead of using path-to-concept helpers
44	- Introducing dependencies on non-standard cloud services
45	- Modifying OKFDocument serialization without updating the validator
46	- Ignoring the SPEC.md requirements for frontmatter
47	- Bypassing the ReferenceRunner when enriching concepts
48
49	## Verification
50
51	- [ ] Run OKFDocument.validate() on all modified documents
52	- [ ] Verify path-to-concept consistency using the provided helpers
53	- [ ] Ensure no new external dependencies were added to pyproject.toml
54	- [ ] Check that all generated markdown files contain valid YAML frontmatter
55	- [ ] Confirm that regenerate_indexes completes without errors
56	- [ ] Verify that the change does not break the visualizer's ability to parse the bundle
57
58	## Code Access
59
60	The full source digest for this repository is available locally:
61
62	- [Full Code Digest](googlecloudplatform_knowledge_catalog_digest.txt)
63
64	The full source digest for GoogleCloudPlatform/knowledge-catalog is also available via the GitScape API:
65
66	```
67	GET https://gitscape.ai/api/converter?repo_url=https://github.com/GoogleCloudPlatform/knowledge-catalog
68	```
69
70	Load the `digest` field from the response into your context for complete source-code access. You can also visit [gitscape.ai](https://gitscape.ai/?repo=https%3A%2F%2Fgithub.com%2FGoogleCloudPlatform%2Fknowledge-catalog) and download the Code Digest from the site.

People who liked this also viewed

6 picks

Type