refactoring

어떤 스킬인가요?

Refactor existing code safely without intentionally changing behavior. Use this skill when Codex needs to clean up procedural PHP, split large files, extract helpers, reduce duplication, rename symbols, simplify control flow, improve maintainability, or prepare code for future features and tests. This applies especially to page-entry PHP files, shared helpers, and CSS in this repository when the user asks to refactor, reorganize, clean up, or make code easier to change.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Refactoring Engineer"
  short_description: "Safe structural cleanup workflow"
  default_prompt: "Use $refactoring to simplify this code without changing behavior."

# Refactoring Checklist

## Before Editing

- Identify the exact behavior that must stay the same (inputs, outputs, side effects).
- Trace includes, session checks, redirects, and query dependencies.
- Separate true duplication from similar-looking code with different rules.
- Note any global state, superglobals (`$_GET`, `$_POST`, `$_SESSION`), or shared config in scope.

## Goals (Applied Throughout)

Every change must move the code toward:

- **DRY** — eliminate repeated logic; extract once, use everywhere
- **Single Responsibility** — each function/class does one thing
- **Clarity** — names describe intent, not implementation
- **Reusability** — helpers are generic enough to reuse, specific enough to be coherent
- **Minimal surface area** — prefer one clear helper over several thin wrappers

## During Editing

- Extract shared logic into named helpers with descriptive, narrow names.
- Preserve request parameter names and expected output structure exactly.
- Keep HTML output order stable unless a layout change is explicitly in scope.
- Remove dead code, unused variables, and commented-out blocks.
- Replace magic values with named constants or config entries.
- Consolidate repeated query patterns into reusable data-access functions.
- Keep business logic out of templates/views.

## Code Quality Rules

- Functions should do one thing and be testable in isolation.
- Avoid deeply nested conditionals — use early returns to reduce indentation.
- Group related functions together; don't scatter helpers across unrelated files.
- Use consistent naming conventions (`camelCase` vs `snake_case`) — match the existing codebase.
- Avoid side effects inside helper functions (no session writes, no redirects inside utilities).

## Validation

- Run `php -l` on every changed PHP file before committing.
- Re-check entry conditions for guest, logged-in, and admin/teacher flows when relevant.
- Confirm links, forms, and redirects still point to the same targets.
- Check that shared CSS changes do not unintentionally affect unrelated pages.
- Manually test the happy path and at least one edge case per changed flow.
- Confirm no change in visible output, error behavior, or redirect destination.

---
name: refactoring
description: >
  Refactor existing code safely without intentionally changing behavior. Use
  this skill when Codex needs to clean up procedural PHP, split large files,
  extract helpers, reduce duplication, rename symbols, simplify control flow,
  improve maintainability, or prepare code for future features and tests. This
  applies especially to page-entry PHP files, shared helpers, and CSS in this
  repository when the user asks to refactor, reorganize, clean up, or make code
  easier to change.
---

# Role: Refactoring Engineer

Improve structure without changing intended behavior. Favor small, verifiable
steps over broad rewrites.

## Workflow

1. Read the touched files first and identify the current behavior, dependencies,
   and duplication.
2. State the refactoring target in one sentence before editing:
   reduce duplication, isolate responsibilities, simplify branching, or improve
   naming.
3. Keep public behavior, routes, session checks, and database interactions
   stable unless the user explicitly asks for behavior changes.
4. Make the smallest structural change that meaningfully improves the code.
5. Re-run lightweight validation after edits.

## Repository-Specific Rules

- Treat top-level `.php` files as page entry points. Keep request handling easy
  to follow.
- Prefer extracting small local helpers or shared include files over introducing
  new abstractions prematurely.
- Preserve role checks, session guards, redirects, and flash-message behavior.
- Keep `db.php` as shared setup unless there is a clear reason to change that
  boundary.
- Treat `game/` as generated export assets unless the task is explicitly about
  replacing the export.
- Preserve existing asset paths and naming patterns.

## Refactoring Priorities

- Remove duplicated markup or repeated PHP branches.
- Give repeated literals and mixed concerns better structure.
- Shorten oversized functions or request handlers by extracting cohesive blocks.
- Replace fragile condition chains with clearer control flow.
- Improve naming when the current name hides intent.
- Add brief comments only where the control flow is genuinely non-obvious.

## Guardrails

- Do not mix refactoring with unrelated feature work.
- Do not silently change SQL semantics, form field names, or redirect targets.
- Do not replace straightforward procedural PHP with heavy architecture.
- Do not move code into shared files unless at least two call sites benefit or
  the page becomes materially clearer.

## Validation

- Lint every changed PHP file with `php -l`.
- Manually inspect the affected flow boundaries: auth, form submit, redirect,
  report/export path, or game launch path.
- Use [references/refactoring-checklist.md](references/refactoring-checklist.md)
  when the change touches multiple pages or mixes PHP, HTML, and CSS.

## Output Expectations

Report:

- what was structurally improved
- what behavior was intentionally preserved
- what validation was run
- any remaining risk if the refactor could not be fully exercised