open-webui/Fu-Jie_openwebui-extensions
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0c7201902c20c3dc197d708d98f7b67e15229f38
Fu-Jie_openwebui-extensions/.github/skills/release-prep/SKILL.md
Fu-Jie 0c7201902c 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
2026-02-28 03:50:56 +08:00

5.5 KiB
Raw Blame History

name, description
name description
release-prep 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 — ![updated](https://img.shields.io/badge/YYYY--MM--DD-gray?style=flat)
  • 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:

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"):

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
Reference in New Issue View Git Blame Copy Permalink