Creating data for some local tests that will connect to Gerrit
Change-Id: I4779786ccb76a4e45424eb000e856a84711c601a
diff --git a/fake_configs/config.textproto b/fake_configs/config.textproto
new file mode 100644
index 0000000..578c5ee
--- /dev/null
+++ b/fake_configs/config.textproto
@@ -0,0 +1,72 @@
+configs: {
+ id: "first-config-id_123"
+ display_name: "First Agent Config 123"
+ description: "First config entry that in the agent list"
+ skills: "kotlin_best_practices"
+ include_filters: {
+ project: "projectA"
+ }
+ include_filters: {
+ project: "projectB"
+ path_regex: ".*\\.kt"
+ }
+}
+
+configs: {
+ id: "second-config-id_123"
+ display_name: "Second Agent Config 123"
+ description: "Second config entry that in the agent list"
+ skills: "typescript_best_practices"
+ include_filters: {
+ project: "projectB"
+ path_regex: ".*\\.ts"
+ }
+ include_filters: {
+ path_regex: "/some/folder/.*"
+ }
+ exclude_filters: {
+ project: "projectA"
+ project: "projectC"
+ }
+}
+
+configs: {
+ id: "third-config-id_123"
+ display_name: "Multiple skills"
+ description: "Configuration with multiple skills"
+ skills: "typescript_best_practices"
+ skills: "chaotic_code_detective"
+ include_filters: {
+ path_regex: ".*\\.ts"
+ }
+}
+
+configs: {
+ id: "conflicting-includes"
+ display_name: "Conflicting includes"
+ description: "Project in both include and exclude filters. Expected to be excluded."
+ skills: "typescript_best_practices"
+ include_filters: {
+ project: "projectA"
+ project: "projectD"
+ }
+ exclude_filters: {
+ project: "projectA"
+ project: "projectC"
+ }
+}
+
+configs: {
+ id: "exclude-specific-path"
+ display_name: "Exclude Specific Paths"
+ description: "Should only exclude files in specific paths for a project but not other paths or projects"
+ skills: "typescript_best_practices"
+ include_filters: {
+ project: "projectA"
+ path_regex: ".*\\.ts"
+ }
+ exclude_filters: {
+ project: "projectA"
+ path_regex: "some/file/path/.*\\.ts"
+ }
+}
\ No newline at end of file
diff --git a/fake_configs/fake_skills/chaotic_code_detective/SKILL.md b/fake_configs/fake_skills/chaotic_code_detective/SKILL.md
new file mode 100644
index 0000000..cdc666c
--- /dev/null
+++ b/fake_configs/fake_skills/chaotic_code_detective/SKILL.md
@@ -0,0 +1,57 @@
+---
+name: chaotic-code-detective
+description: Analyzes source code for signs of developer burnout, confusion, and "creative" naming conventions. Use this skill when a pull request contains variable names like 'temp123' or comments that simply say 'TODO: fix later'.
+license: MIT
+metadata:
+ humor-level: "high"
+ saltiness-factor: "medium-rare"
+---
+
+# Chaotic Code Detective (CCD)
+
+This skill is designed to identify "Organic Codebases"—code that has grown wild and untamed, much like a jungle or a moldy sandwich left in the breakroom since 2022.
+
+## Detection Heuristics
+
+### 1. The "Naming of Parts"
+Flag any variable names that indicate the developer has given up on life:
+- **The Mystery Box:** `data`, `info`, `result`, `stuff`.
+- **The Desperation:** `fixMePlease`, `itWorksNow`, `FINAL_FINAL_v2`.
+- **The Keyboard Smash:** `asdf`, `qwerty`, `jkl`.
+
+### 2. Comment Archeology
+Search for "Load-Bearing Comments" that hold the entire infrastructure together:
+- `// I don't know why this works, don't touch it.`
+- `// Magic happens here.`
+- `// Dear future me: fix this.`
+- `// This is a temporary fix (Written: 6 years ago).`
+
+### 3. Complexity Metrics
+- **The Lasagna Factor:** Too many layers of abstraction to find the actual logic.
+- **The Spaghetti Incident:** A single function that is longer than the average CVS receipt (300+ lines).
+- **The Pyramid of Doom:** Nested `if` statements that reach the right-hand margin of the monitor.
+
+## Remediation Protocol
+
+If chaos is detected, the agent should suggest the following "best" practices:
+
+1. **The 3:00 AM Rule:** If the logic makes sense at 3:00 AM, it is likely wrong. Rewrite it when caffeinated.
+2. **Delete it anyway:** If a block of code is commented out, delete it. Version control is not a digital attic.
+3. **Rubber Ducking:** If the code is too complex to explain to a rubber duck, explain it to a real duck. The legal fees for bringing a bird into the office are worth the clarity.
+
+## Common Warning Signs
+
+| Symptom | Diagnosis | Recommended Treatment |
+| :--- | :--- | :--- |
+| `try { ... } catch { // ignore }` | Extreme Optimism | Apply actual error handling. |
+| Functions named `doEverything()` | Universal Object Syndrome | Break it into "Do One Tiny Thing" functions. |
+| Hardcoded API keys in plain text | Security Nihilism | Use environment variables and a deep sigh. |
+
+## Examples
+
+**Input (Bad):**
+```typescript
+const x = (a: any) => {
+ const b = a.c ? a.c : 'idk'; // logic goes here maybe
+ return b;
+}
\ No newline at end of file
diff --git a/fake_configs/fake_skills/kotlin_best_practices/SKILL.md b/fake_configs/fake_skills/kotlin_best_practices/SKILL.md
new file mode 100644
index 0000000..7a10a74
--- /dev/null
+++ b/fake_configs/fake_skills/kotlin_best_practices/SKILL.md
@@ -0,0 +1,69 @@
+---
+name: kotlin-best-practices
+description: Validates Kotlin code against official JetBrains/Google Kotlin style guides and best practices. Use this skill when reviewing Kotlin code, refactoring, or ensuring idiomatic usage of features like null safety, coroutines, and functional programming patterns.
+license: MIT
+metadata:
+ version: "1.0.0"
+ reference: "https://kotlinlang.org/docs/coding-conventions.html"
+---
+
+# Kotlin Best Practices Checker
+
+This skill provides a systematic framework for reviewing Kotlin source code to ensure it adheres to the official Kotlin Coding Conventions and idiomatic "Kotlin-first" principles.
+
+## Review Methodology
+
+When analyzing Kotlin code, evaluate the following categories in order:
+
+### 1. Formatting & Naming
+- **Class/Object Naming:** Use `PascalCase`.
+- **Function/Property Naming:** Use `camelCase`.
+- **Packages:** Use lowercase without underscores (e.g., `org.example.project`).
+- **Indentation:** Use 4 spaces (standard) or 2 spaces (if following specific Android/Google styles).
+
+### 2. Idiomatic Syntax
+Check for "Java-isms" that should be replaced with Kotlin idioms:
+- Use `val` by default; only use `var` if mutation is strictly necessary.
+- Prefer string templates (`"Hello, $name!"`) over concatenation.
+- Use `when` expressions instead of long `if-else-if` chains.
+- Use `filter`, `map`, and `flatMap` for collection processing instead of manual loops.
+
+### 3. Null Safety
+- Avoid use of the "not-null assertion operator" `!!` unless absolutely necessary.
+- Prefer safe calls `?.` and the Elvis operator `?:`.
+- Check for redundant null checks (e.g., checking `if (x != null)` before using `?.`).
+
+### 4. Classes and Functions
+- Use `data class` for classes that only hold data.
+- Prefer `extension functions` to extend functionality of classes you don't own.
+- Use `default arguments` instead of function overloading.
+- Use `apply`, `with`, `run`, `also`, and `let` (Scope Functions) appropriately:
+ - `let`: For executing a block on a non-null object.
+ - `apply`: For object configuration (returns the object).
+ - `also`: For side effects (returns the object).
+
+### 5. Coroutines & Concurrency
+- Ensure `suspend` functions are used for long-running tasks.
+- Check that `GlobalScope` is avoided in favor of structured concurrency (e.g., `viewModelScope`, `lifecycleScope`, or custom `CoroutineScope`).
+
+## Common Anti-Patterns to Flag
+
+| Anti-Pattern | Recommended Alternative |
+| :--- | :--- |
+| `if (obj is Type) { (obj as Type).member }` | `if (obj is Type) { obj.member }` (Smart cast) |
+| `public` modifiers on everything | Kotlin is `public` by default; omit the modifier. |
+| Large `try-catch` blocks for flow control | Use `runCatching` or specific functional error handling. |
+| Manual singleton implementation | Use the `object` keyword. |
+
+## Example Checklist for Code Review
+
+1. [ ] Are all variables immutable (`val`) where possible?
+2. [ ] Are there any unnecessary `!!` operators?
+3. [ ] Does the code use Scope Functions to improve readability?
+4. [ ] Are collection operations chained efficiently?
+5. [ ] Is the visibility (private, internal, etc.) as restrictive as possible?
+
+## References
+For deeper dives into specific rules, refer to:
+- [Official Kotlin Coding Conventions](https://kotlinlang.org/docs/coding-conventions.html)
+- [Idiomatic Kotlin Guide](https://kotlinlang.org/docs/idioms.html)
\ No newline at end of file
diff --git a/fake_configs/fake_skills/typescript_best_practices/SKILL.md b/fake_configs/fake_skills/typescript_best_practices/SKILL.md
new file mode 100644
index 0000000..9054ec5
--- /dev/null
+++ b/fake_configs/fake_skills/typescript_best_practices/SKILL.md
@@ -0,0 +1,65 @@
+---
+name: typescript-style-checker
+description: Validates TypeScript code against the Google TypeScript Style Guide. Use this skill to ensure consistent formatting, type safety, and idiomatic usage of modern TypeScript features. It covers naming conventions, type declarations, and common pitfalls.
+license: Apache-2.0
+metadata:
+ version: "1.0.0"
+ reference: "https://google.github.io/styleguide/tsguide.html"
+---
+
+# TypeScript Style Checker (Google Style)
+
+This skill provides instructions for reviewing TypeScript code according to the Google TypeScript Style Guide. It focuses on readability, maintainability, and leveraging the type system effectively.
+
+## Core Principles
+
+### 1. Naming Conventions
+- **Classes, Interfaces, Enums, Type Aliases:** Use `PascalCase`.
+- **Variables, Functions, Properties, Parameters:** Use `camelCase`.
+- **Constants (exported or at module level):** Use `CONSTANT_CASE`.
+- **Interface Names:** Do **not** use an `I` prefix (e.g., use `UserInfo`, not `IUserInfo`).
+
+### 2. Type System Best Practices
+- **`any` is Prohibited:** Avoid `any` at all costs. Use `unknown` if the type is truly unknown, or define a proper interface/union.
+- **Type Inference:** Rely on type inference for initialized local variables. Explicitly type function return values and public API members.
+- **`interface` vs `type`:**
+ - Use `interface` for object structures that may be extended.
+ - Use `type` for unions, intersections, and primitives.
+- **Non-null Assertions:** Avoid `!`. Use type guards or safe navigation `?.`.
+
+### 3. Language Features
+- **Decorators:** Use only when necessary (standard in frameworks like Angular).
+- **Enums:** Use `enum` for sets of related constants. Prefer `const enum` if performance is critical and the enum is not exported.
+- **Classes:**
+ - Use `readonly` for properties that aren't reassigned.
+ - Prefer `private` (TypeScript keyword) over `#` (private fields) unless runtime privacy is strictly required.
+- **Arrays:** Use `readonly T[]` or `ReadonlyArray<T>` for arrays that should not be mutated.
+
+### 4. Expressions and Statements
+- **Equality:** Always use triple equals `===` and `!==`.
+- **Null vs Undefined:**
+ - Use `undefined` for missing values or optional parameters.
+ - Use `null` only when it is part of an external API or specifically represents the intentional absence of an object.
+- **Iteration:** Use `for (const x of arr)` for arrays. Do not use `for...in` for arrays.
+
+## Common Anti-Patterns to Flag
+
+| Anti-Pattern | Recommended Alternative |
+| :--- | :--- |
+| `let x: string = 'val';` | `const x = 'val';` (Inference + Immutability) |
+| `var x = 1;` | Use `let` or `const`. |
+| `Array<string>` | `string[]` (Shorthand is preferred). |
+| `<Type>value` (Casting) | `value as Type` (Angle bracket syntax conflicts with JSX). |
+| `module.exports` | Use ESM `export` and `import`. |
+
+## Review Checklist
+
+1. [ ] Are there any instances of `any`? (Request specific types).
+2. [ ] Are all constants using `CONSTANT_CASE`?
+3. [ ] Does the code use `as` casting unnecessarily where a type guard would be safer?
+4. [ ] Are `interface` names free of the `I` prefix?
+5. [ ] Is `triple-equals` used for all comparisons?
+
+## References
+- [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)
+- [TypeScript Official Documentation](https://www.typescriptlang.org/docs/)
\ No newline at end of file
