تشغيل أي مهارة في Manus بنقرة واحدة

refactoring

Attach this capability for behavior-preserving structural cleanup of existing code. It covers clearer structure, names, boundaries, and validation that behavior is preserved. Do not attach it as the sole capability for feature work, bug fixes, unresolved source evidence, or external research; attach requirements-clarification, investigation, public-research, implementation, or epistemic-audit as needed.

تشغيل في Manus

النجوم٠

التفرعات٠

آخر تحديث١ يونيو ٢٠٢٦ في ٠٣:٢٥

المصدر

ZenkakuHiragana

ZenkakuHiragana/my-chezmoi-config

فتح مستودع GitHub عرض مستودعات المنشئ

أمر التثبيت

تنزيل

تشغيل في Manus

مفيد لـSOC

مطوّرو البرمجياتمهن الحاسوب والرياضيات15-1252L4

SKILL.md

readonly

name

refactoring

description

Refactoring

Purpose

This capability guides behavior-preserving cleanup of existing code. Attach it to improve structure, names, boundaries, and maintainability after first understanding the current design.

When to use

the codebase structure is hard to follow
files or modules should be split, merged, or relocated
names should better reflect responsibility
duplicated logic should be consolidated
dependency direction or ownership boundaries need tightening
tests, docs, or comments need to be aligned with the refactor

When not to use

the main task is feature delivery or defect repair
the task only needs a local edit without structural impact
the request depends on external research rather than repository analysis

Refactoring evaluation criteria

Assess the change against:

behavior preservation
public API and contract stability
cohesion and coupling
responsibility clarity
naming precision
duplication reduction
complexity and readability
dependency direction
testability and change locality
removal of dead, stale, or parallel paths

Quality gates

A refactor is ready only when:

intended behavior is unchanged, or every intentional change is isolated and explained
every non-trivial diff hunk is accounted for as one of: rename, move, extraction, deletion of dead code, unchanged logic carried forward, or an explicitly intended behavior change
any newly introduced helper, API, library function, language idiom, or abstraction has its exact semantics confirmed from local usage, existing tests/docs, or an authoritative source before it replaces existing logic
touched public interfaces, schemas, configs, and entry points still line up
weak or missing coverage is backed by characterization tests or another repeatable before/after check
stale references to renamed or moved items are removed
targeted tests for affected paths pass
available static checks or linters for touched code pass
the final diff and validation checks can account for each behavior-affecting change, and any intentional behavior change is isolated and explained

Procedure

Map the current structure, call paths, and invariants.
Make a semantic inventory for the planned diff: what will be renamed, moved, extracted, deleted, or intentionally changed.
Identify the smallest coherent refactor that improves the design.
Prefer deletion, consolidation, and extraction over new abstractions.
Do not substitute existing logic with a new helper, API, library function, language idiom, or abstraction merely because it looks shorter or cleaner. If such a substitution is necessary, record the semantics evidence first; otherwise carry the existing expression forward.
Edit code, tests, docs, and prompts together when needed.
Re-read changed surfaces for stale names, duplicate paths, contradictions, and unaccounted semantic substitutions.
Validate with the most direct checks available, and include at least one before/after or characterization check when behavior preservation is not obvious from inspection.
If a behavior change is unavoidable, isolate it and treat it as a separate verified step.

المزيد من هذا المستودع

نفس المستودع

code-review

ZenkakuHiragana/my-chezmoi-config

Attach this capability when a task frame needs review of a specific diff or codebase surface for quality issues. It produces prioritized findings with severity, authority, evidence, impact, and next steps across correctness, design, tests, maintainability, security, performance, docs, and style. Do not use as the sole capability for implementing fixes, investigating observed behavior, or factual follow-up verification; attach investigation, public-research, or epistemic-audit as needed.

2026-06-010

epistemic-audit

ZenkakuHiragana/my-chezmoi-config

Attach this capability when a task frame needs non-trivial claim control, source-class selection, requirement interpretation, source synthesis, review judgment, implementation premises, or reader-facing constraints. Load it before answering when a follow-up verifies a prior claim and the answer depends on both public docs and a required local source-of-truth class, or when that local source class is known but unchecked. It produces a control-plane ledger, not final prose, and does not replace investigation or public research.

2026-06-010

implementation

ZenkakuHiragana/my-chezmoi-config

Attach this capability when a normalized requirements artifact or task contract identifies the requested repository change, target surfaces, invariants, acceptance criteria, verification method, and required checks, and files must be updated to satisfy it. It covers coherent code, documentation, configuration, prompt, or script changes. Do not use as the sole capability when required source classes, observed behavior, diagnostic evidence, or user decisions remain unresolved; attach investigation, public-research, requirements-clarification, or epistemic-audit first as needed.

2026-06-010

investigation

ZenkakuHiragana/my-chezmoi-config

Attach this capability when repository-local behavior or locally available source-of-truth evidence must be inspected before a claim, fix, or implementation is safe. This includes local upstream checkouts, generated graphs, runtime artifacts, logs, traces, authoritative paths named by AGENTS.md, domain notes, or the user, and unresolved `repo_derivable` attributes. It produces confirmed local observations, source coverage, remaining unknowns, and the next action. Do not use as the sole capability for public-only fact finding or for concrete implementation work whose facts and checks are already resolved.

2026-06-010

public-research

ZenkakuHiragana/my-chezmoi-config

Attach this capability when a task frame requires source-backed public facts, official guidance, standards, policies, APIs, upstream practices, evaluation methods, or unresolved `public_fact` attributes. It covers public evidence acquisition and citation. Do not use it as the primary or sole capability when AGENTS.md, domain notes, project rules, or the user name a local source-of-truth checkout, generated graph, runtime artifact, log, or authoritative path for the same behavior; attach `investigation` for that local evidence first, and add `epistemic-audit` when claim authority or source-class selection is non-trivial.

2026-06-010

requirements-clarification

ZenkakuHiragana/my-chezmoi-config

Attach this capability as the default requirement-normalization step for ordinary implementation-shaped requests that are not yet execution-ready. It treats the user's instruction as a stated requirement, decomposes atomic requirements, records attribute status, field grounding, inferred candidates, rejected assumptions, and remaining source or capability obligations. Do not use it for purely factual questions, pure local investigation, or pure public research with no implementation intent. Expected result: a written requirements artifact plus a next capability set.

2026-06-010

Refactoring

Purpose

This capability guides behavior-preserving cleanup of existing code. Attach it to improve structure, names, boundaries, and maintainability after first understanding the current design.

When to use

the codebase structure is hard to follow

files or modules should be split, merged, or relocated

names should better reflect responsibility

duplicated logic should be consolidated

dependency direction or ownership boundaries need tightening

tests, docs, or comments need to be aligned with the refactor

When not to use

the main task is feature delivery or defect repair

the task only needs a local edit without structural impact

the request depends on external research rather than repository analysis

Refactoring evaluation criteria

Assess the change against:

behavior preservation

public API and contract stability

cohesion and coupling

responsibility clarity

naming precision

duplication reduction

complexity and readability

dependency direction

testability and change locality

removal of dead, stale, or parallel paths

Quality gates

A refactor is ready only when:

intended behavior is unchanged, or every intentional change is isolated and explained

every non-trivial diff hunk is accounted for as one of: rename, move, extraction, deletion of dead code, unchanged logic carried forward, or an explicitly intended behavior change

any newly introduced helper, API, library function, language idiom, or abstraction has its exact semantics confirmed from local usage, existing tests/docs, or an authoritative source before it replaces existing logic

touched public interfaces, schemas, configs, and entry points still line up

weak or missing coverage is backed by characterization tests or another repeatable before/after check

stale references to renamed or moved items are removed

targeted tests for affected paths pass

available static checks or linters for touched code pass

the final diff and validation checks can account for each behavior-affecting change, and any intentional behavior change is isolated and explained

Procedure

Map the current structure, call paths, and invariants.

Make a semantic inventory for the planned diff: what will be renamed, moved, extracted, deleted, or intentionally changed.

Identify the smallest coherent refactor that improves the design.

Prefer deletion, consolidation, and extraction over new abstractions.

Do not substitute existing logic with a new helper, API, library function, language idiom, or abstraction merely because it looks shorter or cleaner. If such a substitution is necessary, record the semantics evidence first; otherwise carry the existing expression forward.

Edit code, tests, docs, and prompts together when needed.

Re-read changed surfaces for stale names, duplicate paths, contradictions, and unaccounted semantic substitutions.

Validate with the most direct checks available, and include at least one before/after or characterization check when behavior preservation is not obvious from inspection.

If a behavior change is unavoidable, isolate it and treat it as a separate verified step.