// Create changelog fragment for release notes. Invoke during /prd-done workflow during the first push to the PR.
Generate intelligent CI/CD workflows through interactive conversation by analyzing repository structure and user preferences
Generate production-ready, secure, multi-stage Dockerfile and .dockerignore for any project
Manage the knowledge base: ingest documents, search with natural language, or delete chunks. Use "ingest" to store organizational documentation, "search" to find relevant content semantically, or "deleteByUri" to remove all chunks for a document. TIP: For complex questions, you can call search multiple times with different phrasings to gather comprehensive information before synthesizing your answer.
Unified tool for managing cluster data: organizational patterns, policy intents, and resource capabilities. For patterns and policies: supports create, list, get, delete, deleteAll, and search operations (patterns also support step-by-step creation workflow). For capabilities: supports scan, list, get, delete, deleteAll, and progress operations for cluster resource capability discovery and management. Use dataType parameter to specify what to manage: "pattern" for organizational patterns, "policy" for policy intents, "capabilities" for resource capabilities.
AI-powered Kubernetes application operations tool for Day 2 operations. Handles updates, scaling, enhancements, rollbacks, and deletions through natural language intents. Analyzes current state, applies organizational patterns and policies, validates changes via dry-run, and executes approved operations safely.
Remove all Port integrations, Kubernetes resources, and local files created by /port-setup
| name | dot-ai-changelog-fragment |
| description | Create changelog fragment for release notes. Invoke during /prd-done workflow during the first push to the PR. |
| user-invocable | true |
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: