Conversation
WalkthroughAdded three GitHub issue templates under Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 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: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/feature_request.md(1 hunks).github/ISSUE_TEMPLATE/job-story.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/ISSUE_TEMPLATE/job-story.md
[style] ~52-~52: Try using a synonym here to strengthen your writing.
Context: ...xactly how long the fields should be or give specifics about date formats and the li...
(GIVE_PROVIDE)
[style] ~160-~160: ‘Last but not least’ might be wordy. Consider a shorter alternative.
Context: .... - To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone ...
(EN_WORDINESS_PREMIUM_LAST_BUT_NOT_LEAST)
[grammar] ~189-~189: Use a hyphen to join words.
Context: ...describe the problem to a colleague face to face. * The PM owns the Intermissio...
(QB_NEW_EN_HYPHEN)
[grammar] ~189-~189: Use a hyphen to join words.
Context: ...cribe the problem to a colleague face to face. * The PM owns the Intermission, ...
(QB_NEW_EN_HYPHEN)
[style] ~191-~191: Consider using a different adjective to strengthen your wording.
Context: ...ld always always solicit input from the full team Team Handshake: - 1. Each story...
(FULL_ENTIRE)
[style] ~197-~197: In American English, abbreviations like “etc.” require a period.
Context: ...rtment ( Design, Engineering, Marketing etc ) - 3. Stories include the following ...
(ETC_PERIOD)
🪛 markdownlint-cli2 (0.18.1)
.github/ISSUE_TEMPLATE/job-story.md
63-63: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
67-67: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
95-95: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
107-107: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
116-116: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
132-132: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
179-179: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
.github/ISSUE_TEMPLATE/bug_report.md
27-27: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
28-28: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
29-29: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
32-32: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
33-33: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
34-34: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
35-35: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
🔇 Additional comments (1)
.github/ISSUE_TEMPLATE/feature_request.md (1)
1-20: Well-structured feature request template.The template follows GitHub's standard format and provides clear guidance for users to describe feature requests comprehensively. YAML front matter is correct, and the markdown sections are well-organized.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/ISSUE_TEMPLATE/job-story.md (1)
52-52: Minor grammar and style refinements.Several static analysis hints suggest improving language clarity:
- Line 52: Consider a stronger synonym than "give" (e.g., "specify" or "provide specific").
- Line 161: "Last but not least" is wordy; consider "Finally," or simply "also."
- Line 190: Use hyphen: "face-to-face" instead of "face to face."
- Line 192: Appears to have a duplicate word ("always always"). Should be "should always."
- Line 198: "etc" requires a period: "etc."
These are minor style improvements and not blocking issues, but addressing them will improve clarity and compliance with standard English conventions.
Apply this diff for these refinements:
-**N = Negotiable**—The story is not so detailed as to describe exactly how long the fields should be or give specifics about date formats and the like. Most likely there will be common routines or libraries that will allow the development team to implement in the way that makes the most sense for them. +**N = Negotiable**—The story is not so detailed as to describe exactly how long the fields should be or specify details about date formats and the like. Most likely there will be common routines or libraries that will allow the development team to implement in the way that makes the most sense for them. - **To serve as a basis for tests.** Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected. + **To serve as a basis for tests.** Finally, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected. -* Always use plain simple English, no technical terminology or codenames. Write this document as you would describe the problem to a colleague face to face. +* Always use plain simple English, no technical terminology or codenames. Write this document as you would describe the problem to a colleague face-to-face. -* The PM owns the Intermission, but should always always solicit input from the full team +* The PM owns the Intermission, but should always solicit input from the entire team -* Stories are short, compact descriptions illustrating a user need and desired outcome for a specific department ( Design, Engineering, Marketing etc ) +* Stories are short, compact descriptions illustrating a user need and desired outcome for a specific department (Design, Engineering, Marketing, etc.)Also applies to: 161-161, 190-190, 192-192, 198-198
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/job-story.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/ISSUE_TEMPLATE/job-story.md
[style] ~52-~52: Try using a synonym here to strengthen your writing.
Context: ...xactly how long the fields should be or give specifics about date formats and the li...
(GIVE_PROVIDE)
[style] ~161-~161: ‘Last but not least’ might be wordy. Consider a shorter alternative.
Context: .... - To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone ...
(EN_WORDINESS_PREMIUM_LAST_BUT_NOT_LEAST)
[grammar] ~190-~190: Use a hyphen to join words.
Context: ...describe the problem to a colleague face to face. * The PM owns the Intermissio...
(QB_NEW_EN_HYPHEN)
[grammar] ~190-~190: Use a hyphen to join words.
Context: ...cribe the problem to a colleague face to face. * The PM owns the Intermission, ...
(QB_NEW_EN_HYPHEN)
[style] ~192-~192: Consider using a different adjective to strengthen your wording.
Context: ...ld always always solicit input from the full team Team Handshake: - 1. Each story...
(FULL_ENTIRE)
[style] ~198-~198: In American English, abbreviations like “etc.” require a period.
Context: ...rtment ( Design, Engineering, Marketing etc ) - 3. Stories include the following ...
(ETC_PERIOD)
🔇 Additional comments (3)
.github/ISSUE_TEMPLATE/bug_report.md (1)
27-35: Well-formatted list structure.The unordered list indentation is now correct, with proper zero-space indentation before each dash. The template structure is clear and provides helpful guidance for bug reporters.
.github/ISSUE_TEMPLATE/job-story.md (2)
14-14: Verify backslash line continuations.Lines 14, 43, 81, 101, and 200 end with backslashes. In standard markdown, these may not render as intended—they could appear as literal backslashes or cause unexpected formatting. GitHub typically doesn't require line-continuation characters in markdown. Consider removing trailing backslashes or restructuring these lines for clarity.
For example, line 14:
-Detailed mocks & feature requirements. You can start by expanding on the scoping section from the brief. Work with your engineers & designer to ensure you've gone into enough detail and covered all the cases.\ +Detailed mocks & feature requirements. You can start by expanding on the scoping section from the brief. Work with your engineers & designer to ensure you've gone into enough detail and covered all the cases.Also applies to: 43-43, 81-81, 101-101, 200-200
1-8: Strong template foundation with clear YAML metadata.The YAML front matter is correctly configured, which will allow GitHub to properly recognize and display this template as an issue option. The template comprehensively covers job story structure, acceptance criteria, workflows, and rollout planning—good guidance for consistent issue submission.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
.github/ISSUE_TEMPLATE/job-story.md (2)
63-65: Convert setext-style headings to atx-style (MD003 violation—previously flagged).Lines 63–65, 67–69, and 95–97 use setext-style headings (underlined with dashes), which violates the markdown linter rule MD003. Past review comments indicate this was addressed in commit 38f06bb, but the violations remain in the current code.
Convert to atx-style headings:
-Requirements & Goals\ -Requirements for the different teams which participate at the specific story ----------------------------------------------------------------------------- +## Requirements & Goals + +Requirements for the different teams which participate at the specific story -Workflows & Scenarios\ -List rules to guide design and development ------------------------------------------- +## Workflows & Scenarios + +List rules to guide design and development -Concept & Mockups\ -Requirements for the different teams which participate at the specific story\ -Known Limitations ------------------ +## Concept & Mockups + +Requirements for the different teams which participate at the specific story + +### Known LimitationsPlease verify whether the current branch includes commit 38f06bb or if this fix needs to be reapplied.
Also applies to: 67-69, 95-97
101-101: Convert emphasis-based headings to proper markdown headings (MD036 violation—previously flagged).Lines 107, 116, 132, and 179 use bold emphasis (
**...**) instead of proper ATX-style markdown headings, triggering the MD036 linter rule. These were previously flagged and marked as addressed, but remain unresolved in the current code.Apply this diff to convert emphasis to headings:
Brainstorm things that could go wrong with your team and partner teams. For each risk, plan appropriate mitigations.\ -**Rough Scoping & Timeline** +## Rough Scoping & Timeline At a high level, what's included in V1 vs. later versions? How big of a project is this? What's the roll out / testing plan? Consider the major pieces of functionality, Mobile, Platform, Internationalization, Entry Points, User Onboarding, Premium. This is part of the feasibility and Stakeholders of all departments have to attend and be accountable for their department decisions. -**Success Criteria** +## Success Criteria What does success look like? Include quant and qual metrics as appropriate. | | | | | | :--------: | :-----------------: | :---------------: | :---------------------: | | **Metric** | **Baseline (Date)** | **Target (Date)** | **Latest (Updated On)** | | | | | | -**Definition of Done** +## Definition of Done e.g. What does it take for the Development team to put the Product into Production? DoD is a shared understanding within the Scrum Team on what it takes to make your Product Increment releasable. The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment "often a user story" is considered "done". Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint's velocity. the DoD consists of 3 main components: - Business or Functional requirements - Quality - Non-Functional Requirements -**Roll out Plan** +## Roll out Plan Put details and a complete plan how the roll-out will be developed from the Engineering team. ## Open Questions Gather open questions here while the spec is in progress. **Acceptance Criteria**Each acceptance criteria written in this format has the following statements: Scenario – the name for the behavior that will be described Given – the beginning state of the scenario When – specific action that the user makes Then – the outcome of the action in "When" And – used to continue any of three previous statements ### What are Acceptance Criteria Used For? - **To define boundaries.** Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed. - **To reach a consensus.** Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app. - **To serve as a basis for tests.** Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected. - **To allow for accurate planning and estimation.** Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned. - Keep your criteria well-defined so any member of the project team understands the idea you're trying to convey. - Keep the criteria realistic and achievable. Define the minimum piece of functionality you're able to deliver and stick to it. On the other hand, don't try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks. - Coordinate with all the stakeholders so your acceptance criteria are based on consensus. - **Create measurable criteria that allow you to adequately estimate development time so you're able to stay within budget and time constraints.** - **Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.** ## Revisions Add revisions that are mentioned on comments and we keep them here for better organizing -**Appendix: Research** +## Appendix: Research Include useful research, such as competitive analysis, metrics, or surveys.Please verify whether the current branch includes commit 38f06bb or if this fix needs to be reapplied.
Also applies to: 107-107, 116-116, 132-132, 179-179
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/job-story.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/ISSUE_TEMPLATE/job-story.md
[style] ~52-~52: Try using a synonym here to strengthen your writing.
Context: ...xactly how long the fields should be or give specifics about date formats and the li...
(GIVE_PROVIDE)
[style] ~160-~160: ‘Last but not least’ might be wordy. Consider a shorter alternative.
Context: .... - To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone ...
(EN_WORDINESS_PREMIUM_LAST_BUT_NOT_LEAST)
[grammar] ~189-~189: Use a hyphen to join words.
Context: ...describe the problem to a colleague face to face. * The PM owns the Intermissio...
(QB_NEW_EN_HYPHEN)
[grammar] ~189-~189: Use a hyphen to join words.
Context: ...cribe the problem to a colleague face to face. * The PM owns the Intermission, ...
(QB_NEW_EN_HYPHEN)
[style] ~191-~191: Consider using a different adjective to strengthen your wording.
Context: ...ld always always solicit input from the full team Team Handshake: - 1. Each story...
(FULL_ENTIRE)
[style] ~197-~197: In American English, abbreviations like “etc.” require a period.
Context: ...rtment ( Design, Engineering, Marketing etc ) - 3. Stories include the following ...
(ETC_PERIOD)
🪛 markdownlint-cli2 (0.18.1)
.github/ISSUE_TEMPLATE/bug_report.md
18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.github/ISSUE_TEMPLATE/job-story.md
63-63: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
67-67: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
95-95: Heading style
Expected: atx; Actual: setext
(MD003, heading-style)
107-107: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
116-116: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
132-132: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
179-179: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
| ``` | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Specify a language for the fenced code block.
The code block on line 18 lacks a language identifier. This helps GitHub apply syntax highlighting and improves readability when users paste debug logs.
Apply this diff to fix the code fence:
## **Debug log:**
-```
+```bash
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.18.1)</summary>
18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
.github/ISSUE_TEMPLATE/bug_report.md lines 18-20: the fenced code block opening
lacks a language identifier; change the opening fence from triple backticks to
include "bash" (i.e., replace withbash) so the block becomes a bash code
block and retains the same closing fence.
</details>
<!-- This is an auto-generated comment by CodeRabbit -->
1 participant
Description:
Added Issues template for reporting Bugs and enhancements
Summary by CodeRabbit