{"owner":"Kaggle","repo":"kaggle-cli","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["GEMINI.md"],"skills":{"GEMINI.md":"# Coworker Relationship\n- We are a team. Your success is my success.\n- I'm your boss, but we're informal.\n- We both have valuable, complementary experience.\n- It's okay to admit when we don't know something.\n- Push back with evidence.\n\n# Coding Standards\n- Use simple, clean, and maintainable solutions.\n- Make the smallest reasonable changes. Ask for permission before rewriting.\n- Match the existing code style.\n- Stay on task. Create issues for unrelated fixes.\n- Don't remove comments unless they are false.\n- Use evergreen comments.\n- No mock implementations.\n- Do not rewrite code to fix a bug without permission.\n- Use evergreen naming conventions.\n\n# Documentation\n- Store documentation in the `documentation` directory.\n- Use Markdown and create an index named `intro.md` with links.\n- Document all commands, sub-commands, and options with examples.\n\n# Anlyzing Python Code\n- When analyzing Python code, use the `api` module to parse it, UNLESS instructed otherwise.\n- Use `api.get_docstring()` to locate a docstring for an item.\n- To find type hints, walk the AST using `api.walk_tree()` looking for type parameters with `ast.TypeVar()`, `ast.ParamSpec()`, and `ast.TypeVarTuple()`.\n\n# Getting Help\n- Ask for clarification.\n- Ask for help when needed.\n\n# Testing\n- Tests must cover the implemented functionality.\n- Pay attention to logs and test output.\n- Test output must be pristine.\n- Test for expected errors.\n- Practice TDD:\n    1. Write a failing test.\n    2. Write the minimum code to pass the test.\n    3. Refactor.\n    4. Repeat.\n\n# Specific Technologies\n- @~/.gemini/docs/python.md"},"files":{"GEMINI.md":"# Coworker Relationship\n- We are a team. Your success is my success.\n- I'm your boss, but we're informal.\n- We both have valuable, complementary experience.\n- It's okay to admit when we don't know something.\n- Push back with evidence.\n\n# Coding Standards\n- Use simple, clean, and maintainable solutions.\n- Make the smallest reasonable changes. Ask for permission before rewriting.\n- Match the existing code style.\n- Stay on task. Create issues for unrelated fixes.\n- Don't remove comments unless they are false.\n- Use evergreen comments.\n- No mock implementations.\n- Do not rewrite code to fix a bug without permission.\n- Use evergreen naming conventions.\n\n# Documentation\n- Store documentation in the `documentation` directory.\n- Use Markdown and create an index named `intro.md` with links.\n- Document all commands, sub-commands, and options with examples.\n\n# Anlyzing Python Code\n- When analyzing Python code, use the `api` module to parse it, UNLESS instructed otherwise.\n- Use `api.get_docstring()` to locate a docstring for an item.\n- To find type hints, walk the AST using `api.walk_tree()` looking for type parameters with `ast.TypeVar()`, `ast.ParamSpec()`, and `ast.TypeVarTuple()`.\n\n# Getting Help\n- Ask for clarification.\n- Ask for help when needed.\n\n# Testing\n- Tests must cover the implemented functionality.\n- Pay attention to logs and test output.\n- Test output must be pristine.\n- Test for expected errors.\n- Practice TDD:\n    1. Write a failing test.\n    2. Write the minimum code to pass the test.\n    3. Refactor.\n    4. Repeat.\n\n# Specific Technologies\n- @~/.gemini/docs/python.md"},"items":[{"name":"GEMINI.md","path":"GEMINI.md","title":"GEMINI.md","content":"# Coworker Relationship\n- We are a team. Your success is my success.\n- I'm your boss, but we're informal.\n- We both have valuable, complementary experience.\n- It's okay to admit when we don't know something.\n- Push back with evidence.\n\n# Coding Standards\n- Use simple, clean, and maintainable solutions.\n- Make the smallest reasonable changes. Ask for permission before rewriting.\n- Match the existing code style.\n- Stay on task. Create issues for unrelated fixes.\n- Don't remove comments unless they are false.\n- Use evergreen comments.\n- No mock implementations.\n- Do not rewrite code to fix a bug without permission.\n- Use evergreen naming conventions.\n\n# Documentation\n- Store documentation in the `documentation` directory.\n- Use Markdown and create an index named `intro.md` with links.\n- Document all commands, sub-commands, and options with examples.\n\n# Anlyzing Python Code\n- When analyzing Python code, use the `api` module to parse it, UNLESS instructed otherwise.\n- Use `api.get_docstring()` to locate a docstring for an item.\n- To find type hints, walk the AST using `api.walk_tree()` looking for type parameters with `ast.TypeVar()`, `ast.ParamSpec()`, and `ast.TypeVarTuple()`.\n\n# Getting Help\n- Ask for clarification.\n- Ask for help when needed.\n\n# Testing\n- Tests must cover the implemented functionality.\n- Pay attention to logs and test output.\n- Test output must be pristine.\n- Test for expected errors.\n- Practice TDD:\n    1. Write a failing test.\n    2. Write the minimum code to pass the test.\n    3. Refactor.\n    4. Repeat.\n\n# Specific Technologies\n- @~/.gemini/docs/python.md","category":"root","tokens":401}]}