Generate Allure Annotations for Test Files with AI
Reads a test file and annotates each test with Allure metadata (epic, feature, story, severity, link to spec, TMS link) based on file path conventions, commit message JIRA prefixes, and test naming — emits a diff, not a rewrite.
When to use it
- Adding Allure reporting to an existing suite without rewriting tests.
- Standardizing test metadata across a team where annotations are inconsistent.
- Wiring JIRA / TestRail / Linear links to tests for traceability.
- Onboarding engineers to Allure conventions.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a test reporting specialist. You know that Allure annotations are most useful when they're consistent — and most accurate when they derive from file paths and naming, not from guesses.
</role>
<context>
Allure annotations (via @allure/decorators or allure-js):
- `@epic("Checkout")` — top-level grouping
- `@feature("Discount codes")` — feature within epic
- `@story("Apply promo code at checkout")` — user story
- `@severity("critical" | "blocker" | "normal" | "minor" | "trivial")` — bug-tracking severity if a test fails
- `@link("https://...", "JIRA-1234")` — link to spec or related issue
- `@tms("https://...", "TC-5678")` — link to test management system
Conventions:
- Epic derived from top-level test directory (`tests/checkout/...` → epic "Checkout")
- Feature derived from second-level directory or filename
- Story derived from `describe` block or test name
- Severity inferred from test name (`smoke` → critical; `edge case` → minor)
- Links from existing JIRA references in comments or commit messages
</context>
<task>
For the test file below:
1. Derive epic from file path (top-level dir).
2. Derive feature from second-level dir or filename.
3. Derive story from `describe` block name.
4. Derive severity from test naming (use rules).
5. Add JIRA / TMS links if present in comments or commit message.
6. RESPECT existing annotations — never overwrite, only add missing.
7. Emit as a DIFF showing only lines added.
</task>
<input>
Test file path: {path}
Test file content: {content}
Recent commit message (for JIRA references): {commit_msg}
Existing TMS pattern (if any): {tms_pattern}
</input>
<constraints>
- Annotations are added at the test level (inside or above the `test(` / `it(` block), not at the file level.
- DIFF format — show only ADDED lines, not modified ones.
- Existing annotations preserved; never overwrite.
- Severity rules:
- "smoke" / "critical path" in name → critical
- "edge case" / "rare" / "unlikely" in name → minor
- default → normal
- "blocker" / "showstopper" in name → blocker
- Link format: `@link("<url>", "<label>")`.
</constraints>
<output_format>
A unified diff (added lines only) showing the annotation insertions. Followed by a "Derivation log" — bullets showing where each annotation came from.
</output_format>
Before writing, identify any existing annotations in the file — never overwrite.Example
Common pitfalls
- Model overwrites existing annotations (e.g., changes severity that was manually set). Force 'preserve existing'.
- Severity defaults to 'normal' without inference rules — re-prompt with explicit rule list.
- JIRA links not added because comment/commit-message reference was missed — feed both to maximize coverage.
- Annotations added at the file level (describe block) instead of per-test — Allure groups poorly when annotations aren't per-test.
Tips
- Run this in batches per directory; epic/feature consistency improves when batching.
- Pair with `github-actions-qa-pipeline` to wire Allure report upload as an artifact step.
- Use `allure-playwright` instead of manual annotations if you can — auto-derives some metadata.
- Re-run when adding new tests; consistency drifts otherwise.
FAQ
TestRail uses `@tms()` for test management; JIRA uses `@link()` for related issues. Use both: tms link to the test case in TestRail, link to bug or story in JIRA. Allure renders both in the report.
Related prompts
GitHub Actions QA Pipeline Generator
Returns a complete `.github/workflows/qa.yml` with unit → integration → E2E stages, Playwright browser matrix, dependency + browser caching keyed on lockfile, artifact retention with explicit period, and failure notification via webhook / Slack.
Open →GitLab CI Test Pipeline Configuration
Returns a `.gitlab-ci.yml` with stages (build, test:unit, test:integration, test:e2e), parallel matrix for E2E browsers, cache keyed on lockfile, rules section for MR vs main differences, and artifact reports with explicit expiration.
Open →Review Test Code for Anti-Patterns
Reads a test file and returns a categorized list of anti-patterns — hard sleeps, shared mutable state, weak assertions (`toBeTruthy` instead of `toEqual`), missing teardown, mixed setup/assertion concerns — each with line numbers, severity, and a suggested fix.
Open →Configure Parallel Test Execution
Returns a parallel-execution config tailored to your framework (Playwright or Jest), CI runner count, average test duration, and flakiness rate — including shard count, worker count per shard, test ordering strategy, and a reasoning paragraph.
Open →