--- name: cupid-code-review-8c702ffd73ea description: Use when reviewing or refactoring code and wanting a structured lens beyond SOLID — applies Daniel Terhorst-North's CUPID properties to surface improvement opportunities in any codebase or language. --- # CUPID as a Code Review and Refactoring Lens ## Overview CUPID is a set of five properties — **C**omposable, **U**nix philosophy, **P**redictable, **I**diomatic, **D**omain-based — described by Daniel Terhorst-North as things good code *tends toward*, not rules it must comply with. That makes them ideal review lenses: you are asking "how strongly does this code exhibit this property?" and "what would moving it further in this direction look like?" Use them as questions, not verdicts. --- ## The Five Lenses ### C — Composable: plays well with others Code is composable when it can be combined with other code in many contexts without modification. **Review questions:** - Can I use this function/module independently, without pulling in unrelated state? - Is the API surface the minimum needed — no accidental exposure? - Are dependencies explicit (passed in) rather than implicit (global/ambient)? - Does it work at multiple call sites, or does it secretly assume one? **Refactoring signals:** - Many parameters that describe context rather than the operation itself - Functions that only make sense when called in a specific order - Hidden global state or singleton dependencies - "God object" arguments that carry everything **Move toward:** Smaller surface area. Dependencies injected. Works in isolation. --- ### U — Unix philosophy: does one thing well Not just single responsibility — the function does its one thing *completely* and *well*, with a clear, nameable purpose. **Review questions:** - Can I describe what this does in one short sentence without using "and"? - Does the name match what it actually does? - Are there multiple abstraction levels mixed together (orchestration alongside detail)? - Would splitting it make each part simpler or just create indirection? **Refactoring signals:** - "and" or "or" in function/method names - Functions that both compute *and* persist *and* notify - Comments that describe sections within a function (each section wants to be a function) - Length as a proxy: long functions often do several things **Move toward:** One clear responsibility. Name that earns no qualification. Flat abstraction level. --- ### P — Predictable: does what you expect Given its name and context, the code behaves consistently, without surprises. Deterministic where possible. Fails loudly rather than silently. **Review questions:** - Given only the name, would a reader expect the observed behaviour? - Are there hidden side effects beyond what the signature suggests? - Does it behave the same way every time with the same inputs? - Does it fail loudly (exception/error) or silently (returns null/zero/empty)? **Refactoring signals:** - Boolean parameters that change behaviour significantly (boolean trap) - Functions that mutate their arguments - Swallowed exceptions or silent fallbacks - Different return types depending on a flag - Names that understate what the function does ("get" that also writes) **Move toward:** Behaviour matches name. Side effects visible in signature. Loud failure. --- ### I — Idiomatic: feels natural Code that fits its language, ecosystem, and team conventions. A reader familiar with the context should not be surprised by the patterns used. **Review questions:** - Would a developer new to this codebase (but experienced in this language) find this familiar? - Are language features used as intended, not fought against? - Does it follow the team/project conventions established elsewhere? - Is anything reimplementing something the standard library provides? **Refactoring signals:** - Manual iteration where a higher-order function is conventional - Reimplementing collection operations, parsing, or formatting from scratch - Patterns that need a comment to explain why they exist - Inconsistent style compared to surrounding code **Move toward:** Follows the grain of the language. Uses established patterns. No surprises for the familiar reader. --- ### D — Domain-based: the solution domain models the problem domain The code uses the language of the business or problem domain. Names come from the domain, not from technical implementation details. **Review questions:** - Do the names in this code appear in conversations with domain experts? - Could a domain expert (non-programmer) read the high-level logic and recognise what it describes? - Are there technical names where domain names exist (e.g. `dataList` vs `invoices`)? - Does the structure of the code mirror the structure of the domain? **Refactoring signals:** - Generic names: `data`, `item`, `manager`, `handler`, `util`, `helper` - Technical names for business concepts: `UserRecord` instead of `Customer` - Domain logic buried inside infrastructure or UI code - No shared vocabulary between code and domain conversations (missing ubiquitous language) **Move toward:** Names from the domain. Structure that reflects domain relationships. Code a domain expert could navigate. --- ## Quick Reference | Property | Core question | Primary smell | | --------- | ------------- | ------------- | | Composable | Can I use this anywhere without baggage? | Hidden dependencies, large surface area | | Unix | Does it do one thing, completely? | "and" in name, mixed abstraction levels | | Predictable | Does it behave as its name suggests? | Hidden side effects, silent failure | | Idiomatic | Does it feel natural here? | Reinventing the wheel, inconsistent patterns | | Domain-based | Does it speak the domain's language? | Generic or technical names for business concepts | --- ## Using CUPID as a Review Lens Work through each property in turn for the code under review. For each one: 1. Ask the review questions above 2. Note which properties are weakly exhibited 3. Describe a concrete change that would move toward the property Avoid framing as pass/fail. The goal is: "this code is more Predictable than Composable — what would make it more Composable?" ## Using CUPID as a Refactoring Guide When deciding where to start refactoring: 1. Score each property loosely (strong / weak / absent) for the target code 2. Prioritise the weakest property that, if improved, would make the others easier 3. Domain-based often unlocks everything else: when names are right, the right structure becomes obvious 4. Composable refactoring tends to have the highest leverage — isolated code is testable, movable, reusable --- ## Common Mistakes - **Treating CUPID as a checklist** — these are properties to aspire toward, not boxes to tick. A function can be partially Predictable. - **Conflating Unix with small** — a function can be small and still do two things. The question is clarity of purpose, not line count. - **Skipping Domain-based** — it feels soft but it is often the most impactful lens. Code that speaks the domain language is self-documenting and easier to reason about. - **Applying all five at once** — pick the one or two properties that are most weakly exhibited and focus there. Trying to improve all five simultaneously leads to over-engineering. --- ## Optional: README Status Addendum After completing a CUPID assessment, offer to add or update a **CUPID Status** section in the project's README. Do not add it automatically — offer it and let the user decide. ### When to offer - After completing a full five-property assessment - After a significant refactoring pass guided by CUPID lenses - When the user asks to document the code quality state ### Badge Add a shields.io static badge to the project's badge row (alongside CI and language badges) that links to the `#cupid-status` section. Update the date whenever the assessment is refreshed: ```markdown [![CUPID Status](https://img.shields.io/badge/CUPID-assessed_YYYY--MM--DD-DAA520?style=flat-square)](README.md#cupid-status) ``` The goldenrod colour (`DAA520`) is intentional — it matches the CUPID five-star rating aesthetic and is visually distinct from the green CI badges. The badge links directly to the status table in the same README. ### GitHub label If the project has a GitHub repository, ensure a `CUPID assessed` label exists for tagging PRs that include a CUPID review. Create it once with: ```bash gh label create "CUPID assessed" --color "DAA520" --description "PR includes a CUPID code quality assessment" --repo / ``` Apply the label when opening a PR that includes a full CUPID review or a targeted CUPID-guided refactoring. ### Standard format Add a `## CUPID Status` section (or update it if already present) using this template: ```markdown ## CUPID Status Last assessed: YYYY-MM-DD | Property | Strength | Top opportunity | | --------- | -------- | --------------- | | Composable | ★★★★☆ | Brief description | | Unix philosophy | ★★★☆☆ | Brief description | | Predictable | ★★★★★ | — | | Idiomatic | ★★★☆☆ | Brief description | | Domain-based | ★★★★☆ | Brief description | ``` **Strength ratings:** use ★ symbols on a 1–5 scale. A `—` in the opportunity column means no meaningful opportunity was identified. **Top opportunity:** one sentence describing the single most impactful change for that property. Keep it specific enough to be actionable, not a restatement of the property definition. ### Placement in the README Insert the section after any existing badges, overview, or quick-start content, and before detailed technical documentation. It should be easy to find at a glance — near the top, not buried at the bottom. The badge belongs in the badge row at the very top of the README, after language/CI badges. ### Workflow If the project uses a branch/PR workflow (e.g. a CLAUDE.md that requires working on branches), follow that workflow to add the addendum: create a branch, make the change, open a PR. Do not commit directly to main if the project convention says otherwise. --- Source attribution: Habitat-Thinking Original project: https://github.com/Habitat-Thinking/ai-literacy-superpowers/blob/a50b8136e8e170a828b7a61aa3e8815475b56bc9/ai-literacy-superpowers/skills/cupid-code-review/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 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, as defined by Sections 1 through 9 of this document, any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works of the Work, that is intentionally submitted to the 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 designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any Legal Entity on behalf of whom a Contribution has been received by the 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 the combined work 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 any Contribution embodied 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, You must include a readable copy of the attribution notices contained within such NOTICE file, 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 in addition 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 license statement for Your modifications and may provide additional grant of rights to use, reproduce, modify, and distribute Your modifications, or for such Derivative Works as a whole, under terms and conditions that You define, 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 reproducing 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 exemplary 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 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 charge 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 in use. It is also recommended that a file or directory "NOTICE" is included with your work that provides attribution notices that are separate from the LICENSE file. Copyright 2026 Russ Miles 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: Habitat-Thinking Original project: https://github.com/Habitat-Thinking/ai-literacy-superpowers/blob/a50b8136e8e170a828b7a61aa3e8815475b56bc9/ai-literacy-superpowers/skills/cupid-code-review/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Product Management Roles: Backend Developer, Full-Stack Developer, Product Manager, QA / Test Engineer, Technical Product Manager Specialties: Backend Tools: Tool not specified Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 08931ea2fdc66bc1a9b028d279373110f9c72dac3d78db89b0b2ba559e076852