diff --git a/.claude/commands/update-pull-request.md b/.claude/commands/update-pull-request.md
index 2eb7bb8c..17b342d6 100644
--- a/.claude/commands/update-pull-request.md
+++ b/.claude/commands/update-pull-request.md
@@ -362,37 +362,32 @@ Follow these steps:
 
 - For each piece of feedback (both addressed and rejected), draft a response comment explaining what was done or why it was rejected, using the commenter name for personalization.
 - Post all response comments to their respective threads:
-  - For review comments (code-level), use GraphQL `addPullRequestReviewComment` mutation:
+  - For review comments (code-level), use GraphQL `addPullRequestReviewThreadReply` mutation to post comments directly to threads (NOT as pending review):
 
     ```bash
-    # Extract PR node ID from metadata
-    PR_ID=$(jq -r '.id' "${SCRATCHPAD}/metadata.json")
-
     # IMPORTANT: Keep response text simple - avoid newlines, code blocks, and special characters
     # GraphQL string literals cannot contain raw newlines; use spaces or simple sentences
     # If complex formatting is needed, save response to a variable first and ensure proper escaping
 
     gh api graphql -f query='
-      mutation {
-        addPullRequestReviewComment(input: {
-          pullRequestId: "'$PR_ID'",
-          body: "<response_text>",
-          inReplyTo: "<comment_node_id>"
+      mutation($pullRequestReviewThreadId: ID!, $body: String!) {
+        addPullRequestReviewThreadReply(input: {
+          pullRequestReviewThreadId: $pullRequestReviewThreadId,
+          body: $body
         }) {
           comment { id }
         }
       }
-    '
+    ' -f pullRequestReviewThreadId="<thread_id>" -f body="<response_text>"
     ```
 
-    Use the PR node ID from `metadata.json` for `pullRequestId`.
-    Use the comment node ID (format: `PRRC_*`) from `review_threads.json` for `inReplyTo` parameter.
+    Use the thread ID (format: `PRRT_*`) from `review_threads.json` for `pullRequestReviewThreadId` parameter.
 
-    Example to get comment node ID:
+    Example to get thread ID:
 
     ```bash
-    # Get first comment's node ID from a specific thread
-    COMMENT_ID=$(jq -r '.[] | select(.threadId == "PRRT_xxx") | .comments[0].id' "${SCRATCHPAD}/review_threads.json")
+    # Get thread ID from review_threads.json
+    THREAD_ID=$(jq -r '.[] | select(.comments[0].body | contains("some text")) | .threadId' "${SCRATCHPAD}/review_threads.json")
     ```
 
     **Response formatting guidelines**:
@@ -415,15 +410,15 @@ Follow these steps:
 
       ```bash
       gh api graphql -f query='
-        mutation {
-          resolveReviewThread(input: {threadId: "<thread_id>"}) {
+        mutation($threadId: ID!) {
+          resolveReviewThread(input: {threadId: $threadId}) {
             thread {
               id
               isResolved
             }
           }
         }
-      '
+      ' -f threadId="<thread_id>"
       ```
 
     - Map each comment back to its parent thread using the data structure from step 3 parsing.
diff --git a/CLAUDE.md b/CLAUDE.md
index 89ce0deb..5772954f 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -41,7 +41,7 @@ This is a collection of guidelines and references.
 - Structured log messages should be short sentences with sentence case (e.g., "Starting data sync" not "STARTING DATA SYNC")
 - When debugging or fixing bugs, check Sentry errors, ECS logs, and Alpaca account status to understand what happened
 - After fixing a bug, create a git commit with a detailed summary of the root cause and fix in the commit message
-- When creating GitHub issues or pull requests, use the templates provided in the `.github/` directory
+- When creating GitHub issues or pull requests, use the templates in the `.github/` directory and follow commented instructions
 - Only use labels already available on the GitHub repository for issues and pull requests
 - When naming branches, use an all-lowercase, hyphenated, and concise summary of the work being done
 - `tools/` folder contains development utilities and scripts
@@ -57,3 +57,9 @@ This is a collection of guidelines and references.
 - Make every change as simple as possible and impact minimal code
 - Find root causes and avoid temporary fixes - maintain high standards
 - Changes should only touch what's necessary to avoid introducing bugs
+- If uncertainty arises, ask for help or input rather than guessing
+- Do not introduce abstractions for single-use code
+- Always match existing styles and patterns in the codebase for consistency
+- When fixing a bug, write tests that reproduce the bug before fixing it, then verify the tests pass after the fix
+- Do not use emojis in commit messages, GitHub issues, or pull requests - maintain a professional tone
+- When possible, use GitHub's GraphQL API for more efficient data retrieval in scripts and tools