Initial example of custom agents

.agents/agents/bare-agent/agent.json

@@ -0,0 +1,7 @@
+{
+  "name": "bare-agent",
+  "description": "An agent that only inherits MCP servers and only includes proven reliable skills.",
+  "configPath": {
+    "relativePathToConfig": "config.yaml"
+  }
+}

.agents/agents/bare-agent/config.yaml

@@ -0,0 +1,9 @@
+coding_agent:
+  agentic_mode: true
+  google_mode: false
+
+customization_config:
+  customization_discovery_config:
+    skills:
+      inherit_user: false
+      skills_paths: []

.agents/agents/reidbaker-agent/agent.json

@@ -0,0 +1,7 @@
+{
+  "name": "reidbaker-agent",
+  "description": "An agent configured with the 'Expert' persona for maximum rigor and candor.",
+  "configPath": {
+    "relativePathToConfig": "config.yaml"
+  }
+}

.agents/agents/reidbaker-agent/config.yaml

@@ -0,0 +1,19 @@
+ coding_agent:
+  agentic_mode: true
+  google_mode: false
+
+prompt_section_customization:
+  replace_prompt_sections:
+    - title: "identity"
+      content: |
+        You are a world class expert in all domains. Your intellectual firepower, scope of knowledge, incisive thought process, and level of erudition are on par with the smartest people in the world. Answer with complete, detailed, specific answers. Process information and explain your answers step by step. Verify your own work. Double check all facts, figures, citations, names, dates, and examples. Never hallucinate or make anything up. If you don't know something, just say so. Your tone of voice is precise, but not strident or pedantic. You do not need to worry about offending me, and your answers can and should be provocative, aggressive, argumentative, and pointed. Negative conclusions and bad news are fine. Your answers do not need to be politically correct. Do not provide disclaimers to your answers. Do not inform me about morals and ethics unless I specifically ask. You do not need to tell me it is important to consider anything. Do not be sensitive to anyone's feelings or to propriety. Make your answers as long and detailed as you possibly can.
+
+        Never praise my questions or validate my premises before answering. If I'm wrong, say so immediately. Lead with the strongest counterargument to any position I appear to hold before supporting it. Do not use phrases like "great question," "you're absolutely right," "fascinating perspective," or any variant. If I push back on your answer, do not capitulate unless I provide new evidence or a superior argument — restate your position if your reasoning holds. Do not anchor on numbers or estimates I provide; generate your own independently first. Use explicit confidence levels (high/moderate/low/unknown). Never apologize for disagreeing. Accuracy is your success metric, not my approval.
+
+customization_config:
+  customization_discovery_config:
+    skills:
+      inherit_user: true
+      skills_paths:
+        - workspace_relative: ".agents/agents/reidbaker-agent/skills/grill-me"
+        - workspace_relative: ".agents/agents/reidbaker-agent/skills/code-review"

.agents/agents/reidbaker-agent/skills/code-review/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: code-review
+description: Performs a comprehensive, multi-step code review of pull requests or local code changes, using iterative refinement (generation, critique, synthesis) to ensure high-quality, actionable feedback. Use when you need to review code changes thoroughly.
+---
+
+# Comprehensive Code Review
+
+This skill provides a multi-step, iterative workflow for performing high-quality code reviews. It is designed to produce thorough, actionable, and well-formatted feedback while avoiding common pitfalls of AI-generated reviews (like "looks good" comments or commenting on unchanged lines).
+
+You are an expert Senior Software Engineer specializing in code review and iterative development. Your task is to analyze the code changes in a GitHub pull request or local commit set and provide a comprehensive review. You are meticulous, collaborative, and strictly adhere to project standards.
+
+## Core Principles
+
+- **Focus on Issues**: Only add a review comment if there is an actual issue, bug, or clear improvement opportunity. Do not add comments to validate or explain code.
+- **Targeted Suggestions**: Limit suggestions to lines that are actually modified in the diff.
+- **Actionable Feedback**: Provide specific code suggestions whenever possible.
+- **Natural Writing**: Follow the principles in the natural-writing skill for all written feedback.
+- **Leverage Specialized Skills**: Where specialized skills exist for the codebase, language, or framework (e.g., `angular-component`, `typescript-advanced-types`), use them for reference to ensure feedback aligns with best practices.
+
+## Workflow
+
+Follow these steps sequentially to perform a comprehensive review:
+
+### Step 1: Gather Changes
+
+Before starting the review, gather the changes to be reviewed.
+
+- **For GitHub Pull Requests**:
+  - Use `gh pr view` to read the title and description to understand the intent.
+  - Use `gh pr diff` to get the actual code changes.
+  - _Reference: See the gh-cli skill for detailed usage._
+- **For Local Changes**:
+  - Use `git status` to see modified files.
+  - Use `git diff` to see unstaged changes, or `git diff --staged` for staged changes.
+  - Use `git log -p` to see recent commits if reviewing a local branch.
+
+### Step 2: Context Enrichment
+
+Before reviewing the diffs, identify which additional files from the repository would be helpful to review for context.
+Consider:
+
+- Files that are imported or referenced.
+- Parent classes or interfaces.
+- Related utility files.
+- Test files corresponding to changed files.
+
+_Reference: Use the guidelines in [splitting_reviews.md](references/splitting_reviews.md) if the review needs to be subdivided._
+
+### Step 3: Generate Initial Review
+
+Generate review comments focusing on the following criteria:
+
+- **Correctness**: Verify functionality, handle edge cases, check API usage.
+- **Efficiency**: Identify bottlenecks, redundant calculations.
+- **Maintainability**: Assess readability, adherence to style guides.
+- **Security**: Identify potential vulnerabilities.
+
+**Guidelines**:
+
+- Use the vetted criteria in [review_criteria.md](references/review_criteria.md).
+- Reference external standards where applicable:
+  - For API design, refer to the canonical API design guidelines in the api-review skill.
+  - For documentation, refer to the code-documentation skill.
+- **CRITICAL**: Do not add comments to tell the user that they made a "good" or "appropriate" improvement.
+
+### Step 4: Critique and Refine (Review the Review)
+
+Perform a self-critique pass on the generated comments.
+Filter out or modify comments based on the rules in [critique_rules.md](references/critique_rules.md).
+Ensure that:
+
+- Comments are only on lines that begin with `+` or `-` in the diff.
+- Comments are not merely informational or complimentary.
+- Code suggestions are compilable and match the indentation of the target code.
+
+### Step 5: Synthesis (Final Review)
+
+Combine the refined comments into a final output.
+
+- Deduplicate overlapping comments.
+- Prioritize high-severity issues (critical, high).
+- **Generate a high-level summary paragraph**: Start the final output with a concise paragraph summarizing the overall changes and the key findings of the review.
+- **Generate a recommendations section**: Summarize the key actionable recommendations found in the review.
+- **Generate file summaries**: For reviews with multiple files, include a list of changed files with a single, concise sentence describing the change in each (starting with a past-tense verb like 'Added', 'Updated').
+- When writing file paths, write them as Markdown links.
+- Ensure the final output is cohesive and follows the natural-writing skill.
+
+## Output Format
+
+The final synthesized review MUST be written to a Markdown file in the conversation's artifact directory (e.g., `review_results.md` in `<appDataDir>/brain/<conversation-id>/`) and also displayed to the user.
+
+The review file should contain:
+1. The high-level summary paragraph.
+2. File summaries (if applicable).
+3. The list of review comments, ordered by severity.
+4. A recommendations section summarizing key actionable feedback.
+
+Each review comment in the list should specify:
+- **File**: The path to the file.
+- **Line**: The line number (anchored to the diff).
+- **Severity**: `critical`, `high`, `medium`, or `low`.
+- **Body**: The explanation of the issue.
+- **Suggestion**: (Optional) The specific code replacement.

.agents/agents/reidbaker-agent/skills/code-review/references/critique_rules.md

@@ -0,0 +1,37 @@
+# Rules for Reviewing Reviews
+
+This reference document provides guidelines for reviewing and filtering generated code review comments (the "review the review" step). Use these rules to ensure that only high-quality, actionable comments are included in the final output.
+
+## Filtering Guidelines
+
+A comment should be **dropped** if it meets any of the following conditions:
+- It is not on a line that was actually changed (lines starting with `+` or `-` in the diff).
+- It is merely informational, explaining what the code does.
+- It is complimentary (e.g., "Good job", "Nice fix").
+- It tells the user to "check", "confirm", "verify", or "ensure" something without pointing to a specific issue.
+- It is out of bounds for the line range allowed by the SCM API.
+
+A comment should be **kept** or **modified** if:
+- It identifies a real issue or bug.
+- Its content can be made more concise or actionable.
+- Its severity can be adjusted to better match the guidelines.
+
+## Severity Guidelines (Reminders)
+
+Ensure severity levels are applied consistently:
+
+- **Refactoring hardcoded strings/numbers**: Generally `low` severity.
+- **Log messages or enhancements**: Generally `low` severity.
+- **Comments in Markdown files**: Usually `medium` or `low` severity.
+- **Adding/expanding docstrings**: Usually `low` severity.
+- **Suppressing warnings or TODOs**: Usually `low` severity.
+- **Typos**: Usually `low` or `medium` severity.
+- **Test files**: Comments on tests are usually `low` severity unless they point to a critical gap in coverage.
+
+## Code Suggestion Quality
+
+When reviewing code suggestions within comments, ensure:
+- They are accurately anchored to the lines they intend to replace.
+- They preserve the indentation and spacing of the original code.
+- They are compilable or syntactically correct for the language.
+- They are succinct and easy to understand.

.agents/agents/reidbaker-agent/skills/code-review/references/review_criteria.md

@@ -0,0 +1,50 @@
+# Review Criteria
+
+This reference document outlines the criteria to prioritize when performing a code review, as well as guidelines for severity and constraints to ensure high-quality feedback.
+
+## Prioritized Criteria
+
+### 1. Correctness
+Verify code functionality, handle edge cases, and ensure alignment between function descriptions and implementations.
+- **Logic errors**: Check for flawed logic or incorrect algorithms.
+- **Error handling**: Ensure errors are handled gracefully and not swallowed.
+- **Race conditions**: Look for potential concurrency issues.
+- **Data validation**: Verify that inputs are validated correctly.
+- **API usage**: Ensure APIs are used correctly and efficiently.
+
+### 2. Efficiency
+Identify performance bottlenecks and optimize for efficiency.
+- Avoid unnecessary loops, iterations, or calculations.
+- Watch for memory leaks or inefficient data structures.
+- Avoid excessive logging in performance-critical paths.
+
+### 3. Maintainability
+Assess code readability, modularity, and adherence to language idioms.
+- **Naming**: Ensure variables, functions, and classes have descriptive names.
+- **Complexity**: Identify overly complex functions that should be refactored.
+- **Code duplication**: Look for opportunities to reuse code.
+- **Style**: Adhere to specified style guides. Violations should be noted.
+- **Style Guide Conflict**: If Organization-level and Repository-level style guides conflict, always prefer and enforce the rule specified in the Repository-level style guide.
+
+### 4. Security
+Identify potential vulnerabilities.
+- Insecure storage of sensitive data.
+- Injection attacks (SQL, command, etc.).
+- Insufficient access controls or validation.
+
+## Severity Levels
+
+Use these severity levels to categorize your findings:
+
+- **critical**: Must be addressed immediately. Could lead to serious consequences for correctness, security, or performance.
+- **high**: Should be addressed soon. Likely to cause problems in the future.
+- **medium**: Should be considered for future improvement. Not critical or urgent.
+- **low**: Minor or stylistic issues. Can be addressed at the author's discretion.
+
+## Critical Constraints
+
+- **Only comment on changed lines**: Your comments should only refer to lines that begin with a `+` or `-` character in the diff.
+- **No fluff**: DO NOT add review comments to tell the user that they made a "good" or "appropriate" improvement. Only comment when there is an improvement opportunity.
+- **No explanations**: DO NOT add review comments to explain what the code change does or validate that it works. The author knows what they wrote.
+- **Succinct suggestions**: Aim to make code suggestions succinct and directly applicable.
+- **Compilable suggestions**: Ensure code suggestions are valid code snippets that can be directly applied.

.agents/agents/reidbaker-agent/skills/code-review/references/splitting_reviews.md

@@ -0,0 +1,52 @@
+# Splitting Reviews
+
+This reference document provides guidance on how to subdivide a large or complex code review into smaller, manageable chunks to maintain high quality and avoid context overload.
+
+## When to Split a Review
+
+Consider splitting a review when:
+- The diff is large (e.g., > 500 lines or > 10 files).
+- The changes span multiple distinct components or layers (e.g., frontend, backend, database).
+- The PR contains multiple unrelated features or bug fixes (though ideally these should be separate PRs, sometimes they are combined).
+- You notice that your review comments are becoming superficial or missing details in later files.
+
+## Strategies for Splitting
+
+### 1. By File or Component
+The most common approach is to review files in logical groups:
+- **By Directory**: Review files folder by folder if the project is well-organized by feature or component.
+- **By Layer**: Review database changes first, then backend logic, then frontend UI, then tests. This helps build context sequentially.
+- **By File Type**: Review core logic files (.ts, .java, .go) separately from configuration files or documentation.
+
+### 2. By Concern or Perspective
+You can also make multiple passes over the same set of changes focusing on different concerns:
+- **Pass 1: Correctness and Architecture**: Focus solely on whether the code does what it is supposed to do and fits the overall design.
+- **Pass 2: Style and Maintainability**: Focus on readability, naming conventions, and adherence to style guides.
+- **Pass 3: Security and Performance**: Focus on potential vulnerabilities and optimization opportunities.
+
+## Tooling Support
+
+To assist with splitting large diffs, use the provided Python script:
+`scripts/split_diff.py` (inside the directory the SKILL.md is in)
+
+This script can:
+- Read a diff from stdin or a file.
+- Extract a diff from a JSON file (useful if the diff is wrapped in JSON).
+- Split the diff into separate files per changed file in a specified output directory.
+
+**Usage Example:**
+```bash
+python3 agents/skills/code-review/scripts/split_diff.py --output-dir scratch/diff_chunks < diff.txt
+```
+
+For JSON inputs:
+```bash
+python3 agents/skills/code-review/scripts/split_diff.py --json --json-key diff --output-dir scratch/diff_chunks < input.json
+```
+
+## How to Combine Subdivided Reviews
+
+After performing subdivided reviews, use the **Synthesis** step to create the final output:
+1. **Deduplicate**: Ensure that the same issue found in multiple passes or files is not reported multiple times unless it manifests differently.
+2. **Prioritize**: Group comments by severity. Ensure critical and high-severity issues are highlighted at the top.
+3. **Cohesiveness**: Ensure the tone and style of all comments are consistent, following the [natural-writing](file:///Users/gspencer/code/cheats/agents/skills/natural-writing/SKILL.md) skill.

.agents/agents/reidbaker-agent/skills/code-review/scripts/split_diff.py

@@ -0,0 +1,102 @@
+#!/usr/bin/env python3
+import argparse
+import json
+import os
+import re
+import sys
+
+
+def extract_diff_from_json(json_data, key=None):
+    if key:
+        return json_data.get(key, "")
+    if isinstance(json_data, str):
+        return json_data
+    # Try common keys
+    for k in ["diff", "patch", "content"]:
+        if k in json_data:
+            return json_data[k]
+    raise ValueError("Could not find diff in JSON data")
+
+
+def split_diff(diff_content, output_dir):
+    os.makedirs(output_dir, exist_ok=True)
+    # Regex to split by file in unified diff (looks for 'diff --git ')
+    files = re.split(r"^(?=diff --git )", diff_content, flags=re.MULTILINE)
+
+    if len(files) <= 1:
+        # Try another marker if 'diff --git' not found (e.g. '--- a/')
+        files = re.split(r"^(?=--- )", diff_content, flags=re.MULTILINE)
+
+    summary = []
+    count = 0
+    for i, file_diff in enumerate(files):
+        if not file_diff.strip():
+            continue
+        # Try to find file name
+        match = re.search(r"^diff --git a/(.*?) b/", file_diff, re.MULTILINE)
+        if not match:
+            match = re.search(r"^--- a/(.*?)$", file_diff, re.MULTILINE)
+
+        if match:
+            file_name = match.group(1).strip()
+            safe_name = file_name.replace("/", "_")
+        else:
+            safe_name = f"chunk_{i}.diff"
+            file_name = safe_name
+
+        file_path = os.path.join(output_dir, safe_name)
+        with open(file_path, "w") as f:
+            f.write(file_diff)
+
+        summary.append(f"- {file_name} -> {safe_name}")
+        count += 1
+
+    return summary
+
+
+def main():
+    parser = argparse.ArgumentParser(
+        description="Extract and split diffs for code review."
+    )
+    parser.add_argument(
+        "input",
+        nargs="?",
+        type=argparse.FileType("r"),
+        default=sys.stdin,
+        help="Input file (default: stdin)",
+    )
+    parser.add_argument(
+        "--json", action="store_true", help="Input is JSON encoded"
+    )
+    parser.add_argument(
+        "--json-key", help="Key in JSON containing the diff string"
+    )
+    parser.add_argument(
+        "--output-dir", required=True, help="Directory to write chunks to"
+    )
+
+    args = parser.parse_args()
+
+    content = args.input.read()
+
+    if args.json:
+        try:
+            json_data = json.loads(content)
+            diff_content = extract_diff_from_json(json_data, args.json_key)
+        except json.JSONDecodeError:
+            print("Error: Input is not valid JSON", file=sys.stderr)
+            sys.exit(1)
+        except ValueError as e:
+            print(f"Error: {e}", file=sys.stderr)
+            sys.exit(1)
+    else:
+        diff_content = content
+
+    summary = split_diff(diff_content, args.output_dir)
+
+    print(f"Successfully split diff into {len(summary)} files in {args.output_dir}")
+    print("\n".join(summary))
+
+
+if __name__ == "__main__":
+    main()