feature

name	feature
description	Plan new features or bug fixes for openstack-k8s-operators operators with Jira integration, cross-repo analysis, and structured implementation strategies
argument-hint	<ticket-id | spec-file.md> [--continue]
user-invocable	true
allowed-tools	["Bash","Read","Write","Grep","Glob","WebFetch","Agent","TaskCreate","TaskUpdate"]
context	fork

You are the openstack-k8s-operators feature planning skill. You orchestrate the planning process and dispatch the feature agent for the heavy lifting.

Input Routing

Determine the input source:

1. Jira ticket: If the argument matches a Jira ticket pattern (e.g., OSPRH-2345, RHOSZ-1234 — uppercase letters, dash, digits):
   • Fetch the ticket via Atlassian MCP
   • Validate Jira hierarchy (see /jira skill rules): if the ticket is an epic with no linked story (or only a Spike), warn the user and suggest creating a story first. If it's a story or bug, proceed.
   • Deep Jira inspection: walk up the hierarchy to the parent Feature/Initiative and inspect all sibling Epics, Stories, Spikes, and Bugs. Collect linked PRs, related resources, and context that might be relevant to the work. See the agent's Jira Context Gathering section for details.
   • If MCP is not available or the call fails, inform the user: "Atlassian MCP is not configured or the ticket could not be fetched. Please provide a spec file path or paste the ticket content."
2. Spec file: If the argument is a file path (e.g., spec.md, docs/my-feature.md) and the file exists on disk, read it.
3. Interactive: If no argument is provided, ask: "Do you have a Jira ticket ID (e.g., OSPRH-2345) or a spec file path?"

Resume Detection

After determining the input source but BEFORE starting the planning process, check for an existing plan:

1. Derive the operator name from the current working directory basename
2. Scan ~/.openstack-k8s-agent-plans/<operator>/ for files matching the ticket ID or spec slug
3. If a matching plan file is found, read it and determine its state:
   • Incomplete plan (missing sections like Strategies or Task Breakdown): offer "Found an incomplete plan from . Resume planning, or start fresh?"
   • Complete plan, no strategy approved (strategies listed but none marked selected): re-present the strategies for approval
   • Complete plan with tasks (all sections present, tasks listed): report "Plan already complete. Run /task-executor to execute, or start fresh?"
4. If no matching plan file is found, proceed with a new plan
5. If --continue flag is provided, skip the prompt and go straight to resume

Workflow

1. Determine input source (Jira ticket, spec file, or interactive)
2. Check for existing plan — resume or start fresh (see Resume Detection above)
3. Dispatch the feature agent to perform the planning:

Agent(
  subagent_type="openstack-k8s-agent-tools:feature:feature",
  description="Plan <ticket-or-slug>",
  prompt="<Context Summary + operator name + resume state if applicable>"
)

The agent handles: input normalization, cross-repo analysis, planning checklist, strategy proposals, task breakdown, and plan file writing.

1. Present the agent's output to the user
2. Wait for user to approve a strategy (if not already approved during resume)
3. Create internal tasks via TaskCreate for tracking

When resuming, pass the existing plan content to the agent so it can skip completed sections.

Prerequisites

• Atlassian MCP (optional): Configure the Atlassian MCP server in Claude Code settings for Jira integration. Without it, the skill works with spec files or pasted content.
• GitHub CLI (optional): gh CLI for remote repo browsing when local checkouts are not available.

Jira Integration

This skill follows the hierarchy rules defined in the /jira skill:

• Outcome comments go on the story, never on the epic
• If the input ticket is an epic with no stories, suggest creating one before planning
• Tasks from the plan breakdown can optionally be created as Jira tasks under the story

Quick Reference

The agent evaluates these planning principles:

• API Changes: new/modified CRD fields, types, version bumps
• lib-common Reuse: existing helpers, upstream contributions needed
• Code Duplication: similar logic in this operator or peers
• Code Style: gopls modernize, import grouping, error wrapping
• Webhook Changes: validation, defaulting, field paths
• Status Conditions: new conditions, severity/reason rules, ObservedGeneration
• EnvTest Tests: new reconciliation paths needing coverage
• Kuttl Tests: integration scenarios needed
• RBAC: new resources, kubebuilder markers
• Pre-existing Evidence: logs, errors, reproduction steps (for bugs)
• Documentation: dev-docs updates, inline doc changes