// Create changelog fragment for release notes. Invoke during /prd-done workflow during the first push to the PR.
Generate a feature request prompt for another dot-ai project. Use when you need a feature implemented in a sibling project (MCP server, controller, etc.) to unblock work in the current project.
Create a git worktree for PRD work with a descriptive branch name. Infers PRD from context or asks user.
Process a feature request or response from another dot-ai project. Reads from tmp directory, implements/integrates, and writes response if needed.
Query sibling dot-ai projects to verify features are USABLE (not just defined). IMPORTANT: When calling this skill, explain HOW you plan to use the feature (e.g., 'I need to call X via REST API from the UI' or 'I need to import Y function'). This helps verify the full chain from definition to exposure.
Create a release tag based on accumulated changelog fragments. Run when ready to cut a release.
| name | changelog-fragment |
| description | Create changelog fragment for release notes. Invoke during /prd-done workflow during the first push to the PR. |
Create a towncrier changelog fragment for release notes when completing PRD work. This should be included in the PR so the fragment is reviewed along with the code changes.
If not already known from context, ask: "Which PRD should I create release notes for?"
Look for:
feature/prd-320-*)Read the entire PRD file to extract:
Read pyproject.toml to see the available fragment types. Each [[tool.towncrier.type]] section has:
directory field (the type identifier used in the filename, e.g., feature for .feature.md)Choose the type that best matches the PRD based on those descriptions.
Create file: changelog.d/[issue-id].[type].md
IMPORTANT: Use flat structure, NOT subdirectories!
changelog.d/329.feature.mdchangelog.d/feature/329.mdNaming convention:
issue-id: GitHub issue number from PRD (e.g., 320)type: Type identifier from step 3 (e.g., feature, bugfix, misc)Content format:
## [Feature Title]
[Opening sentence: What this feature is and the problem it solves]
[Key capabilities paragraph: Specific things users can now do, with concrete examples]
[Configuration/usage paragraph if applicable: How to enable or use the feature]
[Documentation link if docs were updated]
Documentation links: If the PRD includes documentation updates, link to the relevant page on devopstoolkit.ai. The URL pattern is:
https://devopstoolkit.ai/docs/{project}/{path}{project} is: mcp (dot-ai), controller (dot-ai-controller), ui (dot-ai-ui), or stack (dot-ai-stack){path} maps from the docs folder (e.g., docs/guides/mcp-recommendation-guide.md → guides/mcp-recommendation-guide)Example: changelog.d/142.feature.md
## Multi-Cluster Management
Manage multiple Kubernetes clusters from a single dot-ai instance. Previously, each cluster required its own dot-ai deployment, making it difficult to compare configurations or apply consistent patterns across environments.
The `query` tool now accepts a `--cluster` flag to target specific clusters, and results indicate which cluster each resource belongs to. The `recommend` tool can generate manifests targeting different clusters with environment-specific customizations. Cross-cluster searches let you find resources across all connected clusters simultaneously—useful for tracking down where a particular workload is deployed. Cluster health aggregation shows a unified view of all clusters in the `version` output.
Configure additional clusters by adding kubeconfig contexts to `ADDITIONAL_KUBECONFIGS` (comma-separated paths). Each context becomes available as a cluster target. The default cluster remains the current kubeconfig context when no `--cluster` flag is specified.
See the [Multi-Cluster Setup Guide](https://devopstoolkit.ai/docs/mcp/setup/multi-cluster-setup) for configuration details and examples.
Show the user: