feat(triage-security): add early assignment and Assigned transition at Step 0.7#221
Conversation
…t Step 0.7 Add Step 0.7 between JIRA Access (0.5) and Data Extraction (1) to assign the CVE Vulnerability issue to the triaging user and transition to Assigned status. This provides visibility into active triage and enables concurrent triage detection in Step 7. Transitions are discovered dynamically via get_transitions to support the Vulnerability workflow (which uses Assigned, not In Progress). Remove the redundant Case C assignment that the early step now covers. Implements TC-5008 Assisted-by: Claude Code
Reviewer's GuideAdds a new early triage step (0.7) that assigns the CVE Vulnerability issue to the current user and transitions it to Assigned via dynamically discovered Jira transitions, removes a now-redundant late assignment in Case C, and extends the triage-security evals to assert the new behavior. Sequence diagram for Step 0.7 early assignment and Assigned transitionsequenceDiagram
actor User
participant triage_security_skill
participant Jira
User->>triage_security_skill: start Step_0_7_Assign_and_Transition
triage_security_skill->>Jira: user_info()
Jira-->>triage_security_skill: current_user_account_id
triage_security_skill->>Jira: edit_issue(jira_issue_id, assignee=current_user_account_id)
triage_security_skill->>Jira: get_transitions(jira_issue_id)
Jira-->>triage_security_skill: transitions_list
triage_security_skill->>triage_security_skill: [select transition with status Assigned]
alt issue_status_is_New
triage_security_skill->>Jira: transition_issue(jira_issue_id, assigned_transition_id)
else issue_status_not_New
triage_security_skill->>triage_security_skill: [skip transition, keep assignment]
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Consider documenting how to handle cases where
jira.user_info()orjira.get_transitions()fails or returns no matching "Assigned" transition so the skill has a clear fallback behavior. - The new Step 0.7 assumes a single transition to an "Assigned" status; if multiple transitions target "Assigned", it may be worth specifying how to choose among them to avoid ambiguous behavior.
- Early assignment in Step 0.7 could race with other concurrent triage workflows; consider briefly noting how this step interacts with Step 7’s concurrent triage detection to avoid conflicting assignments.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider documenting how to handle cases where `jira.user_info()` or `jira.get_transitions()` fails or returns no matching "Assigned" transition so the skill has a clear fallback behavior.
- The new Step 0.7 assumes a single transition to an "Assigned" status; if multiple transitions target "Assigned", it may be worth specifying how to choose among them to avoid ambiguous behavior.
- Early assignment in Step 0.7 could race with other concurrent triage workflows; consider briefly noting how this step interacts with Step 7’s concurrent triage detection to avoid conflicting assignments.
## Individual Comments
### Comment 1
<location path="plugins/sdlc-workflow/skills/triage-security/SKILL.md" line_range="222-231" />
<code_context>
+2. **Assign the issue to the current user:**
+
+ ```
+ jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>)
+ ```
+
+3. **Discover the target transition dynamically:**
+
+ ```
+ jira.get_transitions(<jira-issue-id>)
+ ```
+
+ Select the transition whose target status name is `"Assigned"`. Do NOT
+ hardcode a transition ID or assume the transition name — Vulnerability issues
+ use a different Jira workflow than Task issues.
+
+4. **Transition to Assigned (if the issue is in New status):**
+
+ ```
+ jira.transition_issue(<jira-issue-id>, <assigned-transition-id>)
+ ```
+
+ If the issue is already in Assigned or any later status (detected via the
+ status-aware handling in the Inputs section), skip the transition silently.
+ The assignment in step 2 still proceeds regardless — it ensures the current
+ user is recorded even when re-triaging an issue that was previously assigned.
+
</code_context>
<issue_to_address>
**suggestion:** Clarify the relationship between the "Vulnerability issue key" input and the `<jira-issue-id>` placeholder used in examples.
The Inputs section uses the term "Vulnerability issue key," while these examples use `<jira-issue-id>`. Please briefly clarify whether the issue key is passed directly as `<jira-issue-id>` or how it is converted, so readers know exactly what value to supply in these calls.
Suggested implementation:
```
2. **Assign the issue to the current user:**
The `<jira-issue-id>` placeholder in these examples is the same value as the
"Vulnerability issue key" input (for example, `SEC-1234`) and should be passed
directly to the Jira client methods without additional conversion.
```
jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>)
```
3. **Discover the target transition dynamically:**
```
jira.get_transitions(<jira-issue-id>)
```
```
```
4. **Transition to Assigned (if the issue is in New status):**
Use the same "Vulnerability issue key" value as `<jira-issue-id>` here as
well (for example, `SEC-1234`):
```
jira.transition_issue(<jira-issue-id>, <assigned-transition-id>)
```
If the issue is already in Assigned or any later status (detected via the
status-aware handling in the Inputs section), skip the transition silently.
The assignment in step 2 still proceeds regardless — it ensures the current
user is recorded even when re-triaging an issue that was previously assigned.
```
If the Inputs section currently uses a different label (for example, "Vulnerability issue key (e.g., SEC-1234)"), you may want to cross-link explicitly, such as: “This is the same value provided as the ‘Vulnerability issue key’ input in the Inputs section.” Adjust the example key format (`SEC-1234`) if your Jira project uses a different key prefix or format.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>) | ||
| ``` | ||
|
|
||
| 3. **Discover the target transition dynamically:** | ||
|
|
||
| ``` | ||
| jira.get_transitions(<jira-issue-id>) | ||
| ``` | ||
|
|
||
| Select the transition whose target status name is `"Assigned"`. Do NOT |
There was a problem hiding this comment.
suggestion: Clarify the relationship between the "Vulnerability issue key" input and the <jira-issue-id> placeholder used in examples.
The Inputs section uses the term "Vulnerability issue key," while these examples use <jira-issue-id>. Please briefly clarify whether the issue key is passed directly as <jira-issue-id> or how it is converted, so readers know exactly what value to supply in these calls.
Suggested implementation:
2. **Assign the issue to the current user:**
The `<jira-issue-id>` placeholder in these examples is the same value as the
"Vulnerability issue key" input (for example, `SEC-1234`) and should be passed
directly to the Jira client methods without additional conversion.
jira.edit_issue(, assignee=)
3. **Discover the target transition dynamically:**
jira.get_transitions()
4. **Transition to Assigned (if the issue is in New status):**
Use the same "Vulnerability issue key" value as `<jira-issue-id>` here as
well (for example, `SEC-1234`):
jira.transition_issue(, )
If the issue is already in Assigned or any later status (detected via the
status-aware handling in the Inputs section), skip the transition silently.
The assignment in step 2 still proceeds regardless — it ensures the current
user is recorded even when re-triaging an issue that was previously assigned.
If the Inputs section currently uses a different label (for example, "Vulnerability issue key (e.g., SEC-1234)"), you may want to cross-link explicitly, such as: “This is the same value provided as the ‘Vulnerability issue key’ input in the Inputs section.” Adjust the example key format (SEC-1234) if your Jira project uses a different key prefix or format.
There was a problem hiding this comment.
[sdlc-workflow/verify-pr] Classified as suggestion — this proposes clarifying placeholder naming conventions, which is not documented in CONVENTIONS.md and has no established codebase-wide convention (angle-bracket placeholders like <jira-issue-id> are used consistently throughout all skill files). No sub-task created.
There was a problem hiding this comment.
Eval Results
Eval Results: triage-security
| Eval | Passed | Failed | Pass Rate |
|---|---|---|---|
| eval-1 | 11/11 | 0 | 100% |
| eval-10 | 5/5 | 0 | 100% |
| eval-11 | 5/5 | 0 | 100% |
| eval-12 | 5/5 | 0 | 100% |
| eval-13 | 5/5 | 0 | 100% |
| eval-14 | 5/5 | 0 | 100% |
| eval-15 | 5/5 | 0 | 100% |
| eval-16 | 7/7 | 0 | 100% |
| eval-17 | 5/5 | 0 | 100% |
| eval-19 | 5/5 | 0 | 100% |
| eval-2 | 5/5 | 0 | 100% |
| eval-20 | 4/4 | 0 | 100% |
| eval-21 | 4/4 | 0 | 100% |
| eval-22 | 4/4 | 0 | 100% |
| eval-23 | 4/4 | 0 | 100% |
| eval-24 | 4/4 | 0 | 100% |
| eval-25 | 4/4 | 0 | 100% |
| eval-3 | 5/5 | 0 | 100% |
| eval-4 | 5/5 | 0 | 100% |
| eval-5 | 6/6 | 0 | 100% |
| eval-6 | 6/6 | 0 | 100% |
| eval-7 | 5/5 | 0 | 100% |
| eval-8 | 5/5 | 0 | 100% |
| eval-9 | 5/5 | 0 | 100% |
Pass rate: 100% · Tokens: 0 · Duration: 0s
Baseline (8b288dc2): 99% · 45,946 tokens · 89s
Generated by sdlc-workflow/run-evals v0.11.1
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — Classified as suggestion (3 items):
|
Verification Report for TC-5008 (commit 66f2019)
Overall: PASSAll functional checks pass. The eval-1 assertion failure (Step 0.7 not demonstrated in eval output) is tracked as TC-5011. Root-cause analysis identified a convention gap — the eval prompt was not updated to request Step 0.7 output, tracked as TC-5012. Note: Test Quality and Root-Cause Investigation are informational and do not affect the Overall result. This comment was AI-generated by sdlc-workflow/verify-pr v0.11.0. |
The eval-1 assertion for Step 0.7 (early assignment) was failing because the prompt never requested Step 0.7 output from the model. Updated the prompt to explicitly request Step 0.7 actions in data-extraction.md and adjusted the assertion wording for dry-run compatibility. Implements TC-5011 Assisted-by: Claude Code
Verification Report for TC-5008 (commit 3786033)
Overall: WARNCommit 3786033 references TC-5011 instead of TC-5008. TC-5011 is an eval fix sub-task created during the first verification run and its commit was pushed to this PR branch. This is expected cross-task tracing within the same PR — no action required. This comment was AI-generated by sdlc-workflow/verify-pr v0.11.0. |
Summary
get_transitionsto support the Vulnerability workflow (Assigned status, not In Progress)Implements TC-5008
Test plan
user_infoandassigneein the new step — both presentget_transitionsin the new step — dynamic discovery present🤖 Generated with Claude Code
Summary by Sourcery
Introduce an early triage step that immediately assigns CVE Vulnerability issues to the triaging user and transitions them to Assigned status after Jira access initialization.
Enhancements:
Documentation:
Tests: