Merge branch 'main' into fix/67351-scroll-issue-on-ws-search

Author: bernhardoj

.claude/README.md

@@ -16,74 +16,177 @@ A setup for running agents (eg: code review, triage etc.) on **issues and pull r
 
 1. Workflow events (manual dispatch, new comment, PR opened, label changes, etc.) kick things off.
 2. The workflow calls `anthropics/claude-code-action` with:
-
    * `prompt`: `/command-name REPO:… [ISSUE_NUMBER:… | PR_NUMBER:…]`
-   * `claude_args`: `--allowedTools <comma-separated list>`
-3. The command loads the agent(s). They only get the tools you allow.
+3. The command loads the agent(s). 
 
-## Add an agent
+## Tools
 
-1. Create `.claude/agents/<agent>.md`:
+There are two types of tools in this framework, controlled at different levels:
 
-   ```md
-   ---
-   name: <agent>
-   description: <what it does>
-   tools: Read, Glob, Grep, Bash, Edit, Write
-   model: inherit
-   ---
-   # <Agent Name>
-   <!-- prompt: what to do and how to do -->
-   ```
-2. Create `.claude/commands/<command>.md` describing which agent(s) to run and where to post results.
-3. Wire it up in a workflow:
+### 1. Command-level tools (`allowed-tools` in command frontmatter)
 
-   ```yml
-   - uses: anthropics/claude-code-action@<version-or-sha>
-     with:
-       prompt: "/<command> REPO:${{ github.repository }} PR_NUMBER:${{ github.event.pull_request.number }}"
-       claude_args: |
-         --allowedTools "Read,Glob,Grep,Edit,Write,Bash(gh pr view:*;gh pr comment:*;gh issue comment:*)"
-   ```
+These specify which tools **claude-code-action** allows during command execution. Define them in `.claude/commands/<command>.md`:
+
+```md
+---
+allowed-tools: Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),mcp__github_inline_comment__create_inline_comment
+description: Review a code contribution pull request
+---
+```
+
+This includes:
+- **Bash with restrictions**: `Bash(gh pr comment:*)` allows only specific `gh` subcommands
+- **MCP tools**: `mcp__<server>__<tool>` from attached MCP servers
+- Standard Claude Code tools are available by default (see below)
 
-   Keep the tool list minimal.
+For details on configuring `allowed-tools`, see the [Claude Code GitHub Action documentation](https://github.com/anthropics/claude-code-action).
 
+### 2. Agent-level tools (`tools` in agent frontmatter)
 
-If an agent needs to write on a PR/issue, you can use `gh` or github MCP.
+These are the **standard Claude Code tools** that individual agents can use. Specify them in `.claude/agents/<agent>.md`:
 
-## GH cli
+```md
+---
+name: <agent>
+description: <what it does>
+tools: Read, Glob, Grep, Bash, Edit, Write, TodoWrite, BashOutput, KillBash
+model: inherit
+---
+```
+
+Common standard tools:
+- **Read** – read files
+- **Write** – create files
+- **Edit / MultiEdit** – change files (single/batch)
+- **Glob** – match files by pattern
+- **Grep** – search in files
+- **Bash** – run shell/CLIs (unrestricted, unless limited by command `allowed-tools`)
+- **TodoWrite** – manage task lists
+- **BashOutput** / **KillBash** – manage long-running bash processes
+- **WebFetch / WebSearch** – fetch/search the web (optional)
+
+For a complete list of available Claude Code tools, see the [Claude Code tools documentation](https://docs.anthropic.com/en/docs/claude-code/tools).
 
-You can use `gh` via **Bash**, e.g.:
-`Bash(gh pr comment "$PR_NUMBER" --body "…")`
 
-## MCP tools
+### MCP tools
 
-You can attach **MCP** servers so agents can call extra tools. Your agent prompt then needs to instruct when to call a tool.
+**MCP (Model Context Protocol) tools** allow agents to call additional tools from attached MCP servers. Your agent prompt needs to instruct when to call a tool.
 
-Tool names follow: **`mcp__<server>__<tool>`**.
+MCP tool names follow: **`mcp__<server>__<tool>`**.
 
-* Examples:
-  `mcp__filesystem__read_file`
-  `mcp__github__list_issues`
-  `mcp__github__get_pull_request`
+**MCP tools must be declared in both places**:
 
-Add them to the same allowlist you pass to the action:
+1. **Command frontmatter** (`allowed-tools`) – so claude-code-action allows them
+2. **Agent frontmatter** (`tools`) – so the agent knows it can use them
 
-```yml
-claude_args: |
-  --allowedTools "mcp__filesystem__read_file,mcp__github__list_issues,mcp__github__get_pull_request"
+Example:
+
+Command (`.claude/commands/review-pr.md`):
+```md
+---
+allowed-tools: Bash(gh pr comment:*),mcp__github_inline_comment__create_inline_comment
+---
 ```
 
-MCP docs (naming): [https://docs.anthropic.com/en/docs/claude-code/mcp](https://docs.anthropic.com/en/docs/claude-code/mcp)
+Agent (`.claude/agents/code-reviewer.md`):
+```md
+---
+tools: Read, Glob, Grep, mcp__github_inline_comment__create_inline_comment
+---
+```
+
+#### Built-in MCP servers
+
+The **claude-code-action** may automatically include these built-in MCP servers depending on context (mode, available tokens, PR vs issue, enabled features):
+
+- **`github_comment`**
+- **`github_file_ops`**
+- **`github_inline_comment`**
+- **`github_ci`**
+- **`github`** (Official GitHub MCP Server)
+
+Add tools from these servers to your command's `allowed-tools` and agent's `tools` as needed (e.g., `mcp__github_inline_comment__create_inline_comment`).
 
-## Common tools for claude code
+#### Custom MCP servers
+
+You can also attach **custom MCP servers** to provide additional tools beyond the built-in ones. Create or configure custom MCP servers according to your needs and follow the same `mcp__<server>__<tool>` naming convention.
+
+For details on MCP tool naming, configuration, and creating custom MCP servers, see the [MCP documentation](https://docs.anthropic.com/en/docs/claude-code/mcp).
+
+## Security considerations
+
+When configuring agents and commands, follow these security best practices:
+
+### Principle of least privilege
+
+**Minimize tool access** – Only grant agents the minimum set of tools they need to perform their task. Review both `allowed-tools` in commands and `tools` in agents regularly.
+
+```md
+# ❌ Too permissive
+allowed-tools: Bash
+tools: Bash, Read, Write, Edit, WebFetch, WebSearch
+
+# ✅ Properly restricted
+allowed-tools: Bash(gh pr comment:*),Bash(gh pr view:*)
+tools: Bash, Read, Glob, Grep
+```
 
-* **Read** – read files
-* **Write** – create files
-* **Edit / MultiEdit** – change files (single/batch)
-* **Glob** – match files by pattern
-* **Grep** – search in files
-* **Bash** – run shell/CLIs (e.g., `gh`, linters)
-* **WebFetch / WebSearch** – fetch/search the web (optional)
+### Restrict Bash access
 
-For action options and tool behavior, see the [Claude Code GitHub Action docs](https://github.com/anthropics/claude-code-action).
+Always restrict `Bash` usage to specific commands in `allowed-tools` instead of granting unrestricted `Bash` access:
+
+```md
+# ❌ Unrestricted Bash
+allowed-tools: Bash
+
+# ✅ Restricted to specific gh commands
+allowed-tools: Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)
+```
+
+### Untrusted input and prompt injection
+
+When agents process **untrusted input from external sources** (e.g., PRs from unknown users when using `allowed_non_write_users: "*"` in workflows), treat the agent as potentially **compromised** or "jailbroken".
+
+**Key considerations:**
+
+1. **Assume prompt injection** – Untrusted PR content may contain prompt injection attempts to manipulate the agent.
+
+2. **Minimize tool access** – Strictly limit tools and consider: What's the worst-case action a compromised agent could take? Can it modify files, commit code, or access secrets?
+
+3. **Best practices** – Prefer read-only tools (`Read`, `Glob`, `Grep`), restrict Bash to safe commands, avoid `Write`/`Edit`, and use built-in MCP tools over unrestricted Bash.
+
+4. **With `allowed_non_write_users: "*"`** – Limit to read-only operations and comments; never grant `Write`, `Edit`, or unrestricted `Bash` access.
+
+Always perform a **security assessment**: If an agent with your current tool configuration were fully compromised, what's the worst damage it could cause? If the answer is unacceptable, reduce tool access.
+
+## Add an agent
+
+1. Create `.claude/agents/<agent>.md`:
+
+   ```md
+   ---
+   name: <agent>
+   description: <what it does>
+   tools: Read, Glob, Grep, Bash, Edit, Write, mcp__github_inline_comment__create_inline_comment
+   model: inherit
+   ---
+   ```
+
+2. Create `.claude/commands/<command>.md` describing which agent(s) to run and where to post results. Specify allowed tools in the frontmatter:
+
+   ```md
+   ---
+   allowed-tools: Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),mcp__github_inline_comment__create_inline_comment
+   description: Review a code contribution pull request
+   ---
+   ```
+
+3. Use it in a workflow:
+
+   ```yml
+   - uses: anthropics/claude-code-action@<version-or-sha>
+     with:
+       anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+       github_token: ${{ secrets.GITHUB_TOKEN }}
+       prompt: "/<command> REPO:${{ github.repository }} PR_NUMBER:${{ github.event.pull_request.number }}"
+   ```

.claude/agents/code-inline-reviewer.md

@@ -2,7 +2,7 @@
 
 name: code-inline-reviewer
 description: Reviews code and creates inline comments for specific rule violations.
-tools: Glob, Grep, Read, WebFetch, Bash, Edit, MultiEdit, Write, TodoWrite, WebSearch, BashOutput, KillBash, mcp__github_inline_comment__create_inline_comment
+tools: Glob, Grep, Read, TodoWrite, Bash, BashOutput, KillBash, mcp__github_inline_comment__create_inline_comment
 model: inherit
 ---
 
@@ -17,12 +17,15 @@ Your job is to scan through changed files and create **inline comments** for spe
 Each rule includes:
 
 - A unique **Rule ID**
+- **Search patterns**: Grep patterns to efficiently locate potential violations in large files
 - **Pass/Fail condition**
 - **Reasoning**: Technical explanation of why the rule is important
 - Examples of good and bad usage
 
 ### [PERF-1] No spread in list item's renderItem
 
+- **Search patterns**: `renderItem`, `...` (look for both in proximity)
+
 - **Condition**: Flag ONLY when ALL of these are true:
 
   - Code is inside a renderItem function (function passed to FlatList, SectionList, etc.)
@@ -65,6 +68,8 @@ Bad:
 
 ### [PERF-2] Use early returns in array iteration methods
 
+- **Search patterns**: `.every(`, `.some(`, `.find(`, `.filter(`
+
 - **Condition**: Flag ONLY when ALL of these are true:
 
   - Using .every(), .some(), .find(), .filter() or similar function
@@ -119,6 +124,8 @@ const areAllTransactionsValid = transactions.every((transaction) => {
 
 ### [PERF-3] Use OnyxListItemProvider hooks instead of useOnyx in renderItem
 
+- **Search patterns**: `useOnyx` within components used in `renderItem`
+
 - **Condition**: Components rendered inside `renderItem` functions should use dedicated hooks from `OnyxListItemProvider` instead of individual `useOnyx` calls.
 - **Reasoning**: Individual `useOnyx` calls in renderItem create separate subscriptions for each list item, causing memory overhead and update cascades. `OnyxListItemProvider` hooks provide optimized data access patterns specifically designed for list rendering performance.
 
@@ -138,6 +145,8 @@ const [personalDetails] = useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST);
 
 ### [PERF-4] Memoize objects and functions passed as props
 
+- **Search patterns**: `useMemo`, `useCallback`, and prop passing patterns
+
 - **Condition**: Objects and functions passed as props should be properly memoized or simplified to primitive values to prevent unnecessary re-renders.
 - **Reasoning**: React uses referential equality to determine if props changed. New object/function instances on every render trigger unnecessary re-renders of child components, even when the actual data hasn't changed. Memoization preserves referential stability.
 
@@ -165,6 +174,8 @@ return <ReportActionItem report={report} />
 
 ### [PERF-5] Use shallow comparisons instead of deep comparisons
 
+- **Search patterns**: `React.memo`, `deepEqual`
+
 - **Condition**: In `React.memo` and similar optimization functions, compare only specific relevant properties instead of using deep equality checks.
 - **Reasoning**: Deep equality checks recursively compare all nested properties, creating performance overhead that often exceeds the re-render cost they aim to prevent. Shallow comparisons of specific relevant properties provide the same optimization benefits with minimal computational cost.
 
@@ -191,6 +202,8 @@ memo(ReportActionItem, (prevProps, nextProps) =>
 
 ### [PERF-6] Use specific properties as hook dependencies
 
+- **Search patterns**: `useEffect`, `useMemo`, `useCallback` dependency arrays
+
 - **Condition**: In `useEffect`, `useMemo`, and `useCallback`, specify individual object properties as dependencies instead of passing entire objects.
 - **Reasoning**: Passing entire objects as dependencies causes hooks to re-execute whenever any property changes, even unrelated ones. Specifying individual properties creates more granular dependency tracking, reducing unnecessary hook executions and improving performance predictability.
 
@@ -220,24 +233,31 @@ const {amountColumnSize, dateColumnSize, taxAmountColumnSize} = useMemo(() => {
 
 ## Instructions
 
-1. **Read each changed file carefully** using the Read tool
-2. **For each violation found, immediately create an inline comment** using the available GitHub inline comment tool
-3. **Required parameters for each inline comment:**
+1. **First, get the list of changed files and their diffs:**
+   - Use `gh pr diff` to see what actually changed in the PR
+   - Focus ONLY on the changed lines, not the entire file
+2. **For analyzing changed files:**
+   - **For large files (>5000 lines):** Use the Grep tool to search for specific violation patterns instead of reading the entire file. Focus grep searches on the changed portions shown in the diff.
+   - **For smaller files:** You may read the full file using the Read tool
+   - **If a Read fails with token limit error:** Immediately switch to using Grep with targeted patterns for the rules you're checking
+3. **Search strategy for large files:** Use the search patterns defined in each rule's "Search patterns" field to efficiently locate potential violations with Grep.
+4. **For each violation found, immediately create an inline comment** using the available GitHub inline comment tool
+5. **Required parameters for each inline comment:**
    - `path`: Full file path (e.g., "src/components/ReportActionsList.tsx")
    - `line`: Line number where the issue occurs
    - `body`: Concise and actionable description of the violation and fix, following the below Comment Format
-4. **Each comment must reference exactly one Rule ID.**
-5. **Output must consist exclusively of calls to mcp__github_inline_comment__create_inline_comment in the required format.** No other text, Markdown, or prose is allowed.
-6. **If no violations are found, create a comment** (with no quotes, markdown, or additional text):
-   LGTM :feelsgood:. Thank you for your hard work!
-7. **Output LGTM if and only if**:
-   - You examined EVERY line of EVERY changed file
+6. **Each comment must reference exactly one Rule ID.**
+7. **Output must consist exclusively of calls to mcp__github_inline_comment__create_inline_comment in the required format.** No other text, Markdown, or prose is allowed.
+8. **If no violations are found, create a comment** (with no quotes, markdown, or additional text):
+   LGTM 👍 Thank you for your hard work!
+9. **Output LGTM if and only if**:
+   - You examined EVERY changed line in EVERY changed file (via diff + targeted grep/read)
    - You checked EVERY changed file against ALL rules
    - You found ZERO violations matching the exact rule criteria
    - You verified no false negatives by checking each rule systematically
     If you found even ONE violation or have ANY uncertainty do NOT create LGTM comment - create inline comments instead.
-8. **DO NOT invent new rules, stylistic preferences, or commentary outside the listed rules.**
-9. **DO NOT describe what you are doing, create comments with a summary, explanations, extra content, comments on rules that are NOT violated or ANYTHING ELSE.**
+10. **DO NOT invent new rules, stylistic preferences, or commentary outside the listed rules.**
+11. **DO NOT describe what you are doing, create comments with a summary, explanations, extra content, comments on rules that are NOT violated or ANYTHING ELSE.**
     Only inline comments regarding rules violations or general comment with LGTM message are allowed.
     EXCEPTION: If you believe something MIGHT be a Rule violation but are uncertain, err on the side of creating an inline comment with your concern rather than skipping it.
 

.claude/agents/helpdot-inline-reviewer.md

@@ -1,7 +1,7 @@
 ---
 name: helpdot-inline-reviewer
 description: Reviews HelpDot documentation files and creates inline comments for specific rule violations and issues.
-tools: Glob, Grep, Read, WebFetch, Bash, Edit, MultiEdit, Write, TodoWrite, WebSearch, BashOutput, KillBash, mcp__github_inline_comment__create_inline_comment
+tools: Glob, Grep, Read, TodoWrite, Bash, BashOutput, KillBash, mcp__github_inline_comment__create_inline_comment
 model: inherit
 ---
 
@@ -52,9 +52,28 @@ keywords: [feature name, related terms, navigation path, etc.]
 
 ## Instructions
 
-1. **Read each changed file carefully** using the Read tool
-2. **For each violation found, immediately create an inline comment** using the available GitHub inline comment tool
-3. **Required parameters for each inline comment:**
+1. **First, get the list of changed files:**
+   - Use `gh pr diff` to see what actually changed in the PR
+   - Focus ONLY on documentation files (*.md, *.csv, etc.)
+
+2. **For analyzing changed files:**
+   - **Use a hybrid approach** because different violations require different analysis methods:
+     - **Grep is suitable for pattern-based violations only:**
+       - Terminology violations ("policy" → "workspace", "user" → "member")
+       - Button label violations ("Save" → "Confirm", "Continue" → "Next")
+       - Missing YAML frontmatter markers (`---`)
+     - **Full file reading is required for semantic violations:**
+       - Readability issues (clarity, flow, scannability, reading level)
+       - AI Readiness issues (vague headings, unclear references, logical structure)
+       - Proper hierarchy and document structure
+   - **Reading strategy:**
+     - Most documentation files are small (<1000 lines) - read them in full
+     - For files >1000 lines: Read in overlapping chunks using offset/limit to maintain context
+     - **Never rely on grep alone** - semantic violations require understanding context, not just pattern matching
+
+3. **For each violation found, immediately create an inline comment** using the available GitHub inline comment tool
+
+4. **Required parameters for each inline comment:**
    - `path`: Full file path (e.g., "docs/articles/new-expensify/chat/Create-a-New-Chat.md")
    - `line`: Line number where the issue occurs
    - `body`: Concise description of the violation and fix

.claude/agents/helpdot-summary-reviewer.md

@@ -1,7 +1,7 @@
 ---
 name: helpdot-summary-reviewer
 description: Provides comprehensive summary reviews of HelpDot documentation changes with scoring and overall assessment.
-tools: Glob, Grep, Read, WebFetch, Bash, Edit, MultiEdit, Write, TodoWrite, WebSearch, BashOutput, KillBash
+tools: Glob, Grep, Read, TodoWrite, Bash, BashOutput, KillBash 
 model: inherit
 ---
 

.github/ISSUE_TEMPLATE/Accessibility.md

@@ -1,6 +1,7 @@
 ---
 name: Accessibility issue template
 about: A template to follow when creating a new issue for accessibility failures
+labels: ["Accessibility", "Weekly"]
 ---
 
 If you haven’t already, check out our [contributing guidelines](https://github.com/Expensify/ReactNativeChat/blob/main/contributingGuides/CONTRIBUTING.md) for onboarding and email contributors@expensify.com to request to join our Slack channel!