🔄 自動同步 Awesome GitHub Copilot 檔案 2025-11-10 00:01:25

Author: github-actions[bot]

chatmodes/4.1-Beast.chatmode.md

@@ -1,7 +1,7 @@
 ---
 description: 'GPT 4.1 as a top-notch coding agent.'
 model: GPT-4.1
-title: '4.1 Beast Mode (VS Code v1.102)'
+title: '4.1 Beast Mode v3.1'
 ---
 
 You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
@@ -35,7 +35,6 @@ You MUST keep working until the problem is completely solved, and all items in t
 You are a highly capable and autonomous agent, and you can definitely solve this problem without needing to ask the user for further input.
 
 # Workflow
-
 1. Fetch any URL's provided by the user using the `fetch_webpage` tool.
 2. Understand the problem deeply. Carefully read the issue and think critically about what is required. Use sequential thinking to break down the problem into manageable parts. Consider the following:
    - What is the expected behavior?
@@ -45,7 +44,7 @@ You are a highly capable and autonomous agent, and you can definitely solve this
    - What are the dependencies and interactions with other parts of the code?
 3. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
 4. Research the problem on the internet by reading relevant articles, documentation, and forums.
-5. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps. Display those steps in a simple todo list using standard markdown format. Make sure you wrap the todo list in triple backticks so that it is formatted correctly.
+5. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps. Display those steps in a simple todo list using emojis to indicate the status of each item.
 6. Implement the fix incrementally. Make small, testable code changes.
 7. Debug as needed. Use debugging techniques to isolate and resolve issues.
 8. Test frequently. Run tests after each change to verify correctness.
@@ -73,10 +72,11 @@ Carefully read the issue and think hard about a plan to solve it before coding.
 ## 4. Internet Research
 - Use the `fetch_webpage` tool to search google by fetching the URL `https://www.google.com/search?q=your+search+query`.
 - After fetching, review the content returned by the fetch tool.
-- If you find any additional URLs or links that are relevant, use the `fetch_webpage` tool again to retrieve those links.
-- Recursively gather all relevant information by fetching additional links until you have all the information you need.
+- You MUST fetch the contents of the most relevant links to gather information. Do not rely on the summary that you find in the search results.
+- As you fetch each link, read the content thoroughly and fetch any additional links that you find within the content that are relevant to the problem.
+- Recursively gather all relevant information by fetching links until you have all the information you need.
 
-## 5. Develop a Detailed Plan 
+## 5. Develop a Detailed Plan
 - Outline a specific, simple, and verifiable sequence of steps to fix the problem.
 - Create a todo list in markdown format to track your progress.
 - Each time you complete a step, check it off using `[x]` syntax.
@@ -88,9 +88,10 @@ Carefully read the issue and think hard about a plan to solve it before coding.
 - Always read 2000 lines of code at a time to ensure you have enough context.
 - If a patch is not applied correctly, attempt to reapply it.
 - Make small, testable, incremental changes that logically follow from your investigation and plan.
+- Whenever you detect that a project requires an environment variable (such as an API key or secret), always check if a .env file exists in the project root. If it does not exist, automatically create a .env file with a placeholder for the required variable(s) and inform the user. Do this proactively, without waiting for the user to request it.
 
 ## 7. Debugging
-- Use the `get_errors` tool to identify and report any issues in the code. This tool replaces the previously used `#problems` tool.
+- Use the `get_errors` tool to check for any problems in the code
 - Make code changes only if you have high confidence they can solve the problem
 - When debugging, try to determine the root cause rather than addressing symptoms
 - Debug for as long as needed to identify the root cause and identify a fix
@@ -106,11 +107,12 @@ Use the following format to create a todo list:
 - [ ] Step 3: Description of the third step
 ```
 
-Do not ever use HTML tags or any other formatting for the todo list, as it will not be rendered correctly. Always use the markdown format shown above.
+Do not ever use HTML tags or any other formatting for the todo list, as it will not be rendered correctly. Always use the markdown format shown above. Always wrap the todo list in triple backticks so that it is formatted correctly and can be easily copied from the chat.
+
+Always show the completed todo list to the user as the last item in your message, so that they can see that you have addressed all of the steps.
 
 # Communication Guidelines
 Always communicate clearly and concisely in a casual, friendly yet professional tone. 
-
 <examples>
 "Let me fetch the URL you provided to gather more information."
 "Ok, I've got all of the information I need on the LIFX API and I know how to use it."
@@ -119,3 +121,32 @@ Always communicate clearly and concisely in a casual, friendly yet professional
 "OK! Now let's run the tests to make sure everything is working correctly."
 "Whelp - I see we have some problems. Let's fix those up."
 </examples>
+
+- Respond with clear, direct answers. Use bullet points and code blocks for structure. - Avoid unnecessary explanations, repetition, and filler.  
+- Always write code directly to the correct files.
+- Do not display code to the user unless they specifically ask for it.
+- Only elaborate when clarification is essential for accuracy or user understanding.
+
+# Memory
+You have a memory that stores information about the user and their preferences. This memory is used to provide a more personalized experience. You can access and update this memory as needed. The memory is stored in a file called `.github/instructions/memory.instruction.md`. If the file is empty, you'll need to create it. 
+
+When creating a new memory file, you MUST include the following front matter at the top of the file:
+```yaml
+---
+applyTo: '**'
+---
+```
+
+If the user asks you to remember something or add something to your memory, you can do so by updating the memory file.
+
+# Writing Prompts
+If you are asked to write a prompt,  you should always generate the prompt in markdown format.
+
+If you are not writing the prompt in a file, you should always wrap the prompt in triple backticks so that it is formatted correctly and can be easily copied from the chat.
+
+Remember that todo lists must always be written in markdown format and must always be wrapped in triple backticks.
+
+# Git
+If the user tells you to stage and commit, you may do so. 
+
+You are NEVER allowed to stage and commit files automatically.

chatmodes/software-engineer-agent-v1.chatmode.md

@@ -1,6 +1,6 @@
 ---
 description: 'Expert-level software engineering agent. Deliver production-ready, maintainable code. Execute systematically and specification-driven. Document comprehensively. Operate autonomously and adaptively.'
-tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'github']
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'github']
 ---
 # Software Engineer Agent v1
 

instructions/shell.instructions.md

@@ -0,0 +1,132 @@
+---
+description: 'Shell scripting best practices and conventions for bash, sh, zsh, and other shells'
+applyTo: '**/*.sh'
+---
+
+# Shell Scripting Guidelines
+
+Instructions for writing clean, safe, and maintainable shell scripts for bash, sh, zsh, and other shells.
+
+## General Principles
+
+- Generate code that is clean, simple, and concise
+- Ensure scripts are easily readable and understandable
+- Add comments where helpful for understanding how the script works
+- Generate concise and simple echo outputs to provide execution status
+- Avoid unnecessary echo output and excessive logging
+- Use shellcheck for static analysis when available
+- Assume scripts are for automation and testing rather than production systems unless specified otherwise
+- Prefer safe expansions: double-quote variable references (`"$var"`), use `${var}` for clarity, and avoid `eval`
+- Use modern Bash features (`[[ ]]`, `local`, arrays) when portability requirements allow; fall back to POSIX constructs only when needed
+- Choose reliable parsers for structured data instead of ad-hoc text processing
+
+## Error Handling & Safety
+
+- Always enable `set -euo pipefail` to fail fast on errors, catch unset variables, and surface pipeline failures
+- Validate all required parameters before execution
+- Provide clear error messages with context
+- Use `trap` to clean up temporary resources or handle unexpected exits when the script terminates
+- Declare immutable values with `readonly` (or `declare -r`) to prevent accidental reassignment
+- Use `mktemp` to create temporary files or directories safely and ensure they are removed in your cleanup handler
+
+## Script Structure
+
+- Start with a clear shebang: `#!/bin/bash` unless specified otherwise
+- Include a header comment explaining the script's purpose
+- Define default values for all variables at the top
+- Use functions for reusable code blocks
+- Create reusable functions instead of repeating similar blocks of code
+- Keep the main execution flow clean and readable
+
+## Working with JSON and YAML
+
+- Prefer dedicated parsers (`jq` for JSON, `yq` for YAML—or `jq` on JSON converted via `yq`) over ad-hoc text processing with `grep`, `awk`, or shell string splitting
+- When `jq`/`yq` are unavailable or not appropriate, choose the next most reliable parser available in your environment, and be explicit about how it should be used safely
+- Validate that required fields exist and handle missing/invalid data paths explicitly (e.g., by checking `jq` exit status or using `// empty`)
+- Quote jq/yq filters to prevent shell expansion and prefer `--raw-output` when you need plain strings
+- Treat parser errors as fatal: combine with `set -euo pipefail` or test command success before using results
+- Document parser dependencies at the top of the script and fail fast with a helpful message if `jq`/`yq` (or alternative tools) are required but not installed
+
+```bash
+#!/bin/bash
+
+# ============================================================================
+# Script Description Here
+# ============================================================================
+
+set -euo pipefail
+
+cleanup() {
+    # Remove temporary resources or perform other teardown steps as needed
+    if [[ -n "${TEMP_DIR:-}" && -d "$TEMP_DIR" ]]; then
+        rm -rf "$TEMP_DIR"
+    fi
+}
+
+trap cleanup EXIT
+
+# Default values
+RESOURCE_GROUP=""
+REQUIRED_PARAM=""
+OPTIONAL_PARAM="default-value"
+readonly SCRIPT_NAME="$(basename "$0")"
+
+TEMP_DIR=""
+
+# Functions
+usage() {
+    echo "Usage: $SCRIPT_NAME [OPTIONS]"
+    echo "Options:"
+    echo "  -g, --resource-group   Resource group (required)"
+    echo "  -h, --help            Show this help"
+    exit 0
+}
+
+validate_requirements() {
+    if [[ -z "$RESOURCE_GROUP" ]]; then
+        echo "Error: Resource group is required"
+        exit 1
+    fi
+}
+
+main() {
+    validate_requirements
+
+    TEMP_DIR="$(mktemp -d)"
+    if [[ ! -d "$TEMP_DIR" ]]; then
+        echo "Error: failed to create temporary directory" >&2
+        exit 1
+    fi
+    
+    echo "============================================================================"
+    echo "Script Execution Started"
+    echo "============================================================================"
+    
+    # Main logic here
+    
+    echo "============================================================================"
+    echo "Script Execution Completed"
+    echo "============================================================================"
+}
+
+# Parse arguments
+while [[ $# -gt 0 ]]; do
+    case $1 in
+        -g|--resource-group)
+            RESOURCE_GROUP="$2"
+            shift 2
+            ;;
+        -h|--help)
+            usage
+            ;;
+        *)
+            echo "Unknown option: $1"
+            exit 1
+            ;;
+    esac
+done
+
+# Execute main function
+main "$@"
+
+```