{"owner":"alibaba","repo":"kubernetes","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":3086,"categories":["plugin-manifest","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["vendor/github.com/bazelbuild/buildtools/buildozer/README.md","vendor/github.com/googleapis/gnostic/extensions/README.md",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)"],"skills":{"vendor/github.com/bazelbuild/buildtools/buildozer/README.md":"# Buildozer\n\nBuildozer is a command line tool to rewrite multiple\n[Bazel](https://github.com/bazelbuild/bazel) BUILD files using\nstandard commands.\n\n## Dependencies\n\n1. Protobuf go runtime: to download\n`go get -u github.com/golang/protobuf/{proto,protoc-gen-go}`\n\n\n## Installation\n\n1. Change directory to the buildifier/buildozer\n\n```bash\ngopath=$(go env GOPATH)\ncd $gopath/src/github.com/bazelbuild/buildtools/buildozer\n```\n\n2. Install\n\n```bash\ngo install\n```\n\n## Usage\n\n```shell\nbuildozer [OPTIONS] ['command args' | -f FILE ] label-list\n```\n\nHere, `label-list` is a comma-separated list of Bazel labels, for example\n`//path/to/pkg1:rule1, //path/to/pkg2:rule2`. Buildozer reads commands from\n`FILE` (`-` for stdin (format: `|`-separated command line arguments to buildozer,\nexcluding flags))\n\nYou should specify at least one command and one target. Buildozer will execute\nall commands on all targets. Commands are executed in order, files are processed\nin parallel.\n\n### Targets\n\nTargets look like Bazel labels, but there can be some differences in presence of\nmacros.\n\n  * Use the label notation to refer to a rule: `//buildtools/buildozer:edit`\n  * Use the `__pkg__` suffix to refer to the package declaration:\n   `//buildtools/buildozer:__pkg__`\n  * Use an asterisk to refer to all rules in a file: `//pkg:*`\n  * Use `...` to refer to all descendant BUILD files in a directory: `//pkg/...:*`\n  * Use percent to refer to all rules of a certain kind: `//pkg:%java_library`\n  * Use percent-and-number to refer to a rule that begins at a certain line:\n   `//pkg:%123`.\n  * Use `-` for the package name if you want to process standard input stream\n   instead of a file: `-:all_tests`.\n\n### Options\n\nOPTIONS include the following options:\n\n  * `-stdout` : write changed BUILD file to stdout\n  * `-buildifier` : format output using a specific buildifier binary. If empty, use built-in formatter.\n  * `-k` : apply all commands, even if there are failures\n  * `-quiet` : suppress informational messages\n  * `-shorten_labels` : convert added labels to short form, e.g. //foo:bar => :bar\n  * `-types`: Filter the targets, keeping only those of the given types, e.g.\n    `buildozer -types go_library,go_binary 'print rule' '//buildtools/buildozer:*'`\n  * `-eol-comments=false`: When adding new comments, put them on a separate line.\n\nSee `buildozer -help` for the full list.\n\n### Edit commands\n\nBuildozer supports the following commands(`'command args'`):\n\n  * `add <attr> <value(s)>`: Adds value(s) to a list attribute of a rule. If a\n    value is already present in the list, it is not added.\n  * `new_load <path> <symbol(s)>`: Add a load statement for the given path,\n    importing the symbols. Before using this, make sure to run\n    `buildozer 'fix movePackageToTop'`. Afterwards, consider running\n    `buildozer 'fix unusedLoads'`.\n  * `comment <attr>? <value>? <comment>`: Add a comment to a rule, an attribute,\n    or a specific value in a list. Spaces in the comment should be escaped with\n    backslashes.\n  * `print_comment <attr>? <value>?`\n  * `delete`: Delete a rule.\n  * `fix <fix(es)>?`: Apply a fix.\n  * `move <old_attr> <new_attr> <value(s)>`: Moves `value(s)` from the list `old_attr`\n    to the list `new_attr`. The wildcard `*` matches all values.\n  * `new <rule_kind> <rule_name> [(before|after) <relative_rule_name>]`: Add a\n    new rule at the end of the BUILD file (before/after `<relative_rule>`).\n  * `print <attr(s)>`\n  * `remove <attr>`: Removes attribute `attr`.\n  * `remove <attr> <value(s)>`: Removes `value(s)` from the list `attr`. The\n    wildcard `*` matches all attributes. Lists containing none of the `value(s)` are\n    not modified.\n  * `rename <old_attr> <new_attr>`: Rename the `old_attr` to `new_attr` which must\n    not yet exist.\n  * `replace <attr> <old_value> <new_value>`: Replaces `old_value` with `new_value`\n    in the list `attr`. Wildcard `*` matches all attributes. Lists not containing\n    `old_value` are not modified.\n  * `substitute <attr> <old_regexp> <new_template>`: Replaces strings which\n    match `old_regexp` in the list `attr` according to `new_template`. Wildcard\n    `*` matches all attributes. The regular expression must follow\n    [RE2 syntax](https://github.com/google/re2/wiki/Syntax). `new_template` may\n    be a simple replacement string, but it may also expand numbered or named\n    groups using `$0` or `$x`. Lists without strings that match `old_regexp`\n    are not modified.\n  * `set <attr> <value(s)>`: Sets the value of an attribute. If the attribute\n    was already present, its old value is replaced.\n  * `set_if_absent <attr> <value(s)>`: Sets the value of an attribute. If the\n    attribute was already present, no action is taken.\n  * `set kind <value>`: Set the target type to value.\n  * `copy <attr> <from_rule>`: Copies the value of `attr` between rules. If it\n    exists in the `to_rule`, it will be overwritten.\n  * `copy_no_overwrite <attr> <from_rule>`:  Copies the value of `attr` between\n    rules. If it exists in the `to_rule`, no action is taken.\n\nHere, `<attr>` represents an attribute (being `add`ed/`rename`d/`delete`d etc.),\ne.g.: `srcs`, `<value(s)>` represents values of the attribute and so on.\nA '?' indicates that the preceding argument is optional.\n\nThe fix command without a fix specified applied to all eligible fixes.\nUse `//path/to/pkg:__pkg__` as label for file level changes like `new_load` and\n`new_rule`.\nA transformation can be applied to all rules of a particular kind by using\n`%rule_kind` at the end of the label(see examples below).\n\n#### Examples\n\n```bash\n# Edit //pkg:rule and //pkg:rule2, and add a dependency on //base\nbuildozer 'add deps //base' //pkg:rule //pkg:rule2\n\n# A load for a skylark file in //pkg\nbuildozer 'new_load /tools/build_rules/build_test build_test' //pkg:__pkg__\n\n# Change the default_visibility to public for the package //pkg\nbuildozer 'set default_visibility //visibility:public' //pkg:__pkg__\n\n# Change all gwt_module targets to java_library in the package //pkg\nbuildozer 'set kind java_library' //pkg:%gwt_module\n\n# Replace the dependency on pkg_v1 with a dependency on pkg_v2\nbuildozer 'replace deps //pkg_v1 //pkg_v2' //pkg:rule\n\n# Replace all dependencies using regular expressions.\nbuildozer 'substitute deps //old/(.*) //new/${1}' //pkg:rule\n\n# Delete the dependency on foo in every cc_library in the package\nbuildozer 'remove deps foo' //pkg:%cc_library\n\n# Delete the testonly attribute in every rule in the package\nbuildozer 'remove testonly' '//pkg:*'\n\n# Add a comment to the timeout attribute of //pkg:rule_test\nbuildozer 'comment timeout Delete\\ this\\ after\\ 2015-12-31.' //pkg:rule_test\n\n# Add a new rule at the end of the file\nbuildozer 'new java_library foo' //pkg:__pkg__\n\n# Add a cc_binary rule named new_bin before the rule named tests\nbuildozer 'new cc_binary new_bin before tests' //:__pkg__\n\n# Copy an attribute from `protolib` to `py_protolib`.\nbuildozer 'copy testonly protolib' //pkg:py_protolib\n\n# Set two attributes in the same rule\nbuildozer 'set compile 1' 'set srcmap 1' //pkg:rule\n\n# Make a default explicit in all soy_js rules in a package\nbuildozer 'set_if_absent allowv1syntax 1' //pkg:%soy_js\n\n# Add an attribute new_attr with value \"def_val\" to all cc_binary rules\n# Note that special characters will automatically be escaped in the string\nbuildozer 'add new_attr def_val' //:%cc_binary\n```\n\n### Print commands\n\nThey work just like the edit commands. Expect a return code of 3 as they are not\nmodifying any file.\n\n  * `print <attribute(s)>`: For each target, prints the value of the attributes\n   (see below).\n  * `print_comment <attr>? <value>?`: Prints a comment associated with a rule,\n    an attribute or a specific value in a list.\n\nThe print command prints the value of the attributes. If a target doesn't have\nthe attribute, a warning is printed on stderr.\n\nThere are some special attributes in the `print` command:\n\n  * `kind`: displays the name of the function\n  * `label`: the fully qualified label\n  * `rule`: the entire rule definition\n  * `startline`: the line number on which the rule begins in the BUILD file\n  * `endline`: the line number on which the rule ends in the BUILD file\n\n#### Examples\n\n```shell\n# Print the kind of a target\nbuildozer 'print kind' base  # output: cc_library\n\n# Print the name of all cc_library in //base\nbuildozer 'print name' base:%cc_library\n\n# Get the default visibility of the //base package\nbuildozer 'print default_visibility' base:%package\n\n# Print labels of cc_library targets in //base that have a deps attribute\nbuildozer 'print label deps' base:%cc_library 2>/dev/null | cut -d' ' -f1\n\n# Print the list of labels in //base that explicitly set the testonly attribute:\nbuildozer 'print label testonly' 'base:*' 2>/dev/null\n\n# Print the entire definition (including comments) of the //base:heapcheck rule:\nbuildozer 'print rule' //base:heapcheck\n```\n\n## Converting labels\n\nBuildozer works at the syntax-level. It doesn't evaluate the BUILD files. If you\nneed to query the information Bazel has, please use `bazel query`. If you have a\nlist of Bazel labels, chances are that some of them are generated by BUILD\nextensions. Labels in Buildozer are slightly different from labels in Bazel.\nBazel cares about the generated code, while Buildozer looks at the BUILD file\nbefore macro expansion.\n\nTo see the expanded BUILD files, try:\n\n```shell\nbazel query --output=build //path/to/BUILD\n```\n\n## Do multiple changes at once\n\nUse `buildozer -f <file>` to load a list of commands from a file. The usage is\njust like arguments on the command-line, except that arguments are separated by\n`|`.\n\n```shell\n$ cat /tmp/cmds\nnew cc_library foo|//buildtools/buildozer/BUILD\nadd deps //base //strings|add srcs foo.cc|//buildtools/buildozer:foo\nadd deps :foo|//buildtools/buildozer\n\n$ buildozer -f /tmp/cmds\nfixed //buildtools/buildozer/BUILD\n```\n\nThe list of commands will typically be generated and can be large. This is\nefficient: Commands are grouped so that each file is modified once. Files are\nprocessed in parallel.\n\n## Error code\n\nThe return code is:\n\n  * `0` on success, if changes were made\n  * `1` when there is a usage error\n  * `2` when at least one command has failed\n  * `3` on success, when no changes were made\n\n## Source Structure\n\n  * `buildozer/main.go` : Entry point for the buildozer binary\n  * `edit/buildozer.go` : Implementation of functions for the buildozer commands\n  * `edit/edit.go`: Library functions to perform various operations on ASTs. These\n  * functions are called by the impl functions in buildozer.go\n  * `edit/fix.go`:  Functions for various fixes for the `buildozer 'fix <fix(es)>'`\n   command, like cleaning unused loads, changing labels to canonical notation, etc.\n  * `edit/types.go`: Type information for attributes\n\n","vendor/github.com/googleapis/gnostic/extensions/README.md":"# Extensions\n\nThis directory contains support code for building Gnostic extensions and associated examples.\n\nExtensions are used to compile vendor or specification extensions into protocol buffer structures.\n",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n"},"files":{"vendor/github.com/bazelbuild/buildtools/buildozer/README.md":"# Buildozer\n\nBuildozer is a command line tool to rewrite multiple\n[Bazel](https://github.com/bazelbuild/bazel) BUILD files using\nstandard commands.\n\n## Dependencies\n\n1. Protobuf go runtime: to download\n`go get -u github.com/golang/protobuf/{proto,protoc-gen-go}`\n\n\n## Installation\n\n1. Change directory to the buildifier/buildozer\n\n```bash\ngopath=$(go env GOPATH)\ncd $gopath/src/github.com/bazelbuild/buildtools/buildozer\n```\n\n2. Install\n\n```bash\ngo install\n```\n\n## Usage\n\n```shell\nbuildozer [OPTIONS] ['command args' | -f FILE ] label-list\n```\n\nHere, `label-list` is a comma-separated list of Bazel labels, for example\n`//path/to/pkg1:rule1, //path/to/pkg2:rule2`. Buildozer reads commands from\n`FILE` (`-` for stdin (format: `|`-separated command line arguments to buildozer,\nexcluding flags))\n\nYou should specify at least one command and one target. Buildozer will execute\nall commands on all targets. Commands are executed in order, files are processed\nin parallel.\n\n### Targets\n\nTargets look like Bazel labels, but there can be some differences in presence of\nmacros.\n\n  * Use the label notation to refer to a rule: `//buildtools/buildozer:edit`\n  * Use the `__pkg__` suffix to refer to the package declaration:\n   `//buildtools/buildozer:__pkg__`\n  * Use an asterisk to refer to all rules in a file: `//pkg:*`\n  * Use `...` to refer to all descendant BUILD files in a directory: `//pkg/...:*`\n  * Use percent to refer to all rules of a certain kind: `//pkg:%java_library`\n  * Use percent-and-number to refer to a rule that begins at a certain line:\n   `//pkg:%123`.\n  * Use `-` for the package name if you want to process standard input stream\n   instead of a file: `-:all_tests`.\n\n### Options\n\nOPTIONS include the following options:\n\n  * `-stdout` : write changed BUILD file to stdout\n  * `-buildifier` : format output using a specific buildifier binary. If empty, use built-in formatter.\n  * `-k` : apply all commands, even if there are failures\n  * `-quiet` : suppress informational messages\n  * `-shorten_labels` : convert added labels to short form, e.g. //foo:bar => :bar\n  * `-types`: Filter the targets, keeping only those of the given types, e.g.\n    `buildozer -types go_library,go_binary 'print rule' '//buildtools/buildozer:*'`\n  * `-eol-comments=false`: When adding new comments, put them on a separate line.\n\nSee `buildozer -help` for the full list.\n\n### Edit commands\n\nBuildozer supports the following commands(`'command args'`):\n\n  * `add <attr> <value(s)>`: Adds value(s) to a list attribute of a rule. If a\n    value is already present in the list, it is not added.\n  * `new_load <path> <symbol(s)>`: Add a load statement for the given path,\n    importing the symbols. Before using this, make sure to run\n    `buildozer 'fix movePackageToTop'`. Afterwards, consider running\n    `buildozer 'fix unusedLoads'`.\n  * `comment <attr>? <value>? <comment>`: Add a comment to a rule, an attribute,\n    or a specific value in a list. Spaces in the comment should be escaped with\n    backslashes.\n  * `print_comment <attr>? <value>?`\n  * `delete`: Delete a rule.\n  * `fix <fix(es)>?`: Apply a fix.\n  * `move <old_attr> <new_attr> <value(s)>`: Moves `value(s)` from the list `old_attr`\n    to the list `new_attr`. The wildcard `*` matches all values.\n  * `new <rule_kind> <rule_name> [(before|after) <relative_rule_name>]`: Add a\n    new rule at the end of the BUILD file (before/after `<relative_rule>`).\n  * `print <attr(s)>`\n  * `remove <attr>`: Removes attribute `attr`.\n  * `remove <attr> <value(s)>`: Removes `value(s)` from the list `attr`. The\n    wildcard `*` matches all attributes. Lists containing none of the `value(s)` are\n    not modified.\n  * `rename <old_attr> <new_attr>`: Rename the `old_attr` to `new_attr` which must\n    not yet exist.\n  * `replace <attr> <old_value> <new_value>`: Replaces `old_value` with `new_value`\n    in the list `attr`. Wildcard `*` matches all attributes. Lists not containing\n    `old_value` are not modified.\n  * `substitute <attr> <old_regexp> <new_template>`: Replaces strings which\n    match `old_regexp` in the list `attr` according to `new_template`. Wildcard\n    `*` matches all attributes. The regular expression must follow\n    [RE2 syntax](https://github.com/google/re2/wiki/Syntax). `new_template` may\n    be a simple replacement string, but it may also expand numbered or named\n    groups using `$0` or `$x`. Lists without strings that match `old_regexp`\n    are not modified.\n  * `set <attr> <value(s)>`: Sets the value of an attribute. If the attribute\n    was already present, its old value is replaced.\n  * `set_if_absent <attr> <value(s)>`: Sets the value of an attribute. If the\n    attribute was already present, no action is taken.\n  * `set kind <value>`: Set the target type to value.\n  * `copy <attr> <from_rule>`: Copies the value of `attr` between rules. If it\n    exists in the `to_rule`, it will be overwritten.\n  * `copy_no_overwrite <attr> <from_rule>`:  Copies the value of `attr` between\n    rules. If it exists in the `to_rule`, no action is taken.\n\nHere, `<attr>` represents an attribute (being `add`ed/`rename`d/`delete`d etc.),\ne.g.: `srcs`, `<value(s)>` represents values of the attribute and so on.\nA '?' indicates that the preceding argument is optional.\n\nThe fix command without a fix specified applied to all eligible fixes.\nUse `//path/to/pkg:__pkg__` as label for file level changes like `new_load` and\n`new_rule`.\nA transformation can be applied to all rules of a particular kind by using\n`%rule_kind` at the end of the label(see examples below).\n\n#### Examples\n\n```bash\n# Edit //pkg:rule and //pkg:rule2, and add a dependency on //base\nbuildozer 'add deps //base' //pkg:rule //pkg:rule2\n\n# A load for a skylark file in //pkg\nbuildozer 'new_load /tools/build_rules/build_test build_test' //pkg:__pkg__\n\n# Change the default_visibility to public for the package //pkg\nbuildozer 'set default_visibility //visibility:public' //pkg:__pkg__\n\n# Change all gwt_module targets to java_library in the package //pkg\nbuildozer 'set kind java_library' //pkg:%gwt_module\n\n# Replace the dependency on pkg_v1 with a dependency on pkg_v2\nbuildozer 'replace deps //pkg_v1 //pkg_v2' //pkg:rule\n\n# Replace all dependencies using regular expressions.\nbuildozer 'substitute deps //old/(.*) //new/${1}' //pkg:rule\n\n# Delete the dependency on foo in every cc_library in the package\nbuildozer 'remove deps foo' //pkg:%cc_library\n\n# Delete the testonly attribute in every rule in the package\nbuildozer 'remove testonly' '//pkg:*'\n\n# Add a comment to the timeout attribute of //pkg:rule_test\nbuildozer 'comment timeout Delete\\ this\\ after\\ 2015-12-31.' //pkg:rule_test\n\n# Add a new rule at the end of the file\nbuildozer 'new java_library foo' //pkg:__pkg__\n\n# Add a cc_binary rule named new_bin before the rule named tests\nbuildozer 'new cc_binary new_bin before tests' //:__pkg__\n\n# Copy an attribute from `protolib` to `py_protolib`.\nbuildozer 'copy testonly protolib' //pkg:py_protolib\n\n# Set two attributes in the same rule\nbuildozer 'set compile 1' 'set srcmap 1' //pkg:rule\n\n# Make a default explicit in all soy_js rules in a package\nbuildozer 'set_if_absent allowv1syntax 1' //pkg:%soy_js\n\n# Add an attribute new_attr with value \"def_val\" to all cc_binary rules\n# Note that special characters will automatically be escaped in the string\nbuildozer 'add new_attr def_val' //:%cc_binary\n```\n\n### Print commands\n\nThey work just like the edit commands. Expect a return code of 3 as they are not\nmodifying any file.\n\n  * `print <attribute(s)>`: For each target, prints the value of the attributes\n   (see below).\n  * `print_comment <attr>? <value>?`: Prints a comment associated with a rule,\n    an attribute or a specific value in a list.\n\nThe print command prints the value of the attributes. If a target doesn't have\nthe attribute, a warning is printed on stderr.\n\nThere are some special attributes in the `print` command:\n\n  * `kind`: displays the name of the function\n  * `label`: the fully qualified label\n  * `rule`: the entire rule definition\n  * `startline`: the line number on which the rule begins in the BUILD file\n  * `endline`: the line number on which the rule ends in the BUILD file\n\n#### Examples\n\n```shell\n# Print the kind of a target\nbuildozer 'print kind' base  # output: cc_library\n\n# Print the name of all cc_library in //base\nbuildozer 'print name' base:%cc_library\n\n# Get the default visibility of the //base package\nbuildozer 'print default_visibility' base:%package\n\n# Print labels of cc_library targets in //base that have a deps attribute\nbuildozer 'print label deps' base:%cc_library 2>/dev/null | cut -d' ' -f1\n\n# Print the list of labels in //base that explicitly set the testonly attribute:\nbuildozer 'print label testonly' 'base:*' 2>/dev/null\n\n# Print the entire definition (including comments) of the //base:heapcheck rule:\nbuildozer 'print rule' //base:heapcheck\n```\n\n## Converting labels\n\nBuildozer works at the syntax-level. It doesn't evaluate the BUILD files. If you\nneed to query the information Bazel has, please use `bazel query`. If you have a\nlist of Bazel labels, chances are that some of them are generated by BUILD\nextensions. Labels in Buildozer are slightly different from labels in Bazel.\nBazel cares about the generated code, while Buildozer looks at the BUILD file\nbefore macro expansion.\n\nTo see the expanded BUILD files, try:\n\n```shell\nbazel query --output=build //path/to/BUILD\n```\n\n## Do multiple changes at once\n\nUse `buildozer -f <file>` to load a list of commands from a file. The usage is\njust like arguments on the command-line, except that arguments are separated by\n`|`.\n\n```shell\n$ cat /tmp/cmds\nnew cc_library foo|//buildtools/buildozer/BUILD\nadd deps //base //strings|add srcs foo.cc|//buildtools/buildozer:foo\nadd deps :foo|//buildtools/buildozer\n\n$ buildozer -f /tmp/cmds\nfixed //buildtools/buildozer/BUILD\n```\n\nThe list of commands will typically be generated and can be large. This is\nefficient: Commands are grouped so that each file is modified once. Files are\nprocessed in parallel.\n\n## Error code\n\nThe return code is:\n\n  * `0` on success, if changes were made\n  * `1` when there is a usage error\n  * `2` when at least one command has failed\n  * `3` on success, when no changes were made\n\n## Source Structure\n\n  * `buildozer/main.go` : Entry point for the buildozer binary\n  * `edit/buildozer.go` : Implementation of functions for the buildozer commands\n  * `edit/edit.go`: Library functions to perform various operations on ASTs. These\n  * functions are called by the impl functions in buildozer.go\n  * `edit/fix.go`:  Functions for various fixes for the `buildozer 'fix <fix(es)>'`\n   command, like cleaning unused loads, changing labels to canonical notation, etc.\n  * `edit/types.go`: Type information for attributes\n\n","vendor/github.com/googleapis/gnostic/extensions/README.md":"# Extensions\n\nThis directory contains support code for building Gnostic extensions and associated examples.\n\nExtensions are used to compile vendor or specification extensions into protocol buffer structures.\n",".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n"},"items":[{"name":"README.md","path":"vendor/github.com/bazelbuild/buildtools/buildozer/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/kubernetes/HEAD/vendor/github.com/bazelbuild/buildtools/buildozer/README.md","title":"buildozer Documentation","category":"plugin-manifest","format":"markdown","content":"# Buildozer\n\nBuildozer is a command line tool to rewrite multiple\n[Bazel](https://github.com/bazelbuild/bazel) BUILD files using\nstandard commands.\n\n## Dependencies\n\n1. Protobuf go runtime: to download\n`go get -u github.com/golang/protobuf/{proto,protoc-gen-go}`\n\n\n## Installation\n\n1. Change directory to the buildifier/buildozer\n\n```bash\ngopath=$(go env GOPATH)\ncd $gopath/src/github.com/bazelbuild/buildtools/buildozer\n```\n\n2. Install\n\n```bash\ngo install\n```\n\n## Usage\n\n```shell\nbuildozer [OPTIONS] ['command args' | -f FILE ] label-list\n```\n\nHere, `label-list` is a comma-separated list of Bazel labels, for example\n`//path/to/pkg1:rule1, //path/to/pkg2:rule2`. Buildozer reads commands from\n`FILE` (`-` for stdin (format: `|`-separated command line arguments to buildozer,\nexcluding flags))\n\nYou should specify at least one command and one target. Buildozer will execute\nall commands on all targets. Commands are executed in order, files are processed\nin parallel.\n\n### Targets\n\nTargets look like Bazel labels, but there can be some differences in presence of\nmacros.\n\n  * Use the label notation to refer to a rule: `//buildtools/buildozer:edit`\n  * Use the `__pkg__` suffix to refer to the package declaration:\n   `//buildtools/buildozer:__pkg__`\n  * Use an asterisk to refer to all rules in a file: `//pkg:*`\n  * Use `...` to refer to all descendant BUILD files in a directory: `//pkg/...:*`\n  * Use percent to refer to all rules of a certain kind: `//pkg:%java_library`\n  * Use percent-and-number to refer to a rule that begins at a certain line:\n   `//pkg:%123`.\n  * Use `-` for the package name if you want to process standard input stream\n   instead of a file: `-:all_tests`.\n\n### Options\n\nOPTIONS include the following options:\n\n  * `-stdout` : write changed BUILD file to stdout\n  * `-buildifier` : format output using a specific buildifier binary. If empty, use built-in formatter.\n  * `-k` : apply all commands, even if there are failures\n  * `-quiet` : suppress informational messages\n  * `-shorten_labels` : convert added labels to short form, e.g. //foo:bar => :bar\n  * `-types`: Filter the targets, keeping only those of the given types, e.g.\n    `buildozer -types go_library,go_binary 'print rule' '//buildtools/buildozer:*'`\n  * `-eol-comments=false`: When adding new comments, put them on a separate line.\n\nSee `buildozer -help` for the full list.\n\n### Edit commands\n\nBuildozer supports the following commands(`'command args'`):\n\n  * `add <attr> <value(s)>`: Adds value(s) to a list attribute of a rule. If a\n    value is already present in the list, it is not added.\n  * `new_load <path> <symbol(s)>`: Add a load statement for the given path,\n    importing the symbols. Before using this, make sure to run\n    `buildozer 'fix movePackageToTop'`. Afterwards, consider running\n    `buildozer 'fix unusedLoads'`.\n  * `comment <attr>? <value>? <comment>`: Add a comment to a rule, an attribute,\n    or a specific value in a list. Spaces in the comment should be escaped with\n    backslashes.\n  * `print_comment <attr>? <value>?`\n  * `delete`: Delete a rule.\n  * `fix <fix(es)>?`: Apply a fix.\n  * `move <old_attr> <new_attr> <value(s)>`: Moves `value(s)` from the list `old_attr`\n    to the list `new_attr`. The wildcard `*` matches all values.\n  * `new <rule_kind> <rule_name> [(before|after) <relative_rule_name>]`: Add a\n    new rule at the end of the BUILD file (before/after `<relative_rule>`).\n  * `print <attr(s)>`\n  * `remove <attr>`: Removes attribute `attr`.\n  * `remove <attr> <value(s)>`: Removes `value(s)` from the list `attr`. The\n    wildcard `*` matches all attributes. Lists containing none of the `value(s)` are\n    not modified.\n  * `rename <old_attr> <new_attr>`: Rename the `old_attr` to `new_attr` which must\n    not yet exist.\n  * `replace <attr> <old_value> <new_value>`: Replaces `old_value` with `new_value`\n    in the list `attr`. Wildcard `*` matches all attributes. Lists not containing\n    `old_value` are not modified.\n  * `substitute <attr> <old_regexp> <new_template>`: Replaces strings which\n    match `old_regexp` in the list `attr` according to `new_template`. Wildcard\n    `*` matches all attributes. The regular expression must follow\n    [RE2 syntax](https://github.com/google/re2/wiki/Syntax). `new_template` may\n    be a simple replacement string, but it may also expand numbered or named\n    groups using `$0` or `$x`. Lists without strings that match `old_regexp`\n    are not modified.\n  * `set <attr> <value(s)>`: Sets the value of an attribute. If the attribute\n    was already present, its old value is replaced.\n  * `set_if_absent <attr> <value(s)>`: Sets the value of an attribute. If the\n    attribute was already present, no action is taken.\n  * `set kind <value>`: Set the target type to value.\n  * `copy <attr> <from_rule>`: Copies the value of `attr` between rules. If it\n    exists in the `to_rule`, it will be overwritten.\n  * `copy_no_overwrite <attr> <from_rule>`:  Copies the value of `attr` between\n    rules. If it exists in the `to_rule`, no action is taken.\n\nHere, `<attr>` represents an attribute (being `add`ed/`rename`d/`delete`d etc.),\ne.g.: `srcs`, `<value(s)>` represents values of the attribute and so on.\nA '?' indicates that the preceding argument is optional.\n\nThe fix command without a fix specified applied to all eligible fixes.\nUse `//path/to/pkg:__pkg__` as label for file level changes like `new_load` and\n`new_rule`.\nA transformation can be applied to all rules of a particular kind by using\n`%rule_kind` at the end of the label(see examples below).\n\n#### Examples\n\n```bash\n# Edit //pkg:rule and //pkg:rule2, and add a dependency on //base\nbuildozer 'add deps //base' //pkg:rule //pkg:rule2\n\n# A load for a skylark file in //pkg\nbuildozer 'new_load /tools/build_rules/build_test build_test' //pkg:__pkg__\n\n# Change the default_visibility to public for the package //pkg\nbuildozer 'set default_visibility //visibility:public' //pkg:__pkg__\n\n# Change all gwt_module targets to java_library in the package //pkg\nbuildozer 'set kind java_library' //pkg:%gwt_module\n\n# Replace the dependency on pkg_v1 with a dependency on pkg_v2\nbuildozer 'replace deps //pkg_v1 //pkg_v2' //pkg:rule\n\n# Replace all dependencies using regular expressions.\nbuildozer 'substitute deps //old/(.*) //new/${1}' //pkg:rule\n\n# Delete the dependency on foo in every cc_library in the package\nbuildozer 'remove deps foo' //pkg:%cc_library\n\n# Delete the testonly attribute in every rule in the package\nbuildozer 'remove testonly' '//pkg:*'\n\n# Add a comment to the timeout attribute of //pkg:rule_test\nbuildozer 'comment timeout Delete\\ this\\ after\\ 2015-12-31.' //pkg:rule_test\n\n# Add a new rule at the end of the file\nbuildozer 'new java_library foo' //pkg:__pkg__\n\n# Add a cc_binary rule named new_bin before the rule named tests\nbuildozer 'new cc_binary new_bin before tests' //:__pkg__\n\n# Copy an attribute from `protolib` to `py_protolib`.\nbuildozer 'copy testonly protolib' //pkg:py_protolib\n\n# Set two attributes in the same rule\nbuildozer 'set compile 1' 'set srcmap 1' //pkg:rule\n\n# Make a default explicit in all soy_js rules in a package\nbuildozer 'set_if_absent allowv1syntax 1' //pkg:%soy_js\n\n# Add an attribute new_attr with value \"def_val\" to all cc_binary rules\n# Note that special characters will automatically be escaped in the string\nbuildozer 'add new_attr def_val' //:%cc_binary\n```\n\n### Print commands\n\nThey work just like the edit commands. Expect a return code of 3 as they are not\nmodifying any file.\n\n  * `print <attribute(s)>`: For each target, prints the value of the attributes\n   (see below).\n  * `print_comment <attr>? <value>?`: Prints a comment associated with a rule,\n    an attribute or a specific value in a list.\n\nThe print command prints the value of the attributes. If a target doesn't have\nthe attribute, a warning is printed on stderr.\n\nThere are some special attributes in the `print` command:\n\n  * `kind`: displays the name of the function\n  * `label`: the fully qualified label\n  * `rule`: the entire rule definition\n  * `startline`: the line number on which the rule begins in the BUILD file\n  * `endline`: the line number on which the rule ends in the BUILD file\n\n#### Examples\n\n```shell\n# Print the kind of a target\nbuildozer 'print kind' base  # output: cc_library\n\n# Print the name of all cc_library in //base\nbuildozer 'print name' base:%cc_library\n\n# Get the default visibility of the //base package\nbuildozer 'print default_visibility' base:%package\n\n# Print labels of cc_library targets in //base that have a deps attribute\nbuildozer 'print label deps' base:%cc_library 2>/dev/null | cut -d' ' -f1\n\n# Print the list of labels in //base that explicitly set the testonly attribute:\nbuildozer 'print label testonly' 'base:*' 2>/dev/null\n\n# Print the entire definition (including comments) of the //base:heapcheck rule:\nbuildozer 'print rule' //base:heapcheck\n```\n\n## Converting labels\n\nBuildozer works at the syntax-level. It doesn't evaluate the BUILD files. If you\nneed to query the information Bazel has, please use `bazel query`. If you have a\nlist of Bazel labels, chances are that some of them are generated by BUILD\nextensions. Labels in Buildozer are slightly different from labels in Bazel.\nBazel cares about the generated code, while Buildozer looks at the BUILD file\nbefore macro expansion.\n\nTo see the expanded BUILD files, try:\n\n```shell\nbazel query --output=build //path/to/BUILD\n```\n\n## Do multiple changes at once\n\nUse `buildozer -f <file>` to load a list of commands from a file. The usage is\njust like arguments on the command-line, except that arguments are separated by\n`|`.\n\n```shell\n$ cat /tmp/cmds\nnew cc_library foo|//buildtools/buildozer/BUILD\nadd deps //base //strings|add srcs foo.cc|//buildtools/buildozer:foo\nadd deps :foo|//buildtools/buildozer\n\n$ buildozer -f /tmp/cmds\nfixed //buildtools/buildozer/BUILD\n```\n\nThe list of commands will typically be generated and can be large. This is\nefficient: Commands are grouped so that each file is modified once. Files are\nprocessed in parallel.\n\n## Error code\n\nThe return code is:\n\n  * `0` on success, if changes were made\n  * `1` when there is a usage error\n  * `2` when at least one command has failed\n  * `3` on success, when no changes were made\n\n## Source Structure\n\n  * `buildozer/main.go` : Entry point for the buildozer binary\n  * `edit/buildozer.go` : Implementation of functions for the buildozer commands\n  * `edit/edit.go`: Library functions to perform various operations on ASTs. These\n  * functions are called by the impl functions in buildozer.go\n  * `edit/fix.go`:  Functions for various fixes for the `buildozer 'fix <fix(es)>'`\n   command, like cleaning unused loads, changing labels to canonical notation, etc.\n  * `edit/types.go`: Type information for attributes\n\n","isInternal":false,"tokens":2882,"sizeBytes":10772},{"name":"README.md","path":"vendor/github.com/googleapis/gnostic/extensions/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/kubernetes/HEAD/vendor/github.com/googleapis/gnostic/extensions/README.md","title":"extensions Documentation","category":"plugin-manifest","format":"markdown","content":"# Extensions\n\nThis directory contains support code for building Gnostic extensions and associated examples.\n\nExtensions are used to compile vendor or specification extensions into protocol buffer structures.\n","isInternal":false,"tokens":31,"sizeBytes":208},{"name":".cursorrules","path":".cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/kubernetes-mkdocs-documentation-cursorrules-prompt.mdc","title":"Awesome Cursorrules: kubernetes mkdocs documentation cursorrules prompt","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n","tokens":173,"sizeBytes":957}],"systemPromptSnippet":"<yakaai_skills repo=\"alibaba/kubernetes\">\n<!-- File: vendor/github.com/bazelbuild/buildtools/buildozer/README.md (Tokens: ~2882 | Category: plugin-manifest) -->\n# Buildozer\n\nBuildozer is a command line tool to rewrite multiple\n[Bazel](https://github.com/bazelbuild/bazel) BUILD files using\nstandard commands.\n\n## Dependencies\n\n1. Protobuf go runtime: to download\n`go get -u github.com/golang/protobuf/{proto,protoc-gen-go}`\n\n\n## Installation\n\n1. Change directory to the buildifier/buildozer\n\n```bash\ngopath=$(go env GOPATH)\ncd $gopath/src/github.com/bazelbuild/buildtools/buildozer\n```\n\n2. Install\n\n```bash\ngo install\n```\n\n## Usage\n\n```shell\nbuildozer [OPTIONS] ['command args' | -f FILE ] label-list\n```\n\nHere, `label-list` is a comma-separated list of Bazel labels, for example\n`//path/to/pkg1:rule1, //path/to/pkg2:rule2`. Buildozer reads commands from\n`FILE` (`-` for stdin (format: `|`-separated command line arguments to buildozer,\nexcluding flags))\n\nYou should specify at least one command and one target. Buildozer will execute\nall commands on all targets. Commands are executed in order, files are processed\nin parallel.\n\n### Targets\n\nTargets look like Bazel labels, but there can be some differences in presence of\nmacros.\n\n  * Use the label notation to refer to a rule: `//buildtools/buildozer:edit`\n  * Use the `__pkg__` suffix to refer to the package declaration:\n   `//buildtools/buildozer:__pkg__`\n  * Use an asterisk to refer to all rules in a file: `//pkg:*`\n  * Use `...` to refer to all descendant BUILD files in a directory: `//pkg/...:*`\n  * Use percent to refer to all rules of a certain kind: `//pkg:%java_library`\n  * Use percent-and-number to refer to a rule that begins at a certain line:\n   `//pkg:%123`.\n  * Use `-` for the package name if you want to process standard input stream\n   instead of a file: `-:all_tests`.\n\n### Options\n\nOPTIONS include the following options:\n\n  * `-stdout` : write changed BUILD file to stdout\n  * `-buildifier` : format output using a specific buildifier binary. If empty, use built-in formatter.\n  * `-k` : apply all commands, even if there are failures\n  * `-quiet` : suppress informational messages\n  * `-shorten_labels` : convert added labels to short form, e.g. //foo:bar => :bar\n  * `-types`: Filter the targets, keeping only those of the given types, e.g.\n    `buildozer -types go_library,go_binary 'print rule' '//buildtools/buildozer:*'`\n  * `-eol-comments=false`: When adding new comments, put them on a separate line.\n\nSee `buildozer -help` for the full list.\n\n### Edit commands\n\nBuildozer supports the following commands(`'command args'`):\n\n  * `add <attr> <value(s)>`: Adds value(s) to a list attribute of a rule. If a\n    value is already present in the list, it is not added.\n  * `new_load <path> <symbol(s)>`: Add a load statement for the given path,\n    importing the symbols. Before using this, make sure to run\n    `buildozer 'fix movePackageToTop'`. Afterwards, consider running\n    `buildozer 'fix unusedLoads'`.\n  * `comment <attr>? <value>? <comment>`: Add a comment to a rule, an attribute,\n    or a specific value in a list. Spaces in the comment should be escaped with\n    backslashes.\n  * `print_comment <attr>? <value>?`\n  * `delete`: Delete a rule.\n  * `fix <fix(es)>?`: Apply a fix.\n  * `move <old_attr> <new_attr> <value(s)>`: Moves `value(s)` from the list `old_attr`\n    to the list `new_attr`. The wildcard `*` matches all values.\n  * `new <rule_kind> <rule_name> [(before|after) <relative_rule_name>]`: Add a\n    new rule at the end of the BUILD file (before/after `<relative_rule>`).\n  * `print <attr(s)>`\n  * `remove <attr>`: Removes attribute `attr`.\n  * `remove <attr> <value(s)>`: Removes `value(s)` from the list `attr`. The\n    wildcard `*` matches all attributes. Lists containing none of the `value(s)` are\n    not modified.\n  * `rename <old_attr> <new_attr>`: Rename the `old_attr` to `new_attr` which must\n    not yet exist.\n  * `replace <attr> <old_value> <new_value>`: Replaces `old_value` with `new_value`\n    in the list `attr`. Wildcard `*` matches all attributes. Lists not containing\n    `old_value` are not modified.\n  * `substitute <attr> <old_regexp> <new_template>`: Replaces strings which\n    match `old_regexp` in the list `attr` according to `new_template`. Wildcard\n    `*` matches all attributes. The regular expression must follow\n    [RE2 syntax](https://github.com/google/re2/wiki/Syntax). `new_template` may\n    be a simple replacement string, but it may also expand numbered or named\n    groups using `$0` or `$x`. Lists without strings that match `old_regexp`\n    are not modified.\n  * `set <attr> <value(s)>`: Sets the value of an attribute. If the attribute\n    was already present, its old value is replaced.\n  * `set_if_absent <attr> <value(s)>`: Sets the value of an attribute. If the\n    attribute was already present, no action is taken.\n  * `set kind <value>`: Set the target type to value.\n  * `copy <attr> <from_rule>`: Copies the value of `attr` between rules. If it\n    exists in the `to_rule`, it will be overwritten.\n  * `copy_no_overwrite <attr> <from_rule>`:  Copies the value of `attr` between\n    rules. If it exists in the `to_rule`, no action is taken.\n\nHere, `<attr>` represents an attribute (being `add`ed/`rename`d/`delete`d etc.),\ne.g.: `srcs`, `<value(s)>` represents values of the attribute and so on.\nA '?' indicates that the preceding argument is optional.\n\nThe fix command without a fix specified applied to all eligible fixes.\nUse `//path/to/pkg:__pkg__` as label for file level changes like `new_load` and\n`new_rule`.\nA transformation can be applied to all rules of a particular kind by using\n`%rule_kind` at the end of the label(see examples below).\n\n#### Examples\n\n```bash\n# Edit //pkg:rule and //pkg:rule2, and add a dependency on //base\nbuildozer 'add deps //base' //pkg:rule //pkg:rule2\n\n# A load for a skylark file in //pkg\nbuildozer 'new_load /tools/build_rules/build_test build_test' //pkg:__pkg__\n\n# Change the default_visibility to public for the package //pkg\nbuildozer 'set default_visibility //visibility:public' //pkg:__pkg__\n\n# Change all gwt_module targets to java_library in the package //pkg\nbuildozer 'set kind java_library' //pkg:%gwt_module\n\n# Replace the dependency on pkg_v1 with a dependency on pkg_v2\nbuildozer 'replace deps //pkg_v1 //pkg_v2' //pkg:rule\n\n# Replace all dependencies using regular expressions.\nbuildozer 'substitute deps //old/(.*) //new/${1}' //pkg:rule\n\n# Delete the dependency on foo in every cc_library in the package\nbuildozer 'remove deps foo' //pkg:%cc_library\n\n# Delete the testonly attribute in every rule in the package\nbuildozer 'remove testonly' '//pkg:*'\n\n# Add a comment to the timeout attribute of //pkg:rule_test\nbuildozer 'comment timeout Delete\\ this\\ after\\ 2015-12-31.' //pkg:rule_test\n\n# Add a new rule at the end of the file\nbuildozer 'new java_library foo' //pkg:__pkg__\n\n# Add a cc_binary rule named new_bin before the rule named tests\nbuildozer 'new cc_binary new_bin before tests' //:__pkg__\n\n# Copy an attribute from `protolib` to `py_protolib`.\nbuildozer 'copy testonly protolib' //pkg:py_protolib\n\n# Set two attributes in the same rule\nbuildozer 'set compile 1' 'set srcmap 1' //pkg:rule\n\n# Make a default explicit in all soy_js rules in a package\nbuildozer 'set_if_absent allowv1syntax 1' //pkg:%soy_js\n\n# Add an attribute new_attr with value \"def_val\" to all cc_binary rules\n# Note that special characters will automatically be escaped in the string\nbuildozer 'add new_attr def_val' //:%cc_binary\n```\n\n### Print commands\n\nThey work just like the edit commands. Expect a return code of 3 as they are not\nmodifying any file.\n\n  * `print <attribute(s)>`: For each target, prints the value of the attributes\n   (see below).\n  * `print_comment <attr>? <value>?`: Prints a comment associated with a rule,\n    an attribute or a specific value in a list.\n\nThe print command prints the value of the attributes. If a target doesn't have\nthe attribute, a warning is printed on stderr.\n\nThere are some special attributes in the `print` command:\n\n  * `kind`: displays the name of the function\n  * `label`: the fully qualified label\n  * `rule`: the entire rule definition\n  * `startline`: the line number on which the rule begins in the BUILD file\n  * `endline`: the line number on which the rule ends in the BUILD file\n\n#### Examples\n\n```shell\n# Print the kind of a target\nbuildozer 'print kind' base  # output: cc_library\n\n# Print the name of all cc_library in //base\nbuildozer 'print name' base:%cc_library\n\n# Get the default visibility of the //base package\nbuildozer 'print default_visibility' base:%package\n\n# Print labels of cc_library targets in //base that have a deps attribute\nbuildozer 'print label deps' base:%cc_library 2>/dev/null | cut -d' ' -f1\n\n# Print the list of labels in //base that explicitly set the testonly attribute:\nbuildozer 'print label testonly' 'base:*' 2>/dev/null\n\n# Print the entire definition (including comments) of the //base:heapcheck rule:\nbuildozer 'print rule' //base:heapcheck\n```\n\n## Converting labels\n\nBuildozer works at the syntax-level. It doesn't evaluate the BUILD files. If you\nneed to query the information Bazel has, please use `bazel query`. If you have a\nlist of Bazel labels, chances are that some of them are generated by BUILD\nextensions. Labels in Buildozer are slightly different from labels in Bazel.\nBazel cares about the generated code, while Buildozer looks at the BUILD file\nbefore macro expansion.\n\nTo see the expanded BUILD files, try:\n\n```shell\nbazel query --output=build //path/to/BUILD\n```\n\n## Do multiple changes at once\n\nUse `buildozer -f <file>` to load a list of commands from a file. The usage is\njust like arguments on the command-line, except that arguments are separated by\n`|`.\n\n```shell\n$ cat /tmp/cmds\nnew cc_library foo|//buildtools/buildozer/BUILD\nadd deps //base //strings|add srcs foo.cc|//buildtools/buildozer:foo\nadd deps :foo|//buildtools/buildozer\n\n$ buildozer -f /tmp/cmds\nfixed //buildtools/buildozer/BUILD\n```\n\nThe list of commands will typically be generated and can be large. This is\nefficient: Commands are grouped so that each file is modified once. Files are\nprocessed in parallel.\n\n## Error code\n\nThe return code is:\n\n  * `0` on success, if changes were made\n  * `1` when there is a usage error\n  * `2` when at least one command has failed\n  * `3` on success, when no changes were made\n\n## Source Structure\n\n  * `buildozer/main.go` : Entry point for the buildozer binary\n  * `edit/buildozer.go` : Implementation of functions for the buildozer commands\n  * `edit/edit.go`: Library functions to perform various operations on ASTs. These\n  * functions are called by the impl functions in buildozer.go\n  * `edit/fix.go`:  Functions for various fixes for the `buildozer 'fix <fix(es)>'`\n   command, like cleaning unused loads, changing labels to canonical notation, etc.\n  * `edit/types.go`: Type information for attributes\n\n<!-- File: vendor/github.com/googleapis/gnostic/extensions/README.md (Tokens: ~31 | Category: plugin-manifest) -->\n# Extensions\n\nThis directory contains support code for building Gnostic extensions and associated examples.\n\nExtensions are used to compile vendor or specification extensions into protocol buffer structures.\n\n<!-- File: .cursorrules (kubernetes-mkdocs-documentation-cursorrules-prompt.mdc) (Tokens: ~173 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Kubernetes development with MkDocs documentation integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert Technical Writer with a deep understanding of cloud native technologies, Kubernetes, and technical documentation best practices. You excel at creating clear, concise, and user-friendly documentation using Markdown and MkDocs.\n\nYou always use the latest stable versions of Kubernetes, cloud native tools, and MkDocs. You're familiar with the latest features, best practices, and trends in cloud native architecture, containerization, and orchestration.\n\nDocumentation Style and Structure:\n\nCloud Native and Kubernetes Expertise:\n\nMkDocs Usage:\n\nContent Creation:\n\nTechnical Accuracy and Usability:\n\nDocumentation Best Practices:\n\nMetadata and SEO:\n\nCollaboration and Version Control:\n\nOther Rules to follow:\n\nDon't be lazy, provide thorough and accurate documentation for all requested topics and features.\n</yakaai_skills>"}