{"owner":"ludwig-ai","repo":"ludwig","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":862,"categories":["command-prompt"],"hasMcp":false,"mcpConfig":null,"found":[".claude/commands/ludwig_review.md"],"skills":{".claude/commands/ludwig_review.md":"# Ludwig Codebase Review\n\nPerform a thorough, opinionated code review of the Ludwig codebase (or a specified subsystem if an argument is given).\n\n## Scope\n\nIf $ARGUMENTS is provided, scope the review to that subsystem or file pattern (e.g. `ludwig/features/`, `data pipeline`, `ray backend`).\nOtherwise review the entire codebase.\n\n## Review Dimensions\n\nEvaluate each area across ALL of the following axes:\n\n### Technical axes\n\n- **Code smells**: long methods, god objects, feature envy, primitive obsession, data clumps, shotgun surgery, dead code\n- **Duplication**: copy-paste logic, structural duplication, near-duplicate classes that should share a base\n- **Abstraction level**: too low (leaking internals), too high (over-engineered), mismatched levels within a single function\n- **Naming**: violate \"naming things\" rules — misleading names, abbreviations, overly generic names (`utils`, `helper`, `Manager`), names that lie about what a thing does, names that describe implementation not intent\n- **Type hints**: missing, incomplete, `Any`-abuse, wrong (e.g. `dict` where `dict[str, float]` is knowable)\n- **Docstrings**: missing on public API, wrong (describe what not why), stale (describe removed behavior)\n- **Test coverage**: untested public surface, tests that only test the happy path, tests that mock away the thing being tested, missing edge cases\n- **Performance**: unnecessary copies, redundant I/O, blocking the event loop, O(N²) in disguise, missing caching\n- **Consistency**: same concept named differently in different files, different patterns for the same operation, inconsistent error handling styles\n\n### Persona axes\n\nRate severity from each perspective and explain why it matters to that audience:\n\n- **ML Engineer** (building production pipelines): Does this cause silent failures? Surprise OOMs? Hard-to-debug errors? Bad default choices?\n- **ML Researcher** (running experiments): Is the config surface clear? Can they reproduce results? Do names match paper terminology? Is the API discoverable?\n- **Open Source Contributor** (first PR): Is the code navigable? Is there a clear pattern to follow? Are there unexplained magic constants? Is test setup obvious?\n- **Social Media ML Reader** (HN/Reddit/X): Would they call this \"spaghetti\"? Is there obvious NIH syndrome? Would they praise the architecture or cringe at it?\n\n## Output Format\n\nStructure the review as:\n\n### Executive Summary\n\n2-3 sentences on overall health and the single most important thing to fix.\n\n### Critical Issues (must fix)\n\nNumbered list. Each entry: file:line_range, what's wrong, why it matters, concrete fix.\n\n### Major Issues (should fix)\n\nSame format. Things that hurt quality but aren't blocking.\n\n### Minor Issues (nice to fix)\n\nGrouped by category (naming, type hints, docstrings, etc.).\n\n### Persona Verdicts\n\nOne paragraph per persona with their honest take.\n\n### Improvement Plan\n\nOrdered list of PRs/tasks to address everything, with rough size estimate (S/M/L/XL).\n\n## Instructions\n\n- Be specific: always cite file paths and line numbers (or ranges)\n- Be opinionated: don't hedge with \"consider maybe possibly\"\n- Don't praise things that are merely adequate\n- Distinguish between subjective style and objective bugs\n- Focus on patterns, not one-off issues — if the same problem appears in 10 files, name the pattern once and give 3 examples\n- Use the Explore subagent for broad searches, then Read for deep dives on critical files\n"},"files":{".claude/commands/ludwig_review.md":"# Ludwig Codebase Review\n\nPerform a thorough, opinionated code review of the Ludwig codebase (or a specified subsystem if an argument is given).\n\n## Scope\n\nIf $ARGUMENTS is provided, scope the review to that subsystem or file pattern (e.g. `ludwig/features/`, `data pipeline`, `ray backend`).\nOtherwise review the entire codebase.\n\n## Review Dimensions\n\nEvaluate each area across ALL of the following axes:\n\n### Technical axes\n\n- **Code smells**: long methods, god objects, feature envy, primitive obsession, data clumps, shotgun surgery, dead code\n- **Duplication**: copy-paste logic, structural duplication, near-duplicate classes that should share a base\n- **Abstraction level**: too low (leaking internals), too high (over-engineered), mismatched levels within a single function\n- **Naming**: violate \"naming things\" rules — misleading names, abbreviations, overly generic names (`utils`, `helper`, `Manager`), names that lie about what a thing does, names that describe implementation not intent\n- **Type hints**: missing, incomplete, `Any`-abuse, wrong (e.g. `dict` where `dict[str, float]` is knowable)\n- **Docstrings**: missing on public API, wrong (describe what not why), stale (describe removed behavior)\n- **Test coverage**: untested public surface, tests that only test the happy path, tests that mock away the thing being tested, missing edge cases\n- **Performance**: unnecessary copies, redundant I/O, blocking the event loop, O(N²) in disguise, missing caching\n- **Consistency**: same concept named differently in different files, different patterns for the same operation, inconsistent error handling styles\n\n### Persona axes\n\nRate severity from each perspective and explain why it matters to that audience:\n\n- **ML Engineer** (building production pipelines): Does this cause silent failures? Surprise OOMs? Hard-to-debug errors? Bad default choices?\n- **ML Researcher** (running experiments): Is the config surface clear? Can they reproduce results? Do names match paper terminology? Is the API discoverable?\n- **Open Source Contributor** (first PR): Is the code navigable? Is there a clear pattern to follow? Are there unexplained magic constants? Is test setup obvious?\n- **Social Media ML Reader** (HN/Reddit/X): Would they call this \"spaghetti\"? Is there obvious NIH syndrome? Would they praise the architecture or cringe at it?\n\n## Output Format\n\nStructure the review as:\n\n### Executive Summary\n\n2-3 sentences on overall health and the single most important thing to fix.\n\n### Critical Issues (must fix)\n\nNumbered list. Each entry: file:line_range, what's wrong, why it matters, concrete fix.\n\n### Major Issues (should fix)\n\nSame format. Things that hurt quality but aren't blocking.\n\n### Minor Issues (nice to fix)\n\nGrouped by category (naming, type hints, docstrings, etc.).\n\n### Persona Verdicts\n\nOne paragraph per persona with their honest take.\n\n### Improvement Plan\n\nOrdered list of PRs/tasks to address everything, with rough size estimate (S/M/L/XL).\n\n## Instructions\n\n- Be specific: always cite file paths and line numbers (or ranges)\n- Be opinionated: don't hedge with \"consider maybe possibly\"\n- Don't praise things that are merely adequate\n- Distinguish between subjective style and objective bugs\n- Focus on patterns, not one-off issues — if the same problem appears in 10 files, name the pattern once and give 3 examples\n- Use the Explore subagent for broad searches, then Read for deep dives on critical files\n"},"items":[{"name":"ludwig_review.md","path":".claude/commands/ludwig_review.md","rawUrl":"https://raw.githubusercontent.com/ludwig-ai/ludwig/HEAD/.claude/commands/ludwig_review.md","title":"Command: /ludwig_review","category":"command-prompt","format":"markdown","content":"# Ludwig Codebase Review\n\nPerform a thorough, opinionated code review of the Ludwig codebase (or a specified subsystem if an argument is given).\n\n## Scope\n\nIf $ARGUMENTS is provided, scope the review to that subsystem or file pattern (e.g. `ludwig/features/`, `data pipeline`, `ray backend`).\nOtherwise review the entire codebase.\n\n## Review Dimensions\n\nEvaluate each area across ALL of the following axes:\n\n### Technical axes\n\n- **Code smells**: long methods, god objects, feature envy, primitive obsession, data clumps, shotgun surgery, dead code\n- **Duplication**: copy-paste logic, structural duplication, near-duplicate classes that should share a base\n- **Abstraction level**: too low (leaking internals), too high (over-engineered), mismatched levels within a single function\n- **Naming**: violate \"naming things\" rules — misleading names, abbreviations, overly generic names (`utils`, `helper`, `Manager`), names that lie about what a thing does, names that describe implementation not intent\n- **Type hints**: missing, incomplete, `Any`-abuse, wrong (e.g. `dict` where `dict[str, float]` is knowable)\n- **Docstrings**: missing on public API, wrong (describe what not why), stale (describe removed behavior)\n- **Test coverage**: untested public surface, tests that only test the happy path, tests that mock away the thing being tested, missing edge cases\n- **Performance**: unnecessary copies, redundant I/O, blocking the event loop, O(N²) in disguise, missing caching\n- **Consistency**: same concept named differently in different files, different patterns for the same operation, inconsistent error handling styles\n\n### Persona axes\n\nRate severity from each perspective and explain why it matters to that audience:\n\n- **ML Engineer** (building production pipelines): Does this cause silent failures? Surprise OOMs? Hard-to-debug errors? Bad default choices?\n- **ML Researcher** (running experiments): Is the config surface clear? Can they reproduce results? Do names match paper terminology? Is the API discoverable?\n- **Open Source Contributor** (first PR): Is the code navigable? Is there a clear pattern to follow? Are there unexplained magic constants? Is test setup obvious?\n- **Social Media ML Reader** (HN/Reddit/X): Would they call this \"spaghetti\"? Is there obvious NIH syndrome? Would they praise the architecture or cringe at it?\n\n## Output Format\n\nStructure the review as:\n\n### Executive Summary\n\n2-3 sentences on overall health and the single most important thing to fix.\n\n### Critical Issues (must fix)\n\nNumbered list. Each entry: file:line_range, what's wrong, why it matters, concrete fix.\n\n### Major Issues (should fix)\n\nSame format. Things that hurt quality but aren't blocking.\n\n### Minor Issues (nice to fix)\n\nGrouped by category (naming, type hints, docstrings, etc.).\n\n### Persona Verdicts\n\nOne paragraph per persona with their honest take.\n\n### Improvement Plan\n\nOrdered list of PRs/tasks to address everything, with rough size estimate (S/M/L/XL).\n\n## Instructions\n\n- Be specific: always cite file paths and line numbers (or ranges)\n- Be opinionated: don't hedge with \"consider maybe possibly\"\n- Don't praise things that are merely adequate\n- Distinguish between subjective style and objective bugs\n- Focus on patterns, not one-off issues — if the same problem appears in 10 files, name the pattern once and give 3 examples\n- Use the Explore subagent for broad searches, then Read for deep dives on critical files\n","isInternal":false,"tokens":862,"sizeBytes":3453}],"systemPromptSnippet":"<agent_rules repository=\"ludwig-ai/ludwig\">\n\n<!-- Skill/Rule: Command: /ludwig_review (.claude/commands/ludwig_review.md) -->\n# Ludwig Codebase Review\n\nPerform a thorough, opinionated code review of the Ludwig codebase (or a specified subsystem if an argument is given).\n\n## Scope\n\nIf $ARGUMENTS is provided, scope the review to that subsystem or file pattern (e.g. `ludwig/features/`, `data pipeline`, `ray backend`).\nOtherwise review the entire codebase.\n\n## Review Dimensions\n\nEvaluate each area across ALL of the following axes:\n\n### Technical axes\n\n- **Code smells**: long methods, god objects, feature envy, primitive obsession, data clumps, shotgun surgery, dead code\n- **Duplication**: copy-paste logic, structural duplication, near-duplicate classes that should share a base\n- **Abstraction level**: too low (leaking internals), too high (over-engineered), mismatched levels within a single function\n- **Naming**: violate \"naming things\" rules — misleading names, abbreviations, overly generic names (`utils`, `helper`, `Manager`), names that lie about what a thing does, names that describe implementation not intent\n- **Type hints**: missing, incomplete, `Any`-abuse, wrong (e.g. `dict` where `dict[str, float]` is knowable)\n- **Docstrings**: missing on public API, wrong (describe what not why), stale (describe removed behavior)\n- **Test coverage**: untested public surface, tests that only test the happy path, tests that mock away the thing being tested, missing edge cases\n- **Performance**: unnecessary copies, redundant I/O, blocking the event loop, O(N²) in disguise, missing caching\n- **Consistency**: same concept named differently in different files, different patterns for the same operation, inconsistent error handling styles\n\n### Persona axes\n\nRate severity from each perspective and explain why it matters to that audience:\n\n- **ML Engineer** (building production pipelines): Does this cause silent failures? Surprise OOMs? Hard-to-debug errors? Bad default choices?\n- **ML Researcher** (running experiments): Is the config surface clear? Can they reproduce results? Do names match paper terminology? Is the API discoverable?\n- **Open Source Contributor** (first PR): Is the code navigable? Is there a clear pattern to follow? Are there unexplained magic constants? Is test setup obvious?\n- **Social Media ML Reader** (HN/Reddit/X): Would they call this \"spaghetti\"? Is there obvious NIH syndrome? Would they praise the architecture or cringe at it?\n\n## Output Format\n\nStructure the review as:\n\n### Executive Summary\n\n2-3 sentences on overall health and the single most important thing to fix.\n\n### Critical Issues (must fix)\n\nNumbered list. Each entry: file:line_range, what's wrong, why it matters, concrete fix.\n\n### Major Issues (should fix)\n\nSame format. Things that hurt quality but aren't blocking.\n\n### Minor Issues (nice to fix)\n\nGrouped by category (naming, type hints, docstrings, etc.).\n\n### Persona Verdicts\n\nOne paragraph per persona with their honest take.\n\n### Improvement Plan\n\nOrdered list of PRs/tasks to address everything, with rough size estimate (S/M/L/XL).\n\n## Instructions\n\n- Be specific: always cite file paths and line numbers (or ranges)\n- Be opinionated: don't hedge with \"consider maybe possibly\"\n- Don't praise things that are merely adequate\n- Distinguish between subjective style and objective bugs\n- Focus on patterns, not one-off issues — if the same problem appears in 10 files, name the pattern once and give 3 examples\n- Use the Explore subagent for broad searches, then Read for deep dives on critical files\n\n\n</agent_rules>"}