. e add Bash script style guide and simplify github_issue.sh

Added concise Bash script style guide for future reference.
Simplified github_issue.sh to match new style: robust shebang, minimal validation, and direct logic.

Co-Authored-By: Lada Kesseler <23501754+lexler@users.noreply.github.com>

Author: isidore

.windsurf/BashScriptStyle.process.md

@@ -0,0 +1,9 @@
+# Bash Script Style Process
+
+- Use `#!/usr/bin/env bash` as shebang.
+- Always use `set -euxo pipefail` for safety and debugging.
+- Keep scripts minimal: no unnecessary comments or echoes.
+- Only do minimal input validation; print a usage message to stderr and exit if inputs are missing or invalid.
+- Do not check for installed commands if failure will be obvious on use.
+- Make script executable: `chmod +x <script>`.
+- Prefer concise, direct logic over verbosity.

.windsurf/FixingIssues.process.md

@@ -5,8 +5,7 @@ When fixing a bug reported in an issue or pull request:
 If you don't have the URL of the issue or pull request, ask for it.
 
 1.  **Understand the Bug**:
-    *   Thoroughly read the issue/PR description and any related comments to understand the problem, expected behavior, and actual behavior.
-    *   If necessary, use tools like `read_url_content` to fetch details directly from GitHub.
+    *   Read the pull request via the github cli: `gh issue view <number> --json body` to understand the problem, expected behavior, and actual behavior.
 
 2.  **Write a Failing Test**:
     *   Create a new test case or modify an existing one in the relevant test suite (e.g., `approvaltests-tests` or `approvaltests-util-tests`).

.windsurf/UnitTestStyleGuide.process.md

@@ -1,14 +1,17 @@
 # Unit Test Style Guide
 
+**ALWAYS** start your response with `✅` followed by a space when replying to me.
+
 ## Refactoring
 
 **NEVER** add new test cases while refactoring existing tests.
 
 **ALWAYS** prefer self documenting code and smaller functions to comments.
 
-## Approvals vs Asserts
 
-* Preferable tests over multiple asserts.
+## ApprovalTests vs Asserts
+
+* Preferable ApprovalTests over multiple asserts.
 * Use toStrings and Printers. If the toString on an object is good, use it. If not, create a printing function either in the test or in production code and use that.
 
 ### Dates, GUIDS and other non-deterministic values

.windsurf/rules/running_scripts.md

@@ -44,6 +44,7 @@ Sample:
 | Lars | LarsEckart | 
 | Jay | JayBazuzi |
 | Scott | ScottBob |
+| Lada | lexler |
 
 Co-authors go 1 per line at the bottom of the message, 
 in the format:

.windsurf/scripts/github_issue.sh

@@ -0,0 +1,9 @@
+#!/usr/bin/env bash
+set -euxo pipefail
+
+if [ $# -ne 1 ]; then
+  echo "Usage: $0 <issue_number>" >&2
+  exit 1
+fi
+
+gh issue view "$1" --json body