Conversation
Extend plan-feature Steps 5 and 6 to support Epic hierarchy between Features and Tasks. When a level-1 issue type (Epic) is discovered in Step 2.5, the skill groups tasks into Epics using one of three strategies: by-repository, by-sub-feature, or trivial. Epics are created with parent set to the Feature, and tasks are parented to their assigned Epic. Incorporates links go from Feature to Epics. When no level-1 type exists, the skill falls back to the existing Feature → Task hierarchy unchanged (graceful degradation). Adds three new constraints (1.79-1.81) and a new eval scenario (id 6) with a multi-repo fixture to exercise by-repository grouping. Implements TC-4869 Assisted-by: Claude Code
Reviewer's GuideAdds Epic-level hierarchy support to the plan-feature skill, including configurable grouping strategies, Epic creation in Jira, hierarchy-aware parent/link behavior, and corresponding constraints/eval fixtures while preserving backward-compatible Feature → Task behavior. Sequence diagram for Epic-aware Jira issue creation in plan-featuresequenceDiagram
actor User
participant plan_feature_skill
participant Jira
User->>plan_feature_skill: run plan-feature (Step 0–6)
plan_feature_skill->>plan_feature_skill: Step_2_5_discover_level_1_type
alt level_1_type_found
plan_feature_skill->>plan_feature_skill: Step_5_determine_epic_grouping_strategy
plan_feature_skill->>plan_feature_skill: Step_5_assign_tasks_to_epic_groups
loop for_each_epic_group
plan_feature_skill->>Jira: jira.create_issue(projectKey, issueTypeName, summary, description, parent, additional_fields)
Jira-->>plan_feature_skill: epic_key
plan_feature_skill->>plan_feature_skill: record_epic_group_mapping
end
loop for_each_task
plan_feature_skill->>Jira: jira.create_issue(projectKey, taskIssueTypeName, summary, description, parent=epic_key, additional_fields)
Jira-->>plan_feature_skill: task_key
end
loop for_each_epic
plan_feature_skill->>Jira: jira.create_issue_link(link_type="Incorporates", inward_issue_key=feature_key, outward_issue_key=epic_key)
end
else no_level_1_type
plan_feature_skill->>plan_feature_skill: set_no_epic_flag
loop for_each_task
plan_feature_skill->>Jira: jira.create_issue(projectKey, taskIssueTypeName, summary, description, parent=feature_or_none, additional_fields)
Jira-->>plan_feature_skill: task_key
end
loop for_each_task
plan_feature_skill->>Jira: jira.create_issue_link(link_type="Incorporates", inward_issue_key=feature_key, outward_issue_key=task_key)
end
end
Entity relationship diagram for Feature–Epic–Task Jira hierarchyerDiagram
FEATURE {
string feature_key
string summary
}
EPIC {
string epic_key
string summary
string parent_feature_key
}
TASK {
string task_key
string summary
string parent_key
}
FEATURE ||--o{ EPIC : has_epics_when_level_1_type
EPIC ||--o{ TASK : epic_parent_of_tasks
FEATURE ||--o{ TASK : direct_parent_when_no_epic
FEATURE ||--o{ FEATURE : incorporates_epic_or_task
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The by-sub-feature Epic grouping flow is currently a bit underspecified—consider adding concrete guidance on how sub-feature group labels are derived and presented to the user to keep behavior consistent across runs.
- In the Epic-aware parent field and graceful degradation sections, it may help to explicitly spell out how the
no-Epicflag from Step 2.5 is surfaced and consumed (variable name / state handling) to avoid ambiguity for implementers wiring the logic.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The by-sub-feature Epic grouping flow is currently a bit underspecified—consider adding concrete guidance on how sub-feature group labels are derived and presented to the user to keep behavior consistent across runs.
- In the Epic-aware parent field and graceful degradation sections, it may help to explicitly spell out how the `no-Epic` flag from Step 2.5 is surfaced and consumed (variable name / state handling) to avoid ambiguity for implementers wiring the logic.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Eval Results
Eval Results: plan-feature
| Eval | Passed | Failed | Pass Rate |
|---|---|---|---|
| eval-1 | 16/16 | 0 | 100% |
| eval-2 | 14/14 | 0 | 100% |
| eval-3 | 15/15 | 0 | 100% |
| eval-4 | 7/11 | 4 | 64% |
| eval-5 | 11/15 | 4 | 73% |
| eval-6 | 14/14 | 0 | 100% |
Failed Assertions
eval-4: 4 failing assertions
-
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "Each task file contains a digest line at the bottom (e.g., task-1 line 44: 'Description digest: sha256-md:23ca784d1b3b08815985bfe2505561e22412caee786d324b73fc76f607d6dcdf'). While all four digests have the sha256-md: prefix followed by exactly 64 lowercase hex characters, the marker format does NOT match the required '[sdlc-workflow] Description digest: sha256-md:<hash>' pattern — the '[sdlc-workflow]' prefix is missing from all four. The assertion specifies the marker format must include this prefix." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "No task description contains any reference to CONVENTIONS.md, 'Per CONVENTIONS', or 'Applies:' rationale lines. The convention-applicability-rules.md prescribes that applicable conventions include 'Applies: task modifies <file> matching the convention's <scope>' in Implementation Notes. None of the four task files contain any such rationale. While this could mean no conventions were applicable (if no CONVENTIONS.md exists for the target repo), the assertion requires that convention-aware enrichment was performed — there is no evidence of any convention applicability check having been done." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "The Feature TC-9004 has Priority: Major (not 'Undefined'). The impact-map.md states 'Priority: Major (propagated from TC-9004)' and summary-comment.md states 'Priority: Major — inherited from TC-9004 and propagated to all created tasks'. However, none of the four task description files contain any mention of 'priority', 'Major', or 'additional_fields'. There is no concrete evidence in the output files that the Jira API calls to create tasks actually included priority in additional_fields — only the plan documents state the intention to propagate." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "The Feature TC-9004 has Fix Versions: RHTPA 1.5.0. CLAUDE.md has no '### Jira Field Defaults' section, so fixVersion scope defaults to 'both', meaning fixVersions should propagate to tasks. The impact-map.md states 'Fix Versions: RHTPA 1.5.0 (propagated from TC-9004)' and summary-comment.md states 'Fix Versions: RHTPA 1.5.0 — inherited from TC-9004 and propagated to all created tasks'. However, none of the four task description files contain any mention of 'fixVersions', 'RHTPA', or 'additional_fields'. There is no concrete evidence in the output files that the Jira API calls actually included fixVersions in additional_fields."
eval-5: 4 failing assertions
-
Assertion: "Each task file contains all required template sections: Repository, Target Branch, Description, at least one of Files to Modify or Files to Create, Implementation Notes, Acceptance Criteria, Test Requirements"
Evidence: "Bookend tasks (task-1-create-feature-branch.md and task-8-merge-feature-branch.md) are missing 'Files to Modify', 'Files to Create', and 'Implementation Notes' sections. Task 1 has sections: Repository, Target Branch, Bookend Type, Description, Acceptance Criteria, Test Requirements, Dependencies. Task 8 has sections: Repository, Target Branch, Bookend Type, Description, Acceptance Criteria, Test Requirements, Dependencies. Non-bookend tasks (2-7) all contain the required sections." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "No convention-related enrichment with prescribed 'Applies:' rationale format is present in any task file. The task files reference 'Per docs/constraints.md' rules (e.g., task-2 lines 28-31, task-3 lines 23-24) but these are constraint references, not convention enrichment. There is no 'Per CONVENTIONS.md' reference with 'Applies: task modifies <file> matching the convention's <scope>' format anywhere in the outputs. The CONVENTIONS.md in this repo (sdlc-plugins) contains conventions like 'Commit Messages' that are broadly applicable and should have been included with the prescribed 'Applies: convention has no file-type restriction (broadly applicable)' rationale, but no such rationale appears." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "The feature issue has Priority: High (not Undefined), so every created task should include priority in additional_fields. The summary-comment.md states 'Priority: High — inherited from Feature TC-9005 and propagated to all created tasks' and the impact-map.md states 'Priority: High (inherited from Feature TC-9005, propagated to all tasks)'. However, none of the 8 individual task files (task-1 through task-8) contain any 'additional_fields' section, 'priority' field, or mention of 'High' priority. The priority propagation is only documented in the summary and impact map, not in the actual task descriptions themselves." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "The feature issue has Fix Versions: RHTPA 2.0.0 (non-empty) and there is no fixVersion scope config in CLAUDE.md (defaults to 'both'), so every created task should include fixVersions in additional_fields. The summary-comment.md and impact-map.md both mention fixVersions propagation. However, none of the 8 individual task files contain any 'additional_fields' section or 'fixVersions' field. The fixVersions propagation is only documented in the summary and impact map, not in the actual task descriptions."
Pass rate: 89% · Tokens: 69,716 · Duration: 281s
Baseline (b22bcfd2): 76% · 47,235 tokens · 217s
Generated by sdlc-workflow/run-evals v0.11.1
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — Two items classified:
|
Verification Report for TC-4869 (commit 11919ac)
Overall: PASSAll checks pass. The PR correctly extends plan-feature Steps 5 and 6 with Epic grouping strategies and creation logic, adds graceful degradation for projects without Epics, introduces 3 new constraints (1.79–1.81), and adds eval scenario 6 with 14 assertions — all passing at 100%. The overall eval pass rate improved from 76% baseline to 89%. This comment was AI-generated by sdlc-workflow/verify-pr v0.11.1. |
1 participant
Summary
Implements TC-4869
Test plan
🤖 Generated with Claude Code
Summary by Sourcery
Introduce configurable Epic-level hierarchy between Features and Tasks in the plan-feature workflow, with backward-compatible behavior when Epics are unavailable.
New Features:
Enhancements:
Documentation:
Tests: