feat: add diagnose_deployment_failure and add_release_notes prompts

[egorpavlikhin]

Summary

Adds the first two MCP prompts to the server, registered alongside tools and resources:

• diagnose_deployment_failure — walks the LLM through analyzing a failed deployment or runbook run: locate the failed task, extract the specific error, categorize it, suggest remediation. Points at the relevant tools (find_releases/find_runbooks, list_deployments, get_task_from_url, read_resource for the task activity tree, grep_task_log, find_events) and reminds about release snapshotting.
• add_release_notes — guides the LLM through summarizing a change set into a Markdown changelog and writing it to an existing release via the PUT /releases/{id} round-trip (read full body → swap ReleaseNotes → PUT back), with a create_release fallback when no matching release exists. Flags Octostache non-re-evaluation and ReleaseEdit permission gotchas.

Both prompts require spaceName and projectName; release version / runbook name are optional and steer behavior. Wired into src/index.ts via a new registerPrompts barrel mirroring the tool/resource registration pattern.

Test plan

• Build passes (npm run build)
• Lint passes (npm run lint)
• Connect a client (Claude Code / MCP Inspector) and confirm both prompts appear in prompts/list
• Run diagnose_deployment_failure against a known failed deployment and confirm the LLM follows the prescribed tool path
• Run add_release_notes end-to-end: draft notes, PUT round-trip, verify only ReleaseNotes changed on the release
• Run add_release_notes against a non-existent release version and confirm the create_release fallback engages

[akirayamamoto]

I left some comments there, happy to discuss.

[akirayamamoto]

What if the one I want to diagnose is not the most recently failed? For example, not the lastest runbook run? It could be an intermittent one.

It could be possible for a release as well but less likely.

[akirayamamoto]

Leaving the range of category open (and not well defined) could lead to unpredictable results, therefore, I wonder if extracting a category here is useful. Maybe we are looking for a summary?

[akirayamamoto]

"Follow the Octopus Deploy writing guide" is this guide available in the MCP server? If not it could be dropped.

[akirayamamoto]

I think this would be more predictable if we split the workflow into draft_release_notes and set_release_notes.

draft_release_notes should be a non-mutating prompt: take explicit source material, like PRs, commits, tickets, or a user-provided changelog, and return a draft for review.

set_release_notes should probably be a tool, not a prompt. Updating ReleaseNotes is a concrete Octopus write operation, so it benefits from typed inputs, validation, confirmation, tests, and deterministic behavior. It should update an existing release only and not fall back to creating one.

For creating releases, I’d use the existing create_release tool and recommend passing releaseNotes there when needed. That tool already supports release notes, so a separate “create release with notes” prompt would duplicate behavior.

This keeps the boundaries clearer:

• draft notes: prompt, no side effects
• set notes on an existing release: tool, write operation
• create a release with notes: existing create_release tool

The current add_release_notes prompt mixes drafting, release selection, updating, and fallback creation in one flow. That makes the outcome harder to predict, especially when releaseVersion is omitted or the release is not found.