Link published PRs to the Jira Git Pull Request field - #88
Conversation
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
WalkthroughThe implement workflow documentation now permits a single Jira write during ChangesJira PR linking workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 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 `@implement/skills/publish.md`:
- Line 25: Update the Jira write timing statement in the publish workflow to say
it occurs after successful draft PR creation during /publish. Keep the
restriction that only the story’s Git Pull Request field may be set to the
created PR URL, with no other Jira changes.
- Around line 283-289: Update the Output section of the publish procedure to
avoid promising that the Jira field is always updated. State that the Jira link
result is recorded, and clarify that the PR URL is written to the Git Pull
Request field only when linking succeeds; preserve the existing artifact
outputs.
- Around line 230-233: Update the publish workflow’s Jira-link handling and Step
9 reporting to persist the outcome in
`.artifacts/implement/{issue-key}/publish-metadata.json` under
`jira_link_status`, recording `linked`, `skipped`, or `failed` consistently
alongside the existing publish metadata.
- Around line 208-216: The field update instructions in the publish workflow
must prevent concurrent appends from overwriting one another. Replace the
read-modify-write append behavior with Jira’s atomic update operation when
available; otherwise require optimistic-concurrency checks with a re-read and
retry before persisting the appended PR URL, while preserving idempotency and
single-value replacement prompting.
- Around line 208-226: Update Step 3 to require inspecting the resolved Jira
field’s schema and cardinality before constructing the update. Specify matching
encodings for scalar fields, newline-delimited text fields, and array/multivalue
fields, while preserving the existing idempotency, append, and replacement
prompts. Ensure the jira_update_issue example uses the schema-appropriate value
shape.
- Around line 194-202: Update the Git Pull Request field resolution instructions
to require exactly one case-insensitive name match: report an ambiguity and skip
the Jira link when multiple compatible fields are found, and retain the existing
no-match handling. Use the field ID only when exactly one matching field exists.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: abda6306-19cb-4577-99eb-26b3f2bc188d
📒 Files selected for processing (6)
AGENTS.mdimplement/README.mdimplement/SKILL.mdimplement/guidelines.mdimplement/skills/controller.mdimplement/skills/publish.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (11)
**/{SKILL.md,guidelines.md,skills/*.md,commands/*.md}
📄 CodeRabbit inference engine (Custom checks)
Flag any absolute filesystem path in markdown files within workflow directories (*/SKILL.md, /skills/.md, /commands/.md, */guidelines.md). Paths like /home/, /Users/, /tmp/, /var/, /opt/ are prohibited because workflows are installed via symlink and must use relative paths only. Paths inside fenced code blocks that are clearly examples (containing "example", "e.g.", or placeholder usernames like /home/user/) are exempt.
Files:
implement/guidelines.mdimplement/skills/controller.mdimplement/SKILL.mdimplement/skills/publish.md
**/{SKILL.md,guidelines.md,controller.md}
📄 CodeRabbit inference engine (Custom checks)
When any of SKILL.md, guidelines.md, or controller.md in a workflow is changed, compare it against whichever of the other two files are present and check for verbatim duplication of multi-line instruction blocks or paragraphs. Each has a distinct role: SKILL.md is the thin entry point, guidelines.md holds principles/limits/safety/quality/escalation, controller.md manages phase dispatch. Phase names and brief one-line descriptions appearing in multiple files is EXPECTED (cross-referencing, not duplication) — only flag substantial blocks of identical prose or step-by-step instructions that are copied between files.
Files:
implement/guidelines.mdimplement/skills/controller.mdimplement/SKILL.md
**/*.md
📄 CodeRabbit inference engine (Custom checks)
For any changed markdown file in a workflow directory, verify that file path references (backtick-quoted paths like
../skills/controller.mdorguidelines.md) point to files that exist. Flag references to files that don't exist (dangling references). Also flag skill or command files that exist but are never referenced from SKILL.md, controller.md, or any command file (orphaned files).
**/*.md: All workflow content must use plain Markdown without IDE-specific syntax.
All file references in workflow Markdown must be relative to the referencing file's location for symlink compatibility.
Files:
implement/guidelines.mdimplement/skills/controller.mdAGENTS.mdimplement/SKILL.mdimplement/README.mdimplement/skills/publish.md
⚙️ CodeRabbit configuration file
**/*.md: Cross-workflow consistency (ai-workflows conventions):
- All file references must be relative paths (never absolute) —
this is critical for symlink compatibility- No IDE-specific syntax (Cursor-specific, VS Code-specific, etc.)
- Consistent terminology within a workflow: pick one term, stick
with it- Schema field names and types must match between producer and
consumer files (e.g., if a field is defined in one phase skill
and consumed in another, names and types must agree)- No verbatim duplication of multi-line instruction blocks
across SKILL.md, guidelines.md, and controller.md — each has
a distinct role (shared phase names and brief references are
expected cross-referencing, not duplication)
Files:
implement/guidelines.mdimplement/skills/controller.mdAGENTS.mdimplement/SKILL.mdimplement/README.mdimplement/skills/publish.md
**/*.{md,py,sh}
📄 CodeRabbit inference engine (AGENTS.md)
Significant workflow outputs must be persisted under
.artifacts/{workflow-name}/{context}/.
Files:
implement/guidelines.mdimplement/skills/controller.mdAGENTS.mdimplement/SKILL.mdimplement/README.mdimplement/skills/publish.md
**/{SKILL.md,guidelines.md,skills/*.md,commands/*.md,templates/*,prompts/*,scripts/*}
📄 CodeRabbit inference engine (AGENTS.md)
Changes to behavioral workflow files require a version bump, while
README.mdandGUIDE.mdchanges do not.
Files:
implement/guidelines.mdimplement/skills/controller.mdimplement/SKILL.mdimplement/skills/publish.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
**/*: Include the required workflow version bump in the same commit as the behavioral change; do not create a separate version-bump commit.
Before destructive Git operations, verify the state withgit status.
Before creating or pushing a PR/MR, confirm the branch and base branch.
Only cve-fix/close, design/sync, sizing/apply, and implement/publish(Git Pull Request field only) may write to Jira, and all such writes require explicit approval.
Run Vale validation before applying documentation changes to repository files.
Files:
implement/guidelines.mdimplement/skills/controller.mdAGENTS.mdimplement/SKILL.mdimplement/README.mdimplement/skills/publish.md
**/guidelines.md
⚙️ CodeRabbit configuration file
**/guidelines.md: Guidelines review (ai-workflows conventions):
- Must contain: Principles, Hard Limits, Safety, Quality, and
Escalation sections (or equivalent coverage)- Content must NOT duplicate SKILL.md or controller.md — each
file has a distinct role- Escalation criteria must be specific and actionable (not vague
"when things go wrong")- Hard limits must be concrete prohibitions, not suggestions
- All phase references should use consistent naming matching
the workflow's actual phase names
Files:
implement/guidelines.md
**/skills/*.md
📄 CodeRabbit inference engine (Custom checks)
For any changed skills/*.md file, verify that main steps are numbered sequentially (Step 1, Step 2, Step 3... or ## Step 1, ## Step 2...). Flag: gaps in numbering (1, 2, 4), duplicate numbers (two Step 3s), and any skill with more than 10 main steps (cognitive load risk for AI agents). Sub-steps (Step 1a, Step 3b) are acceptable ONLY when they represent conditional branches off the parent step (e.g., "Step 1a: If , do X"). Flag sub-steps that are actually new main steps inserted to avoid renumbering — those should be promoted to full steps with the sequence renumbered.
Workflows must not auto-advance between phases in attended mode unless an explicit unattended mode is documented.
Files:
implement/skills/controller.mdimplement/skills/publish.md
⚙️ CodeRabbit configuration file
**/skills/*.md: Phase skill review (ai-workflows conventions):
- Maximum 10 steps per skill invocation — flag if exceeded
(cognitive load / context window risk for AI agents)- Main steps must be numbered sequentially: no gaps, no
duplicates. Sub-steps (e.g., Step 1a) are allowed ONLY for
conditional branches off a parent step — never as a way to
insert a new main step without renumbering- Internal cross-references (e.g., "see Step 4") must point to
correct step numbers- No step should depend on output from a later step
- Synthesis tasks (summarization, assessment, verdict) must NOT
be buried after heavy per-item processing — they degrade in
long contexts- controller.md must reference sibling skills as phase-name.md
(not skills/phase-name.md) — relative to its own directory- Skills referencing _shared/ resources must use the correct
relative path depth (e.g., ../../_shared/recipes/self-review-gate.md
from skills/)- Failure modes must be documented: what to do when prerequisites
are missing, when zero results are returned, when tools are
unavailable- Escalation criteria must be clear: when to stop and ask the user
- Instructions must be unambiguous — an AI agent reading
top-to-bottom should produce correct output on the first try- If the file has YAML frontmatter, name and description are required
Files:
implement/skills/controller.mdimplement/skills/publish.md
**/skills/controller.md
📄 CodeRabbit inference engine (AGENTS.md)
Controllers must reference sibling skills using
phase-name.md, notskills/phase-name.md.
Files:
implement/skills/controller.md
**/SKILL.md
📄 CodeRabbit inference engine (Custom checks)
For any SKILL.md file changed in this PR, verify it is under 30 lines total (including frontmatter). SKILL.md must be thin entry points using progressive disclosure. If a SKILL.md exceeds 30 lines, flag it with the count and suggest moving content to guidelines.md or skills/ files.
**/SKILL.md: Every workflow must include aSKILL.mdentry point with YAML frontmatter containing name, version, and description.
KeepSKILL.mdthin, under 30 lines, with details placed inguidelines.mdandskills/.
SKILL.mdmust referenceguidelines.mdand may referenceskills/controller.mdusing same-directory relative paths.
Every workflow directory containingSKILL.mdis auto-discovered by the installer.
When behavioral workflow files change, update the workflow version inSKILL.mdaccording to semver: PATCH for wording or formatting, MINOR for steps/rules/templates/phases, and MAJOR for removed or renamed phases or commands.
Files:
implement/SKILL.md
⚙️ CodeRabbit configuration file
**/SKILL.md: SKILL.md review (ai-workflows conventions):
- YAML frontmatter required: opening/closing --- delimiters
- Required fields: name (lowercase, hyphens only, max 64 chars),
description (third person, includes trigger terms and
activated-by commands)- Total file length must be under 30 lines (progressive
disclosure rule — details belong in guidelines.md or skills/)- Must reference guidelines.md for principles/limits/safety/quality
- Must NOT duplicate content from guidelines.md or controller.md
- Should list all phases with references to skills/ or commands/
- No IDE-specific syntax — plain markdown only
- Verify every file path reference resolves to an existing file
Files:
implement/SKILL.md
*/README.md
⚙️ CodeRabbit configuration file
*/README.md: Workflow README review (ai-workflows conventions):
- Must document .artifacts/ output path for the workflow
- Phase descriptions must match what SKILL.md and skills/
actually implement — flag any documentation drift- Features mentioned in README must exist in the skill files;
features implemented in skills must be documented in README- Prerequisites (required tools, environment, integrations)
must be listed- Usage examples should show actual command invocations
(e.g., /workflow:phase)
Files:
implement/README.md
🧠 Learnings (6)
📚 Learning: 2026-07-23T14:18:59.204Z
Learnt from: adalton
Repo: flightctl/ai-workflows PR: 84
File: bugfix/SKILL.md:3-3
Timestamp: 2026-07-23T14:18:59.204Z
Learning: In flightctl/ai-workflows documentation, treat backtick-quoted workflow path templates that include placeholders (e.g., `commands/{command}.md`, `skills/{phase}.md`) as runtime-dispatch/template instructions for AI agents, not literal Markdown links. When these appear, do not flag them as dangling/invalid references solely because the braces indicate substitution of an invoked command or phase name at runtime.
Applied to files:
implement/guidelines.mdimplement/skills/controller.mdAGENTS.mdimplement/SKILL.mdimplement/README.mdimplement/skills/publish.md
📚 Learning: 2026-04-12T00:25:51.234Z
Learnt from: adalton
Repo: flightctl/ai-workflows PR: 20
File: design/skills/respond.md:29-31
Timestamp: 2026-04-12T00:25:51.234Z
Learning: In flightctl/ai-workflows skill markdown files, treat path references as two categories:
1) For cross-document markdown links (e.g., links to other .md files like ../skills/controller.md or ../../templates/design.md), use paths relative to the current markdown file’s location so links work under symlinks.
2) For runtime artifact paths used as prose instructions to the AI agent (e.g., .artifacts/design/{issue-number}/publish-metadata.json or .artifacts/prd/config.json), keep them repo-root-relative (start with .artifacts/). Do not convert these artifact paths to be relative to the skill file directory (e.g., don’t rewrite to ../../.artifacts/...), because the AI resolves them from the repo root.
Applied to files:
implement/skills/controller.mdimplement/skills/publish.md
📚 Learning: 2026-04-15T10:19:54.839Z
Learnt from: galel12
Repo: flightctl/ai-workflows PR: 22
File: kcs/skills/gather.md:25-26
Timestamp: 2026-04-15T10:19:54.839Z
Learning: In flightctl/ai-workflows, for Jira URL examples inside skill Markdown files, follow the repo-wide convention and use a real example Jira link of the form `https://issues.redhat.com/browse/PROJ-123` (not a generic placeholder like `https://example.com/...`). Since this is a documented convention, do not flag it as a portability/documentation hardcoding issue when reviewing similar skill markdown files.
Applied to files:
implement/skills/controller.mdimplement/skills/publish.md
📚 Learning: 2026-04-16T10:39:50.418Z
Learnt from: galel12
Repo: flightctl/ai-workflows PR: 22
File: kcs/skills/gather.md:34-37
Timestamp: 2026-04-16T10:39:50.418Z
Learning: In flightctl/ai-workflows workflow skill files (e.g., kcs/bugfix/prd/design skills), do not require sanitization/normalization of free-form user-supplied identifier placeholders (such as {issue-key} or {issue-number}) when they’re used to construct artifact paths like `.artifacts/{workflow}/{identifier}/`. This is intentional because these workflows run in human-supervised IDE sessions where the user provides the values interactively and confirms the output. Therefore, do not flag missing sanitization/normalization of these identifiers as a security or correctness issue during review for these skill files.
Applied to files:
implement/skills/controller.mdimplement/skills/publish.md
📚 Learning: 2026-05-25T17:11:32.207Z
Learnt from: galel12
Repo: flightctl/ai-workflows PR: 47
File: README.md:140-142
Timestamp: 2026-05-25T17:11:32.207Z
Learning: In markdown files under the repo’s skill/command areas (e.g., `skills/**` and `commands/**`), any references to other files on disk (like links/includes pointing to other skill/command markdown such as `../skills/controller.md` or `commands/*.md`) must use relative paths—never absolute paths (no leading `/` or fully-qualified filesystem paths). This ensures the references remain symlink-safe and resolve correctly at runtime. Do not apply this rule to human-facing prose docs like `README.md`/`CONTRIBUTING.md`; when those documents intentionally distinguish user-level vs project-level install locations, keep the absolute user-level paths (e.g., `~/.cursor/commands/`) as written so the distinction is clear.
Applied to files:
implement/skills/controller.mdimplement/skills/publish.md
📚 Learning: 2026-06-15T15:50:50.503Z
Learnt from: adalton
Repo: flightctl/ai-workflows PR: 64
File: skill-reviewer/SKILL.md:3-3
Timestamp: 2026-06-15T15:50:50.503Z
Learning: In flightctl/ai-workflows, treat `SKILL.md` as a size-constrained document: keep it at or under 30 lines. If a `SKILL.md` already exceeds 30 lines but was not changed by the current PR (a known pre-existing issue), don’t require fixing it as part of the PR. If the PR does modify a too-long `SKILL.md`, refactor it into a thin entry point (e.g., move bulk content to smaller companion docs and leave only a brief overview/links) so the `SKILL.md` itself stays within the 30-line limit.
Applied to files:
implement/SKILL.md
🪛 LanguageTool
implement/skills/publish.md
[style] ~277-~277: Consider using the typographical ellipsis character here instead.
Context: ...rt to User Present: - PR URL (the full https://github.com/... link, not just owner/repo#number) - ...
(ELLIPSIS)
🔇 Additional comments (5)
AGENTS.md (1)
182-182: LGTM!implement/guidelines.md (1)
29-29: LGTM!implement/skills/controller.md (1)
31-32: LGTM!Also applies to: 166-166
implement/README.md (1)
25-25: LGTM!Also applies to: 40-40, 79-79
implement/SKILL.md (1)
3-3: 📐 Maintainability & Code QualityNo change needed. Implement’s
SKILL.mdentry point is under 30 lines, has valid frontmatter, referencesguidelines.mdandskills/controller.md, and points to existing files.
2cc6b2a to
3513cf8
Compare
After implement /publish creates a draft PR, write the PR URL into the story's Git Pull Request field so the ticket stays in sync without a manual paste. Field ID is resolved by name (exactly one match); schema-aware encoding; outcome recorded as jira_link_status; failures are reported but do not fail the publish. Assisted-by: Cursor
3513cf8 to
e0441bc
Compare
|
@coderabbitai Addressed the inline findings and the Ai-Attribution check:
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "=== Changed files and diff summary ==="
git diff --stat HEAD^ HEAD
git diff --name-only HEAD^ HEAD
echo
echo "=== Relevant publish workflow sections ==="
if [ -f implement/skills/publish.md ]; then
rg -n -C 5 -i \
'Git Pull Request|exactly one|field match|schema|scalar|array|re-read|retry|append|jira_link_status|Output|write' \
implement/skills/publish.md
fi
echo
echo "=== Cross-file Jira-write policy wording ==="
rg -n -C 3 -i \
'Jira write|Jira.*read-only|Git Pull Request|publish.*Jira|Jira.*publish' \
AGENTS.md implement/README.md implement/guidelines.md implement/skills/controller.md implement/SKILL.md \
2>/dev/null || true
echo
echo "=== Latest commit trailer ==="
git show -s --format='%B' HEADLength of output: 14473
🐇 ✅ ✏️ Learnings added
If you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! |
1 participant
Summary
implement/publishcreates a draft GitHub PR, write the PR URL into the Jira story's Git Pull Request field so the ticket stays in sync without a manual pasteGET /rest/api/3/field(no hardcoded customfield ID); update is idempotent and failures are reported without failing the publish/ingestremains read-onlyTest plan
/implement-publishfor EDM-4758 — PR was created and the Jira Git Pull Request field was updated successfullyMade with Cursor
Summary
/implement /publishnow links newly created draft GitHub PRs to Jira by updating the story’s Git Pull Request field./ingestremains read-only._shared/resources were changed. Cross-workflow guidance now explicitly permits this narrowly scoped Jira write during/publish.