googlecloudplatform-knowledge-catalog
Skill33 starsChanged 4 months agoApache-2.0View on GitHub
Use this skill when interacting with the knowledge-catalog repository to ensure all modifications strictly adhere to the Open Knowledge Format (OKF) specification.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
When NOT to use: Do not use this skill for tasks that introduce vendor-specific dependencies or deviate from the plain-text markdown/YAML …
- Distinctive: line 28
Before writing code, verify that your proposed change complies with SPEC.md.
- Distinctive: line 32
Always use path_to_concept_id and concept_id_to_path when navigating the bundle structure.
- Distinctive: line 36
When adding new knowledge, utilize the ReferenceRunner.enrich_concept method.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GoogleCloudPlatform/knowledge-catalog — Engineering Skill
Overview
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.
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.
When to Use
- Implementing custom logic to generate OKF bundles
- Extending the ReferenceRunner to support new data sources
- Updating the validation logic for OKFDocument
- Regenerating indexes for existing knowledge bundles
- Adding new enrichment strategies via synthesize_description
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.
Core Process
Step 1: Validate against OKF Specification
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.
Step 2: Maintain Path-Concept Mapping
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.
Step 3: Enrich with ReferenceRunner
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.
Common Rationalizations
| Rationalization | Reality |
| 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. |
| I can hardcode paths to simplify the logic. | Hardcoded paths break the portability of the bundle; always use the provided path-to-concept helpers. |
| 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. |
Red Flags
- Hardcoding file paths instead of using path-to-concept helpers
- Introducing dependencies on non-standard cloud services
- Modifying OKFDocument serialization without updating the validator
- Ignoring the SPEC.md requirements for frontmatter
- Bypassing the ReferenceRunner when enriching concepts
Verification
- Run OKFDocument.validate() on all modified documents
- Verify path-to-concept consistency using the provided helpers
- Ensure no new external dependencies were added to pyproject.toml
- Check that all generated markdown files contain valid YAML frontmatter
- Confirm that regenerate_indexes completes without errors
- Verify that the change does not break the visualizer's ability to parse the bundle
Code Access
The full source digest for this repository is available locally:
- Full Code Digest
The full source digest for GoogleCloudPlatform/knowledge-catalog is also available via the GitScape API:
GET https://gitscape.ai/api/converter?repo_url=https://github.com/GoogleCloudPlatform/knowledge-catalogLoad the digest field from the response into your context for complete source-code access. You can also visit gitscape.ai and download the Code Digest from the site.
In this repository53 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- ad-creativeSkill
- addyosmani-agent-skillsSkill
- api-and-interface-designSkill
- brandkitSkill
- browser-testing-with-devtoolsSkill
- chef-assistantSkill
- ci-cd-and-automationSkill
- cloud-run-basicsSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- context-engineeringSkill
- debugging-and-error-recoverySkill
- deprecation-and-migrationSkill
- design-taste-frontendSkill
- design-taste-frontend-v1Skill
- documentation-and-adrsSkill
- frontend-ui-engineeringSkill
- full-output-enforcementSkill
- gemini-apiSkill
- git-workflow-and-versioningSkill
- google-cloud-recipe-authSkill
- google-cloud-recipe-networking-observabilitySkill
- google-cloud-recipe-onboardingSkill
- google-cloud-waf-cost-optimizationSkill
- google-cloud-waf-reliabilitySkill
- google-cloud-waf-securitySkill
- gpt-tasteSkill
- high-end-visual-designSkill
- imagegen-frontend-mobileSkill
- imagegen-frontend-webSkill
- image-to-codeSkill
- incremental-implementationSkill
- industrial-brutalist-uiSkill
- marketing-ideasSkill
- minimalist-uiSkill
- nvidia-skillspectorSkill
- observability-and-instrumentationSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- pricing-strategySkill
- programmatic-seoSkill
- redesign-existing-projectsSkill
- security-and-hardeningSkill
- seo-auditSkill
- shipping-and-launchSkill
- social-contentSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- stitch-design-tasteSkill
- test-driven-developmentSkill
- using-agent-skillsSkill
- videoSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

