メニュー
Project stylistic refactoring rules for TypeScript/Bun. Proactively scans for refactoring opportunities and produces a prioritized plan. Defines the team's preferred coding style.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Browser recording and control via the krometrail CLI. Use when recording a browser session, driving the browser with batch actions, or investigating recorded sessions. Captures network, console, DOM, framework state, screenshots.
Krometrail MCP navigation guide. Load this skill first to understand which tool namespace to use. Covers the three tool namespaces (debug_*, chrome_*, session_*), when to use each, common pitfalls, and pointers to the detailed skill for each namespace.
Runtime debugging via the krometrail CLI. Use when a test fails and reading the code isn't enough, when you need to inspect runtime values, or when a bug is in logic you can't trace statically. Set breakpoints, step through code, inspect variables, evaluate expressions — across 10 languages.
Project structural organization rules for TypeScript/Bun. Proactively scans for organizational issues and produces a prioritized plan. Defines the team's preferred file, folder, and module structure.
Project code patterns and conventions. Auto-loads when implementing, designing, verifying, or reviewing code. Provides detailed pattern definitions with code examples.
React DevTools hook internals reference. Use when implementing or debugging React state observation — fiber tree traversal, hook linked lists, onCommitFiberRoot, state extraction, bug pattern detection.
| name | stylistic-refactor |
| description | Project stylistic refactoring rules for TypeScript/Bun. Proactively scans for refactoring opportunities and produces a prioritized plan. Defines the team's preferred coding style. |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Agent, Write |
Scan the codebase for opportunities to apply these stylistic preferences. Each style has a reference file with rationale, examples, and exceptions.
| Style | Rule (one line) | Reference |
|---|---|---|
| Early Returns | Prefer early returns and guard clauses over nested conditionals | details |
| Classes vs Functions | Classes for stateful coordinators; plain functions for pure logic | details |
| Arrow vs Declaration | Arrow functions for callbacks/inline; function declarations for named exports | details |
| Explicit Return Types | Exported functions must have explicit return type annotations | details |
| Descriptive Naming | Boolean prefixes (is/has/should/can); descriptive names over abbreviations | details |
| Function Size | Functions should stay under ~50 lines; extract when logic is a named concept | details |
| Composition over Inheritance | Flat interface implementations; no deep class hierarchies; share via helpers | details |
Write the refactoring plan to docs/stylistic-refactor-plan.md.
The document should be a prioritized refactoring plan with these sections:
Implement-ready refactors with current/target code, file paths, and acceptance criteria.
Valid refactors with moderate impact. Brief entries with file paths and rationale.
Code that technically violates a style but should NOT be refactored, with justification.
