cg-boolean-and-naming

Audits and refactors boolean naming, enum suffixes, and nested conditionals across Go, TypeScript, and PHP codebases.

Updated May 16, 2026
One-click install
npx skills add https://github.com/alimtvnetwork/img-pdf-v2 --skill cg-boolean-and-naming-alimtvnetwork
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cg-boolean-and-naming
Source: https://github.com/alimtvnetwork/img-pdf-v2/tree/main/.agents/skills/cg-boolean-and-naming
Command: npx skills add https://github.com/alimtvnetwork/img-pdf-v2 --skill cg-boolean-and-naming-alimtvnetwork

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate inconsistent boolean naming (bare flags like stop, negative names like isNotValid, single-letter parameters like v bool), deeply nested conditionals, and non-standard enum declarations that hurt readability and maintainability. Manually auditing every file against coding guidelines is slow and error-prone. ## Core Features & Use Cases - Boolean Convention Enforcement: Detects and rewrites violations such as == true comparisons, negative identifiers (isNotValid, hasNoData), unprefixed flags (dryRun, force), and inverted empty checks (!isEmpty -> isDefined). - Conditional Flattening: Eliminates nested if blocks and compound negative chains using guard clauses, early returns, and pre-evaluated single-variable boolean checks. - Enum Standardization: Enforces the Type suffix on all enum declarations across TypeScript, Go, and PHP. - Use Case: A team maintaining a large Go monorepo runs this Skill to sweep every source file, rename SetStopOnFail(v bool) to SetStopOnFail(isStopOnFail bool), flatten nested conditionals, and validate results with the bundled linter before a single atomic commit. ## Quick Start Ask the agent to audit the repository for boolean naming violations and nested if statements, then refactor all offending files to follow the coding guidelines and commit the changes.

Frequently Asked Questions about cg-boolean-and-naming

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce boolean naming conventions across a codebase?

Run an automated audit that flags bare boolean names like `stop` or `force`, negative identifiers like `isNotValid`, and single-letter parameters like `v bool`. Each violation is rewritten to an affirmative `is*` or `has*` prefixed form such as `isStopped` or `hasHeader`.

How to refactor nested if statements into guard clauses?

Replace nested conditionals with early returns so nesting depth stays at one level or less. Split mixed-polarity conditions like `if isA && !isB` into separate guard clauses, and pre-evaluate compound boolean expressions into a single affirmative variable before the if statement.

What boolean prefixes are acceptable in clean code guidelines?

Only `is` and `has` prefixes are allowed; prefixes like `can`, `should`, `was`, `will`, and `did` are banned. Negative forms such as `isNotValid` or `hasNoData` must be inverted to affirmative names like `isValid` or `hasValue`.

Does this refactoring approach run tests or builds to verify changes?

No, test execution and build verification are explicitly banned during routine refactoring turns. Changes are validated only with targeted file-level linters such as the enum-and-boolean checker, with full verification deferred to CI/CD.

Can map lookup booleans use isDefined in Go?

No, map comma-ok lookups must use `val, isFound := map[k]` or a contextual name like `isUserExist`. The `isDefined` identifier is reserved strictly for replacing inverted empty checks such as `!isEmpty` or `!res.IsEmpty()`.