NO-ISSUE: add release-plan skill for forward-looking version planning - #154
NO-ISSUE: add release-plan skill for forward-looking version planning#154oourfali wants to merge 5 commits into
Conversation
Adds a skill that fetches GitHub Actions check statuses for an OSAC PR, reads failure logs, classifies root causes, and suggests fix commands. Automatically delegates Prow E2E failures to /debug-e2e for deep analysis. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Oved Ourfali <oourfali@redhat.com>
Generates a styled HTML report showing what an OSAC version will deliver, framed as a target plan rather than a progress tracker. Shows cumulative capabilities vs prior version, customer requirements coverage (NCP, Telefónica, MOC, AI Grid), and use-case cards with color-coded badges. Complements /milestone-scope (progress tracking) with an aspirational planning view suitable for stakeholder communication. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Oved Ourfali <oourfali@redhat.com>
|
@oourfali: This pull request explicitly references no jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: oourfali The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: WalkthroughAdds two skill documents: one for CI failure diagnosis and one for Jira-based OSAC release plan generation, including their workflows, output formats, edge cases, and operational guidance. ChangesCI failure analysis
Release plan generation
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
||
| # CI Failure Analysis | ||
|
|
||
| Investigate why CI checks failed on an OSAC pull request. Fetches GitHub Actions check results, reads failure logs, classifies root causes, and suggests the exact command to fix each failure. Delegates Prow E2E failures to `/debug-e2e`. |
There was a problem hiding this comment.
content-inconsistent-terminology): Inconsistent terminology: PR/pull request/merge request — multiple variants used across files. Pick one and use it consistently.
|
|
||
| ### Check appears failed but has no logs | ||
|
|
||
| Some checks (like required status contexts from external systems) don't have GitHub Actions logs. Report the check name and status, and note that logs are not available via `gh`. |
There was a problem hiding this comment.
content-weak-language): Weak language (non-actionable): 'note that' — Restructure — state the constraint directly
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@skills/ci-failure/SKILL.md`:
- Around line 127-131: Specify the text language on the fenced code block
containing the debug-e2e skill tool-call example in SKILL.md by changing the
opening fence to use text, while preserving the example content unchanged.
- Around line 71-76: Validate the extracted RUN_ID before invoking gh run view:
when the check’s link is empty or malformed and RUN_ID is unavailable, report
that logs are unavailable for the check and continue processing the remaining
failures. Keep normal log fetching unchanged for valid run IDs.
- Around line 98-114: Make the “Fix Command” column actionable for every row in
the CI failure reference table. Replace non-command guidance such as “Read test
output for failing test name” and “Check uploaded workflow artifacts” with
concrete commands or diagnostic actions, or rename the column to “Suggested
action” if non-command instructions remain.
- Around line 141-156: Update the CI Failure Analysis report template’s nested
Error code block to use a valid outer/inner Markdown fence combination, such as
four backticks outside the template and three backticks inside, or tildes for
the inner block. Remove the literal backslash escaping so copied reports render
a valid fenced log block.
- Around line 48-54: Update the Step 7 reporting template to include individual
pending checks with elapsed time, plus skipped and cancelled checks, alongside
the existing aggregate passed/failed/pending counts. Ensure the report preserves
these statuses and actionable details when Step 2 finds incomplete CI, while
keeping the all-passing and no-checks messages unchanged.
- Around line 80-86: Update the failed-log retrieval instructions to enumerate
each failed job and fetch its logs separately using the job-specific gh run view
-j JOB_ID option before applying tail or other truncation. Preserve the existing
guidance to inspect the final 100–200 lines and error markers, but ensure
truncation cannot combine multiple jobs and discard earlier job output.
- Around line 60-67: Update the Prow handling between the check detection and
Step 6 delegation to require an explicit E2E classification before invoking
/debug-e2e or labeling a result as a “Prow E2E Failure.” Preserve the existing
behavior for non-E2E Prow failures by handling them separately or excluding them
from E2E delegation, consistent with the skill’s stated contract.
In `@skills/release-plan/SKILL.md`:
- Around line 60-64: Update the NCP requirements workflow around the OSAC-991
enumeration to define all 13 requirement identifiers explicitly, verify that
discovery returns exactly 13 requirements, and resolve each linked OSAC feature
across versions before mapping coverage. Require Section 5 to include an
explicit row for every unlinked or uncovered requirement instead of silently
omitting it.
- Around line 16-18: Define explicit validation for the release-plan workflow’s
Target version and Prior version arguments before any Jira query: require
exactly one or two arguments, parse both using the supported version format,
reject identical versions, and ensure the prior version is strictly older than
the target. Resolve the default prior version numerically rather than lexically,
including cases such as 0.10, and exit with a clear error for invalid input.
- Around line 118-147: Update Step 6 HTML report generation to HTML-escape every
Jira-sourced text field, including summaries, descriptions, labels, and customer
tags, before embedding it in the browser-opened report. If limited rich text is
supported, sanitize it with an explicit allowlist; otherwise render all Jira
content as plain text.
- Around line 103-116: Update “Step 5: Build the Service Offering Matrix” with
deterministic, evidence-based rules mapping Jira components, descriptions,
features, and epics to each of the five dimensions. Require every matrix claim
to cite and retain its supporting feature or epic keys, and mark cells as
unknown rather than infer capabilities when evidence is absent.
- Around line 10-12: Update the Jira query guidance throughout the release-plan
workflow so completed-feature queries require resolution = Done, while queries
intentionally including unresolved planning items use resolution IS EMPTY OR
resolution = Done. Apply this consistently to the target open, prior,
Telefónica, and MOC queries so non-Done resolutions cannot appear in foundation,
coverage tables, inventory, or action notes; clarify that “duplicates” in notes
is generic guidance, not specific issue IDs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: b2d6664d-6e70-468d-bf51-b86baf529b1c
📒 Files selected for processing (2)
skills/ci-failure/SKILL.mdskills/release-plan/SKILL.md
| **Edge cases — handle before continuing:** | ||
|
|
||
| | Condition | Action | | ||
| |-----------|--------| | ||
| | All checks pass | Report "All CI checks are passing on `$REPO#$PR_NUMBER`." and stop. | | ||
| | Checks still running | Report which are pending (with elapsed time) and which have passed/failed so far. Analyze any failures that are already complete. | | ||
| | No checks found | Report "No CI checks found. Verify the PR URL and that workflows are enabled." and stop. | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Preserve pending, skipped, and cancelled check details in the report.
Step 2 requires listing pending checks and elapsed time, but the Step 7 template only includes aggregate passed/failed/pending counts and has no sections for pending, skipped, or cancelled checks. Add those details so users can act on incomplete CI rather than seeing an incomplete summary.
Also applies to: 139-167
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/ci-failure/SKILL.md` around lines 48 - 54, Update the Step 7 reporting
template to include individual pending checks with elapsed time, plus skipped
and cancelled checks, alongside the existing aggregate passed/failed/pending
counts. Ensure the report preserves these statuses and actionable details when
Step 2 finds incomplete CI, while keeping the all-passing and no-checks messages
unchanged.
| **Prow check detection** — a check is a Prow job if ANY of: | ||
| - Name matches `pull-ci-osac-project-*` | ||
| - Name matches `rehearse-*-pull-ci-osac-project-*` | ||
| - Link contains `prow.ci.openshift.org` | ||
|
|
||
| All other failed checks are GitHub Actions checks. | ||
|
|
||
| If there are no GitHub Actions failures (only Prow), skip to Step 6. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files matching skill/debug-e2e names:"
fd -i 'SKILL\.md|debug.*e2e|e2e' . 2>/dev/null | sed 's#^\./##' | head -200
echo
echo "Skill file size and relevant lines:"
wc -l skills/ci-failure/SKILL.md
sed -n '1,180p' skills/ci-failure/SKILL.md | cat -n
echo
echo "Search for /debug-e2e and Prow E2E labels:"
rg -n "/debug-e2e|Prow E2E Failures|pull-ci-osac-project|rehearse-|prow.ci.openshift.org" -S .Repository: osac-project/osac-workspace
Length of output: 11336
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files matching skill/debug-e2e names:"
fd -i 'SKILL\.md|debug.*e2e|e2e' . 2>/dev/null | sed 's#^\./##' | head -200
echo
echo "Skill file size and relevant lines:"
wc -l skills/ci-failure/SKILL.md
sed -n '1,180p' skills/ci-failure/SKILL.md | cat -n
echo
echo "Search for /debug-e2e and Prow E2E labels:"
rg -n "/debug-e2e/Prow E2E Failures|pull-ci-osac-project|rehearse-|prow.ci.openshift.org" -S .Repository: osac-project/osac-workspace
Length of output: 9934
🌐 Web query:
CLAUDE.md /debug-e2e Prow CI job skill description
💡 Result:
The /debug-e2e (or occasionally /debug-e2e-tests) command is an agentic skill used to automate the investigation and triage of failed end-to-end (E2E) tests, particularly within Prow CI environments [1][2][3]. Key characteristics and functionality of the skill include: Workflow Automation: The skill typically orchestrates a structured debugging session by identifying the failed CI run (via PR number, CI URL, or log hash) [1][2]. It often delegates log retrieval and analysis to specialized subagents—such as identify-ci-failures or analyze-logs—to maintain a clean conversation context [1]. Typical Artifact Handling: The skill is designed to prioritize and process common CI artifacts, including JUnit XML reports, application/container logs (e.g., pod logs), screenshots, saved DOMs, and cluster diagnostics (like must-gather) [2][4]. Capabilities: 1. Root Cause Analysis: It attempts to categorize failures (e.g., test error, UI issue, infrastructure instability, or cascade failures) and often provides actionable recommendations [2][4]. 2. Environment Awareness: It often uses project-specific documentation (e.g., references in CLAUDE.md, AGENTS.md, or component maps) to understand system architecture and interpret logs correctly [1][5][3]. 3. Reporting: Many implementations generate a summary or a detailed markdown report (e.g., claude-failure-analysis.md) that is stored within the CI artifacts directory [4]. Usage: Developers invoke it by providing a reference to the failing test context [1][2]: - /debug-e2e [PR number / CI URL / log hash] - /debug-e2e-tests (often synonymous with /debug-e2e in specific toolsets) [6][2] While often configured in CLAUDE.md to guide agents in specific repositories, the logic typically relies on underlying CI infrastructure (like Prow) to provide the necessary diagnostic data [7][4]. Configurations often include options to disable analysis or handle authentication (e.g., for cloud-based AI services) [4].
Citations:
- 1: https://mcp.directory/skills/debug-e2e
- 2: chore(KFLUXUI-1263): add debug-e2e-tests skill for CI failure triage konflux-ci/konflux-ui#836
- 3: https://github.com/osac-project/osac-workspace/blob/main/AI-assisted-development-workflow.md
- 4: https://github.com/openshift/oadp-operator/blob/oadp-dev/CLAUDE.md
- 5: https://github.com/duc01226/easy-claude/blob/main/.claude/agents/e2e-runner.md
- 6: https://github.com/osac-project/osac-workspace/blob/main/AGENTS.md
- 7: https://github.com/openshift/release/blob/main/CLAUDE.md
Gate Prow delegation on E2E classification.
Step 3's Prow patterns can match non-E2E Prow jobs, but Step 6 delegates every matching job to /debug-e2e and reports it under “Prow E2E Failures,” while the skill description says it delegates Prow E2E failures. Add an explicit E2E signal/gate before delegation, or broaden the contract to cover debugging generic Prow failures.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/ci-failure/SKILL.md` around lines 60 - 67, Update the Prow handling
between the check detection and Step 6 delegation to require an explicit E2E
classification before invoking /debug-e2e or labeling a result as a “Prow E2E
Failure.” Preserve the existing behavior for non-E2E Prow failures by handling
them separately or excluding them from E2E delegation, consistent with the
skill’s stated contract.
| For each failed GitHub Actions check, extract the workflow run ID from the `link` field: | ||
|
|
||
| ```bash | ||
| # link format: https://github.com/osac-project/<repo>/actions/runs/<RUN_ID>/job/<JOB_ID> | ||
| RUN_ID=$(echo "$LINK" | grep -oE 'runs/[0-9]+' | cut -d/ -f2) | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Handle missing or malformed check links before fetching logs.
If link is empty or does not contain a run ID, RUN_ID becomes empty and the subsequent gh run view command cannot analyze that check. Report the check as having unavailable logs and continue with the remaining failures.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/ci-failure/SKILL.md` around lines 71 - 76, Validate the extracted
RUN_ID before invoking gh run view: when the check’s link is empty or malformed
and RUN_ID is unavailable, report that logs are unavailable for the check and
continue processing the remaining failures. Keep normal log fetching unchanged
for valid run IDs.
| For each unique run ID, fetch the failed step logs: | ||
|
|
||
| ```bash | ||
| gh run view $RUN_ID --repo $REPO --log-failed 2>&1 | tail -200 | ||
| ``` | ||
|
|
||
| If the output is very long, focus on the last 100-200 lines per failed job — the actual error is almost always at the end. Look for error markers: `FAIL`, `Error`, `error:`, `panic:`, `fatal:`, `FAILED`, `exit code`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file excerpt =="
sed -n '1,130p' skills/ci-failure/SKILL.md
echo
echo "== search for gh run usage in repo =="
rg -n "gh run|tail -200|log-failed|-j|job" skills README.md mkdocs.yaml .github 2>/dev/null || true
echo
echo "== gh availability =="
if command -v gh >/dev/null 2>&1; then
gh version || true
else
echo "gh not installed"
fi
echo
echo "== documentation references in installed docs if any =="
(gh run --help 2>&1 | sed -n '1,160p') || trueRepository: osac-project/osac-workspace
Length of output: 10873
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== gh run view help =="
(gh run view --help 2>&1 | sed -n '1,220p') || true
echo
echo "== relevant skills excerpt around tail/job-specific guidance =="
sed -n '150,215p' skills/ci-failure/SKILL.md
sed -n '190,210p' skills/debug-e2e/SKILL.md 2>/dev/null || true
echo
echo "== static verifier: command pipeline ordering and documented job guidance =="
python3 - <<'PY'
from pathlib import Path
p = Path("skills/ci-failure/SKILL.md")
text = p.read_text()
cmd = "gh run view $RUN_ID --repo $REPO --log-failed 2>&1 | tail -200"
job_opt = "gh run view $RUN_ID --repo $REPO --log-failed -j <JOB_ID>"
print("run-level command present:", cmd in text)
print("run-level command has tail after full run", "| tail -200" in cmd)
print("run-level truncated last line doc states per failed job:", "focus on the last 100-200 lines per failed job" in text)
print("job-specific truncated command guidance present:", "gh run view $RUN_ID --repo $REPO --log-failed -j <JOB_ID>" in text)
if "github-actions" in [x.stem.lower() for x in p.parent.glob(".")]:
for part in ("--log-failed"), ("--log-failed -j", "<JOB_ID>"):
print("job-specific guidance nearby:", part in text)
PYRepository: osac-project/osac-workspace
Length of output: 5196
Fetch logs per failed job before truncating.
The current command applies tail -200 to the combined failed-step output for the whole run, so earlier failed jobs can be truncated while later jobs use the quoted “last 100-200 lines per job” intent. Use a job-specific command such as gh run view $RUN_ID --repo $REPO --log-failed -j <JOB_ID> before cutting each job’s logs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/ci-failure/SKILL.md` around lines 80 - 86, Update the failed-log
retrieval instructions to enumerate each failed job and fetch its logs
separately using the job-specific gh run view -j JOB_ID option before applying
tail or other truncation. Preserve the existing guidance to inspect the final
100–200 lines and error markers, but ensure truncation cannot combine multiple
jobs and discard earlier job output.
| | Check Name Pattern | Category | Common Root Cause | Fix Command | | ||
| |---|---|---|---| | ||
| | `pre-commit` / `Check pre-commit` | Lint/Format | Whitespace, trailing newline, YAML lint, file size | `pre-commit run --all-files` | | ||
| | `Check Python code` / `ruff` | Python Lint | Import order, unused import, style violation | `uv run ruff check --fix` | | ||
| | `Check Go code` / `golangci-lint` | Go Lint | Lint violations, unused vars, error handling | `make lint` or `golangci-lint run` | | ||
| | `Check generated code` / `check-generated-code` | Code Gen Drift | Proto changed without regenerating Go code | `buf generate && git diff --exit-code` | | ||
| | `Run unit tests` | Test Failure | Assertion failure, panic, timeout | Read test output for failing test name | | ||
| | `Build binaries` / `build` / `make build` | Build Failure | Compilation error, missing dependency | Read compiler error message | | ||
| | `Run integration tests` | Integration Test | Service startup failure, test assertion | Check uploaded workflow artifacts | | ||
| | `Kustomize Build` | Manifest Validation | Invalid kustomization, missing resource | `bash scripts/kustomize-build-all.sh` | | ||
| | `Check image tags` | Image Tag Drift | Image tag doesn't match submodule commit | `bash scripts/sync-image-tags.sh --fix` | | ||
| | `Check AuthConfig Rego` | Rego Policy Drift | Overlay Rego doesn't match base | `python3 scripts/sync-authconfig-rego.py --fix` | | ||
| | `Helm Lint` / `helm-crds-sync` | Helm Validation | CRD template out of sync, chart lint error | `make check-helm-crds` or `helm lint charts/...` | | ||
| | `ansible-lint` | Ansible Lint | FQCN missing, task name missing, YAML style | `ansible-lint` | | ||
| | `Lint` (osac-ui) | Frontend Lint | ESLint/Prettier violations, i18n sync | `pnpm lint` | | ||
| | `build-image` | Image Build | Dockerfile error, missing dependency | Read docker build error | | ||
| | `execution-environment` | EE Build | Ansible EE build failure | Check EE definition and dependencies | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Make every “Fix Command” actionable.
Several cells contain instructions such as “Read test output” or “Check uploaded workflow artifacts,” not commands. Rename the column to “Suggested action,” or require the final report to provide a concrete command after identifying the root cause.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/ci-failure/SKILL.md` around lines 98 - 114, Make the “Fix Command”
column actionable for every row in the CI failure reference table. Replace
non-command guidance such as “Read test output for failing test name” and “Check
uploaded workflow artifacts” with concrete commands or diagnostic actions, or
rename the column to “Suggested action” if non-command instructions remain.
| **CRITICAL**: Use `jira` as the jira binary (must be on PATH). All `list` commands use `--plain --no-headers`. Do NOT use `--no-input` on `list` or `view`. | ||
|
|
||
| **IMPORTANT**: Only features with resolution "Done" appear as completed. Features resolved as "Duplicate" or other non-Done resolutions must NOT appear anywhere. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate file =="
git ls-files | grep -F 'skills/release-plan/SKILL.md' || true
echo "== file stats =="
wc -l skills/release-plan/SKILL.md
echo "== relevant sections =="
sed -n '1,40p' skills/release-plan/SKILL.md
echo '---'
sed -n '60,80p' skills/release-plan/SKILL.md
echo '---'
sed -n '140,160p' skills/release-plan/SKILL.md
echo "== searches for resolution filters around jira/list/view =="
rg -n "resolution|list --plain --no-headers|view|Duplicate|Won't|Don't|resolved|Done" skills/release-plan/SKILL.mdRepository: osac-project/osac-workspace
Length of output: 5109
Apply the resolution-exclusion rule consistently.
The target open query only filters status != Closed, and the prior, Telefónica, and MOC queries have no status/resolution filter. Closed resolved features such as Duplicate, Won’t Do, or other non-Done resolutions can still enter the foundation, coverage tables, inventory, and action notes, contradicting the “must NOT appear anywhere” rule. Use resolution = Done for completed queries and resolution IS EMPTY OR resolution = Done where unresolved planning items are intentionally included; also clarify that “duplicates” in the notes are generic guidance, not specific issue IDs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/release-plan/SKILL.md` around lines 10 - 12, Update the Jira query
guidance throughout the release-plan workflow so completed-feature queries
require resolution = Done, while queries intentionally including unresolved
planning items use resolution IS EMPTY OR resolution = Done. Apply this
consistently to the target open, prior, Telefónica, and MOC queries so non-Done
resolutions cannot appear in foundation, coverage tables, inventory, or action
notes; clarify that “duplicates” in notes is generic guidance, not specific
issue IDs.
| Accept two arguments: | ||
| 1. **Target version** (required) — the version to plan (e.g., `0.3`) | ||
| 2. **Prior version** (optional) — the version it builds on (defaults to the version immediately before, e.g., `0.2`) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Validate the version arguments before querying Jira.
The workflow does not define validation for missing or extra arguments, malformed versions, identical versions, or a prior version that is not older than the target. “Immediately before” is also ambiguous for versions such as 0.10; invalid input can produce a misleading delta report. Add explicit version parsing and ordering checks before any Jira commands.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/release-plan/SKILL.md` around lines 16 - 18, Define explicit
validation for the release-plan workflow’s Target version and Prior version
arguments before any Jira query: require exactly one or two arguments, parse
both using the supported version format, reject identical versions, and ensure
the prior version is strictly older than the target. Resolve the default prior
version numerically rather than lexically, including cases such as 0.10, and
exit with a clear error for invalid input.
| **NCP requirements** (OSAC-991): | ||
| ```bash | ||
| jira issue view OSAC-991 --plain | ||
| ``` | ||
| Extract the linked issues and their statuses. Map each NCP requirement to its OSAC feature and determine which version covers it. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Make NCP requirement enumeration deterministic.
jira issue view OSAC-991 --plain does not specify how all 13 requirements are enumerated, how linked features are resolved across versions, or how unlinked/uncovered requirements are represented. Without those rules, Section 5 can silently omit rows despite promising an “all 13 requirements” table. Define the requirement identifiers, assert the discovered count, and emit explicit uncovered rows.
🧰 Tools
🪛 markdownlint-cli2 (0.23.0)
[warning] 61-61: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 63-63: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/release-plan/SKILL.md` around lines 60 - 64, Update the NCP
requirements workflow around the OSAC-991 enumeration to define all 13
requirement identifiers explicitly, verify that discovery returns exactly 13
requirements, and resolve each linked OSAC feature across versions before
mapping coverage. Require Section 5 to include an explicit row for every
unlinked or uncovered requirement instead of silently omitting it.
| ### Step 5: Build the Service Offering Matrix | ||
|
|
||
| For each of the three core services (CaaS, VMaaS, BMaaS), evaluate five dimensions: | ||
|
|
||
| 1. **API** — What API capabilities exist (cumulative)? | ||
| 2. **Multi-Tenancy** — How is tenant isolation handled? | ||
| 3. **Networking** — What networking capabilities are available? | ||
| 4. **Storage** — What storage capabilities are available? | ||
| 5. **UI** — What UI surfaces exist? | ||
|
|
||
| For each cell, show: | ||
| - `0.X` label for capabilities from the prior version (carried forward) | ||
| - `+0.Y` label for new capabilities in the target version | ||
| - Use descriptive text, not status indicators — this is aspirational, not tracking |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Define evidence-based rules for the service matrix.
The workflow asks the agent to “evaluate” five service dimensions but provides no mapping from Jira components, descriptions, features, or epics to API, tenancy, networking, storage, and UI capabilities. This makes the matrix prone to unsupported or inconsistent claims. Add deterministic classification rules and retain the supporting feature/epic keys for each cell.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/release-plan/SKILL.md` around lines 103 - 116, Update “Step 5: Build
the Service Offering Matrix” with deterministic, evidence-based rules mapping
Jira components, descriptions, features, and epics to each of the five
dimensions. Require every matrix claim to cite and retain its supporting feature
or epic keys, and mark cells as unknown rather than infer capabilities when
evidence is absent.
| ### Step 6: Generate HTML Report | ||
|
|
||
| Output a styled HTML report with these sections: | ||
|
|
||
| #### Section 1: Release Vision | ||
| - One-paragraph summary of what the version delivers | ||
| - Metric cards: total features, use cases, customer drivers, epics decomposed | ||
|
|
||
| #### Section 2: What's New vs Prior Version | ||
| - Two-column layout: "Prior Delivers (Foundation)" vs "Target Adds (New)" | ||
| - Bullet points of capabilities, not Jira keys | ||
|
|
||
| #### Section 3: Target Service Offering Matrix | ||
| - Table with CaaS / VMaaS / BMaaS columns | ||
| - Rows: API, Multi-Tenancy, Networking, Storage, UI | ||
| - Each cell shows cumulative capabilities with prior/new labels | ||
|
|
||
| #### Section 4: Use Case Cards | ||
| - Card grid (2 columns) with color-coded borders per use case | ||
| - Each card lists capabilities with customer driver tags (NCP, Telefónica, MOC, AI Grid) | ||
| - New capabilities marked with a star icon | ||
|
|
||
| #### Section 5: Customer Requirements Coverage | ||
| - NCP table: all 13 requirements with which version covers each | ||
| - Telefónica RFP table: open items with version coverage | ||
| - Summary callout showing coverage ratios | ||
|
|
||
| #### Section 6: Feature Inventory | ||
| - Tables grouped by use case, showing: Jira key, feature name, customer tags | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Escape Jira-sourced content before embedding it in HTML.
Summaries, descriptions, labels, and customer tags are inserted into a browser-opened report, but the workflow does not require HTML escaping or sanitization. Jira content containing markup could break the report or execute active content. Specify escaping for all text fields and an allowlist sanitizer if limited rich text is intended.
🧰 Tools
🪛 markdownlint-cli2 (0.23.0)
[warning] 122-122: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 126-126: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 130-130: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 135-135: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 140-140: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 145-145: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/release-plan/SKILL.md` around lines 118 - 147, Update Step 6 HTML
report generation to HTML-escape every Jira-sourced text field, including
summaries, descriptions, labels, and customer tags, before embedding it in the
browser-opened report. If limited rich text is supported, sanitize it with an
explicit allowlist; otherwise render all Jira content as plain text.
|
gonna close it for now. might revisit in the future. |
- Cumulative capability progression across all prior versions (0.1, 0.2, +N) - Both MD and HTML output with timestamped filenames (YYYY-MM-DD-HHMM) - Hardcoded CSS from Aug-17 reference report for consistent styling - MaaS as 4th column in service offering matrix - Auto-discover customer:* labels dynamically (no hard-coding) - NCP label fallback queries only target version (prevents version bleed) - Epic enrichment (Step 1.5) for all versions including prior versions - UI epics with no fixVersion inherit parent feature's version for matrix - Spikes excluded from matrix, appear only in detailed tables - Component takes precedence over summary for grouping - Feature Inventory shows only target version features (no Backlog bleed) - macOS bash 3 compatibility warning (no associative arrays) - No 'Foundation maintained' rows — omit if version adds nothing - No Jira keys in matrix cells — human-readable descriptions only - Feature title plain text in inventory (key column already links) - 'status' reserved variable warning for zsh Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Oved Ourfali <oourfali@redhat.com>
- Remove Multi-Tenancy row from matrix (platform-level concern, not per-service) - Remove standalone UI sections (cards, cumulative, inventory) — UI belongs in service sections - No Jira keys or raw titles in matrix — human-readable 5-8 word descriptions only - Feature Inventory: title is plain text (key column already links) - Feature Inventory: actual Jira status (Done/In Progress/Review/Planned), not hard-coded "New" - Backlog section: show ALL items with clickable titles, never truncate with "and N more" - Spikes excluded from matrix, shown only in detailed tables - Component takes precedence over summary for grouping (with Infrastructure deprioritized) - Epic enrichment (Step 1.5) applies to ALL versions including prior - Epics with no fixVersion inherit parent feature's version - N-1 version includes all features (expected to land); N-2+ only Closed+Done - NCP label fallback queries only target version (prevents version bleed) - Auto-discover customer:* labels dynamically - macOS bash 3 compatibility (no associative arrays — use Python) - Embedded CSS from Aug-17 reference report for consistent styling - MaaS as 4th column in service offering matrix - 4 matrix dimensions: API, Networking, Storage, UI Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Oved Ourfali <oourfali@redhat.com>
Local permission changes should not be committed. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Oved Ourfali <oourfali@redhat.com>
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
tchughesiv
left a comment
There was a problem hiding this comment.
we'll be archiving this repo soon. if this is new skill is still warranted, please open a similar PR against https://github.com/osac-project/osac-ai-skills instead. thanks
|
this changed was merged into the new skills repo - osac-project/osac-ai-skills#19 |
Summary
/release-planskill that generates a styled HTML report showing what an OSAC version will deliver/milestone-scope(progress tracking with gap analysis)Usage
Context
Born from a planning session where
/milestone-scope 0.3showed everything as "Gap" since no work had started yet. The release-plan skill reframes the same data as an aspirational delivery plan suitable for stakeholder communication.Test plan
/release-plan 0.3and verify HTML output renders correctly🤖 Generated with Claude Code
Summary by CodeRabbit