@khoavu882/doflow 0.0.0-stage → 2.0.0-beta.3

package/core/shared/skills/do-code-review/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: do-code-review
+description: Code review automation for TypeScript, JavaScript, Python, Go, Swift, Kotlin, C#, .NET, Java, C, C++, Rust, Ruby, PHP, Dart/Flutter, and Shell, plus declarative YAML/JSON config and OpenAPI specs. Analyzes PRs for complexity and risk, checks code quality for SOLID violations and code smells, generates review reports. Use when reviewing pull requests, analyzing code quality, identifying issues, generating review checklists.
+---
+
+# Code Reviewer
+
+Automated code review tools for analyzing pull requests, detecting code quality issues, and generating review reports.
+
+---
+
+## How This Skill Is Organized
+
+### Loading order for every review
+
+1. This file (`SKILL.md`) — tools and thresholds
+2. `rules/universal.md` — always, for every language
+3. The matching `languages/*.md` — one file based on the extension table below
+
+Two additional files for code (`rules/universal.md` + one `languages/*.md`); one for prose
+(`content-types/markdown.md`, which has no universal counterpart).
+
+| Extension(s) | Load |
+|---|---|
+| `.py` | `languages/python.md` |
+| `.ts`, `.tsx`, `.js`, `.jsx`, `.mjs` | `languages/typescript.md` |
+| `.go` | `languages/go.md` |
+| `.swift` | `languages/swift.md` |
+| `.kt`, `.kts` | `languages/kotlin.md` |
+| `.cs`, `.csx`, `.razor`, `.cshtml` | `languages/csharp.md` |
+| `.java` | `languages/java.md` |
+| `.c`, `.h` | `languages/c.md` |
+| `.cpp`, `.cc`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `languages/cpp.md` |
+| `.rs` | `languages/rust.md` |
+| `.rb`, `.rake`, `.gemspec`, `.ru` | `languages/ruby.md` |
+| `.php`, `.phtml` | `languages/php.md` |
+| `.dart` | `languages/dart.md` |
+| `.sh`, `.bash`, `.zsh` | `languages/shell.md` |
+
+---
+
+### Content-type dispatch
+
+For non-code content, a second axis applies alongside (or instead of) the language table above:
+
+| Content type | Extension(s) | Load |
+|---|---|---|
+| Markdown / prose | `.md` | `content-types/markdown.md` |
+| Declarative config | `.yaml`, `.yml`, `.json` | `content-types/config.md` |
+
+Markdown dispatch runs `scripts/doc_quality_checker.py` instead of `code_quality_checker.py` — see
+`content-types/markdown.md` for the checks it performs. Declarative config stays with
+`code_quality_checker.py`, which routes those extensions to a structural path that reports no
+complexity, function count or SOLID verdict — see `content-types/config.md` for why.
+
+---
+
+## The Review Contract
+
+State this before producing a single finding, and report against it when the review ends.
+
+1. **The file set, and how it was derived** — the `pr_analyzer.py` diff between base and head, the
+   paths the user named, or the working tree. Name the derivation, not just the count. A file the
+   derivation includes but the review never opened is reported as not reviewed; it is never dropped
+   from the list.
+2. **The rules files that will load** — from the dispatch tables above: `rules/universal.md` plus
+   one `languages/*.md` per code file, `content-types/markdown.md` per prose file. Name them before
+   loading them, so a file reviewed under the wrong rules is visible rather than plausible.
+3. **What this review refuses to conclude** — it does not certify a file it did not open, does not
+   report a threshold the analyzer does not implement, and does not convert a score into a verdict
+   the table below does not define. A check that could not run is reported as not run.
+4. **The coverage the analyzer actually achieved** — `code_quality_checker.py` reports
+   `files_analyzed`, `files_skipped` and a `coverage` of `complete` or `partial`. Report all three.
+   A `partial` coverage means the verdict describes the analysed subset, and saying so is not
+   optional: a score presented as if it covered the whole change is the defect this contract exists
+   to prevent.
+5. **Process-leak scan** — run
+   `doflow leak-scan --path <each reviewed file> --json` over the reviewed set. These are DoFlow's
+   own identifiers (`FR-###`, `agent-docs/`, chain artifact names) reaching files that ship to
+   people who never used DoFlow. Occurrences inside `agent-docs/` are correct usage and the verb
+   excludes them itself. The verb reports and never blocks.
+
+   **Say which kind of repository you are scanning before you list anything.** A repository that
+   *uses* DoFlow should contain none of this vocabulary outside `agent-docs/`, so every finding is
+   worth a line. A repository that *implements* it — DoFlow's own tree, or any project vendoring the
+   chain — contains it correctly and by the hundred: its scaffold generator writes `requirement.md`,
+   its guards assert on `FR-###`, its changelog describes the chain. Listing those individually
+   teaches a reviewer to skip this step, and a skipped check protects nothing.
+
+   So: in an implementing repository, narrow the scan with `--exclude <segment>` (repeatable, and it
+   extends the artifact-directory exclusion rather than replacing it), and report the count you
+   excluded alongside the findings you kept. Never silently drop a path — the verb reports an
+   excluded file as `unscanned` with its reason, and so should you.
+
+   **Derive the exclusion set, do not judge it by eye.** What a repository *implements* is what its
+   package manifest ships plus its tests — for DoFlow that is `package.json`'s
+   `files: ["bin/", "src/", "core/"]`, so the set is `--exclude bin --exclude src --exclude core
+   --exclude test`. Reading "the code that ships onward" as a matter of judgement is how this step
+   was first narrowed wrong: `bin/` was left in and its internal requirement references were
+   reported as leaks, when `bin/` is as much DoFlow's implementation as `src/` is.
+
+   What survives that exclusion in an implementing repository is documentation *about* the chain —
+   a changelog, a docs tree — which contains the vocabulary correctly and in volume. Report the
+   count and say so, rather than pasting it. In DoFlow's own repository this step therefore has no
+   applicable surface at all, and saying that plainly is the honest result, not a failure to look.
+
+**Stop when** every file in the reviewed set the contract names has an answer or a stated gap, **and** the last round produced no new file in the reviewed set. A round that only restates what you already have is the last round. Report the remaining gaps rather than continuing.
+
+---
+
+## Tools
+
+### PR Analyzer
+
+Analyzes git diff between branches to assess review complexity and identify risks.
+
+```bash
+# Analyze current branch against main
+python scripts/pr_analyzer.py /path/to/repo
+
+# Compare specific branches
+python scripts/pr_analyzer.py . --base main --head feature-branch
+
+# JSON output for integration
+python scripts/pr_analyzer.py /path/to/repo --json
+```
+
+**Extracted — what the analyzer detects** (universal; see also the language file for
+language-specific signals):
+- Hardcoded secrets (passwords, API keys, tokens, connection strings)
+- SQL / query injection patterns
+- Debug statements left in production code
+- Lint / analyzer suppression annotations
+- TODO/FIXME comments
+
+**Language-specific detections** are defined in each `languages/*.md` file.
+
+**Inferred — what the report concludes from those detections:**
+- Complexity score (1-10)
+- Risk categorization (critical, high, medium, low)
+- File prioritization for review order
+- Commit message validation
+
+Report the two halves apart. A detection is a locator in a file; a conclusion is your reading of
+several of them, and merging them into one line is how a reading stops being falsifiable.
+
+---
+
+### Code Quality Checker
+
+Analyzes source code for structural issues, code smells, and SOLID violations.
+
+```bash
+# Analyze a directory
+python scripts/code_quality_checker.py /path/to/code
+
+# Analyze specific language
+# Valid values: python, typescript, javascript, go, swift, kotlin, csharp, java, c, cpp, rust, ruby, php, dart
+python scripts/code_quality_checker.py . --language java
+
+# JSON output
+python scripts/code_quality_checker.py /path/to/code --json
+```
+
+**Universal thresholds:** declared in `review-policy.json`, never here. A guard fails the suite if a
+number from it reappears in any document. Read what a run applies from the run: `--json` carries a
+`policy` block naming the thresholds in force and the tiers that supplied them.
+
+Three tiers resolve into one, lowest precedence first: the analyzer's built-in literal, the shipped
+`review-policy.json` beside this file, then `agent-docs/review-policy.json` in the repository under
+review, which a project's tech lead owns. A per-repo file is **partial** — declare only what you are
+changing — and its absence is the ordinary state. A file that does not parse, names an unknown group,
+or gives a threshold a non-integer value stops the analyzer naming the file and the problem rather
+than reverting to defaults under a maintainer who believes their tuning applies. The policy also
+declares severities, the verdict bands below, and the globs a review excludes.
+
+The per-repo tier is found by walking up from the analysed path, so a target outside any repository
+resolves none, which the `policy` block makes visible.
+
+Language-specific checks are defined in each `languages/*.md` file.
+
+---
+
+### Review Report Generator
+
+Combines PR analysis and code quality findings into structured review reports.
+
+```bash
+# Generate report for current repo
+python scripts/review_report_generator.py /path/to/repo
+
+# Markdown output
+python scripts/review_report_generator.py . --format markdown --output review.md
+
+# Use pre-computed analyses
+python scripts/review_report_generator.py . \
+  --pr-analysis pr_results.json \
+  --quality-analysis quality_results.json
+```
+
+**Verdicts:** the bands live in `review-policy.json` under `verdictBands`, for the same reason the
+thresholds do. They are **declared, never applied**: they orient a reviewer reading a score, and
+nothing computes the verdict from one. A verdict may therefore disagree with the band a score falls
+in, provided the report says so and why.
+
+---
+
+## Recording the Review
+
+1. **Resolve the runtime seam** — every DoFlow runtime call in this skill goes through the runtime
+   seam. Resolve it **once** here and reuse `$DOFLOW` for every later call in this skill:
+
+```bash
+# Resolve the DoFlow runtime: nearest project install wins, then the global one.
+D=$PWD; while [ "$D" != / ] && [ ! -x "$D/.doflow/scripts/doflow/bin/doflow-run" ]; do D=$(dirname "$D"); done
+DOFLOW="$D/.doflow/scripts/doflow/bin/doflow-run"
+[ -x "$DOFLOW" ] || DOFLOW="$HOME/.doflow/scripts/doflow/bin/doflow-run"
+[ -x "$DOFLOW" ] || { echo "doflow: no runtime found in any .doflow/ above $PWD, nor at $HOME/.doflow. Run: npx @khoavu882/doflow install -t <harness>" >&2; exit 2; }
+```
+
+   Run every command below from the project root — the walk-up starts at `$PWD`. On exit 2, print
+   the message verbatim and stop; it names every path searched.
+
+2. **Batch this stage's evidence** — one pass here at the stage boundary, never one call per fact.
+   `<task id>` is the unit these stores key on — the same id the chain's earlier stages recorded
+   against, or the feature slug when this review runs standalone. Use it for every `evidence` and
+   `claim` call this review makes:
+   ```bash
+   "$DOFLOW" evidence --task-id "<task id>" --action add --batch <batch>.json --json
+   "$DOFLOW" claim --task-id "<task id>" --action add --statement "<one conclusion>"
+   ```
+   Item schema, provenance rules, and the refused-field list: the guidance tree's
+   `references/EVIDENCE_LEDGER.md`. Read it before writing the batch.
+
+   This stage's items are its findings. A finding read from code — a detection surfaced by the PR
+   Analyzer, the Code Quality Checker, or your own reading of a diff line — is `extracted` and
+   carries a `locator`. A judgement the reviewer reached about that finding — severity, root cause,
+   whether it blocks — is `inferred` and carries `content`. Keep the two distinguishable in the
+   batch the way the Tools section above already keeps a detection distinguishable from a
+   conclusion in the report: never file a judgement as if it were something the code itself stated.
+   Add the review's verdict rationale and any other conclusion as a claim in the same pass.
+
+   A finding never carries `score`, `confidence`, `relevance` or a similarity field — the runtime
+   refuses those keys by name and the whole batch writes nothing. The Complexity score and Risk
+   categorization this skill's Tools compute are inputs to your `content`, never fields on the item.
+
+   This gains the review no gate: recording evidence and claims here is bookkeeping, not authority.
+   `do-code-review` still cannot block a merge or stop a downstream stage — only the Block verdict
+   in its own report, read by a human or by `/do-implement`, does that.
+
+3. **Record the handoff, then handle this stage's gate** — read the guidance tree's
+   `references/WORKFLOW_HANDOFF.md`. When a feature is active, use its slug:
+   ```bash
+   "$DOFLOW" orchestrate --action handoff --task-id "<feature_slug>" --calling-skill do-code-review --result <passed|failed> --note "<verdict and finding counts>" --json
+   ```
+   The runtime derives the class and stage from the existing run. `standalone` creates no run
+   and asks no gate question. `deferred` reports a prior gate, unfinished mutating stage or
+   rejected run: report its `reason` and leave that transition to its owner. `completed` records
+   the review; `annotated` records a re-review without replaying any stage.
+   Only a `completed` handoff can present a newly reached gate owned by this stage, below.
+   - **The gate after this stage — check that one exists before trying to resolve one.** Read the
+     handoff response's `awaitingGate` field; do not re-derive it from `workflow.gates[]`.
+     - **`awaitingGate` is non-null and its `gateId` is anchored after this stage** — `gate-b`,
+       "Before commit or merge", in the `feature` workflow, which is the only shipped class with any
+       gate at all. This stage is that workflow's last and nothing downstream runs to ask it (its own
+       `handoff` sends commit and merge to `/do-git`, outside the workflow), so ask it here: put
+       `awaitingGate.prompt` to the user through `AskUserQuestion` as a plain go/no-go. Its trigger
+       is `always` — nothing in this review's own output answers it, so never approve it mechanically.
+       No gate is ever auto-approved by `catch-up`, `clarification`-kind included — only a human or
+       that gate's own owning skill decides it. On approve:
+       ```bash
+       "$DOFLOW" orchestrate --action decide-gate --task-id "<feature_slug>" --gate "<awaitingGate.gateId>" --decision approve --note "<the user's own answer, one line>" --json
+       ```
+       On "not yet", leave the gate open and say so plainly — the run stays `AWAITING_GATE` and the
+       user can decide later. Do not send `--decision reject` for a deferral: reject terminates the
+       run outright, which is a different answer from "not now", and do not force the approval.
+     - **`awaitingGate` is `null`** — there is no gate to resolve. `bug`, `refactor`, `review`,
+       `documentation` and `dependency-change` declare none, so the response comes back with the run
+       either `COMPLETED` or simply advanced. Say the review is recorded and stop: do not fabricate a
+       prompt, and do not call `decide-gate` on a gate that does not exist.
+     - When `/do-flow` is driving the chain it presents this gate and records the answer itself. That
+       needs no special-casing here: a gate it already decided is no longer open, so the `catch-up`
+       above never stops on it and `awaitingGate` comes back `null` — the same no-op branch.
+     Finish by rendering the trail — the `--slug` value attaches with an `=`; a space-separated one
+     is rejected with an error rather than silently rendering the wrong feature's trail:
+     ```bash
+     "$DOFLOW" render-audit --slug="<feature_slug>" --json
+     ```
+   - This step gains the review no authority either, exactly as step 2's own note says: the gate
+     records the user's answer, it does not produce one. If any call here fails for a reason outside
+     this flow's control (an unwritable local state directory, say), report the failure plainly and
+     continue — a missing `audit.md` entry changes nothing about the verdict already reported.
+
+## Embedded feature research
+
+For an external fact gap or explicit request, follow the conditional protocol in `../do-document/references/embedded-research.md` before stage completion.
+
+## Boundaries
+
+**Will:** Analyze source and prose for complexity, risk, SOLID violations, and code/doc smells;
+generate structured review reports with a verdict (Approve / Approve with suggestions / Request
+changes / Block); dispatch by language or content type to the matching rules file; record the review
+stage's handoff and put the workflow's final approval gate to the user when this review is part of a
+chain *and* the run reports such a gate open.
+
+**Will Not:** Edit files, apply fixes, or otherwise remediate the findings it reports — that is
+`/do-implement`'s job once a review has run. It does not answer the final gate on the user's behalf,
+approve it mechanically from its own verdict, ask for a gate the workflow does not declare, resolve a
+gate anchored before its own stage, or start a workflow run for a standalone review. It also does not orchestrate a multi-task checklist
+through specialist subagents (`/do-execute-plan`'s job) or replace human judgment on a Block verdict.
+
+## Running the review in a subagent
+
+A review over a large change can be dispatched whole to the `quality-guardian` archetype, which
+already declares code quality review among its capabilities, and which returns its report to the
+calling session. Use it when the analysis would otherwise consume context the caller still needs for
+the work itself.
+
+This changes **where** the review runs and nothing else: the dispatched review loads the same rules
+files by the same dispatch tables, states the same Review Contract, and returns the same verdict
+vocabulary. A dispatched review that reports differently from an in-session one is a defect, not a
+variant.
+
+Review read-only at `frontier`, with an agent and model different from the author; pass `model:`
+where supported. Re-review only an open blocker tests cannot settle, after asking. See
+`references/MODEL_SELECTION.md`.
+
+This is not the multi-task orchestration the boundary above rules out: one review, one subagent, one
+report back.
+
+## Next Step
+After review, use `/do-implement` to address requested changes, then rerun `/do-code-review`.
+On a clean review with nothing left to fix, consider `/do-document --type impl` to record what was built — optional, and does not gate or pause completion.

package/core/shared/skills/do-code-review/assets/sample_c_clean.c

@@ -0,0 +1,71 @@
+/*
+ * sample_c_clean.c — sample_c_smells.c refactored per
+ * rules/universal.md + languages/c.md. Same surface area, zero
+ * detector hits.
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+
+void safe_input(void) {
+    char buf[64];
+
+    /* fgets is bounds-aware */
+    if (fgets(buf, sizeof(buf), stdin) == NULL) {
+        return;
+    }
+
+    char dest[10];
+    /* strncpy with explicit bound + manual null-terminate */
+    strncpy(dest, buf, sizeof(dest) - 1);
+    dest[sizeof(dest) - 1] = '\0';
+
+    /* strncat with remaining-space bound */
+    size_t room = sizeof(dest) - strlen(dest) - 1;
+    strncat(dest, "world", room);
+
+    char msg[100];
+    /* snprintf is bounds-aware */
+    snprintf(msg, sizeof(msg), "%s says hello", buf);
+
+    /* Format string is a literal; buf is an argument */
+    printf("%s\n", buf);
+
+    char name[32];
+    /* %s with explicit width prevents overflow */
+    scanf("%31s", name);
+}
+
+
+void checked_alloc(int n) {
+    /* malloc result is NULL-checked before any dereference */
+    char *buf = malloc(n);
+    if (buf == NULL) {
+        return;
+    }
+    buf[0] = 'x';
+    buf[1] = 'y';
+    strncpy(buf, "ok", n - 1);
+
+    free(buf);
+    buf = NULL;
+    printf("done\n");
+}
+
+
+void run_safe_cmd(void) {
+    /* system() with a string literal — no command-injection surface */
+    system("ls -la");
+}
+
+
+int main(int argc, char *argv[]) {
+    (void)argc;
+    (void)argv;
+    safe_input();
+    checked_alloc(100);
+    run_safe_cmd();
+    return 0;
+}

package/core/shared/skills/do-code-review/assets/sample_c_smells.c

@@ -0,0 +1,66 @@
+/*
+ * sample_c_smells.c — labelled instances of every C-specific pattern
+ * the code-reviewer skill flags. Every smell is annotated inline with
+ * its CWE and the rule from languages/c.md.
+ *
+ * Refactored counterpart: sample_c_clean.c
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+
+void unsafe_input(void) {
+    char buf[64];
+
+    /* RULE: banned function gets() — CWE-242, no bounds check */
+    gets(buf);
+
+    char dest[10];
+    /* RULE: banned function strcpy() — no bounds check */
+    strcpy(dest, buf);
+
+    /* RULE: banned function strcat() — no bounds check */
+    strcat(dest, "world");
+
+    char msg[100];
+    /* RULE: banned function sprintf() — no bounds check */
+    sprintf(msg, "%s says hello", buf);
+
+    /* RULE: format-string vulnerability — CWE-134, buf controls format */
+    printf(buf);
+
+    char name[32];
+    /* RULE: unbounded scanf — %s without width, CWE-120 */
+    scanf("%s", name);
+}
+
+
+void leaky_alloc(int n) {
+    /* RULE: malloc result not NULL-checked within 5 lines — CWE-690 */
+    char *buf = malloc(n);
+    buf[0] = 'x';
+    buf[1] = 'y';
+    strcpy(buf, "leak");
+
+    /* RULE: free without zeroing pointer — CWE-416 dangling */
+    free(buf);
+    printf("done\n");
+}
+
+
+void run_user_cmd(const char *cmd_from_user) {
+    /* RULE: system() with non-literal argument — CWE-78 command injection */
+    system(cmd_from_user);
+}
+
+
+int main(int argc, char *argv[]) {
+    if (argc > 1) {
+        unsafe_input();
+        leaky_alloc(100);
+        run_user_cmd(argv[1]);
+    }
+    return 0;
+}

package/core/shared/skills/do-code-review/assets/sample_cpp_shift.cpp

@@ -0,0 +1,19 @@
+// Fixture guarding the heredoc language gate. `<<` here is stream insertion, not a heredoc
+// opener, and the lone `total` line below is an expression statement, not a terminator.
+// Without the gate this function scored complexity 1 instead of 7: every branch between the
+// two was blanked as a heredoc body. See _blank_heredocs in code_quality_checker.py.
+#include <iostream>
+
+void report(int total) {
+    std::cout << total
+    if (total > 0 && total < 100) {
+        for (int i = 0; i < total; i++) {
+            if (i % 2) { log(i); }
+        }
+    }
+    while (total-- > 0) {
+        switch (total) { case 1: break; default: break; }
+    }
+    total
+    ;
+}

package/core/shared/skills/do-code-review/assets/sample_csharp_clean.cs

@@ -0,0 +1,100 @@
+// Sample C# file showing the fixed version of sample_csharp_smells.cs.
+// Same shape, but every smell has been resolved per the patterns documented
+// in rules/universal.md and languages/csharp.md.
+//
+// Run:
+//   python scripts/code_quality_checker.py assets/sample_csharp_clean.cs
+//
+// Expected: no HIGH C#-specific smells flagged.
+
+using System;
+using System.Net.Http;
+using System.Threading.Tasks;
+using System.Data.SqlClient;
+using Microsoft.Extensions.Logging;
+using Microsoft.Extensions.Options;
+
+namespace Sample
+{
+    public class DbOptions
+    {
+        // FIX: connection string from configuration, never inlined.
+        public string ConnectionString { get; init; } = "";
+    }
+
+    public class UserService
+    {
+        private readonly string _connectionString;
+        private readonly HttpClient _httpClient;
+        private readonly ILogger<UserService> _logger;
+
+        // FIX: IHttpClientFactory + IOptions, no hardcoded secrets, no `new HttpClient()`.
+        public UserService(
+            IHttpClientFactory httpClientFactory,
+            IOptions<DbOptions> dbOptions,
+            ILogger<UserService> logger)
+        {
+            _httpClient = httpClientFactory.CreateClient("api");
+            _connectionString = dbOptions.Value.ConnectionString;
+            _logger = logger;
+        }
+
+        // FIX: async Task (not async void) so callers can await and observe exceptions.
+        public async Task HandleClickAsync()
+        {
+            // FIX: await the Task instead of blocking on it.
+            var data = await FetchAsync().ConfigureAwait(false);
+            _logger.LogInformation("Fetched {Length} bytes", data.Length);
+        }
+
+        public async Task<string> FetchAsync()
+        {
+            try
+            {
+                // FIX: await the async call — Task is no longer discarded.
+                await FireAndForgetAsync().ConfigureAwait(false);
+
+                // FIX: real null check, no `!`.
+                var user = await GetCurrentUserAsync().ConfigureAwait(false);
+                if (user is null)
+                {
+                    throw new InvalidOperationException("No current user");
+                }
+                _ = user.Name;
+
+                return await _httpClient
+                    .GetStringAsync("https://api.example/data")
+                    .ConfigureAwait(false);
+            }
+            catch (HttpRequestException ex)
+            {
+                // FIX: catch specific exception, log with context, rethrow.
+                _logger.LogError(ex, "Upstream fetch failed");
+                throw;
+            }
+        }
+
+        // FIX: real type, not `dynamic`.
+        public User? CurrentUser { get; private set; }
+
+        // FIX: `unsafe` removed — none of the logic actually needed pointers.
+        public int FirstValue(int[] values) => values.Length > 0 ? values[0] : 0;
+
+        // FIX: no #pragma / [SuppressMessage] — root cause fixed instead.
+        public string GetName(int id)
+        {
+            // FIX: `using var` disposes connection + command deterministically.
+            using var conn = new SqlConnection(_connectionString);
+            // FIX: parameterized query, no string concatenation.
+            using var cmd = new SqlCommand("SELECT name FROM users WHERE id = @id", conn);
+            cmd.Parameters.AddWithValue("@id", id);
+            conn.Open();
+            return (string)cmd.ExecuteScalar();
+        }
+
+        private Task<User?> GetCurrentUserAsync() => Task.FromResult<User?>(null);
+        private Task FireAndForgetAsync() => Task.CompletedTask;
+    }
+
+    public record User(int Id, string Name);
+}

package/core/shared/skills/do-code-review/assets/sample_csharp_smells.cs

@@ -0,0 +1,78 @@
+// Sample C# file demonstrating every C#-specific pattern the code-reviewer
+// skill detects. Each smell is labelled inline. This file is NOT meant to
+// compile cleanly — it is a fixture for code_quality_checker.py and
+// pr_analyzer.py.
+//
+// Run:
+//   python scripts/code_quality_checker.py assets/sample_csharp_smells.cs
+//
+// Expected output: see expected_outputs/sample_csharp_smells_quality.json
+
+using System;
+using System.Net.Http;
+using System.Threading.Tasks;
+using System.Data.SqlClient;
+using System.Diagnostics.CodeAnalysis;
+
+namespace Sample
+{
+    public class UserService
+    {
+        // [hardcoded_secrets] hardcoded connection string with password
+        public string ConnectionString = "Server=prod;Database=app;Password=hunter2;";
+
+        // [csharp_async_void] async void on a non-event-handler signature
+        public async void HandleClick(object sender, EventArgs e)
+        {
+            // [csharp_blocking_async] .Result blocks on Task in a sync context
+            var data = FetchAsync().Result;
+            // [console_log] Debug.WriteLine output statement
+            Debug.WriteLine(data);
+        }
+
+        public async Task<string> FetchAsync()
+        {
+            // [csharp_new_httpclient] new HttpClient() in method body
+            // [csharp_undisposed_idisposable] HttpClient not in `using`
+            var client = new HttpClient();
+
+            try
+            {
+                // [csharp_missing_await] FireAndForgetAsync() returns Task, never awaited
+                FireAndForgetAsync();
+
+                // [csharp_null_forgiving] `user!.Name` forces null-forgiving
+                var name = user!.Name;
+
+                return await client.GetStringAsync("https://api.example/data");
+            }
+            catch (Exception)
+            {
+                // [csharp_swallowed_exception] empty catch (Exception)
+            }
+            return null!;
+        }
+
+        // [loose_type] C# `dynamic` overuse
+        public dynamic Untyped = null;
+
+        // [csharp_unsafe_block] `unsafe` modifier on a method
+        public unsafe void Pointers()
+        {
+            int x = 0;
+            int* p = &x;
+        }
+
+        // [analyzer_disable] #pragma warning disable
+        #pragma warning disable CS0168
+        // [analyzer_disable] [SuppressMessage] attribute
+        [SuppressMessage("Style", "IDE0060")]
+        public string GetName(SqlConnection conn, int id)
+        {
+            // [csharp_undisposed_idisposable] SqlCommand without `using`
+            // [sql_concatenation] string concatenation builds SQL with user input
+            var cmd = new SqlCommand("SELECT name FROM users WHERE id = " + id, conn);
+            return cmd.ExecuteScalar().ToString();
+        }
+    }
+}