com um clique
style-review
// Review changed or staged C# code against the docs-builder coding standards and flag violations. Use when the user asks to review code style, check for standards violations, or audit a diff before committing.
// Review changed or staged C# code against the docs-builder coding standards and flag violations. Use when the user asks to review code style, check for standards violations, or audit a diff before committing.
Stage relevant files and create a well-formed git commit for the docs-builder repo. Use this when the user asks to commit changes, save work, or create a commit.
Auto-fix all formatting issues in the docs-builder repo — runs dotnet format for C# and npm fmt:write for TypeScript/JS. Use when the user asks to fix formatting, lint the code, or when a pre-commit hook fails due to formatting.
Create a GitHub pull request for the current branch with a focused why/what body and exactly one release-drafter label. Use when the user asks to open a PR, create a pull request, or ship a branch.
Run the relevant tests for what changed — detects whether to run C# unit tests, specific test projects, integration tests, or JS/TS tests based on changed files. Use when the user asks to run tests, verify changes, or check if something is broken.
Search, analyze, and author Elastic documentation using the remote MCP server. Use this when the user asks about Elastic product documentation, features, or APIs; wants to find, read, or verify existing docs pages; is writing or editing documentation; mentions cross-links between repos; asks about documentation structure, coherence, or consistency; wants to generate templates following Elastic content type guidelines; or references elastic.co/docs URLs or Elastic product names.
| name | style-review |
| description | Review changed or staged C# code against the docs-builder coding standards and flag violations. Use when the user asks to review code style, check for standards violations, or audit a diff before committing. |
Reviews C# changes for violations that dotnet format and .editorconfig cannot catch — behavioral patterns, naming conventions, and architectural rules.
.editorconfig + dotnet format already enforce (mechanically):
var everywhere, no explicit typesthis. qualifierstring not String){?., ??)is/as castsout var x)[] instead of new List<T>() / Array.Empty<T>()Run dotnet format (or /lint) to fix those. Only continue with this skill for the behavioral checks below.
git diff # unstaged changes
git diff --staged # staged changes
git diff main...HEAD # full branch
Async correctness (error-level):
Async; private async methods must NOT.Result or .Wait() on an async call.ConfigureAwait(false) on awaitsCancellationToken ct = defaultMethod design (error-level):
Structural (error-level):
#region directivesReturn values (error-level):
null — must return []Testing (style-level, in tests/ and tests-integration/):
MethodName_Scenario_ExpectedShould().Be(...) not Assert.Equal(...))Comments (style-level):
#region (already error-level above)Format violations as a numbered list with severity:
ERROR:
1. src/Elastic.Markdown/Foo.cs:42 — public async method `GetData` missing `Async` suffix
2. src/Elastic.Markdown/Foo.cs:67 — `.Result` blocks on async call; use `await`
STYLE:
3. tests/Elastic.Markdown.Tests/Bar.cs:15 — test name `TestGetUser` should follow `GetUser_ValidId_ReturnsUser` pattern
If no violations: "No behavioral style violations found."
Report only. For formatting issues, run /lint. For logic violations (blocking async, null collections), the developer must fix manually.