Add Code Assist

.gemini/config.yaml

@@ -0,0 +1,35 @@
+# Gemini Code Assist configuration for Samsung/Tizen.NET
+# Docs: https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github
+
+have_fun: false
+
+code_review:
+  disable: false
+  # MEDIUM: only flag meaningful issues. Lower (LOW) = noisy, higher (HIGH) = misses subtle bugs.
+  comment_severity_threshold: MEDIUM
+  # Hard cap to avoid drowning contributors in bot noise on large PRs.
+  max_review_comments: 5
+  pull_request_opened:
+    help: false
+    summary: true
+    code_review: true
+
+# Skip generated, vendored, and non-source files.
+ignore_patterns:
+  # Build / IDE artifacts
+  - "**/bin/**"
+  - "**/obj/**"
+  - "**/.vs/**"
+  - "**/*.Designer.cs"
+  - "**/*.generated.cs"
+
+  # Data file (workload version map) — not source code, line-by-line review adds noise.
+  - "workload/scripts/version-map.json"
+
+  # Docs and assets
+  - "**/*.md"
+  - "assets/**"
+
+  # Lockfiles / package metadata
+  - "**/packages.lock.json"
+  - "**/NuGet.config"

.gemini/styleguide.md

@@ -0,0 +1,20 @@
+# Tizen.NET Code Review Style Guide
+
+This guide instructs Gemini Code Assist on how to review pull requests in the
+`Samsung/Tizen.NET` repository. The repo provides the **Tizen workload for the
+.NET SDK**, so reviews must consider workload manifests, install scripts, and
+multi-branch (per-SDK-band) layout — not just C# code style.
+
+## 1. Project Context
+
+- This repo ships the **Tizen workload for the .NET SDK**.
+- Active branches map to .NET SDK bands (e.g., `main`, `net10.0`, `net9.0`, `net8.0`, `net7.0`, `net6.0`). The same file may have legitimately different content across branches — don't reflexively suggest "syncing" content across branches.
+- `workload/scripts/workload-install.sh` and `workload-install.ps1` are end-user-facing install scripts. Behavior changes there have user-visible blast radius.
+
+## 2. Tone / What NOT to comment on
+
+- Do **not** nitpick `.md`, `assets/`, or generated files (already in `ignore_patterns`, but reinforced here).
+- Do **not** suggest churning existing code style just because newer C# syntax exists.
+- Do **not** propose architectural rewrites in a small PR. Keep suggestions scoped to the diff.
+- Do **not** reflexively suggest adding tests for trivial constant changes or version bumps.
+- Reviews should be terse and technical. No emoji, no congratulatory language.