เพิ่มประสิทธิภาพ Claude Fable5 ให้สูงสุดก่อนวันที่ 7 กรกฎาคม: งานสำคัญและ 2 พรอมต์จากผู้เชี่ยวชาญ

1Please inventory the skill group under .claude/skills/ and improve them from both defensive and offensive perspectives.
2
3## Purpose
4A skill is a "reproduction device for methods that worked in the past." Do two things:
5- Defense: Eliminate room for interpretation and outdated info so it works with the same quality regardless of the model or date.
6- Offense: Extract successful patterns from actual deliverables and feed them back into the skill to increase reproducibility.
7
8## Preparation
9- If the skills directory is under git, commit before working; if not, make a backup copy.
10- Location of usage history: [Path to work logs, deliverables, or products. If none, write "None" (Offense will be reduced)]
11
12## Defense: Diagnose all skills based on 6 items
13First, create a list (Skill Name / 1-line Role / Last Updated / Line Count). For each skill:
14- Triggering: Can the situation to use/not use be determined by the description alone? Are there overlapping trigger conditions with other skills?
15- Reproducibility: Are there instructions that change results based on the executor's interpretation (e.g., "appropriately," "nicely")? Are judgment criteria and default values written?
16- Examples: Is there at least one good and one bad example? (Examples define behavior most strongly)
17- Completion Criteria: Is what constitutes a pass written in an observable way?
18- Freshness: Do referenced paths, tools, and premises still exist? (Verify paths actually exist)
19- Structure: Is the main body bloated? Are details separated into reference files?
20
21## Offense: Strengthening from results
221. Feedback: Look for actual deliverables of each skill that were adopted, published, or passed without correction. If superior to existing examples in the skill, incorporate them as good examples. Conversely, extract NG examples and prohibited rules from corrected or rejected deliverables.
232. Discovery of Omissions: Look for work patterns repeated in logs but not yet turned into skills, and suggest them as new skill candidates (with trigger conditions, procedures, and completion criteria drafts).
24
25## Handling Changes
26- Implement directly: Objective corrections (dead paths, contradictions, factual errors) and additions that can be sourced from results. Always write the source for additions.
27- Proposals only: Things that change the skill's purpose, judgment criteria, or scope, or improvement ideas without a source. Provide options and recommendations for each proposal.
28
29## Completion Check
30For each modified skill, trace the procedure from the beginning as if you were an AI seeing it for the first time, and complete only after confirming no confusing parts remain.
31
32## Report
33- Diagnostic list (Severity: High/Medium/Low. Write "No issues" for skills with no problems)
34- Full diff of corrections (Offensive additions with sources)
35- List of new skill candidates and proposals requiring intention confirmation
36- How to revert

1Please create a refactoring plan for [Project Path].
2This time, plan only. Do not change a single character of code.
3Since execution will be left to another AI, the success condition is: "The executor, given only this plan and the code, can complete the work safely and without hesitation."
4
5## Process
61. Read the entire code and create a structural map (roles of major files and dependencies).
72. Identify problems (duplication / giant functions / mixed responsibilities / dead code / inconsistent naming / error handling holes / scattered hardcoded values).
83. Prioritize by Effect x Risk and break down into work items.
94. Trace the completed plan from the beginning in execution order, verify that changes in previous items do not break premises for later items, and then submit.
10
11## Plan Structure
121. Current Understanding: What this code achieves and how (serves as context sharing for the executor).
132. Building a Safety Net (Execute first as Item 0):
14   - Pre-work commit procedure.
15   - Baseline verification method. If there are no tests, write "which behavior, with what input and expected output to fix" as characterization test specs at a granularity the executor can turn directly into test code.
163. Work Item List (Execution Order). Each item must include:
17   - ID / Target location (File path: line range)
18   - What the problem is (1-2 lines)
19   - How to change it (Specifically. For parts involving judgment, include code sketches before and after).
20   - Completion criteria (Command to run and expected result. For tests, include the target test name).
21   - Risk and how to revert if it fails.
22   - Dependency: ID of items that must be completed first.
234. "What Not to Do" List (Prohibit in advance things the executor might do out of goodwill, such as adding features, changing specs, or updating dependency libraries).
245. Instructions for the Executor (A format that can be copy-pasted when handing over the plan. Include "Execute one item at a time, commit after each item, and stop and report if completion criteria are not met").
25
26## Quality Standards
27- The executor has no context other than this plan and the code. Write down all premises in your head.
28- Split into granularity where 1 item = 1 commit and completion can be verified independently.
29- Do not leave expressions requiring the executor's interpretation, such as "organize XX," in work items.