feat(github-copilot-sdk): add workspace skills support (v0.9.0) (#51)
* feat(github-copilot-sdk): add workspace skills support - Introduce ENABLE_WORKSPACE_SKILLS valve to enable/disable workspace custom tools discovery - Modify _build_session_config() to auto-load tools from .copilot-skills/ directory - Add workspace_skills_example.py template with 3 working example tools - Update README.md and README_CN.md with Workspace Skills guide and usage examples - Create v0.9.0.md and v0.9.0_CN.md release notes - Sync version to all docs files (index.md, index.zh.md, and main docs) - Bump version from 0.8.0 to 0.9.0 across all 7+ locations * docs: establish temp files handling policy (project-based, not /tmp) - Add TEMP_FILES_POLICY.md guideline for all skills and workflows - Update pr-submitter skill to use .temp/ directory instead of /tmp - Update release-prep skill documentation with temp file convention - Add .temp/ and .build/ entries to .gitignore - Create internal policy memo in /memories/repo/ This policy ensures: - All temporary files stay within project workspace (not system /tmp) - Alignment with OpenWebUI workspace isolation principles - Multi-user safety and cleanup traceability - Consistent handling across all skills and development workflows * fix(terminology): rename 'workspace skills' to 'workspace custom tools' for accuracy The term 'Skills' in Anthropic context refers to instruction-based frameworks (SKILL.md files with YAML frontmatter + markdown), not custom tool functions. Our implementation uses @define_tool decorator to define custom tools that the SDK auto-discovers from .copilot-skills/ directory. These are Tools, not Skills. Changes: - Rename ENABLE_WORKSPACE_SKILLS valve -> ENABLE_WORKSPACE_TOOLS - Update all documentation (README, README_CN, docs, release notes) - Fix section headings and descriptions throughout - Ensure consistent terminology across all files This is a terminology-only change; functionality remains identical. * feat(pipes): release v0.9.0 of GitHub Copilot SDK Pipe - Integrated OpenWebUI Skills Bridge and manage_skills tool - Reinforced status bar stability with session_finalized logic - Added persistent SDK config directory support * docs(pipes): add comprehensive guides and v0.9.0 notes for Copilot SDK - Added skill manager and best practices guides - Added publishing tool documentation - Included v0.9.0 release notes and deployment script - Updated usage guides
This commit is contained in:
64
.agent/skills/test-copilot-pipe/SKILL.md
Normal file
64
.agent/skills/test-copilot-pipe/SKILL.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
name: test-copilot-pipe
|
||||
description: Automotive deployment and testing of GitHub Copilot SDK Pipe plugin for frontend/backend status stability.
|
||||
---
|
||||
|
||||
# 🤖 Skill: Test Copilot Pipe
|
||||
|
||||
This is a **universal testing framework** for publishing the latest `github_copilot_sdk.py` (Pipe) code to a local OpenWebUI instance and verifying it via an automated agent (`browser_subagent`).
|
||||
|
||||
## 🎯 Core Principles
|
||||
|
||||
- **Fixed Infrastructure**: The deployment script and the test entry URL are always static.
|
||||
- **Dynamic Test Planning**: Specific test prompts and expectations (acceptance criteria) **must** be dynamically planned by you based on the code changes or specific user requests before execution.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Static Environment Info
|
||||
|
||||
| Attribute | Fixed Value |
|
||||
|------|--------|
|
||||
| **Deployment Script** | `/Users/fujie/app/python/oui/openwebui-extensions/scripts/update_pipe.py` |
|
||||
| **Python Path** | `/opt/homebrew/Caskroom/miniconda/base/envs/ai/bin/python3` |
|
||||
| **Test URL** | `http://localhost:3003/?model=github_copilot_official_sdk_pipe.github_copilot_sdk-gpt-4.1` |
|
||||
|
||||
---
|
||||
|
||||
## 📋 Standard Workflow
|
||||
|
||||
### Step 1: Analyze Changes & Plan Test (Plan)
|
||||
|
||||
Before triggering the test, you must define the purpose of this test turn.
|
||||
Example: *Modified tool calling logic -> Test prompt should trigger a specific tool; observe if the tool executes and returns the correct result.*
|
||||
|
||||
### Step 2: Deploy Latest Code (Deploy)
|
||||
|
||||
Use the `run_command` tool to execute the fixed update task:
|
||||
|
||||
```bash
|
||||
/opt/homebrew/Caskroom/miniconda/base/envs/ai/bin/python3 /Users/fujie/app/python/oui/openwebui-extensions/scripts/update_pipe.py
|
||||
```
|
||||
|
||||
> **Mechanism**: `update_pipe.py` automatically loads the API Key from `scripts/.env` in the same directory.
|
||||
> **Verification**: Look for `✅ Successfully updated... version X.X.X`. If a 401 error occurs, remind the user to generate a new API Key in OpenWebUI and update `.env`.
|
||||
|
||||
### Step 3: Verify via Browser Subagent (Verify)
|
||||
|
||||
Use the `browser_subagent` tool. **You must fill in the `[Dynamic Content]` slots based on Step 1**:
|
||||
|
||||
```text
|
||||
Task:
|
||||
1. Access The Fixed URL: http://localhost:3003/?model=github_copilot_official_sdk_pipe.github_copilot_sdk-gpt-4.1
|
||||
2. RELIABILITY WAIT: Wait until the page fully loads. Wait until the chat input text area (`#chat-input`) is present in the DOM.
|
||||
3. ACTION - FAST INPUT: Use the `execute_browser_javascript` tool to instantly inject the query and submit it. Use exactly this script format to ensure stability:
|
||||
`const input = document.getElementById('chat-input'); input.value = "[YOUR_DYNAMIC_TEST_PROMPT]"; input.dispatchEvent(new Event('input', { bubbles: true })); const e = new KeyboardEvent('keydown', { key: 'Enter', code: 'Enter', keyCode: 13, which: 13, bubbles: true }); input.dispatchEvent(e);`
|
||||
4. WAITING: Wait patiently for the streaming response to stop completely. You should wait for the Stop button to disappear, or wait for the system to settle (approximately 10-15 seconds depending on the query).
|
||||
5. CHECK THE OUTCOME: [List the phenomena you expect to see, e.g., status bar shows specific text, tool card appears, result contains specific keywords, etc.]
|
||||
6. CAPTURE: Take a screenshot of the settled state to prove the outcome.
|
||||
7. REPORT: Report the EXACT outcome matching the criteria from step 5.
|
||||
```
|
||||
|
||||
### Step 4: Evaluate & Iterate (Evaluate)
|
||||
|
||||
- **PASS**: Screenshot and phenomena match expectations. Report success to the user.
|
||||
- **FAIL**: Analyze the issue based on screenshots/logs (e.g., race condition reappeared, API error). Modify the code and **re-run the entire skill workflow**.
|
||||
Reference in New Issue
Block a user