--- name: code-review-153f560ad9c5 description: Systematically retrieve and address PR code review comments using make pr-comments. Enforces DDD architecture, code organization principles, and quality standards. Use when handling code review feedback, refactoring based on reviewer suggestions, or addressing PR comments. --- # Code Review Workflow Skill ## Context (Input) - PR has unresolved code review comments - Need systematic approach to address feedback - Ready to implement reviewer suggestions - Need to verify DDD architecture compliance - Need to ensure code organization best practices - Need to maintain quality standards ## Task (Function) Retrieve PR comments, categorize by type, verify architecture compliance, enforce code organization principles, and implement all changes systematically while maintaining 100% quality standards. ## Execution Steps ### Step 1: Get PR Comments ```bash make pr-comments # Auto-detect from current branch make pr-comments PR=62 # Specify PR number make pr-comments FORMAT=json # JSON output ``` **Output**: All unresolved comments with file/line, author, timestamp, URL ### Step 2: Categorize Comments | Type | Identifier | Priority | Action | | ---------------------- | --------------------------- | -------- | ------------------------------------ | | Committable Suggestion | Code block, "```suggestion" | Highest | Apply immediately, commit separately | | LLM Prompt | "🤖 Prompt for AI Agents" | High | Execute prompt, implement changes | | Architecture Concern | Class naming, file location | High | Verify DDD compliance (see Step 2.1) | | Question | Ends with "?" | Medium | Answer inline or via code change | | General Feedback | Discussion, recommendation | Low | Consider and improve | #### Step 2.1: Architecture & Code Organization Verification For any code changes (suggestions, prompts, or new files), **MANDATORY** verification: **A. Code Organization Principle** (see `code-organization` skill): > **Directory X contains ONLY class type X** Verify class is in the correct directory for its type: - `Converter/` → ONLY converters (type conversion) - `Transformer/` → ONLY transformers (data transformation for DB/serialization) - `Validator/` → ONLY validators (validation logic) - `Builder/` → ONLY builders (object construction) - `Fixer/` → ONLY fixers (modify/correct data) - `Cleaner/` → ONLY cleaners (filter/clean data) - `Factory/` → ONLY factories (create complex objects) - `Resolver/` → ONLY resolvers (resolve/determine values) - `Serializer/` → ONLY serializers/normalizers **B. Class Naming Compliance** (see `implementing-ddd-architecture` skill): | Layer | Class Type | Naming Pattern | Example | | ------------------ | ------------------ | ------------------------------------ | --------------------------------- | | **Domain** | Entity | `{EntityName}.php` | `Customer.php` | | | Value Object | `{ConceptName}.php` | `Email.php`, `Money.php` | | | Domain Event | `{Entity}{PastTenseAction}.php` | `CustomerCreated.php` | | | Repository Iface | `{Entity}RepositoryInterface.php` | `CustomerRepositoryInterface.php` | | | Exception | `{SpecificError}Exception.php` | `InvalidEmailException.php` | | **Application** | Command | `{Action}{Entity}Command.php` | `CreateCustomerCommand.php` | | | Command Handler | `{Action}{Entity}Handler.php` | `CreateCustomerHandler.php` | | | Event Subscriber | `{Action}On{Event}.php` | `SendEmailOnCustomerCreated.php` | | | DTO | `{Entity}{Type}.php` | `CustomerInput.php` | | | Processor | `{Action}{Entity}Processor.php` | `CreateCustomerProcessor.php` | | | Transformer | `{From}To{To}Transformer.php` | `CustomerToArrayTransformer.php` | | **Infrastructure** | Repository | `{Technology}{Entity}Repository.php` | `MongoDBCustomerRepository.php` | | | Doctrine Type | `{ConceptName}Type.php` | `UlidType.php` | | | Bus Implementation | `{Framework}{Type}Bus.php` | `SymfonyCommandBus.php` | **Directory Location Compliance**: ``` src/{Context}/ ├── Application/ │ ├── Command/ ← Commands │ ├── CommandHandler/ ← Command Handlers │ ├── EventSubscriber/ ← Event Subscribers │ ├── DTO/ ← Data Transfer Objects │ ├── Processor/ ← API Platform Processors │ ├── Transformer/ ← Data Transformers │ └── MutationInput/ ← GraphQL Mutation Inputs ├── Domain/ │ ├── Entity/ ← Entities & Aggregates │ ├── ValueObject/ ← Value Objects │ ├── Event/ ← Domain Events │ ├── Repository/ ← Repository Interfaces │ └── Exception/ ← Domain Exceptions └── Infrastructure/ ├── Repository/ ← Repository Implementations ├── DoctrineType/ ← Custom Doctrine Types └── Bus/ ← Message Bus Implementations ``` **Verification Questions**: 1. ✅ Is the class following **"Directory X contains ONLY class type X"** principle? - Example: `UlidValidator` must be in `Validator/`, NOT in `Transformer/` or `Converter/` 2. ✅ Is the class name following the DDD naming pattern for its type? 3. ✅ Is the class in the correct directory according to its responsibility? 4. ✅ Does the class name reflect what it actually does? 5. ✅ Is the class in the correct layer (Domain/Application/Infrastructure)? 6. ✅ Does Domain layer have NO framework imports (Symfony/Doctrine/API Platform)? 7. ✅ Are variable names specific (not vague)? - ✅ `$typeConverter`, `$scalarResolver` (specific) - ❌ `$converter`, `$resolver` (too vague) 8. ✅ Are parameter names accurate (match actual types)? - ✅ `mixed $value` when accepts any type - ❌ `string $binary` when accepts mixed **C. Namespace Consistency**: Namespace **MUST** match directory structure exactly: ```php ✅ CORRECT: // File: src/Shared/Infrastructure/Validator/UlidValidator.php namespace App\Shared\Infrastructure\Validator; ❌ WRONG: // File: src/Shared/Infrastructure/Validator/UlidValidator.php namespace App\Shared\Infrastructure\Transformer; // Mismatch! ``` **D. PHP Best Practices**: - ✅ Use constructor property promotion - ✅ Inject ALL dependencies (no default instantiation) - ✅ Use `readonly` when appropriate - ✅ Use `final` for classes that shouldn't be extended - ❌ NO "Helper" or "Util" classes (code smell - extract specific responsibilities) **E. Factory Pattern (Maintainability & Flexibility)**: > **Use factories when creating typed classes with dependencies or configuration** Factories provide maintainability, flexibility, and testability for object creation: | Scenario | Direct Instantiation | Factory | | -------------------------------- | -------------------- | -------------------- | | Simple value objects | ✅ Acceptable | Optional | | Objects with config/dependencies | ❌ Avoid | ✅ Required | | Objects created in production | ❌ Avoid | ✅ Required | | Objects created in tests | ✅ Acceptable | Optional (for speed) | **Benefits of factories**: - ✅ Centralized object creation logic - ✅ Easy to inject different implementations (testing, staging, prod) - ✅ Configuration changes don't affect consumers - ✅ Single place to add validation/transformation - ✅ Enables dependency injection for complex objects **Example**: ```php // ❌ BAD: Direct instantiation with configuration public function emit(BusinessMetric $metric): void { $timestamp = (int)(microtime(true) * 1000); $payload = new EmfPayload( new EmfAwsMetadata($timestamp, new EmfCloudWatchMetricConfig(...)), new EmfDimensionValueCollection(...), new EmfMetricValueCollection(...) ); $this->logger->info($payload); } // ✅ GOOD: Factory handles complexity public function emit(BusinessMetric $metric): void { $payload = $this->payloadFactory->createFromMetric($metric); $this->logger->info($payload); } ``` **Factory naming convention**: - `{ObjectName}Factory` - creates `{ObjectName}` instances - Location: Same namespace as the object being created - Example: `EmfPayloadFactory` creates `EmfPayload` **When factories are REQUIRED** (in production code): 1. Objects with injected dependencies (timestamp providers, config, etc.) 2. Objects that require complex construction logic 3. Objects that might need different implementations per environment 4. Objects created from external input (DTOs, metrics, etc.) **When factories are OPTIONAL** (in tests): - Tests can instantiate objects directly for simplicity - Test-specific factories can be created for reusable test fixtures **F. Classes Over Arrays (Type Safety)**: > **Prefer typed classes and collections over arrays for structured data** Arrays lack type safety and self-documentation. Use concrete classes instead: | Pattern | Bad (Array) | Good (Class) | | ------------- | ----------------------------------------- | ------------------------------------------- | | Configuration | `['endpoint' => 'X', 'operation' => 'Y']` | `new EndpointOperationDimensions('X', 'Y')` | | Return data | `return ['name' => $n, 'value' => $v]` | `return new MetricData($n, $v)` | | Method params | `function emit(array $metrics)` | `function emit(MetricCollection $metrics)` | | Events data | `['type' => 'created', 'id' => $id]` | `new CustomerCreatedEvent($id)` | **Benefits of typed classes**: - ✅ IDE autocompletion and refactoring support - ✅ Static analysis catches type errors - ✅ Self-documenting code (class name describes purpose) - ✅ Encapsulation (validation in constructor) - ✅ Single Responsibility (each class has clear purpose) - ✅ Open/Closed (extend via new classes, not array key changes) **Collection Pattern**: ```php // ❌ BAD: Array of arrays $metrics = [ ['name' => 'OrdersPlaced', 'value' => 1], ['name' => 'OrderValue', 'value' => 99.99], ]; // ✅ GOOD: Typed collection of objects $metrics = new MetricCollection( new OrdersPlacedMetric(value: 1), new OrderValueMetric(value: 99.99) ); ``` **When arrays ARE acceptable**: - Simple key-value maps for serialization output (`toArray()` methods) - Framework integration points requiring arrays - Temporary internal data within a single method **Action on Violations**: 1. **Class in Wrong Directory**: ```bash # Move file to correct directory mv src/Path/WrongDir/ClassName.php src/Path/CorrectDir/ClassName.php # Update namespace in file # Update all imports across codebase grep -r "use.*WrongDir\\ClassName" src/ tests/ ``` 2. **Wrong Class Name**: - Rename class to follow naming conventions - Update all references to renamed class - Ensure name reflects actual functionality 3. **Vague Variable/Parameter Names**: ```php ❌ BEFORE: private UlidTypeConverter $converter; ✅ AFTER: private UlidTypeConverter $typeConverter; ❌ BEFORE: private CustomerUpdateScalarResolver $resolver; ✅ AFTER: private CustomerUpdateScalarResolver $scalarResolver; ``` 4. **Quality Verification**: ```bash make phpcsfixer # Fix code style make psalm # Static analysis make deptrac # Verify no layer violations make unit-tests # Run tests ``` ### Step 3: Apply Changes Systematically #### For Committable Suggestions 1. Apply code change exactly as suggested 2. Commit with reference: ```bash git commit -m "Apply review suggestion: [brief description] Ref: [comment URL]" ``` #### For LLM Prompts 1. Copy prompt from comment 2. Execute as instructed 3. Verify output meets requirements 4. Commit with reference #### For Questions 1. Determine if code change or reply needed 2. If code: implement + commit 3. If reply: respond on GitHub #### For Feedback 1. Evaluate suggestion merit 2. Implement if beneficial 3. Document reasoning if declined ### Step 4: Verify All Addressed ```bash make pr-comments # Should show zero unresolved comments ``` ### Step 5: Run Quality Checks **MANDATORY**: Run comprehensive CI checks after implementing all changes: ```bash make ci # Must output "✅ CI checks successfully passed!" ``` **If CI fails**, address issues systematically: 1. **Code Style Issues**: `make phpcsfixer` 2. **Static Analysis Errors**: `make psalm` 3. **Architecture Violations**: `make deptrac` 4. **Test Failures**: `make unit-tests` / `make integration-tests` 5. **Mutation Testing**: `make infection` (must maintain 100% MSI) 6. **Complexity Issues**: - Run `make phpmd` first to identify specific hotspots - Refactor complex methods (keep complexity < 5 per method) - Re-run `make phpinsights` **Quality Standards Protection** (see `quality-standards` skill): - **PHPInsights**: 100% quality, 93% src / 95% tests complexity, 100% architecture, 100% style - **Test Coverage**: 100% (no decrease allowed) - **Mutation Testing**: 100% MSI, 0 escaped mutants - **Cyclomatic Complexity**: < 5 per class/method **DO NOT** finish the task until `make ci` shows: `✅ CI checks successfully passed!` ## Comment Resolution Workflow ```mermaid PR Comments → Categorize → Apply by Priority → Verify → Run CI → Done ``` ## Constraints (Parameters) **NEVER**: - Skip committable suggestions - Batch unrelated changes in one commit - Ignore LLM prompts from reviewers - Commit without running `make ci` - Leave questions unanswered - Accept class names that don't follow DDD naming patterns - Place files in wrong directories (violates layer architecture) - Allow Domain layer to import framework code (Symfony/Doctrine/API Platform) - Put class in wrong type directory (e.g., Validator in Transformer/) - Use vague variable names like `$converter`, `$resolver` (be specific!) - Create "Helper" or "Util" classes (extract specific responsibilities) - Allow namespace to mismatch directory structure - Decrease quality thresholds (PHPInsights, test coverage, mutation score) - Allow cyclomatic complexity > 5 per method - Finish task before `make ci` shows success message - Use arrays for structured data when typed classes would be more appropriate - Inject cross-cutting concerns (metrics, logging) directly into command handlers - use event subscribers instead - Create complex objects directly without factories in production code (use factories for maintainability) **ALWAYS**: - Apply suggestions exactly as provided - Commit each suggestion separately with URL reference - Verify **"Directory X contains ONLY class type X"** principle - Verify architecture compliance for any new/modified classes - Check class naming follows DDD patterns (see Step 2.1) - Verify files are in correct directories according to layer AND type - Ensure namespace matches directory structure exactly - Use specific variable names (`$typeConverter`, not `$converter`) - Use accurate parameter names (match actual types) - Run `make deptrac` to ensure no layer violations - Run `make ci` after implementing changes - Address ALL quality standard violations before finishing - Maintain 100% test coverage and 100% MSI (0 escaped mutants) - Keep cyclomatic complexity < 5 per method - Mark conversations resolved after addressing - Prefer typed classes over arrays for structured data (configuration, DTOs, events) - Use collections (`MetricCollection`, `EntityCollection`) instead of arrays of objects - Add new features via new classes following Open/Closed principle (don't modify existing classes) - Use factories for creating objects with dependencies or complex construction (required in production, optional in tests) ## Format (Output) **Commit Message Template**: ``` Apply review suggestion: [concise description] [Optional: explanation if non-obvious] Ref: https://github.com/owner/repo/pull/XX#discussion_rYYYYYYY ``` **Final Verification**: ```bash ✅ make pr-comments shows 0 unresolved ✅ make ci shows "CI checks successfully passed!" ``` ## Verification Checklist - [ ] All PR comments retrieved via `make pr-comments` - [ ] Comments categorized by type (suggestion/prompt/question/feedback) - [ ] **Code Organization verified for all changes**: - [ ] **"Directory X contains ONLY class type X"** principle enforced - [ ] Converters in `Converter/`, Transformers in `Transformer/`, etc. - [ ] Class type matches directory (no mismatches) - [ ] **Architecture & DDD compliance verified**: - [ ] Class names follow DDD naming patterns - [ ] Files in correct directories according to layer - [ ] Class names reflect what they actually do - [ ] Domain layer has NO framework imports - [ ] `make deptrac` passes (0 violations) - [ ] **Naming conventions enforced**: - [ ] Variable names are specific (`$typeConverter`, not `$converter`) - [ ] Parameter names match actual types - [ ] Namespace matches directory structure - [ ] No "Helper" or "Util" classes - [ ] **PHP best practices applied**: - [ ] Constructor property promotion used - [ ] All dependencies injected (no default instantiation) - [ ] `readonly` and `final` used appropriately - [ ] **Type safety & SOLID principles enforced**: - [ ] Typed classes used instead of arrays for structured data - [ ] Collections used instead of arrays of objects - [ ] New features added via new classes (Open/Closed principle) - [ ] Cross-cutting concerns (metrics) in event subscribers, not handlers - [ ] Factories used for complex object creation (required in production, optional in tests) - [ ] Committable suggestions applied and committed separately - [ ] LLM prompts executed and implemented - [ ] Questions answered (code or reply) - [ ] General feedback evaluated and addressed - [ ] **Quality standards maintained**: - [ ] Test coverage remains 100% - [ ] Mutation testing: 100% MSI (0 escaped mutants) - [ ] PHPInsights: 100% quality, 93% src / 95% tests complexity, 100% architecture, 100% style - [ ] Cyclomatic complexity < 5 per method - [ ] `make ci` shows "✅ CI checks successfully passed!" - [ ] `make pr-comments` shows zero unresolved - [ ] All conversations marked resolved on GitHub ## Common Code Organization Issues in Reviews ### Issue 1: Class in Wrong Type Directory **Scenario**: `UlidValidator` placed in `Transformer/` directory ```bash ❌ WRONG: src/Shared/Infrastructure/Transformer/UlidValidator.php ✅ CORRECT: src/Shared/Infrastructure/Validator/UlidValidator.php ``` **Fix**: ```bash mv src/Shared/Infrastructure/Transformer/UlidValidator.php \ src/Shared/Infrastructure/Validator/UlidValidator.php # Update namespace and all imports ``` ### Issue 2: Vague Variable Names **Scenario**: Generic variable names in constructor ```php ❌ WRONG: public function __construct( private UlidTypeConverter $converter, // Converter of what? ) {} ✅ CORRECT: public function __construct( private UlidTypeConverter $typeConverter, // Specific! ) {} ``` ### Issue 3: Misleading Parameter Names **Scenario**: Parameter name doesn't match actual type ```php ❌ WRONG: public function fromBinary(mixed $binary): Ulid // Accepts mixed, not just binary ✅ CORRECT: public function fromBinary(mixed $value): Ulid // Accurate! ``` ### Issue 4: Helper/Util Classes **Scenario**: Code review flags `CustomerHelper` class ```php ❌ WRONG: class CustomerHelper { public function validateEmail() {} public function formatName() {} public function convertData() {} } ✅ CORRECT: Extract specific responsibilities - CustomerEmailValidator (Validator/) - CustomerNameFormatter (Formatter/) - CustomerDataConverter (Converter/) ``` ### Issue 5: Arrays Instead of Typed Classes **Scenario**: Method returns/accepts arrays for structured data ```php ❌ WRONG: Array for configuration/data public function emit(array $metrics): void { foreach ($metrics as $metric) { $name = $metric['name']; // No type safety $value = $metric['value']; // No IDE support } } ✅ CORRECT: Typed collection of objects public function emit(MetricCollection $metrics): void { foreach ($metrics as $metric) { $name = $metric->name(); // Type-safe $value = $metric->value(); // IDE autocomplete } } ``` ### Issue 6: Missing Factory for Complex Object Creation **Scenario**: Complex objects created directly in production code ```php ❌ WRONG: Direct instantiation with configuration final class AwsEmfBusinessMetricsEmitter { public function emit(BusinessMetric $metric): void { $timestamp = (int)(microtime(true) * 1000); $dimensionValues = []; foreach ($metric->dimensions()->toArray() as $key => $value) { $dimensionValues[] = new EmfDimensionValue($key, $value); } $payload = new EmfPayload( new EmfAwsMetadata($timestamp, new EmfCloudWatchMetricConfig(...)), new EmfDimensionValueCollection(...$dimensionValues), new EmfMetricValueCollection(new EmfMetricValue($metric->name(), $metric->value())) ); // Complex construction logic mixed with business logic } } ✅ CORRECT: Factory encapsulates complexity final class AwsEmfBusinessMetricsEmitter { public function __construct( private EmfPayloadFactory $payloadFactory // Factory injected ) {} public function emit(BusinessMetric $metric): void { $payload = $this->payloadFactory->createFromMetric($metric); // Clean separation - emitter only handles emission } } ``` **Note**: In tests, direct instantiation is acceptable for simplicity and speed. ### Issue 7: Cross-Cutting Concerns in Handlers **Scenario**: Metrics/logging injected directly into command handlers ```php ❌ WRONG: Metrics in command handler final class CreateCustomerHandler { public function __construct( private CustomerRepository $repository, private BusinessMetricsEmitterInterface $metrics // Wrong place! ) {} public function __invoke(CreateCustomerCommand $cmd): void { $customer = Customer::create(...); $this->repository->save($customer); $this->metrics->emit(new CustomersCreatedMetric()); // Violates SRP } } ✅ CORRECT: Metrics in dedicated event subscriber final class CreateCustomerHandler { public function __construct( private CustomerRepository $repository, private EventBusInterface $eventBus ) {} public function __invoke(CreateCustomerCommand $cmd): void { $customer = Customer::create(...); $this->repository->save($customer); $this->eventBus->publish(...$customer->pullDomainEvents()); // Metrics subscriber handles emission } } final class CustomerCreatedMetricsSubscriber implements DomainEventSubscriberInterface { public function __invoke(CustomerCreatedEvent $event): void { // Error handling is automatic via DomainEventMessageHandler. // Subscribers are executed in async workers - failures are logged + emit metrics. // This ensures observability never breaks the main request (AP from CAP). $this->metricsEmitter->emit($this->metricFactory->create()); } } ``` ## Related Skills - **quality-standards**: Maintains 100% code quality metrics - **code-organization**: Enforces "Directory X contains ONLY class type X" - **implementing-ddd-architecture**: DDD patterns and structure - **ci-workflow**: Comprehensive quality checks - **testing-workflow**: Test coverage and mutation testing --- Source attribution: David-Li0406 Original project: https://github.com/David-Li0406/meta-skill-evloving/blob/ca3a335628981df10c36e00cb9850df2c247ab9a/skill-flow/data/skills-refined-36k/skillsmp/code-review-115/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Mega AI Hub resource metadata Creator / publisher: David-Li0406 Original project: https://github.com/David-Li0406/meta-skill-evloving/blob/ca3a335628981df10c36e00cb9850df2c247ab9a/skill-flow/data/skills-refined-36k/skillsmp/code-review-115/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Product Management Roles: Backend Developer, DevOps / SRE, Product Manager, QA / Test Engineer, Technical Product Manager Specialties: Backend, Testing Tools: Make Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 3222d5d3470780851e9d1d90418a2c95f6d8921c2b7dc03929ff34c91cc5c09c