「refactoring」の検索結果

Tech debt assessment that identifies, classifies, and prioritizes maintainability problems — helping teams build a refactoring roadmap — drawing on twelve classic engineering books. Triggers when: user asks about tech debt, refactoring priorities, what to clean up first, or asks "why is this so hard to change?", "what should we fix first?", or "how do I justify refactoring to management?". Do NOT trigger for: server health checks, HTTP /health endpoints, Kubernetes probes, database health, or application uptime — "health" in those contexts is infrastructure, not code quality. Also not for single-function refactoring questions.

日本語の概要は準備中です。原文の説明を表示しています。

Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named refactorings, and the full suite re-run after every step. Use when the user wants to refactor, restructure, clean up, simplify, or improve the design of existing code, or to apply refactoring recommendations from a code-review or architectural-analysis report. This skill changes code; it does not review code (use code-review), assess architecture (use architectural-analysis), plan a multi-module restructure before executing it (use plan-a-change), map domain boundaries before restructuring along them (use ddd-analysis), or build new behavior test-first (use tdd). Do not use it on code inside an active tdd loop; the refactor step of tdd owns that cleanup. Runs its planned sequence to completion without pausing for review; to review each named refactoring as it lands, use pairing.

日本語の概要は準備中です。原文の説明を表示しています。

대화형 System-wide Refactoring — 변경 파일에서 Extract Method·Domain Logic 이동·Pull Up 등 클래스 경계를 넘는 구조 변경 후보를 찾아 승인 후 기법별 커밋으로 적용. "구조 리팩토링", "도메인 로직 이동", "클래스 분리", "system-wide", "/system-wide-refactoring" 요청 시 사용. 단, 메서드 내부 정돈(guard clause·extract variable 등)은 /tdd-tidy가 적합. /system-wide-refactoring [commit-ref]로 호출.

日本語の概要は準備中です。原文の説明を表示しています。

Google TypeScript Style Guide reference for writing, reviewing, and refactoring TypeScript code. Use this skill whenever you are writing TypeScript code, reviewing TypeScript code, refactoring TypeScript, configuring ESLint or linter rules for TypeScript, or when the user asks about TypeScript coding conventions, naming conventions, type system best practices, or import/export patterns. Also trigger when the user mentions 'Google style', 'gts', 'TypeScript style guide', or asks 'how should I name this', 'should I use interface or type', 'how to handle null/undefined' in a TypeScript context. TypeScriptを書く・レビューする・リファクタリングする、ESLintの設定をする、「命名規則」「型の使い方」「import/exportのルール」「interfaceとtypeどっち」「anyを使っていい？」「nullチェックどうする」「Google式」「コーディング規約」「スタイルガイド」などの質問にも対応します。TypeScriptのコードに関する質問や作業であれば積極的にこのスキルを使ってください。

Apply Refactoring.Guru-inspired rules when diagnosing code smells, choosing refactoring techniques, and stopping cleanup before uncontrolled redesign.

日本語の概要は準備中です。原文の説明を表示しています。

Apply named refactoring transformations to improve code structure without changing behavior. Use when the user mentions "refactor this", "code smells", "extract method", "replace conditional", "technical debt", "move method", "inline variable", "decompose conditional", or "clean up this messy code". Also trigger when cleaning up legacy code, preparing code for new features by restructuring, or identifying which transformation fits a specific code smell. Covers smell-driven refactoring, safe transformation sequences, and testing guards. For code-quality foundations, see clean-code. For managing complexity, see software-design-philosophy.

日本語の概要は準備中です。原文の説明を表示しています。

Applies the Refactoring Priority Premise (RPP) levels L1-L6 for systematic code refactoring. Use when improving code quality through structured refactoring passes.

日本語の概要は準備中です。原文の説明を表示しています。

Progressive L1-L6 refactoring hierarchy, 22 code smell taxonomy, atomic transformations, test code smells, and Fowler refactoring catalog

日本語の概要は準備中です。原文の説明を表示しています。

Use when you need to verify Java performance optimizations by comparing profiling results before and after refactoring — including baseline validation, post-refactoring report generation, quantitative before/after metrics comparison, side-by-side flamegraph analysis, regression detection, or creating profiling-comparison-analysis and profiling-final-results documentation. This should trigger for requests such as Verify performance fix; Verify the performance; Verify the memory; Verify the threading; Compare before and after profiling results; Check for performance regressions after refactoring. Part of Plinth Toolkit

日本語の概要は準備中です。原文の説明を表示しています。

Intelligent code refactoring using IDE-level tools (rename, find-references, go-to-definition), AST-aware pattern matching, and TDD verification. Use for safe, large-scale refactoring with precision.

日本語の概要は準備中です。原文の説明を表示しています。

Update Java test classes and methods to work with new code versions after refactoring or modifications. Use when code changes break existing tests due to signature changes, refactoring, or behavior modifications. Takes old and new code versions plus old tests as input, and outputs updated tests that compile and pass against the new code. Handles method signature changes, class refactoring, assertion updates, and mock modifications.

日本語の概要は準備中です。原文の説明を表示しています。

Identify and report code smells indicating poor design or maintainability issues in Python code, including duplicate code, magic numbers, hardcoded values, God classes, feature envy, inappropriate intimacy, data clumps, primitive obsession, and long parameter lists. Use when conducting code quality audits, preparing for refactoring, improving codebase maintainability, or performing design reviews. Produces markdown reports with severity ratings, locations, descriptions, and specific refactoring recommendations with before/after examples. Triggers when users ask to find code smells, identify design issues, suggest refactorings, improve code quality, or detect maintainability problems.

日本語の概要は準備中です。原文の説明を表示しています。

Improve code quality and maintainability through systematic identification of code smells and application of proven refactoring patterns. Use when the user requests refactoring or provides relevant inputs for this workflow.

日本語の概要は準備中です。原文の説明を表示しています。

Comprehensive UI design guidance based on Refactoring UI principles covering design personality, color theory, layout strategy, visual hierarchy, typography, spacing, mobile-first responsive design, and writing copy that doesn't read like AI wrote it. Use this skill whenever the user is creating new pages, building components, making design additions or changes, reviewing UI code, asking about design decisions (colors, fonts, spacing, layout), writing or editing interface copy, or discussing visual improvements. Trigger for any design-related conversation including "how should this look", "what color", "font size", "spacing", "layout", "responsive", "mobile", "this copy", "headline", "button text", "microcopy", or when reviewing/critiquing existing interfaces.

日本語の概要は準備中です。原文の説明を表示しています。

Four-stage alchemical code transmutation — nigredo (decomposition), albedo (purification), citrinitas (illumination), rubedo (synthesis) — with meditate and heal checkpoints between stages. Transforms tangled or legacy code into optimized, well-structured output through systematic material analysis. Use when transforming legacy code into modern equivalents, refactoring deeply tangled modules where incremental fixes keep failing, converting a codebase between paradigms, or when simpler refactoring approaches have stalled and a full-cycle transformation is needed.

日本語の概要は準備中です。原文の説明を表示しています。

Measurement-driven code refactoring — profile before changing, measure after, keep only if metrics improve. Covers complexity reduction, extraction patterns, and bulk refactoring for mechanical changes across many files.

日本語の概要は準備中です。原文の説明を表示しています。

Practical UI refactoring and visual design review inspired by Refactoring UI by Steve Schoger and Adam Wathan. Use when an AI coding agent needs to improve an existing interface, audit visual polish, redesign a rough UI, review frontend code for hierarchy/spacing/typography/color/depth/image issues, or turn a plain implementation into a cleaner product-quality screen. Do not use for creating UI from scratch, scaffolding a new app, building a new landing page, or designing a new design system unless the user explicitly asks to review or refactor an existing interface.

日本語の概要は準備中です。原文の説明を表示しています。

Code refactoring strategies, technical debt reduction, architecture modernization, and code quality improvement. Use when refactoring code, modernizing legacy code, reducing complexity, or improving maintainability.

日本語の概要は準備中です。原文の説明を表示しています。

Refactoring using Remove Parameter in Java Language

日本語の概要は準備中です。原文の説明を表示しています。

Refactoring using Extract Methods in Java Language

日本語の概要は準備中です。原文の説明を表示しています。

Analyzes code diffs and files to identify bugs, security vulnerabilities (SQL injection, XSS, insecure deserialization), code smells, N+1 queries, naming issues, and architectural concerns, then produces a structured review report with prioritized, actionable feedback. Use when reviewing pull requests, conducting code quality audits, identifying refactoring opportunities, or checking for security issues. Invoke for PR reviews, code quality checks, refactoring suggestions, review code, code quality. Complements specialized skills (security-reviewer, test-master) by providing broad-scope review across correctness, performance, maintainability, and test coverage in a single pass.

日本語の概要は準備中です。原文の説明を表示しています。

Activation requires either supplied .NET coverage reports/percentages/line, branch, or condition metrics, or an explicit request to collect .NET coverage for analysis. USE FOR: interpreting that evidence, including Cobertura data, partial conditions, plateaus, target arithmetic, project-wide coverage-backed CRAP, and coverage-backed refactoring safety. Analyze supplied reports directly without rerunning tests or installing tools. DO NOT USE FOR: requests with neither coverage evidence nor explicit coverage-collection intent, including hypothetical change-survival questions (use test-gap-analysis); CRAP or refactoring safety for one named target (use crap-score); or requests owned by test-tagging, find-untested-sources, test-anti-patterns, run-tests, or code-testing.

日本語の概要は準備中です。原文の説明を表示しています。

Safely refactors C#/.NET code without changing behavior. USE FOR any request to refactor, rename, move, extract, inline, merge, consolidate, deduplicate, split, or modernize C# code, including partial/generated declarations, wrappers, public APIs, serialization/reflection/configuration names, friend assemblies, conditional compilation, and multi-targeted projects. Also use when a request calls a feature, bug fix, package/framework upgrade, or public nullability change a refactor and the behavior-changing part must be separated or declined. DO NOT USE FOR ordinary feature or bug fixes not presented as refactoring; standalone upgrades after reclassification (use dotnet-upgrade); adding tests; or formatting-only work.

日本語の概要は準備中です。原文の説明を表示しています。

Golang refactoring — safe, at-scale restructuring of existing Go code: a coverage-adaptive safety net, behavior-preserving transforms (gopls Rename/Extract, `gofmt -r`, `gopatch`), the Fowler catalog mapped to Go, breaking import cycles, and small stacked PRs. Apply when a function or type has grown too large, a code smell blocks a feature, or the user asks to refactor Go code — also for renaming at scale, extracting functions or interfaces, moving code between packages, or planning a multi-step refactor. Target styles owned elsewhere → See `samber/cc-skills-golang@golang-naming` (renames), `samber/cc-skills-golang@golang-project-layout` (splits), `samber/cc-skills-golang@golang-modernize` (idioms), `samber/cc-skills-golang@golang-code-style` (control flow), `samber/cc-skills-golang@golang-design-patterns` (patterns/DI).

日本語の概要は準備中です。原文の説明を表示しています。