Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Every user-facing change in a software release should have corresponding test coverage that verifies the change works as intended. In practice, this mapping between changelog entries and test cases is rarely maintained, leading to releases where features ship without adequate verification and bug fixes lack regression tests. The Changelog Test Mapper bridges this gap by programmatically analyzing changelog entries, release notes, and commit histories, then mapping them to existing test cases and identifying coverage gaps. This skill covers the full pipeline: parsing changelogs in various formats, extracting change metadata, building a bidirectional mapping between changes and tests, scoring coverage completeness, and integrating the analysis into release workflows to prevent untested changes from reaching production.
Core Principles
1. Every Shipped Change Deserves a Test
The fundamental premise of changelog-test mapping is that if a change is important enough to appear in the changelog, it is important enough to have a test. Bug fixes need regression tests. New features need functional tests. Performance improvements need benchmark tests. Changes without tests are unverified promises.
2. Bidirectional Traceability
The mapping must work in both directions. Given a changelog entry, you should be able to find all related tests. Given a test, you should be able to find which changelog entries it covers. This bidirectional traceability enables both forward analysis ("is this release well-tested?") and backward analysis ("what does this test protect?").
3. Automation Over Manual Tracking
Manually maintaining a spreadsheet of change-to-test mappings does not scale. The mapping should be derived automatically from commit messages, PR descriptions, issue tracker links, and file-level change analysis. Manual annotations should supplement, not replace, automated discovery.
4. Coverage Scoring Is Contextual
Not all changelog entries need the same level of test coverage. A breaking API change requires more comprehensive testing than a documentation fix. The coverage scoring model must account for change severity, affected surface area, and historical defect rates.
5. Integrate at Release Time
The mapping analysis should run as part of the release process, not as an afterthought. A release checklist that includes "all changelog entries have mapped tests" prevents untested changes from shipping.
The file-based mapper connects changelog entries to tests by analyzing which source files changed and finding tests that import or reference those files:
/**
* @coversPROJ-123
* @verifies User can reset password via email link
* @regressionBUG-456
*/test('password reset flow sends email and allows reset', async ({ page }) => {
await page.goto('/forgot-password');
await page.getByLabel('Email').fill('test@example.com');
await page.getByRole('button', { name: 'Send Reset Link' }).click();
awaitexpect(page.getByText('Reset link sent')).toBeVisible();
});
Best Practices
Parse changelogs automatically on every PR that modifies CHANGELOG.md. This ensures the mapping analysis runs before release decisions are made, not after.
Use conventional commits to generate structured changelog data. Conventional commits provide machine-parseable change metadata (type, scope, breaking changes) that dramatically improves mapping accuracy.
Require explicit test annotations for breaking changes. Breaking changes have the highest risk of user impact. Require developers to annotate at least one test with @verifies for every breaking change entry.
Combine multiple mapping strategies. No single mapping strategy catches everything. Use file-based mapping, import analysis, and semantic matching together, then merge results with confidence scores.
Set release gates based on coverage thresholds. Block releases when changelog-to-test coverage falls below a configurable threshold. Start at 50% and increase as the team matures.
Track coverage trends across releases. Compare mapping coverage between releases to identify whether the team is improving or declining in test discipline.
Generate reports as PR comments. Posting the readiness report directly on the PR makes coverage gaps visible during code review, when they can still be addressed.
Maintain a test index for semantic matching. Periodically build an index of all test names and descriptions to enable efficient semantic matching against changelog entries.
Differentiate between types of coverage. A bug fix needs a specific regression test. A new feature needs functional tests. A performance improvement needs a benchmark. The mapping should verify the right type of test exists.
Use issue tracker references as primary mapping keys. When both changelog entries and tests reference the same Jira ticket or GitHub issue, the mapping confidence is highest. Encourage developers to include issue references in both places.
Audit the mapping regularly. Periodically review false positives and false negatives in the mapping to improve parser accuracy and mapping strategies.
Anti-Patterns to Avoid
Treating changelog-test mapping as optional documentation. If the mapping is not enforced in CI, it will be ignored. Treat it as a release gate, not a nice-to-have report.
Relying solely on file-based mapping. File-based mapping misses behavioral connections. A change to a shared utility function may affect many features, but only tests that directly import the utility will appear in file-based mapping.
Mapping quantity over quality. Having 10 low-confidence test mappings for a changelog entry is not the same as having 1 high-confidence mapping. Weight confidence scores when calculating coverage.
Ignoring security changelog entries. Security changes are the highest-risk entries in any changelog. Never skip test mapping for security fixes and vulnerability patches.
Running the analysis only at release time. By the time the release is ready, it is too late to write missing tests without delaying the release. Run the analysis continuously on PRs.
Hard-coding changelog formats. Support multiple changelog formats from the start. Teams migrate between formats, and the tool should adapt without requiring rewriting.
Debugging Tips
Parser finds no entries in the changelog. Check the exact format of your CHANGELOG.md. The Keep a Changelog parser expects specific heading formats: ## [version] - date for versions and ### Added for types. Verify that your file matches the expected format exactly.
File-based mapping produces zero matches. Check that your test files follow naming conventions that the mapper recognizes. If tests are in a __tests__ directory with different names than source files, the convention-based strategy will miss them. Consider adding import analysis or explicit annotations.
Semantic matching produces too many false positives. Tighten the confidence threshold. If the default threshold of 0.3 produces noise, increase it to 0.5 or 0.6. Also review and expand the stop words list to filter common words that create spurious matches.
Coverage score seems artificially high. The score may be inflated if many changelog entries have no affected files listed. Ensure that commit SHAs or file paths are populated for each entry so the mapper has data to work with.
The release gate blocks a valid release. If the mapping legitimately cannot find tests for a low-risk change (e.g., documentation update), add an exclusion mechanism. Allow entries to be marked as @no-test-needed with a justification.
