new jira ticket writing skill and details on paying attention to names

plugins/compound-engineering/commands/workflows/plan.md

@@ -465,6 +465,22 @@ end
 
 ### 6. Final Review & Submission
 
+**Naming Scrutiny (REQUIRED for any plan that introduces new interfaces):**
+
+When the plan proposes new functions, classes, variables, modules, API fields, or database columns, scrutinize every name:
+
+| # | Check | Question |
+|---|-------|----------|
+| 1 | **Caller's perspective** | Does the name describe what it does, not how? |
+| 2 | **No false qualifiers** | Does every `_with_X` / `_and_X` reflect a real choice? |
+| 3 | **Visibility matches intent** | Should private helpers be private? |
+| 4 | **Consistent convention** | Does the pattern match existing codebase conventions? |
+| 5 | **Precise, not vague** | Could this name apply to ten different things? (`data`, `manager`, `handler` = red flags) |
+| 6 | **Complete words** | No ambiguous abbreviations? |
+| 7 | **Correct part of speech** | Functions = verbs, classes = nouns, booleans = assertions? |
+
+Bad names in plans become bad names in code. Catching them here is cheaper than catching them in review.
+
 **Pre-submission Checklist:**
 
 - [ ] Title is searchable and descriptive
@@ -472,6 +488,7 @@ end
 - [ ] All template sections are complete
 - [ ] Links and references are working
 - [ ] Acceptance criteria are measurable
+- [ ] All proposed names pass the naming scrutiny checklist above
 - [ ] Add names of files in pseudo code examples and todo lists
 - [ ] Add an ERD mermaid diagram if applicable for new model changes
 

plugins/compound-engineering/commands/workflows/review.md

@@ -179,6 +179,30 @@ Complete system context map with component interactions
 - Engineering best practices
 - Technical documentation quality
 - Tooling and automation assessment
+- **Naming accuracy** (see Naming Scrutiny below)
+
+#### Naming Scrutiny (REQUIRED)
+
+Every name introduced or modified in the PR must pass these checks:
+
+| # | Check | Question |
+|---|-------|----------|
+| 1 | **Caller's perspective** | Does the name describe what it does, not how? |
+| 2 | **No false qualifiers** | Does every `_with_X` / `_and_X` reflect a real choice? |
+| 3 | **Visibility matches intent** | Are private helpers actually private? |
+| 4 | **Consistent convention** | Does the pattern match every other instance in the codebase? |
+| 5 | **Precise, not vague** | Could this name apply to ten different things? (`data`, `manager`, `handler` = red flags) |
+| 6 | **Complete words** | No ambiguous abbreviations? (`auth` = authentication or authorization?) |
+| 7 | **Correct part of speech** | Functions = verbs, classes = nouns, booleans = assertions? |
+
+**Common anti-patterns to flag:**
+- False optionality: `save_with_validation()` when validation is mandatory
+- Leaked implementation: `create_batch_with_items()` when callers just need `create_batch()`
+- Type encoding: `word_string`, `new_hash` instead of domain terms
+- Structural naming: `input`, `output`, `result` instead of what they contain
+- Doppelgangers: names differing by one letter (`useProfileQuery` vs `useProfilesQuery`)
+
+Include naming findings in the synthesized review. Flag as P2 (Important) unless the name is actively misleading about behavior (P1).
 
 #### Business Value Angle
 

plugins/compound-engineering/commands/workflows/work.md

@@ -137,14 +137,30 @@ This command takes a work document (plan, specification, or todo file) and execu
    - Follow project coding standards (see CLAUDE.md)
    - When in doubt, grep for similar implementations
 
-4. **Test Continuously**
+4. **Naming Scrutiny (Apply to every new name)**
+
+   Before committing any new function, class, variable, module, or field name:
+
+   | # | Check | Question |
+   |---|-------|----------|
+   | 1 | **Caller's perspective** | Does the name describe what it does, not how? |
+   | 2 | **No false qualifiers** | Does every `_with_X` / `_and_X` reflect a real choice? |
+   | 3 | **Visibility matches intent** | Are private helpers actually private? |
+   | 4 | **Consistent convention** | Does the pattern match every other instance in the codebase? |
+   | 5 | **Precise, not vague** | Could this name apply to ten different things? |
+   | 6 | **Complete words** | No ambiguous abbreviations? |
+   | 7 | **Correct part of speech** | Functions = verbs, classes = nouns, booleans = assertions? |
+
+   **Quick validation:** Search the codebase for the naming pattern you're using. If your convention doesn't match existing instances, align with the codebase.
+
+5. **Test Continuously**
 
    - Run relevant tests after each significant change
    - Don't wait until the end to test
    - Fix failures immediately
    - Add new tests for new functionality
 
-5. **Figma Design Sync** (if applicable)
+6. **Figma Design Sync** (if applicable)
 
    For UI work with Figma designs:
 
@@ -153,7 +169,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    - Fix visual differences identified
    - Repeat until implementation matches design
 
-6. **Track Progress**
+7. **Track Progress**
    - Keep TodoWrite updated as you complete tasks
    - Note any blockers or unexpected discoveries
    - Create new tasks if scope expands
@@ -424,6 +440,7 @@ Before creating PR, verify:
 - [ ] Tests pass (run project's test command)
 - [ ] Linting passes (use linting-agent)
 - [ ] Code follows existing patterns
+- [ ] All new names pass naming scrutiny (caller's perspective, no false qualifiers, correct visibility, consistent conventions, precise, complete words, correct part of speech)
 - [ ] Figma designs match implementation (if applicable)
 - [ ] Before/after screenshots captured and uploaded (for UI changes)
 - [ ] Commit messages follow conventional format