@bovinphang/frontend-craft 2.8.0 → 2.9.0

package/skills/fec-code-review/SKILL.md

@@ -5,6 +5,22 @@ description: Use when the user asks for general frontend code review, PR review,
 
 # Front-end code review
 
+## Review modes and coverage
+
+User-specified scope takes precedence over the default. Use the following three review modes:
+
+- **Change review**: only when recent changes, current edits, staged changes, a PR or a commit are explicitly requested or clearly established by the active task, review those changes and necessary context. For local changes, inspect staged and unstaged diffs and relevant untracked project files within the requested scope; a staged-only request reviews only staged changes. If there are no changes, report that there is nothing to review; do not switch to recent commits or expand scope automatically.
+- **Targeted review**: when files or directories are specified, inventory and review existing code in that scope, including unchanged code; no Git diff is required.
+- **Project review (default)**: when no scope or change context is specified, or when the entire project is requested, inventory project-owned frontend code, related tests, configuration and dependency declarations, then review in module batches, including unchanged code; no Git diff is required.
+
+Select scope before collecting diffs. A file/directory alone means full review of that scope; a path combined with an explicit change request restricts incremental review to that path. An unqualified invocation defaults to project review even if Git changes exist. At review start, state the selected mode and target scope. When automatically delegating review after edits, pass the current change scope explicitly; do not trigger project review merely because the reviewer was called.
+
+Exclude dependency directories, build outputs, caches, generated files and third-party code by default, and record exclusions. Keep the frontend responsibility boundary; this is not a backend audit. A nonexistent target or a scope with no relevant files must be reported explicitly, not replaced with another scope.
+
+Merge findings with the same root cause across batches. Report **review mode, target scope, reviewed files/modules, exclusions, unreviewed files/modules, completion status and verification commands/results**. If context or execution limits prevent completion, mark the review partial and list remaining modules; never claim complete project coverage. Reading callers for context or running project-wide lint/typecheck does not count as manual review of those files.
+
+Change reviews retain merge recommendations. Targeted and project reviews use a risk assessment (Low / Medium / High, with blocking findings), not a claim of merge readiness. Preserve severity levels, evidence requirements and report filenames. Output reports only unless repairs are explicitly requested.
+
 ## Purpose
 
 Review the front-end code quality from 8 dimensions including architecture, type safety, accessibility, style consistency, performance and testability, and output a graded review report.
@@ -128,7 +144,7 @@ When writing a code review report, load [references/report-template.md](referenc
 ## Constraints
 
 - Do not write personal style preferences as blocking issues; blocking items must have clear evidence of user impact, runtime risk, security risk, or maintenance cost.
-- Don't give conclusions when diff, file location or reproduction clues are missing.
+- Do not give findings without file locations and supporting evidence; a diff is required only for change review.
 - In-depth security, accessibility, E2E and performance issues are only screened initially; when an evidence chain is needed, they will be diverted to special skills.
 - Do not report multiple reports for the same root cause; merge them into one representative finding and list the scope of impact.
 - Format issues that are stably covered by automated tools are handed over to lint/format and are not discovered by human reviewers.
@@ -141,3 +157,6 @@ When writing a code review report, load [references/report-template.md](referenc
 - The review report is saved as `reports/code-review-YYYY-MM-DD-HHmmss.md`
 - Multi-dimensional reviews should consolidate duplicate findings and explain which special capabilities have been diverted to
 - Label uncertain items with required verification commands or supplementary context, and do not write guesses into facts
+## Refactoring Boundary
+
+A general review may flag maintainability evidence, but dedicated smell diagnosis or a behavior-preserving refactoring plan owns deeper structural analysis. Review should not silently execute structural changes; it can recommend diagnosis/planning when a finding needs systematic transformation.

package/skills/fec-code-review/references/report-template.md

@@ -6,6 +6,14 @@
 > Generation time: YYYY-MM-DD HH:mm
 > Review tool: frontend-craft
 
+> Review mode: change / targeted / project
+> Target scope: paths or PR/commit
+> Reviewed: file or module inventory
+> Exclusions: paths and reasons
+> Unreviewed: remaining files or modules (state none if complete)
+> Completion: complete / partial
+> Verification: commands, results and reasons for skipped checks
+
 ## CRITICAL / Must be modified (N items)
 - **[File:line number]** Problem description -> Suggested modifications
 
@@ -23,7 +31,9 @@
 
 ## Risk Level: Low / Medium / High
 
-**Overall Rating**: Can be merged / merged after modification / needs to be refactored
+**Conclusion**: Change review: merge recommendation; targeted/project review: Low / Medium / High risk and blocking findings
 ```
 
 After the review is completed, save the report to `reports/code-review-YYYY-MM-DD-HHmmss.md` and inform the user of the report path.
+
+Retain merge recommendations for change review; use risk assessments for targeted and project reviews. For partial reviews, conclusions apply only to reviewed scope and do not establish project-wide approval.

package/skills/fec-code-smells/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: fec-code-smells
+description: Use when diagnosing structural maintainability problems in existing frontend code before deciding how to refactor it, especially when evidence, false-positive checks, and candidate transformations are needed without editing business code.
+---
+
+# Code Smell Diagnosis
+
+## Overview
+Diagnose structural problems from concrete evidence. A smell is a prompt to investigate, not proof that code must change.
+
+## Procedure
+1. Establish the requested scope and project facts.
+2. Collect concrete structural and change-coupling evidence.
+3. Match evidence against [the smell catalog](references/smell-catalog.md).
+4. Apply [false-positive checks](references/detection-guide.md).
+5. Report confidence, impact, and candidates from [the mapping guide](references/smell-to-refactoring-map.md).
+6. If the request is diagnosis-only, do not modify business code.
+
+## Finding Contract
+Every finding states location, evidence, smell ID/name, impact, confidence (`HIGH`, `MEDIUM`, `LOW`), candidate refactorings, priority, and material false-positive considerations. `LOW` confidence is never an automatic-edit signal.
+
+## Quick Reference
+| Need | Reference |
+| --- | --- |
+| Standard 24-smell model | [Smell catalog](references/smell-catalog.md) |
+| Evidence and false positives | [Detection guide](references/detection-guide.md) |
+| Candidate refactorings | [Smell-to-refactoring map](references/smell-to-refactoring-map.md) |
+
+## Common Mistakes
+- Treating a metric threshold as proof.
+- Reporting a smell without a file/symbol and evidence.
+- Treating every loop, switch, comment, wrapper, or pipeline as defective.
+- Editing code when the user asked for diagnosis only.

package/skills/fec-code-smells/references/detection-guide.md

@@ -0,0 +1,25 @@
+# Code Smell Detection Guide
+
+## Evidence First
+Use code structure, dependency direction, ownership, repeated change patterns, and observable maintenance burden. Metrics can focus investigation but cannot prove a smell alone.
+
+## Required False-Positive Guards
+- LOC alone does not prove Long Function or Large Class.
+- One switch does not prove Repeated Switches.
+- A function/array pipeline is not automatically Message Chains.
+- Comments are not defects by themselves.
+- Immutable transfer data may legitimately remain data-only.
+- React/Vue declarative composition is not automatically Middle Man.
+- `filter().map().reduce()` pipelines are not Message Chains.
+
+## Frontend Evidence Checklist
+- Identify data ownership across props, stores, API DTOs, hooks/composables, and modules.
+- Check lifecycle semantics before labeling effects/watchers as duplication or message chains.
+- Check public component, route, event, and package contracts before recommending movement.
+- Check dynamic references: lazy imports, route registries, Storybook, i18n keys, runtime templates, and generated CSS classes.
+- Distinguish domain duplication from coincidentally similar rendering.
+
+## Confidence
+- **HIGH:** direct, repeated evidence and false positives ruled out.
+- **MEDIUM:** evidence is meaningful but history, dynamic references, or ownership is incomplete.
+- **LOW:** mostly metric/surface evidence or material uncertainty remains. Report only; do not auto-edit.