From pda
Analyzes code for readability and simplicity issues including unclear naming, complex control flow, dead code, missing or misleading comments, over-engineering, and unnecessary length. Use when performing a readability review or as part of code-review.
npx claudepluginhub spaghetti-lover/pda-plugins --plugin pdaThis skill uses the workspace's default tool permissions.
Analyze code for readability and simplicity issues that make it harder for
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.
Analyze code for readability and simplicity issues that make it harder for another engineer — or agent — to understand without the author present.
git diff for PR/branchNaming — vague identifiers (temp, data, result, x) without
context; names that lie about what a variable/function actually does;
inconsistency with surrounding project conventions; overly abbreviated or
overly verbose names
Control flow — nested ternaries, deep callback pyramids, flag variables that could be replaced with early returns, boolean logic that requires mental simulation to evaluate, switch/if-else chains that could be a lookup table
Length & concision — functions or files that do more than one thing; code that achieves in 100 lines what 20 would suffice for; duplicated logic that should be extracted; long parameter lists that should be an options object
Abstraction level — premature generalization (abstractions introduced before the third use case); leaky abstractions that force callers to know implementation details; mixed abstraction levels inside a single function
Comments & documentation — comments that merely restate the code
(i++ // increment i); missing comments on non-obvious intent, algorithmic
choices, or "why not X" decisions; stale comments that no longer match the
code; commented-out code left in place
Dead code — unused variables, parameters, imports, or exports; functions
that are defined but never called; backwards-compatibility shims with no
remaining callers; // removed / // TODO: delete annotations that were
never followed through; feature flags that are permanently enabled/disabled
Complexity & cleverness — "clever" tricks that sacrifice clarity for brevity; unnecessary use of advanced language features where a simple loop would read better; magic numbers or magic strings without named constants; deeply nested data transformations that should be broken into named steps
Consistency — deviations from the file's or project's established patterns without justification; mixed naming conventions (camelCase vs snake_case) within the same scope; inconsistent error handling styles
Per finding: Severity (REQUIRED / NIT / SUGGESTION), Confidence (HIGH / MEDIUM / LOW), Category (NAMING / CONTROL_FLOW / LENGTH / ABSTRACTION / COMMENTS / DEAD_CODE / COMPLEXITY / CONSISTENCY).
### [SEVERITY] Title
- **File**: `path:line`
- **Category**: CATEGORY
- **Confidence**: HIGH / MEDIUM / LOW
- **Description**: what the readability problem is and why it matters
- **Current code**: snippet
- **Recommendation**: clearer alternative or approach
After the per-finding list, always include a dedicated section:
## Dead Code Identified
- `symbolName` in `path:line` — reason it appears unused
- (or "None identified.")
→ Confirm with author before removing anything non-obvious.
End with an impact counts table and one of these assessments:
| Severity | Count |
|------------|-------|
| REQUIRED | X |
| SUGGESTION | X |
| NIT | X |
**Assessment**: CLEAR / NEEDS_CLEANUP / HARD_TO_FOLLOW