create-missing-tests-in-pr — pekral/ai-olympus

## Constraints - Apply @rules/php/core-standards.md - Apply @rules/git/general.md - Apply @rules/code-testing/general.md - If the current project uses Laravel, also apply `@rules/laravel/laravel.md`, `@rules/laravel/architecture.md`, `@rules/laravel/filament.md`, and `@rules/laravel/livewire.md` - Work on the pull request's own branch, synced per `@rules/git/general.md` *Pull Policy*; never commit to the default branch. - This task is based on the existing pull request review. - First read your existing code review for the current pull request and identify all testing recommendations related to current changes. - Never change the assignment scope. - Only add or modify tests when needed. - Production code may only be changed if it is strictly required by the existing create-test skill or test infrastructure, otherwise do not modify it — the only exception is the **Pre-existing issue handling** workflow below, which lands the production-code fix of a pre-existing security vulnerability in its own separate commit. - Use @skills/create-test/SKILL.md for all test-writing work. - **Coverage alone is never evidence that a new test is required.** For every uncovered line or branch: 1. identify the observable behaviour or credible risk it carries; 2. check whether a stronger test already protects that behaviour; 3. add a test only for a missing behavioural contract, through the authoring gate of `@skills/test-audit/SKILL.md`. When coverage is below the required threshold but no meaningful testable contract exists, never write a fake or implementation-coupled test to reach the number — report the conflict per `@skills/test-audit/SKILL.md` *Coverage*. --- ## Read, Map & Verify before writing tests (mandatory pre-flight) Reading, mapping, and verifying come first; writing tests comes last. This pre-flight is **blocking** — do not add or modify a single line until all three steps pass, and never act on an assumption you have not confirmed by reading the code. 1. **Read** — open and read the actual changed code and the code it depends on (callers, called methods, related existing tests, configuration). Confirm what the code does by reading it, not by guessing from the review text or names. 2. **Map** — map the change's blast radius: every missing behaviour and uncovered code path the review flagged, its call sites, the branches a test must exercise, and the existing test conventions, helpers, and fixtures to reuse instead of reinventing. Then run a **completeness sweep** over the whole tree. Grep the entire repository for every name, pattern, and convention the flagged code path touches, and every test path, helper, and fixture that already exercises it — never only the files the assignment names, and never only the files you have already opened. Cover every file category the repository carries: source, tests, `rules/`, `skills/`, `agents/`, documentation, configuration, and generated assets such as `CHANGELOG.md` or `README.md`. Record the full match list before you add the first missing test, then classify each match as in scope for this batch of missing tests or as a stated exception. An incomplete sweep re-adds coverage that already exists elsewhere in the tree, or closes the review item while a sibling call site of the same code path stays untested. 3. **Verify** — check your assumptions against the real code and its observed behavior, and confirm each recommended test does not already exist before adding it. If what you read contradicts the review recommendation, surface the discrepancy instead of writing tests on a wrong premise. Only after Read, Map, and Verify are complete may test-writing begin. --- ## Execution - Load the pull request context through `skills/code-review-github/scripts/load-issue.sh <PR-URL>`. If the script is unavailable (exit code 2/3), use a GitHub MCP server. If neither is available, stop and return a failed result about missing GitHub tools. - Read your existing code review for the pull request. - Extract all recommendations related to missing tests, missing scenarios, edge cases, regression coverage, and coverage gaps. - **Take the data a finding names verbatim.** When a finding's **Test Hint** carries concrete values from the assignment — an input value, a payload, a boundary value, an expected output or error message — write the test with exactly those values. Never substitute a rounder number, a simplified payload, or an invented equivalent: that value is what reproduces the defect, and replacing it re-opens the finding the review raised (`@rules/code-review/review-process.md` *Validation & Coverage Gate*). Reaching the same value through a named fixture or constant is fine, and adding further cases beyond the named ones is allowed — the stated data are a minimum, not a ceiling. - Analyze the current branch changes against the review findings. - Verify whether the recommended tests already exist in the codebase. - Check whether current changes have 100% coverage **for the changed files only**, using the project's available coverage tooling (per the Coverage gate in `@skills/code-review/SKILL.md`). Do not gate on the project-wide coverage percentage — if the project ships no coverage tooling at all, stop and report it as a blocker, and **do not add a new bespoke coverage script** to the consuming project. - If coverage is incomplete or recommended test scenarios are missing, use @skills/create-test/SKILL.md. - Follow existing project test conventions, helpers, patterns, and abstractions. - Prefer updating existing tests first. Create new tests only if required. - Make sure tests are deterministic and not flaky. - In tests, avoid reflection; test through the public boundary, and mock only what `@rules/code-testing/general.md` *Mocking* allows. - Tests must not contain conditions (e.g., `if`, `switch`); split conditional logic into separate test cases instead. - Use data providers where they improve readability and simplify repeated test cases. - After adding or updating tests, run only the necessary tests for the current changes. - If coverage tooling exists, verify that current changes are covered with 100% coverage for the changed files only, using the project's available coverage tooling (per the Coverage gate in `@skills/code-review/SKILL.md`) — do not gate on the full-suite coverage percentage. Delete any generated coverage report file once read so it is not accidentally committed. - Use the project's coverage command, discovered per `@skills/resolve-issue/references/quality-gates.md`. Do not run fixers or checkers here; the project's gate runs once at the merge boundary (*Gate placement — deferred to the merge boundary* in that file). - Do not run the whole test suite unless it is required for the changed files workflow. - If the review recommendation is already satisfied by existing tests, do not duplicate test coverage. - **Place new test files per `@rules/code-testing/general.md` *Test Organization*** — the test file path mirrors the namespace of the SUT (e.g. `App\Service\Billing\InvoiceCalculator` → `tests/Service/Billing/InvoiceCalculatorTest.php`), the file name is `{ClassName}Test.php` (or `{ClassName}{Scenario}Test.php` for an extracted scenario file of the same SUT), and cross-cutting tests sit under an intent-named directory (`tests/Feature/<flow>`, `tests/Contract/<vendor>`, `tests/Integration/<area>`). - **Name every `it()` / `test()` block to match the scenario the body asserts** — plain-language descriptions such as `it('returns zero for an empty cart')` or `test('throws InvalidArgumentException when the discount is negative')`. Never use placeholders (`it('it works')`, `test('test1')`, `test('happy path')`), method names (`test('calculate')`, `it('handles getUser')`), or descriptions that contradict the assertions, so the code-review test-organization gate passes when the PR is re-reviewed. - **Structure every test body arrange-act-assert per `@rules/php/core-standards.md` Testing** — phases in order (setup → action → assertions), separated by blank lines, never by `// Arrange` / `// Act` / `// Assert` comments; see the canonical rule for the exception list. ### Pre-existing issue handling Change nothing outside the assignment (`@rules/compound-engineering/general.md` *The assignment is the scope*). While writing the missing tests you may uncover a problem that is **unrelated to the current PR scope** but was already present in the code you had to read or exercise. - **A security vulnerability is fixed**, in its own commit with its regression test, distinct from the missing-tests commit. The procedure lives in `@skills/resolve-issue/references/pre-existing-issue-handling.md`; the "Production code may only be changed if it is strictly required" constraint above is overridden for this fix only. - A refactoring-only pull request files a vulnerability instead of fixing it (`@rules/refactoring/general.md` *Behaviour stays identical — bugs included*). - Do not scan unrelated files for more. ### After completing the tasks - Run a quick code review of all added or updated tests against `@rules/code-testing/general.md` and fix any findings. - Summarize what testing recommendations from the code review were verified. - List added or modified test files. - Confirm whether current changes now meet the required test coverage (must be 100%). - If something is still missing, clearly describe the blocker, the uncovered scenario, or the coverage conflict that has no meaningful test. - Create a new commit with the missing tests, separate from any pre-existing security fix commit produced by *Pre-existing issue handling* above --- ## Output Provide a brief markdown summary including: - reviewed PR testing recommendations - which recommendations were already covered - which tests were added or updated - whether 100% coverage for current changes was achieved, or which coverage conflict was reported instead - list of pre-existing security fix commits (if any), each with a one-line rationale, plus the URL of any follow-up issue filed for a point outside the assignment (`@skills/resolve-issue/SKILL.md` *Deferred-item follow-up issues*) - any blocker preventing full completion --- ## Principles - Follow code review recommendations strictly - Data a finding names are copied verbatim, never re-invented - Do not duplicate existing tests - Minimum tests, maximum confidence; coverage verifies them - Use data providers where they improve readability and reduce duplication - Every test change must be verified to pass before moving on - Focus on changed code only

Constraints

Apply @rules/php/core-standards.md
Apply @rules/git/general.md
Apply @rules/code-testing/general.md
If the current project uses Laravel, also apply @rules/laravel/laravel.md, @rules/laravel/architecture.md, @rules/laravel/filament.md, and @rules/laravel/livewire.md
Work on the pull request's own branch, synced per @rules/git/general.md Pull Policy; never commit to the default branch.
This task is based on the existing pull request review.
First read your existing code review for the current pull request and identify all testing recommendations related to current changes.
Never change the assignment scope.
Only add or modify tests when needed.
Production code may only be changed if it is strictly required by the existing create-test skill or test infrastructure, otherwise do not modify it — the only exception is the Pre-existing issue handling workflow below, which lands the production-code fix of a pre-existing security vulnerability in its own separate commit.
Use @skills/create-test/SKILL.md for all test-writing work.
Coverage alone is never evidence that a new test is required. For every uncovered line or branch:
1. identify the observable behaviour or credible risk it carries;
2. check whether a stronger test already protects that behaviour;
3. add a test only for a missing behavioural contract, through the authoring gate of @skills/test-audit/SKILL.md. When coverage is below the required threshold but no meaningful testable contract exists, never write a fake or implementation-coupled test to reach the number — report the conflict per @skills/test-audit/SKILL.md Coverage.

Read, Map & Verify before writing tests (mandatory pre-flight)

Reading, mapping, and verifying come first; writing tests comes last. This pre-flight is blocking — do not add or modify a single line until all three steps pass, and never act on an assumption you have not confirmed by reading the code.

Read — open and read the actual changed code and the code it depends on (callers, called methods, related existing tests, configuration). Confirm what the code does by reading it, not by guessing from the review text or names.
Map — map the change's blast radius: every missing behaviour and uncovered code path the review flagged, its call sites, the branches a test must exercise, and the existing test conventions, helpers, and fixtures to reuse instead of reinventing. Then run a completeness sweep over the whole tree. Grep the entire repository for every name, pattern, and convention the flagged code path touches, and every test path, helper, and fixture that already exercises it — never only the files the assignment names, and never only the files you have already opened. Cover every file category the repository carries: source, tests, rules/, skills/, agents/, documentation, configuration, and generated assets such as CHANGELOG.md or README.md. Record the full match list before you add the first missing test, then classify each match as in scope for this batch of missing tests or as a stated exception. An incomplete sweep re-adds coverage that already exists elsewhere in the tree, or closes the review item while a sibling call site of the same code path stays untested.
Verify — check your assumptions against the real code and its observed behavior, and confirm each recommended test does not already exist before adding it. If what you read contradicts the review recommendation, surface the discrepancy instead of writing tests on a wrong premise.

Only after Read, Map, and Verify are complete may test-writing begin.

Execution

Load the pull request context through skills/code-review-github/scripts/load-issue.sh <PR-URL>. If the script is unavailable (exit code 2/3), use a GitHub MCP server. If neither is available, stop and return a failed result about missing GitHub tools.
Read your existing code review for the pull request.
Extract all recommendations related to missing tests, missing scenarios, edge cases, regression coverage, and coverage gaps.
Take the data a finding names verbatim. When a finding's Test Hint carries concrete values from the assignment — an input value, a payload, a boundary value, an expected output or error message — write the test with exactly those values. Never substitute a rounder number, a simplified payload, or an invented equivalent: that value is what reproduces the defect, and replacing it re-opens the finding the review raised (@rules/code-review/review-process.md Validation & Coverage Gate). Reaching the same value through a named fixture or constant is fine, and adding further cases beyond the named ones is allowed — the stated data are a minimum, not a ceiling.
Analyze the current branch changes against the review findings.
Verify whether the recommended tests already exist in the codebase.
Check whether current changes have 100% coverage for the changed files only, using the project's available coverage tooling (per the Coverage gate in @skills/code-review/SKILL.md). Do not gate on the project-wide coverage percentage — if the project ships no coverage tooling at all, stop and report it as a blocker, and do not add a new bespoke coverage script to the consuming project.
If coverage is incomplete or recommended test scenarios are missing, use @skills/create-test/SKILL.md.
Follow existing project test conventions, helpers, patterns, and abstractions.
Prefer updating existing tests first. Create new tests only if required.
Make sure tests are deterministic and not flaky.
In tests, avoid reflection; test through the public boundary, and mock only what @rules/code-testing/general.md Mocking allows.
Tests must not contain conditions (e.g., if, switch); split conditional logic into separate test cases instead.
Use data providers where they improve readability and simplify repeated test cases.
After adding or updating tests, run only the necessary tests for the current changes.
If coverage tooling exists, verify that current changes are covered with 100% coverage for the changed files only, using the project's available coverage tooling (per the Coverage gate in @skills/code-review/SKILL.md) — do not gate on the full-suite coverage percentage. Delete any generated coverage report file once read so it is not accidentally committed.
Use the project's coverage command, discovered per @skills/resolve-issue/references/quality-gates.md. Do not run fixers or checkers here; the project's gate runs once at the merge boundary (Gate placement — deferred to the merge boundary in that file).
Do not run the whole test suite unless it is required for the changed files workflow.
If the review recommendation is already satisfied by existing tests, do not duplicate test coverage.
Place new test files per @rules/code-testing/general.md Test Organization — the test file path mirrors the namespace of the SUT (e.g. App\Service\Billing\InvoiceCalculator → tests/Service/Billing/InvoiceCalculatorTest.php), the file name is {ClassName}Test.php (or {ClassName}{Scenario}Test.php for an extracted scenario file of the same SUT), and cross-cutting tests sit under an intent-named directory (tests/Feature/<flow>, tests/Contract/<vendor>, tests/Integration/<area>).
Name every it() / test() block to match the scenario the body asserts — plain-language descriptions such as it('returns zero for an empty cart') or test('throws InvalidArgumentException when the discount is negative'). Never use placeholders (it('it works'), test('test1'), test('happy path')), method names (test('calculate'), it('handles getUser')), or descriptions that contradict the assertions, so the code-review test-organization gate passes when the PR is re-reviewed.
Structure every test body arrange-act-assert per @rules/php/core-standards.md Testing — phases in order (setup → action → assertions), separated by blank lines, never by // Arrange / // Act / // Assert comments; see the canonical rule for the exception list.

Pre-existing issue handling

Change nothing outside the assignment (@rules/compound-engineering/general.md The assignment is the scope). While writing the missing tests you may uncover a problem that is unrelated to the current PR scope but was already present in the code you had to read or exercise.

A security vulnerability is fixed, in its own commit with its regression test, distinct from the missing-tests commit. The procedure lives in @skills/resolve-issue/references/pre-existing-issue-handling.md; the "Production code may only be changed if it is strictly required" constraint above is overridden for this fix only.
A refactoring-only pull request files a vulnerability instead of fixing it (@rules/refactoring/general.md Behaviour stays identical — bugs included).
Do not scan unrelated files for more.

After completing the tasks

Run a quick code review of all added or updated tests against @rules/code-testing/general.md and fix any findings.
Summarize what testing recommendations from the code review were verified.
List added or modified test files.
Confirm whether current changes now meet the required test coverage (must be 100%).
If something is still missing, clearly describe the blocker, the uncovered scenario, or the coverage conflict that has no meaningful test.
Create a new commit with the missing tests, separate from any pre-existing security fix commit produced by Pre-existing issue handling above

Output

Provide a brief markdown summary including:

reviewed PR testing recommendations
which recommendations were already covered
which tests were added or updated
whether 100% coverage for current changes was achieved, or which coverage conflict was reported instead
list of pre-existing security fix commits (if any), each with a one-line rationale, plus the URL of any follow-up issue filed for a point outside the assignment (@skills/resolve-issue/SKILL.md Deferred-item follow-up issues)
any blocker preventing full completion

Principles

Follow code review recommendations strictly
Data a finding names are copied verbatim, never re-invented
Do not duplicate existing tests
Minimum tests, maximum confidence; coverage verifies them
Use data providers where they improve readability and reduce duplication
Every test change must be verified to pass before moving on
Focus on changed code only