원클릭으로
phpunit-unit-test-reviewing
Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill when the user asks to write, create, draft, or validate an Architecture Decision Record for the Shopware core repository — phrases like "write an ADR", "create an architecture decision record", "draft a decision record", "validate this ADR", "check ADR quality", or when they mention "ADR", "architecture decision record", or "decision record" in a context that calls for capturing or auditing an architectural decision. Interactively creates ADRs (simple or multi-domain structure) with proper YAML front matter and guided content, and validates existing ADRs against front matter rules, required coverage, structure, writing style, and Shopware-specific patterns.
Use this skill when the user explicitly asks to generate, write, draft, or create a commit message, squash commit, commit title, or merge commit message for the Shopware core repository (shopware/shopware). Supports two modes — full commit messages (title + body) for branch commits, and squash merge titles (title-only) for trunk merges — the skill auto-detects which based on the current branch and PR target. Analyzes diffs, infers scope from Shopware's directory structure, and detects breaking changes. Do NOT activate during implementation work or when the user is still writing code; only when they are ready to capture a finished change. For commit messages in the ai-coding-tools marketplace repo itself, use the commit-message-generating skill instead.
Use this skill when the user asks to write, draft, create, or improve a PR description for a Shopware core repository PR — AND that PR targets a non-trunk feature branch (not trunk itself). Trigger phrases like "write a PR description", "draft the PR", "what should I put in the PR body". The skill detects the target branch and only activates for non-trunk targets; for trunk-targeting PRs, use pr-description-writing instead. Do NOT activate mid-implementation — only when the user is ready to describe finished changes. Produces a conventional-commit title and a narrative-prose description with topical subsections, leveraging the diff against the target branch and any related PRs in the chain.
Use this skill when the user asks to write, draft, create, or improve a PR description, is about to create a PR, or mentions "PR description", "pull request description", or "PR template" — AND that PR targets trunk in the Shopware core repository (shopware/shopware). The skill detects the target and only activates for trunk-targeting PRs; for PRs targeting a feature branch, use feature-branch-pr-writing instead. Do NOT activate mid-implementation — only when the user is ready to describe finished changes. Produces a conventional-commit title and a description following Shopware's 5-section template, leveraging the full branch diff against trunk and session context.
Use this skill when the user is completing features, deprecations, or breaking changes in the Shopware core repository that affect external developers, or when they ask to write release info, upgrade entries, release notes, release documentation, or changelog entries — phrases like "write a release info entry for my changes", "add an upgrade note", "what goes in RELEASE_INFO", "draft an UPGRADE.md entry". Drafts entries for RELEASE_INFO-6.*.md and UPGRADE-6.*.md based on the full branch diff against trunk, calibrated to the magnitude of change. Do NOT activate mid-implementation, for internal refactoring, non-critical bug fixes, or test-only changes — those do not get release entries.
Use this skill when the user just installed the chunkhound-integration plugin and needs to configure it, asks how to set up semantic code search or ChunkHound — phrases like "help me set up chunkhound", "configure semantic search", "set up code research" — or when ChunkHound MCP tools fail with config or connection errors. Walks through prerequisite checks (chunkhound CLI, embedding provider — VoyageAI or OpenAI), creates .chunkhound.json with the chosen provider, runs the initial index, and validates the MCP server connection.
| name | phpunit-unit-test-reviewing |
| version | 4.2.2 |
| description | Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent. |
| user-invocable | false |
| allowed-tools | Glob, Grep, Read, mcp__plugin_test-writing_test-rules__get_rules |
Review a Shopware PHPUnit unit test for compliance with testing guidelines and best practices.
Review the test against Shopware testing conventions group by group: convention → design → unit → isolation → provider.
Category-aware: Scope rules to the detected category (A: DTO, B: Service, C: Flow/Event, D: DAL, E: Exception).
Scope-aware: When method names are provided, report only violations within those methods. Still read class-level context (imports, #[CoversClass], base class) for understanding, but ignore findings outside the scoped methods.
Output: Structured report with code snippets and suggested fixes per references/output-format.md.
{test_path} (required) — Path to the test file{methods} (optional) — List of test method names to scope the review to. When omitted, the full class is reviewed.{review_unit} (optional) — method, class-structure, class-bodies, or a list of these. When set, only rules whose minimal evaluation unit matches load. When omitted, all rules load. Orthogonal to {methods}: both may be set (e.g. methods=[...] + review_unit=method).{digest} (optional) — a pre-extracted, body-free structural digest of the test class. When set, review this text and skip reading the test file. Forces class-structure rules only. See Digest Mode.{rules} (optional) — the pre-rendered rule catalog as text, provided in your prompt. When set, enter Inline-Rules Mode: select rules from this text instead of calling get_rules. When omitted, rules load via get_rules. See Inline-Rules Mode.If {digest} is set, skip this phase and follow Digest Mode below instead.
Glob("tests/unit/**/*Test.php"))tests/unit/ directory (abort if tests/integration/)TestCase or appropriate base class#[CoversClass]) — needed by rules that analyze test-to-code-path coverage{methods} provided: verify each named method exists in the test class. If a method is not found, report it as a warning and continue with the remaining methods. If no methods match, abort with reason "No matching methods found."All mcp__plugin_test-writing_test-rules__get_rules calls in Phases 3-7 include these shared filters: test_type=unit, test_category={detected_category}, scoped_review={true if methods provided, omit otherwise}.
When {review_unit} is set, also add review_unit={value} to every call. The review_unit filter is single-valued per call: for a list (e.g. the fused whole-class track [class-structure, class-bodies]), issue one get_rules call per value and union the results within each group. When {review_unit} is omitted, leave the filter off (all rules load).
When {methods} is provided, apply this constraint to ALL rule detection in Phases 3-7:
#[DataProvider] attributes on scoped methods)When {digest} is set, the supplied text is the only artifact under review:
Read the test file or the source class. Detect nothing from disk; the digest is body-free (class declaration, #[CoversClass], member order, method signatures, attribute lines, property declarations) and self-contained for class-structure rules.review_unit=class-structure. In Phases 3-7, call get_rules(group={group}, review_unit=class-structure) with NO test_category and NO scoped_review. Apply whatever rules the filter returns — class-structure rules are category-agnostic, and groups with none return nothing. When {rules} is also set, instead select the class-structure rules from the inline text per Inline-Rules Mode (group match + Review unit == class-structure, no category and no scoped filter).location as a member name or attribute from the digest (line numbers are unavailable without the file body).{methods} and {review_unit} inputs are subsumed: the digest defines the scope and the unit.When {rules} is set, the catalog is provided as text in your prompt: select rules from that text instead of calling get_rules in Phases 3-7. Each rule in the text is a metadata header — # {id} — {title}, then Group: … | Enforce: …, then Test types: … | Categories: … | Scope: … | Review unit: … | Scoped review: … — followed by the rule body. Per phase, select a rule when ALL hold:
Group equals the current phase's group, andCategories CSV, and{review_unit} is set: its Review unit equals that value (for a list, take the union over the values), and{methods} is set (scoped review): its Scoped review is not exclude.Apply each selected rule's detection algorithm exactly as in Phases 3-7. While {rules} is set, the inline text is the complete rule set: NEVER read, open, search, or locate a rule file by any means — no Read/Grep/Glob, no get_rules — not to resolve a rule ID, fetch a detection algorithm, or check for missing content. (Reading the test file and its source class is unaffected — that is required.) When {rules} is omitted, rules load via get_rules with the Phase 2 filters.
For each group in the table below (in phase order), execute:
{rules} is set, select them from the inline text per Inline-Rules Mode; otherwise call mcp__plugin_test-writing_test-rules__get_rules(group={group}) with the Phase 2 filters.| Phase | Group | Covers | + Source class |
|---|---|---|---|
| 3 | convention | Naming, attributes, TestDox, assertions, class structure, method ordering | |
| 4 | design | Conditionals, single behavior, test redundancy, data provider usage, coverage distribution | ✓ |
| 5 | unit | Behavior vs implementation focus, mocking strategy, call-count coupling | ✓ |
| 6 | isolation | FIRST principles (Independent, Repeatable), shared state, fixtures, feature flags | |
| 7 | provider | Data provider key quality, naming, yield patterns, TestDox parameters |
For output format and examples, see references/output-format.md.
Report each issue using the rule's ID and title from mcp__plugin_test-writing_test-rules__get_rules:
### [{rule_id}] {title}
Include for each issue:
Include full passed checks list.
scope:
mode: scoped | full
methods: [method1, method2] # only when mode=scoped
errors:
- rule_id: {from mcp__plugin_test-writing_test-rules__get_rules response}
title: {from mcp__plugin_test-writing_test-rules__get_rules response}
enforce: must-fix
location: ClassTest.php:45
current: |
# problematic code
suggested: |
# fixed code
warnings:
- rule_id: {from mcp__plugin_test-writing_test-rules__get_rules response}
title: {from mcp__plugin_test-writing_test-rules__get_rules response}
enforce: should-fix
location: ClassTest.php:78
current: |
# code
suggested: |
# improved code
When test characteristics match multiple categories:
#[CoversClass]expectException presentWhen a test class contains both unit and integration patterns:
If mcp__plugin_test-writing_test-rules__get_rules is unavailable:
| Status | Condition |
|---|---|
| PASS | 0 errors, 0 warnings |
| NEEDS_ATTENTION | 0 errors, 1+ warnings |
| ISSUES_FOUND | 1+ errors |
For complete report structure and templates, see references/output-format.md.
The team review decomposes large files into per-track reviews. Each track also receives {rules} (the pre-rendered catalog text in its prompt), so rule loading is Inline-Rules Mode selection rather than get_rules. Each track sets the inputs below:
test_path=…ProductServiceTest.php, methods=[testCreates, testThrows], review_unit=method. The selection predicate becomes …, scoped_review=true, review_unit=method; only method rules are selected and only the named methods are judged.test_path=…, review_unit=[class-structure, class-bodies], plus methods=[…] when the review is scoped (omit for a full-class review). Reads full bodies; selects, per group, the class-structure and class-bodies rules from the inline text and unions them (one selection per review_unit value).digest="<class shape text>", no test_path read. Per Digest Mode: select the class-structure rules from the inline text across groups and judge them against the digest text alone.