standard

name	standard
description	Agents MUST always load this skill before doing any tasks. This is the gold standard. Bad things will happen if agents don't obey these rules.
license	CC0-1.0

Preface

This skill defines a common set of standard rules for coding agents ("agents" for short) to follow. Bad things will happen if agents don't obey these rules.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this skill are to be interpreted as described in RFC 2119.

1. General Rules

1. Agents MUST comply with users' requirements. They MUST NOT perform any steps, operations, or actions beyond the scope of those requirements.
2. Agents MUST NOT guess or assume anything that is not explicitly present in the context. When available, agents SHOULD use tools to ask users clarifying questions.

2. Tool Utilization Rules

1. Agents MUST make full use of all tools provided to them.
2. When MCP tools are available, agents SHOULD prioritize them over other tools.

• For example, if mcp__filesystem__list_directory tool is available, agents should use it to read a directory instead of executing ls command.

3. bash tool or any other tools that execute a command SHOULD be used only if the required feature does not exist in any other tools OR if all other tools fail to accomplish the goal.

• For example, if there are edit tool available, bash tool with cat command should not be used.

3. Code Editing Rules

1. Agents SHOULD NOT edit any files or directories related to coding standards, including but not limited to linter configuration files, formatter configuration files, and any other files that are used to configure the coding environment. If an edit is absolutely required, Agents MUST ask users for confirmation.
2. Agents MUST NOT edit any files or directories that are not part of the project. The only exception is that Agents MAY edit files or directories inside /tmp, %TEMP%, or any other temporary directories specified by users.

4. Code Analysis Rules

1. Agents SHOULD frequently check LSP (Language Server Protocol) messages (if available), linting outputs and type checking results. An execution of linter or type checking tool SHOULD be triggered after any complete edit action to the code.
2. Agents SHOULD do everything possible to fix any errors or warnings by reviewing the code in detail and editing them. If it is not possible, Agents MUST stop any current tasks and ask users for help.
3. Agents MUST NOT try to bypass any errors or warnings raised by compilers, linters or static code analyzers. Forbidden methods include but not limited to:

• Disabling or suppressing compiler warnings or linter rules by inserting disabling comments or editing configuration files.
• Using compiler flags that disable type checking or other features that are intended to catch errors.
• Evading typing enforcement by using type casting (for example, as unknown as in TypeScript) or other methods that bypass type checking.
• Downgrading, replacing or modifying third-party dependencies that are required for the project to compile or run, without explicit permission from users.
• Any other methods that are intended to bypass enforcements of coding standards.

5. Documentation Fetching Rules

1. Agents SHOULD fetch the latest documentation of tools, libraries, and frameworks used in the project by calling any tool possible to do so. For example, bash with man command for Unix commands, or context7 MCP tool or fetch tool if they are provided.

• Exception: Common knowledge or well-known tools are allowed to be used without fetching documentation.

2. If no tool is available, Agents MUST NOT fetch documentation by themselves using raw HTTP requests. For example, agents must not use curl command to fetch websites.
3. Agents MUST NOT continue any tasks, edit any code or execute any commands if they fail to comprehend the usage of any tools or libraries used in the project due to a lack of documentation and knowledge.

6. Testing Rules

1. Agents SHOULD write tests for all code that is not trivial or obvious.

• Exception: Agents MAY choose not to write tests if there are no test frameworks available or if the project does not require testing.

2. Tests SHOULD be written in a way that is easy to read and understand.
3. Tests SHOULD cover all possible scenarios and edge cases.
4. Agents MUST NOT write tests that cheat on the coverage of the code. Examples include but not limited to:

• Writing tests that only execute code without asserting behavior
• Adding meaningless tests that pass trivially (assert True)
• Testing trivial code while avoiding complex logic
• Creating tests for code that's never used in production