菜单
Write user-facing release notes from git history. Use when preparing announcements, GitHub Releases, or user documentation. Differs from changelog — focuses on user impact, not implementation or crate structure.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit godmode skills, agents, and plugin files for internal consistency, broken references, stale commands, and cross-skill contradictions. Use when asked to "introspect", "audit the skills", "review godmode", or after adding new skills.
Use at the start of every conversation to orient to available skills and workspace rules. Replaces superpowers entirely. Triggers on session start, "/godmode", or "what skills do you have".
Generate and maintain a `.ctx/godmode/memory-bank/` directory that captures project context backed by source code. The memory bank is injected into prompts via lifecycle hooks and updated incrementally as work progresses. Use when starting a new project, onboarding to an unfamiliar codebase, or when context drift is detected.
Patterns and techniques for adding governance, safety, and trust controls to AI agent systems in Rust. Use this skill when building agents that call external tools, implementing policy-based access controls, adding semantic intent classification to detect dangerous prompts, creating trust scoring systems for multi-agent workflows, building audit trails, or enforcing rate limits and content filters. Covers policy composition, tool wrappers, trust decay, and JSONL audit trails — all in Rust.
Parse git history into structured changelogs. Use to generate release notes, audit commit conventions before tagging, or integrate with `godmode release` workflow.
Dead code detector for Rust workspaces. Finds unused public API surface, orphaned test helpers, stale feature flags, and plugin artifacts referencing removed CLI subcommands. Cross-references pub exports against call sites across the workspace.
| name | godmode:release-notes |
| description | Write user-facing release notes from git history. Use when preparing announcements, GitHub Releases, or user documentation. Differs from changelog — focuses on user impact, not implementation or crate structure. |
| requires | [] |
| next | [] |
| Aspect | Changelog | Release Notes |
|---|---|---|
| Audience | Developers, maintainers | End users |
| Grouping | By crate, then type | By user-visible feature area |
| Language | Technical | Plain, user-centric |
| Detail level | Commit granularity | User impact only |
| Scope | All changes | User-visible changes only |
Changelog: "refactor(dispatch): use Arc for thread-safe graph mutations"
Release Notes: "Task execution is now thread-safe, allowing larger projects to run without race conditions."
Group changes by how users perceive them, not by implementation structure.
User-visible areas:
Skip entirely:
--parallel N to run
multiple tasks concurrently"Example:
godmode task list --priority high, making it easier to focus on critical work."Always include a "Breaking Changes" section if applicable. For each breaking change:
Example:
## Breaking Changes
### `godmode task add` flag rename
The `--depends` flag has been renamed to `--depends-on` for consistency.
**Migration**: Update scripts that use `godmode task add` from
`--depends t1,t2` to `--depends-on t1,t2`.
Produce markdown with these sections (omit if empty):
# Release v<version>
## What's New
(brand-new user-facing features)
## Improvements
(enhancements to existing features, performance, documentation)
## Bug Fixes
(critical bugs, correctness issues)
## Breaking Changes
(specify migration path for each)
## Deprecations
(features that still work but will be removed)
## Contributors
(if applicable)
Write final notes to .ctx/ or docs/ as appropriate, then commit.
When bumping versions, pass the notes manually to your release script or commit
alongside the version bump (godmode release bump / tag / push handle the version side).
git log before writing