knokmki612
- 6 skills
- 0 followers
- 11 hours ago last updated
- ▌ Design Review · knokmki612 bundleEvaluate a design or refactoring decision problem-first, treating design principles and patterns (SOLID, DRY, GoF patterns, etc.) as after-the-fact tools rather than goals to reach. Use when reviewing a design, judging whether to apply or invoke a principle/pattern, deciding whether code "should" be refactored, planning a refactoring (what it keeps needs the same scrutiny as what it changes), or whenever a review risks forcing code into a pattern for its own sake. Guards against pattern-fitting that drifts from the actual problem.
- ▌ Comment Pruning · knokmki612 bundlePrune comments and developer docs that no longer earn their reading cost — history narration git already records, references drifted from the code they point at, restatements of facts that tests or schemas enforce, and blocks that overload the reader. Classify every annotation (keep / rewrite / relocate / delete), reshape overloaded units to per-unit load budgets, guarantee the information survives in at least one durable place, and verify behavior is unchanged with an annotation-only diff plus the project's format/lint/test checks. Use when comments have piled up over iterations of agent or human work, when a file reads like a changelog, when docs have grown too long to read, after a multi-round change settles and before finalizing a PR, or when asked to clean up, tidy, prune, or organize comments or documentation.
- ▌ Safety Deletion · knokmki612 bundleSafely delete files or directories in a git working tree by routing deletions through `git rm` or `git clean` instead of `rm`, `rmdir`, `shred`, `unlink`, `find -delete`, or `truncate`, keeping removals recoverable via git. Use before any non-git deletion command, and when the user asks to delete, remove, drop, wipe, purge, or clean up files.
- ▌ Docs Restructuring · knokmki612 bundleRestructure developer documentation whose structure has failed — the heading tree no longer predicts content, one list mixes concepts with invariants and procedures, half a document sits under an unrelated parent, or the same fact is maintained in several places. Rebuild the document around the four reader questions (understand / not break / do / look up), give every fact exactly one canonical home with pointers elsewhere, and verify with a move map that no passage is lost and no inbound link breaks. Structure only — per-unit tightening of comments and sentences is the comment-pruning skill's job; run it after this one. Use when a README or docs set has grown past navigability, when readers can't find things they know are written down, or when asked to reorganize, restructure, or split documentation.
- ▌ Serena Semantic Search · knokmki612 bundleTrigger at the moment you are about to grep an identifier (a function/class/method/variable name) to find its definition, references, implementations, or call sites — or about to read a whole source file just to map its structure. Use Serena's language-server-backed read tools for that instead; also for compiler/LSP diagnostics. Needs the Serena MCP server. Literal-text search (strings, error messages, config keys), line-range reads, and file listing stay on the existing grep/sed/Read tools.
- ▌ Wip Commit Organization · knokmki612 bundleReorganize a messy stack of work-in-progress commits into a clean, reviewable history without ever losing the working diff. Analyze the commits a branch adds over its base, propose a reconstruction plan (order, granularity, messages), get approval, then rebuild the history and mechanically verify the final tree is byte-for-byte identical. Use after piling up commits — literal `wip` commits, `fixup`, `.`, "address review", or any ad-hoc checkpoint — when squashing, splitting, reordering, or rewording branch history, or tidying commits before opening or updating a PR.