feat: add shared QA requirements writing rule#9010
Conversation
Adds a team-wide Claude rule for writing QA requirements on Linear tickets. Combines scenario-based format (validated by QA) with change analysis, indirect impact tracing, and regression testing guidance. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
WalkthroughAdded two new Markdown documentation files defining a standardized, step-by-step process for writing QA requirements for Linear tickets, including when to apply the workflow, systematic branch-change analysis, required output format (scenarios, setup/verify checklists), collaboration cadence, and conditional regression testing guidance. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
View your CI Pipeline Execution ↗ for commit 50240d4
☁️ Nx Cloud last updated this comment at |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.claude/rules/writing-qa-requirements.md (2)
26-33: Add concrete symbol-tracing commands for indirect impact checks.This section is good conceptually, but adding command examples will make execution consistent across engineers.
Suggested doc enhancement
2. **Trace indirect impacts:** - Identify shared components, hooks, or utilities that were modified - - Check where those shared pieces are imported/used across the codebase + - Check where those shared pieces are imported/used across the codebase (e.g. `rg -n "from '...'"`, `rg -n "<SymbolName>"`) - Note any user-facing flows that consume the changed code, even if those flows weren't the target of the change🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/rules/writing-qa-requirements.md around lines 26 - 33, Update the "Trace indirect impacts" and "Map entry points" sections to include concrete symbol-tracing commands engineers can run: show examples such as ripgrep/rg or git grep to find usages (e.g. rg --hidden --glob '!node_modules' "MyComponent" or git grep -n "useMyHook"), VSCode/IDE actions like "Find All References" and "Go to Implementation", and git history commands for change impact (git log -S"symbol" -- path or git blame path). Also add a short example for mapping entry points using browser-searchable route patterns and ripgrep to locate route handlers/pages (e.g. rg "RouteName|/path" src) so readers can follow a concrete workflow for identifying indirect consumers referenced in those sections.
14-16: Include console-log capture guidance for regression debugging.You already request screenshots/videos; adding console log capture for regressions would make bug triage faster.
Based on learnings: Extend Playwright scenarios when UI behavior shifts, and capture console logs/screenshots for regressions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/rules/writing-qa-requirements.md around lines 14 - 16, Add a new bullet after the existing bullets ("Ask the user if any scenarios are blocked by other work..." and "Remind the user to attach screenshots or videos...") that instructs reporters to include console-log captures for regression debugging and to attach Playwright/Chromium console logs and network logs alongside screenshots/videos; specify preferred capture guidance (e.g., collect browser console output, error stacks, and a short repro script or Playwright trace) and a short recommended filename/format convention so triage can quickly correlate logs with screenshots and Linear tickets.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/rules/writing-qa-requirements.md:
- Around line 21-24: Update the guidance around using "git log main..HEAD
--oneline" and "git diff main..HEAD --stat" to first refresh the local main
branch so diffs aren’t stale; add a preceding step telling the reader to fetch
and update main from upstream (e.g., perform a git fetch and update/reset or
pull main) before running the log/diff commands so the QA scope includes the
latest upstream changes.
---
Nitpick comments:
In @.claude/rules/writing-qa-requirements.md:
- Around line 26-33: Update the "Trace indirect impacts" and "Map entry points"
sections to include concrete symbol-tracing commands engineers can run: show
examples such as ripgrep/rg or git grep to find usages (e.g. rg --hidden --glob
'!node_modules' "MyComponent" or git grep -n "useMyHook"), VSCode/IDE actions
like "Find All References" and "Go to Implementation", and git history commands
for change impact (git log -S"symbol" -- path or git blame path). Also add a
short example for mapping entry points using browser-searchable route patterns
and ripgrep to locate route handlers/pages (e.g. rg "RouteName|/path" src) so
readers can follow a concrete workflow for identifying indirect consumers
referenced in those sections.
- Around line 14-16: Add a new bullet after the existing bullets ("Ask the user
if any scenarios are blocked by other work..." and "Remind the user to attach
screenshots or videos...") that instructs reporters to include console-log
captures for regression debugging and to attach Playwright/Chromium console logs
and network logs alongside screenshots/videos; specify preferred capture
guidance (e.g., collect browser console output, error stacks, and a short repro
script or Playwright trace) and a short recommended filename/format convention
so triage can quickly correlate logs with screenshots and Linear tickets.
🪄 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 UI
Review profile: CHILL
Plan: Pro
Run ID: 10eb170b-e455-44cf-81e9-46c46594c8dd
📒 Files selected for processing (1)
.claude/rules/writing-qa-requirements.md
| 1. **Identify all changes on the branch:** | ||
| - Run `git log main..HEAD --oneline` to see all commits | ||
| - Run `git diff main..HEAD --stat` to see all changed files | ||
| - Read the key changed files to understand what was modified |
There was a problem hiding this comment.
Refresh main before branch diff to avoid stale analysis.
main..HEAD is only reliable if local main is current. Without a fetch/reset step, QA scope can miss recent upstream changes.
Suggested doc fix
1. **Identify all changes on the branch:**
+ - Run `git fetch origin main` (or update local `main`) first so comparisons use the latest baseline
- Run `git log main..HEAD --oneline` to see all commits
- Run `git diff main..HEAD --stat` to see all changed files
- Read the key changed files to understand what was modified🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/writing-qa-requirements.md around lines 21 - 24, Update the
guidance around using "git log main..HEAD --oneline" and "git diff main..HEAD
--stat" to first refresh the local main branch so diffs aren’t stale; add a
preceding step telling the reader to fetch and update main from upstream (e.g.,
perform a git fetch and update/reset or pull main) before running the log/diff
commands so the QA scope includes the latest upstream changes.
|
nit: Really useful content — the format and change-analysis steps are great. One small packaging suggestion: this file reads as a multi-step procedure (fetch Linear ticket → run Core's existing From Anthropic's Skills docs (note: custom commands and skills are now the same thing —
And Best Practices:
Moving this to |
Move writing-qa-requirements from .claude/rules/ to .claude/commands/write-qa-requirements.md — this is a multi-step procedure invoked on demand, not a path-scoped convention. Addresses review feedback from jaco-brink. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mirror of .claude/commands/write-qa-requirements.md with Cursor frontmatter conventions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2 participants
Summary
.claude/rules/writing-qa-requirements.md) for writing QA requirements on Linear ticketsContext
Compared the existing QA checklist skill from #8831 with a personal QA rule that QA has confirmed produces clear, actionable requirements. This rule merges the best of both:
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit