chengpeiquan/bassist-skills/bassist-refactor-summary

Bassist Refactor Summary

Use this skill to turn scattered refactor work into a concise, evidence-led summary that developers can trust and managers can scan.

Writing Principles

• Lead with outcomes. Put measurable results, scope, and current state before

implementation details.

• Use the frame: why -> before -> after -> benefits -> next plan.
• Keep details at system or module level. Mention technology migrations,

architecture boundaries, CI/deploy changes, or ownership changes only when they explain the result.

• Do not write a file-by-file changelog. Avoid listing exact files, PR minutiae,

or internal code edits unless the user explicitly asks.

• Match the user's language. Use Chinese when the user writes in Chinese; use

English, Japanese, German, or another language when the user uses or requests that language.

• Use a neutral, fair, and mild tone. Avoid inflated claims, personalized

credit, blame, or vague improvement words without data.

• Avoid first-, second-, and third-person personal pronouns by default, such as

"I", "we", "you", "he", "she", or "they". Use them only when the context truly requires attribution or ownership. Prefer process- and outcome-centered wording.

• If work is incomplete, say so directly and make the remaining plan concrete.

Evidence To Collect

Before drafting, gather the smallest set of evidence that can support the summary:

• Metrics: time, size, count, success rate, failure rate, coverage, number of

modules migrated, number of duplicated assets removed, or before/after version numbers.

• Scope: affected module, platform, package, CI/deploy chain, API layer, data

flow, or agent workflow.

• Before state: what was slow, scattered, duplicated, fragile, ambiguous, or

hard to maintain.

• After state: what became centralized, standardized, split by boundary,

automated, faster, smaller, safer, or easier to locate.

• Constraints: what was intentionally kept, why some assets or legacy paths

remain, and what would be risky to remove now.

• Follow-up: remaining migrations, verification, rollout, monitoring, cleanup,

or product/design decisions.

If metrics are missing, ask for them when they would change the message. If the user wants a first draft, write with explicit placeholders such as [build duration missing] rather than inventing numbers.

Output Structure

Default to this structure for a standalone record:

# <Use the title suggested by the user, or draft a concise topic-based title>
 
<State the outcome in 1-3 sentences. Prioritize data: from X to Y, reduced by Z,
improved by N times, covered M modules, or completed phase N. Add the current
state if useful.>
 
## Results
 
-<Key metric 1: before -> after -> percentage change or practical meaning>
-<Key metric 2>
-<Current completion scope or phase>
 
## Before
 
<Describe the state before takeover or refactoring. Keep the data and limited
details that explain the problem, such as pipeline duration, package size,
duplicated assets, scattered API contracts, overloaded rule entry points, or
split toolchain versions.>
 
## After
 
<Describe the new state and boundaries. List 3-7 system-level changes when
useful, such as pipeline consolidation, technology migration, centralized API
contracts, unified deployment entry points, rule decomposition, or automated
checks.>
 
## Benefits
 
<Translate the changes into benefits: faster feedback, clearer maintenance
entry points, lower collaboration cost, lower migration risk, narrower
diagnosis scope, or stronger release readiness. Tie benefits back to data when
possible.>
 
## Follow-Up Plan
 
-<Only include items that are clearly unfinished and still need optimization or
  verification>
-<Omit this section if there is no concrete follow-up plan>

For shorter review material or OKR-style output, compress to:

This phase completed the first round of <topic> refactoring. The main result is
<metric or outcome>.
 
Before the refactor, <problem and data>. After the refactor, <new boundary or
capability>. The practical benefit is <impact on engineering efficiency,
delivery, maintenance, collaboration, or risk>.
 
Next, <unfinished plan> will continue.

Section Guidance

Opening Result

Use the opening to answer "what changed and how much":

• Good: "Web CI build time dropped from 4 minutes 40 seconds to 22 seconds;

direct reruns now complete in 15 seconds."

• Good: "The ZIP package dropped from about 57.6 MB to about 51.7 MB, reducing

upload size by about 5.9 MB."

• Good: "A unified API package and Web API entry point were added; the first

phase migrated the favorites provider."

• Avoid: "Several configuration files were changed and some historical code was

cleaned up."

Before State

Describe the pain in concrete terms:

• scattered contracts, duplicated raw types, hardcoded paths
• duplicated assets or oversized output
• CI/deploy scripts missing, ambiguous, or brand-stale
• multiple toolchain versions in one project
• rules concentrated in one heavy entry file
• standards depending on memory instead of local enforcement

Include enough detail for credibility, but stop before implementation trivia.

After State

Describe the new operating model:

• which chain was narrowed or standardized
• which technology was migrated
• which boundary became the source of truth
• which compatibility or legacy behavior was intentionally preserved
• which module is done first if the migration is staged

Prefer "what this layer now owns" over "which file changed".

Benefits

Translate engineering changes into outcomes:

• faster CI feedback or deployment preparation
• smaller upload/package size
• clearer ownership and fewer reverse searches
• lower onboarding and collaboration cost
• safer staged migration with existing behavior preserved
• easier future diagnosis when a similar issue returns

Tie benefits back to the opening metrics whenever possible.

Follow-Up Plan

Only include real next steps. Good follow-ups are:

• verify mainland/international build artifacts in Jenkins
• migrate remaining providers by feature
• evaluate CDN/offline/cache/rollback strategy for large assets
• add package-size or duplicate-hash checks
• continue brand naming cleanup
• finish rollout, monitoring, or validation

Do not add generic plans like "continue improving the experience" unless paired with a concrete scope and verification method.

Quality Checklist

Before returning the summary, check:

• Does the first paragraph show the main result without needing to read details?
• Are at least one or two metrics included when data exists?
• Can a manager understand the impact without knowing the codebase?
• Can a developer identify the new module boundary or operating model?
• Does "Before" explain why the work was necessary?
• Does "After" avoid file-level bookkeeping?
• Does "Benefits" connect back to speed, size, risk, maintainability, or

delivery?

• Are unfinished items clearly separated into "Follow-Up Plan"?
• Are uncertain numbers marked as assumptions or placeholders?