メニュー
This skill should be used when the user asks to "calculate code mass", "measure code complexity with APP", "compare implementations using APP", "apply Absolute Priority Premise", "use mass calculations", or during TDD refactor phases when comparing alternative implementations. Based on Micah Martin's work.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Always load this skill when working on a Quarkus project, when the quarkus-maven-plugin is present in pom.xml, or when project setup has already chosen Quarkus before the pom.xml exists yet. It provides Quarkus-specific patterns and gotchas that complement the java and maven skills.
Orchestrator role in the Unfolding Specs process. Launches the PO, forwards unsolicited Sensei guidance, handles genuine commissioner issues, and resumes the workflow through the platform-specific live task mechanism.
Always load this skill when a pom.xml file exists in the project, when creating or editing a pom.xml, or when setting up Maven project structure in a new project. It provides Maven-specific conventions for running tests, building, managing dependencies, and project structure.
This skill should be used when starting work on any project that uses tdder. It establishes interaction style, commit conventions, documentation discipline, and skill-trust principles. Invoke automatically alongside other tdder skills.
Always load this skill when writing, modifying, creating, or moving Java or Kotlin source code, or when project setup has already chosen Java/Kotlin as the implementation language.
This skill should be used when the user asks to "add a feature using TDD", "fix a bug with TDD", "do TDD", "red-green-refactor", "write a failing test first", "use test-driven development", "start TDD", "test first approach", "TDD loop", "TDD cycle", or mentions TDD workflow, baby steps, guessing game, or red-green-refactor cycles. Not applicable for pure refactoring without new tests.
| name | app |
| description | This skill should be used when the user asks to "calculate code mass", "measure code complexity with APP", "compare implementations using APP", "apply Absolute Priority Premise", "use mass calculations", or during TDD refactor phases when comparing alternative implementations. Based on Micah Martin's work. |
| version | 0.1.0 |
Objective heuristic for comparing code quality by assigning mass values to code components. Lower total mass indicates simpler code.
| Component | Mass | Examples |
|---|---|---|
| Constant | 1 | 5, "hello", true, [] |
| Binding | 1 | amount, userName, result |
| Invocation | 2 | calculate(), Math.max(a, b) |
| Conditional | 4 | if, switch, case, ?: |
| Loop | 5 | while, for, forEach, map |
| Assignment | 6 | x = 5, count++, list.add() |
Total Mass = (constants x 1) + (bindings x 1) + (invocations x 2)
+ (conditionals x 4) + (loops x 5) + (assignments x 6)
Lower mass = Better code (all else being equal).
final fields and local variables are Bindings (1), not Assignments (6)Simple Design Rule #2 trumps APP - Choose clarity over low mass. APP helps choose between equivalent clear solutions.