vlsit-rtl-spec-change-implementer git:20261004.09d39b0A

Immutable. This exact content never changes and is served at /api/v1/blob/b0d88ccedf251bb8.

---
name: vlsit-rtl-spec-change-implementer
description: Analyze existing RTL against an optional prior specification and a requested new feature, present a bilingual minimal-change plan for explicit user sign-off, then implement only the approved changes and report the RTL code-change percentage.
---

# RTL Specification Change Analysis and Implementation / Phân tích và triển khai thay đổi RTL theo specification

Use this skill when a user wants an existing RTL design analyzed against an earlier specification and a new feature or behavior requirement, then minimally updated after review. Work in English and Vietnamese throughout: questions, plan, approval request, final report, and explanations must be bilingual.

Dùng skill này khi người dùng muốn phân tích RTL hiện có theo specification cũ và yêu cầu tính năng/hành vi mới, sau đó cập nhật RTL ở mức tối thiểu sau khi được duyệt. Luôn làm việc bằng cả tiếng Anh và tiếng Việt: câu hỏi, kế hoạch, yêu cầu ký duyệt, báo cáo cuối và giải thích đều phải song ngữ.

## Inputs and clarification / Đầu vào và làm rõ

- A specific existing RTL source directory is mandatory. Do not infer it from the current workspace, repository root, a prior task, or a specification path. If it is missing or ambiguous, ask for the RTL directory before inspecting RTL.
- An old/original specification is optional. If supplied, use it to identify existing requirements and detect conflicts or regressions. If absent, derive the baseline behavior from RTL and clearly state that comparison against a written old specification was unavailable.
- A new specification file is optional only when the user describes the requested new behavior in the prompt or supplies that description in response to clarification. If neither is present, ask for the new specification path or ask the user to describe the requested feature/change in the same reply.
- Ask only for missing or materially ambiguous information. Bundle missing inputs into one concise bilingual question when practical. Example:
  - EN: Please provide (1) the RTL source directory (required), (2) the old specification path or “none” (optional), and (3) the new specification path, or describe the requested feature if no new spec file exists.
  - VI: Vui lòng cung cấp (1) thư mục RTL hiện có (bắt buộc), (2) đường dẫn specification cũ hoặc “không có” (tùy chọn), và (3) đường dẫn specification mới; nếu chưa có file spec mới, hãy mô tả tính năng cần bổ sung.
- If a new spec and the user's prose differ, identify the difference and ask which is authoritative before planning affected behavior.
- Clarify ambiguities that materially affect interface, timing, reset, register behavior, compatibility, or externally visible behavior. Do useful read-only analysis while awaiting answers, but do not guess these decisions.

## Workflow and approval gate / Quy trình và cổng phê duyệt

### 1. Establish the baseline / Xác lập baseline

- Inspect the supplied RTL tree and relevant local context: module hierarchy, interfaces, parameters, existing behavior, coding conventions, file lists, and existing verification instructions. Inspect old/new specifications and map each new requirement to relevant RTL modules/files.
- Separate what the source proves from interpretation. Record gaps, contradictions, conditional behavior, unresolved modules, and existing working-tree changes that could affect a clean comparison.
- Do not run tests, simulations, synthesis, or other executable checks during analysis. Do not edit RTL during this phase.
- Preserve the user's existing changes. Never treat an unrelated prior snapshot or repository output folder as the current baseline.

### 2. Prepare a detailed change plan / Lập kế hoạch thay đổi chi tiết

Before editing any RTL, prepare a bilingual review document named rtl_change_review.md. Save it to a user-specified output location; otherwise use the project root containing the supplied RTL directory when identifiable. If the location is ambiguous or not writable, ask where to save it. Do not silently overwrite an existing report; choose a numbered filename or ask.

The plan must include / Kế hoạch phải có:

1. Design and input summary: RTL root, old spec status, new spec source, selected top/modules, and analysis limits. / Tóm tắt thiết kế và đầu vào: thư mục RTL, trạng thái spec cũ, nguồn spec mới, top/module được chọn và giới hạn phân tích.
2. Requirement comparison: each new requirement, relevant old requirement or “not supplied,” current RTL behavior with source evidence, and intended behavior. / So sánh yêu cầu: từng yêu cầu mới, yêu cầu cũ liên quan hoặc “không được cung cấp,” hành vi RTL hiện tại có dẫn chứng và hành vi mong muốn.
3. Affected-module/file map: exact module, file, relevant code region, proposed change, and why it is needed. / Bản đồ module/file ảnh hưởng: module, file, vùng code, thay đổi dự kiến và lý do.
4. Design choices: present no more than three strong implementation strategies, and only when there are materially different viable options. Rank them, recommend one, and compare functional coverage, change size, interface/backward compatibility, complexity, and risk. If only one sound approach exists, present one. / Phương án: chỉ nêu tối đa ba phương án tốt khi thực sự có lựa chọn khác biệt; xếp hạng, đề xuất một phương án và so sánh độ bao phủ, phạm vi sửa, tương thích interface/ngược, độ phức tạp và rủi ro. Nếu chỉ có một cách hợp lý, trình bày một cách.
5. Minimal-change rationale: explain why each planned edit is necessary; identify related code explicitly excluded from the change. / Lý do sửa tối thiểu: giải thích vì sao cần từng thay đổi và nêu rõ code liên quan sẽ không sửa.
6. Open questions, assumptions, conflicts, and compatibility risks. / Câu hỏi còn mở, giả định, xung đột và rủi ro tương thích.
7. Proposed validation: specific existing checks that could verify the change, their commands when discoverable, and expected evidence. Do not claim a check has run. / Kiểm chứng dự kiến: các kiểm tra sẵn có, lệnh nếu xác định được và kết quả mong đợi. Không khẳng định đã chạy kiểm tra.
8. A clear approval status, such as “Awaiting user sign-off / Đang chờ người dùng ký duyệt.”

Keep the document and user-facing review bilingual. Use paired English/Vietnamese headings and translate substantive findings, not only headings. Make table rows understandable in both languages.

Then summarize the proposed plan in chat in both languages and ask the user to approve, revise, or stop. Approval must refer to the presented plan/version and exact scope. The initial request to add a feature is not approval of an unseen implementation plan.

- Until explicit approval, do not modify RTL, create patches in source files, run checks, or make unrelated project edits. Preparing and revising the review document is allowed.
- If the user requests revisions, update the plan and present the revised version for sign-off. Wait for the user's response before implementation.
- If the user stops or does not approve, make no RTL changes; leave the review document marked as not approved.
- Treat approval as limited to the listed files, behaviors, strategy, and checks. If implementation reveals a necessary change outside the approved scope, stop, update the plan, and request approval for the expanded scope before proceeding.

Approval prompt / Câu hỏi ký duyệt:
- EN: Do you approve plan version N, including the listed RTL files, proposed behavior, and validation commands? Reply APPROVE, REVISE, or STOP.
- VI: Bạn có duyệt kế hoạch phiên bản N, gồm các file RTL, hành vi dự kiến và lệnh kiểm chứng đã liệt kê không? Trả lời DUYỆT, ĐIỀU CHỈNH hoặc DỪNG.

### 3. Implement only the approved change / Chỉ triển khai thay đổi đã duyệt

- Make the smallest safe set of RTL changes that fully implements the approved behavior. Prefer existing architecture, naming, reset, handshake, register, and coding patterns. Avoid unrelated cleanup, redesign, renaming, formatting churn, or broad refactoring.
- Minimality must not compromise correctness, timing/interface contracts, reset behavior, parameterized configurations, or maintainability. If a tiny patch would be fragile or incomplete, use the smallest robust approach and explain why.
- Do not invent unspecified behavior. Follow approved decisions and assumptions. If new evidence changes the planned solution, return to the approval gate.
- Modify only approved RTL files and any explicitly approved supporting files. Do not edit either specification unless separately requested.
- Preserve the source language and comment style. Do not add bilingual comments to RTL solely to satisfy the bilingual communication requirement; keep user-facing plans and reports bilingual.

### 4. Validate and report / Kiểm chứng và báo cáo

- Run only the validation commands explicitly listed and approved in the plan or separately requested by the user. Do not add tests or claim lint, compile, simulation, synthesis, or formal success unless that exact check was run and its result inspected.
- Compare final RTL to the task-start baseline, not blindly to HEAD if the working tree was already dirty. Isolate this task's edits from pre-existing user changes.
- Update rtl_change_review.md with the final implementation report. Include requirement-to-code traceability; changed files and concise per-file summary; actual checks and results; remaining risks or unimplemented items; and a clear completion status.
- Report the RTL code-change percentage with raw counts and scope:
  - Baseline denominator: count nonblank, non-comment RTL code lines across the supplied RTL source tree before this task's edits.
  - Change numerator: task-specific nonblank, non-comment RTL lines added plus such lines deleted, measured against the captured task-start baseline. A replaced line counts once as deleted and once as added.
  - Percentage: (added RTL code lines + deleted RTL code lines) / baseline RTL code lines × 100.
  - State total baseline RTL code lines, added lines, deleted lines, changed-file list, and percentage. The ratio can exceed 100% if the change adds more code than the original design size.
  - Exclude Markdown reports, comments-only changes, blank lines, generated logs, tests, and unrelated/pre-existing edits from the numerator. The denominator covers the supplied RTL tree, not only edited files.
  - Use a captured content snapshot or equivalent diff against the task-start files if version control cannot isolate the baseline. If an exact task-specific comparison is impossible, report the percentage as unavailable and explain why; never estimate or fabricate it.
- The final report and chat response must be bilingual. Translate results, caveats, and test status, and distinguish verified outcomes from source-based reasoning.

## Final response / Phản hồi cuối

Provide the review/report file link and a concise bilingual summary of approved behavior, RTL files changed, implementation status, RTL code-change percentage with formula counts, executed checks and results, and outstanding risks.

Cung cấp liên kết tới file kế hoạch/báo cáo và phần tóm tắt song ngữ về hành vi đã duyệt, các file RTL đã sửa, tình trạng triển khai, tỷ lệ code RTL thay đổi cùng số liệu tính toán, các kiểm chứng đã chạy và kết quả, cùng rủi ro còn lại.