0c7201902c
* 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
145 lines
5.5 KiB
Markdown
145 lines
5.5 KiB
Markdown
---
|
|
name: release-prep
|
|
description: Orchestrates the full release preparation flow for a plugin — version sync across 7+ files, bilingual release notes creation, and commit message drafting. Use before submitting a PR. Does NOT push or create a PR; that is handled by pr-submitter.
|
|
---
|
|
|
|
# Release Prep
|
|
|
|
## Overview
|
|
|
|
This skill drives the complete pre-PR release pipeline. It enforces the repository rule that every release must synchronize the version number and changelog across **at least 7 locations** before a commit is created.
|
|
|
|
## Scope
|
|
|
|
This skill covers:
|
|
1. Version sync (delegates detail to `version-bumper` if needed)
|
|
2. Bilingual release notes file creation
|
|
3. 7-location consistency verification
|
|
4. Conventional Commits message drafting
|
|
5. `git add -A && git commit` execution
|
|
|
|
It **stops before** `git push` or `gh pr create`. Use the `pr-submitter` skill for those steps.
|
|
|
|
### Temporary File Convention
|
|
|
|
Any temporary files created during release prep (e.g., draft changelogs) must:
|
|
- Be written to the project's `.temp/` directory, **NOT** system `/tmp`
|
|
- Be cleaned up before commit using `rm -f .temp/file_name`
|
|
- Never be committed to git (add `.temp/` to `.gitignore`)
|
|
|
|
---
|
|
|
|
## Workflow
|
|
|
|
### Step 1 — Collect Release Info
|
|
|
|
Ask the user (or infer from current state) the following:
|
|
- **Plugin name** and **type** (actions / filters / pipes / tools)
|
|
- **New version number** (e.g., `0.8.0`)
|
|
- **Key changes** in English and Chinese (1-5 bullet points each)
|
|
|
|
If a `What's New` section already exists in README.md, extract it as the source of truth.
|
|
|
|
### Step 2 — Sync Version Across 7 Locations
|
|
|
|
Verify AND update the version string in all of the following. Mark each as ✅ or ❌:
|
|
|
|
| # | File | Location |
|
|
|---|------|----------|
|
|
| 1 | `plugins/{type}/{name}/{name}.py` | `version:` in docstring |
|
|
| 2 | `plugins/{type}/{name}/README.md` | `**Version:** x.x.x` metadata line |
|
|
| 3 | `plugins/{type}/{name}/README_CN.md` | `**Version:** x.x.x` metadata line |
|
|
| 4 | `docs/plugins/{type}/{name}.md` | `**Version:** x.x.x` metadata line |
|
|
| 5 | `docs/plugins/{type}/{name}.zh.md` | `**Version:** x.x.x` metadata line |
|
|
| 6 | `docs/plugins/{type}/index.md` | version badge for this plugin |
|
|
| 7 | `docs/plugins/{type}/index.zh.md` | version badge for this plugin |
|
|
|
|
Additionally update the root-level **updated date badge** in:
|
|
- `README.md` — ``
|
|
- `README_CN.md` — same badge format
|
|
|
|
Use today's date (`YYYY-MM-DD`) for the badge.
|
|
|
|
### Step 3 — Update What's New (All 4 Doc Files)
|
|
|
|
The `What's New` / `最新更新` section must contain **only the most recent release's changes**. Previous entries should be removed from this section (they live in CHANGELOG or release notes files).
|
|
|
|
Update these 4 files' `What's New` / `最新更新` block consistently:
|
|
- `plugins/{type}/{name}/README.md`
|
|
- `plugins/{type}/{name}/README_CN.md`
|
|
- `docs/plugins/{type}/{name}.md`
|
|
- `docs/plugins/{type}/{name}.zh.md`
|
|
|
|
### Step 4 — Create Bilingual Release Notes Files
|
|
|
|
Create two versioned release notes files:
|
|
|
|
**Path**: `plugins/{type}/{name}/v{version}.md`
|
|
**Path**: `plugins/{type}/{name}/v{version}_CN.md`
|
|
|
|
#### Required Sections
|
|
|
|
Each file must include:
|
|
1. **Title**: `# v{version} Release Notes` (EN) / `# v{version} 版本发布说明` (CN)
|
|
2. **Overview**: One paragraph summarizing this release
|
|
3. **New Features** / **新功能**: Bulleted list of features
|
|
4. **Bug Fixes** / **问题修复**: Bulleted list of fixes
|
|
5. **Migration Notes** / **迁移说明**: Breaking changes or Valve key renames (omit section if none)
|
|
6. **Companion Plugins** / **配套插件** (optional): If a companion plugin was updated
|
|
|
|
If a release notes file already exists for this version, update it rather than creating a new one.
|
|
|
|
### Step 5 — Verify Consistency (Pre-Commit Check)
|
|
|
|
Run the consistency check script:
|
|
|
|
```bash
|
|
python3 scripts/check_version_consistency.py
|
|
```
|
|
|
|
If issues are found, fix them before proceeding. Do not commit with inconsistencies.
|
|
|
|
### Step 6 — Draft Conventional Commits Message
|
|
|
|
Generate the commit message following `commit-message.instructions.md` rules:
|
|
- **Language**: English ONLY
|
|
- **Format**: `type(scope): subject` + blank line + body bullets
|
|
- **Scope**: use plugin folder name (e.g., `github-copilot-sdk`)
|
|
- **Body**: 1-3 bullets summarizing key changes
|
|
- Explicitly mention "READMEs and docs synced" if version was bumped
|
|
|
|
Present the full commit message to the user for review before executing.
|
|
|
|
### Step 7 — Stage and Commit
|
|
|
|
After user approval (or if user says "commit it"):
|
|
|
|
```bash
|
|
git add -A
|
|
git commit -m "<approved commit message>"
|
|
```
|
|
|
|
Confirm the commit hash and list the number of files changed.
|
|
|
|
---
|
|
|
|
## Checklist (Auto-Verify Before Commit)
|
|
|
|
- [ ] `version:` in `.py` docstring matches target version
|
|
- [ ] `**Version:**` in all 4 README/docs files matches
|
|
- [ ] Both `index.md` version badges updated
|
|
- [ ] Root `README.md` and `README_CN.md` date badges updated to today
|
|
- [ ] `What's New` / `最新更新` contains ONLY the latest release
|
|
- [ ] `v{version}.md` and `v{version}_CN.md` created or updated
|
|
- [ ] `python3 scripts/check_version_consistency.py` returns no errors
|
|
- [ ] Commit message is English-only Conventional Commits format
|
|
|
|
---
|
|
|
|
## Anti-Patterns to Avoid
|
|
|
|
- ❌ Do NOT add extra features or refactor code during release prep — only version/doc updates
|
|
- ❌ Do NOT push or create PR in this skill — use `pr-submitter`
|
|
- ❌ Do NOT use today's date in commit messages; only in badge URLs
|
|
- ❌ Do NOT leave stale What's New content from prior versions
|