TDAK1509
- 11 skills
- 0 followers
- 5 hours ago last updated
- ▌ Oversized Function · tdak1509 bundleRefactor a function that is too long by finding its real responsibility boundaries instead of extracting helpers to hit a line count. Use when a function is over ~12 lines, when a linter or reviewer flags "function too long" / "too many lines" / "oversized function", or when the user asks to split, shorten, or clean up a long function or method.
- ▌ Self Documenting Names · tdak1509 bundleWrite code that explains itself through names instead of comments. Use when adding or reviewing comments, when a comment explains what code does, when naming variables, functions, classes or files, when writing or trimming a docstring, when a hook reports a comment or an over-long name, or when the user asks to clean up comments or improve naming.
- ▌ Function Names Are Verbs · tdak1509Name every function with a verb, because a function is an action. Use when naming or renaming a function, method, hook callback or handler, when a function name is a noun such as `data`, `result`, `userValidation` or `payment`, when reviewing new code for naming, or when the user asks what to call a function.
- ▌ Clean Code Implementation · tdak1509The rules that bind every line of code you write in this codebase - verb function names, functions under the line limit, names instead of comments, helpers defined below their caller, and the wider maintainability habits. Use whenever you write, edit or review code, before you start an implementation, when a hook blocks an edit, or when you are about to open a pull request.
- ▌ Helper Functions Ordering · tdak1509 bundleDefine every helper function directly below the function that calls it, so a file reads from the whole to the parts. Use when adding a helper, when ordering or moving functions in a file, when a hook reports a helper defined above its caller, or when deciding where a new function goes.
- ▌ Code Review Do What It Claims · tdak1509Review the current branch's diff against main and check whether the changes actually do what they claim to do, and whether they overengineer the solution. Use when the user asks to review a PR, review changes, or check if a change matches its description, commit message, or ticket.
- ▌ Maintainable Coding Principles · tdak1509Seven habits for writing code that is easier to understand, change, test, debug, and trust - visible main paths, meaningful names, contained external dependencies, invalid states made unrepresentable, decisions separated from side effects, useful errors, and focused changes. Use whenever you write, edit or review code, before you start an implementation, or when the user asks how to make code more maintainable.
- ▌ Tdd · tdak1509 bundleDrives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
- ▌ Increments Plan · tdak1509Plan a task as a sequence of small, single-responsibility PRs, each one a working, testable, revertible step toward an outcome. Every PR carries an outcome list — the steps someone runs to confirm it works. Use when planning or scoping multi-step work, when a task looks too big for one PR, when the user asks for a phased or incremental plan, or when the user asks how to break work into pull requests.
- ▌ Code Review Full · tdak1509Full review of the current branch against main — runs the claim-check, the security/performance-leak review, and the clean-code check together. Use when the user asks for a full code review, a combined review, or just "review this branch" without specifying which kind.
- ▌ Code Review Leaks · tdak1509Review the current branch's diff against main for security and performance leaks — only in the changed files. Use when the user asks to review a PR, review changes, check for security issues, or check for performance regressions.