{"owner":"open-telemetry","repo":"opentelemetry-specification","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":428,"categories":["claude-rule","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"# Instructions for Claude Code\n\n@AGENTS.md\n","AGENTS.md":"# AGENTS.md\n\nThis repository contains the OpenTelemetry specification. This file is a short\nrouting guide for agents.\n\nCanonical requirements and project guidance live in the repository documents.\nIf details differ, follow the canonical repository documents linked here,\nespecially [Contributing guidelines] and [Specification Principles].\n\n## Contributing\n\n- Follow [Contributing guidelines].\n\n## Reviewing\n\n- Ensure the changes align with the [Contributing guidelines] and\n  [Specification Principles].\n- Check if the changes are focused, vendor-neutral, and implementable across\n  languages.\n- Check related specification sections for conflicts in requirements,\n  terminology, or data model behavior.\n- For feature, behavior, or stability changes, check whether the pull request\n  links to an issue or OTEP and includes prototype links.\n- For SDK component configuration changes, check whether a corresponding\n  proposed change exists in the [declarative configuration schema].\n- In `specification/`, treat `MUST`, `MUST NOT`, `REQUIRED`, `SHOULD`,\n  `SHOULD NOT`, `RECOMMENDED`, `NOT RECOMMENDED`, `MAY`, and `OPTIONAL` as\n  BCP 14 terms only when they appear in all capitals.\n- Flag lowercase modal wording such as \"must\", \"should\", and \"may\" in\n  specification prose when it reads like an implementation requirement. For\n  non-normative text, suggest neutral wording or explicit non-normative\n  framing instead of hidden requirements.\n- Verify the affected document or section [status] when a change adds, removes,\n  or tightens requirements. Status is commonly marked with a `**Status**: ...`\n  line or bold inline marker.\n- Flag possible stability or breaking-change impact for human review,\n  especially in Stable and Release Candidate content.\n\n[Contributing guidelines]: CONTRIBUTING.md\n[Specification Principles]: specification/specification-principles.md\n[declarative configuration schema]: https://github.com/open-telemetry/opentelemetry-configuration\n[status]: specification/document-status.md\n"},"files":{"CLAUDE.md":"# Instructions for Claude Code\n\n@AGENTS.md\n","AGENTS.md":"# AGENTS.md\n\nThis repository contains the OpenTelemetry specification. This file is a short\nrouting guide for agents.\n\nCanonical requirements and project guidance live in the repository documents.\nIf details differ, follow the canonical repository documents linked here,\nespecially [Contributing guidelines] and [Specification Principles].\n\n## Contributing\n\n- Follow [Contributing guidelines].\n\n## Reviewing\n\n- Ensure the changes align with the [Contributing guidelines] and\n  [Specification Principles].\n- Check if the changes are focused, vendor-neutral, and implementable across\n  languages.\n- Check related specification sections for conflicts in requirements,\n  terminology, or data model behavior.\n- For feature, behavior, or stability changes, check whether the pull request\n  links to an issue or OTEP and includes prototype links.\n- For SDK component configuration changes, check whether a corresponding\n  proposed change exists in the [declarative configuration schema].\n- In `specification/`, treat `MUST`, `MUST NOT`, `REQUIRED`, `SHOULD`,\n  `SHOULD NOT`, `RECOMMENDED`, `NOT RECOMMENDED`, `MAY`, and `OPTIONAL` as\n  BCP 14 terms only when they appear in all capitals.\n- Flag lowercase modal wording such as \"must\", \"should\", and \"may\" in\n  specification prose when it reads like an implementation requirement. For\n  non-normative text, suggest neutral wording or explicit non-normative\n  framing instead of hidden requirements.\n- Verify the affected document or section [status] when a change adds, removes,\n  or tightens requirements. Status is commonly marked with a `**Status**: ...`\n  line or bold inline marker.\n- Flag possible stability or breaking-change impact for human review,\n  especially in Stable and Release Candidate content.\n\n[Contributing guidelines]: CONTRIBUTING.md\n[Specification Principles]: specification/specification-principles.md\n[declarative configuration schema]: https://github.com/open-telemetry/opentelemetry-configuration\n[status]: specification/document-status.md\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/open-telemetry/opentelemetry-specification/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nThis repository contains the OpenTelemetry specification. This file is a short\nrouting guide for agents.\n\nCanonical requirements and project guidance live in the repository documents.\nIf details differ, follow the canonical repository documents linked here,\nespecially [Contributing guidelines] and [Specification Principles].\n\n## Contributing\n\n- Follow [Contributing guidelines].\n\n## Reviewing\n\n- Ensure the changes align with the [Contributing guidelines] and\n  [Specification Principles].\n- Check if the changes are focused, vendor-neutral, and implementable across\n  languages.\n- Check related specification sections for conflicts in requirements,\n  terminology, or data model behavior.\n- For feature, behavior, or stability changes, check whether the pull request\n  links to an issue or OTEP and includes prototype links.\n- For SDK component configuration changes, check whether a corresponding\n  proposed change exists in the [declarative configuration schema].\n- In `specification/`, treat `MUST`, `MUST NOT`, `REQUIRED`, `SHOULD`,\n  `SHOULD NOT`, `RECOMMENDED`, `NOT RECOMMENDED`, `MAY`, and `OPTIONAL` as\n  BCP 14 terms only when they appear in all capitals.\n- Flag lowercase modal wording such as \"must\", \"should\", and \"may\" in\n  specification prose when it reads like an implementation requirement. For\n  non-normative text, suggest neutral wording or explicit non-normative\n  framing instead of hidden requirements.\n- Verify the affected document or section [status] when a change adds, removes,\n  or tightens requirements. Status is commonly marked with a `**Status**: ...`\n  line or bold inline marker.\n- Flag possible stability or breaking-change impact for human review,\n  especially in Stable and Release Candidate content.\n\n[Contributing guidelines]: CONTRIBUTING.md\n[Specification Principles]: specification/specification-principles.md\n[declarative configuration schema]: https://github.com/open-telemetry/opentelemetry-configuration\n[status]: specification/document-status.md\n","isInternal":false,"tokens":417,"sizeBytes":2009},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/open-telemetry/opentelemetry-specification/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Instructions for Claude Code\n\n@AGENTS.md\n","isInternal":false,"tokens":11,"sizeBytes":43}],"systemPromptSnippet":"<yakaai_skills repo=\"open-telemetry/opentelemetry-specification\">\n<!-- File: AGENTS.md (Tokens: ~417 | Category: root-instruction) -->\n# AGENTS.md\n\nThis repository contains the OpenTelemetry specification. This file is a short\nrouting guide for agents.\n\nCanonical requirements and project guidance live in the repository documents.\nIf details differ, follow the canonical repository documents linked here,\nespecially [Contributing guidelines] and [Specification Principles].\n\n## Contributing\n\n- Follow [Contributing guidelines].\n\n## Reviewing\n\n- Ensure the changes align with the [Contributing guidelines] and\n  [Specification Principles].\n- Check if the changes are focused, vendor-neutral, and implementable across\n  languages.\n- Check related specification sections for conflicts in requirements,\n  terminology, or data model behavior.\n- For feature, behavior, or stability changes, check whether the pull request\n  links to an issue or OTEP and includes prototype links.\n- For SDK component configuration changes, check whether a corresponding\n  proposed change exists in the [declarative configuration schema].\n- In `specification/`, treat `MUST`, `MUST NOT`, `REQUIRED`, `SHOULD`,\n  `SHOULD NOT`, `RECOMMENDED`, `NOT RECOMMENDED`, `MAY`, and `OPTIONAL` as\n  BCP 14 terms only when they appear in all capitals.\n- Flag lowercase modal wording such as \"must\", \"should\", and \"may\" in\n  specification prose when it reads like an implementation requirement. For\n  non-normative text, suggest neutral wording or explicit non-normative\n  framing instead of hidden requirements.\n- Verify the affected document or section [status] when a change adds, removes,\n  or tightens requirements. Status is commonly marked with a `**Status**: ...`\n  line or bold inline marker.\n- Flag possible stability or breaking-change impact for human review,\n  especially in Stable and Release Candidate content.\n\n[Contributing guidelines]: CONTRIBUTING.md\n[Specification Principles]: specification/specification-principles.md\n[declarative configuration schema]: https://github.com/open-telemetry/opentelemetry-configuration\n[status]: specification/document-status.md\n\n<!-- File: CLAUDE.md (Tokens: ~11 | Category: claude-rule) -->\n# Instructions for Claude Code\n\n@AGENTS.md\n</yakaai_skills>"}