Automatic Critical Standard Verification (Check Standards)

This skill can be triggered independently and does not rely on the ai-dev-workflow full process: Whether you follow the complete spec process or directly "write an interface/modify a section of code", as long as Java code is produced, you should load this skill for bottom-up self-check at the end.

Mode Judgment and Verification Basis (Must Read Before Execution, Judge Mode First Then Verify)

docs/<Module>V<Version>-<Timestamp>/2.1-Project Constraints.md

docs/0.5-Existing Code Scan.md

2.1-Project Constraints-Existing Adaptation.md

Step 0: Correct Intermediate Product Naming and Paths (Must Do Before Verification, Prevent Missing Scans/Broken Acceptance References)

docs/*/3.*.1-Technical Solution*.md

3.*.2-Interface List*.md

.1

T02-01

Target Naming Rules (Consistent with ai-dev-workflow "Unified Product Naming Rules", Single Source of Truth)

3.<Function Item Serial Number>.1-<Function Name>-Technical Solution.md

3.1-Service Product Classification and BANNER-Technical Solution.md

3.1.1-…

.1

3.6-T02-01-Frontend Product List and Details-Technical Solution.md

3.6.1-…

.1

3.<Function Item Serial Number>.2-<Function Name>-Interface List (Universal for Frontend and Backend).md

3.6.2-T02-01-Frontend Product List and Details-Interface List (Universal for Frontend and Backend).md

3.6.2-…

4.1.<Function Item Serial Number>-<Function Name>-Task Breakdown.md

4.1-Frontend Product List and Details-Task Breakdown.md

4.1.6-…

src/test/java/.../Test<Function Name>.java

5.2.<Function Item Serial Number>-<Function Name>-Standard Verification Report.md

5.2-T02-01-Frontend Product List and Details-Standard Verification Report.md

5.2.6-…

3.6.x-Frontend Product List and Details-…

5.3.<Function Item Serial Number>-<Function Name>-Acceptance Report.md

5.3-T02-01-Frontend Product List and Details-Acceptance Report.md

5.3.6-…

How to derive function item serial number: Take the serial number from the technical solution file name of the same function name (

3.<Serial Number>.1-<Function Name>-Technical Solution.md

); If there is no technical solution → Read the function item # column in

1.1-Function List.md

; If still unable to determine → Stop and ask the user, prohibit guessing.

Execution Steps

1. Scan:

   ls docs/

   (module directory) +

   find docs -name "*.md"

   to list all intermediate products, and check file names and paths against the above table one by one
2. Judge non-compliance: ① Technical Solution missing

   .1

   (

   3.1-…

   ); ② File name with task ID prefix (

   T0\d+-

   /

   T02-01

   , etc.); ③ 5.2/5.3 reports missing function serial numbers (

   5.2-…

   /

   5.3-…

   ); ④ Path not under

   docs/<Module Name>V<Version Number>-<YYYYMMDDHHMMSS>/

   (scattered in docs root directory / other directories)
3. List correction list (

   Old Path → New Path

   + reason) → Confirm with the user first (The principle that this skill does not modify files also applies: only take action after confirmation)
4. Correct: Use

   mv

   (or

   git mv

   to retain history in git repositories) to move to the correct directory + rename files; Update references: If other md files (constraints/solutions/acceptance reports) reference the old file name → Update references synchronously
5. Record the correction result in the "Product Correction Record" section of the verification report (Old→New + reason) for reference in 5.3 acceptance review

[!NOTE] Correction Scope Boundary Only correct file names and directories of intermediate product md files (products under docs/), do not touch source code/test code (src/ is checked by verification items); If there is no corresponding function name → Do not force renaming (stop and ask)

Execution Method (Core Rules)

1. Correct product naming and paths first (See "Step 0" section for execution rules): Scan intermediate products in docs/, if naming/paths are non-compliant → List correction list → User confirmation → Correction → Then enter verification
2. Define verification scope first (See "Verification Scope Definition" section below, read before execution): User-specified directory → Use the specified path; User says "a certain requirement/this round of changes" → Use git diff to define files → Use this path; No specification → Whole project. Replace the default path

   src/main/java

   in each check command with the defined scope
3. Judge mode first (See "Mode Judgment and Verification Basis" above), read the corresponding constraint file, determine the judgment caliber for selection-type verification items
4. For each item below, actually execute the "standard check command" (grep/ast-grep, use the scope defined in Step 1 for paths), paste the command + hit lines (File:Line Number) as evidence
5. No hits → Record

   ✅

   ; Hit violations → Record

   ❌

   (attach evidence)
6. All unimplemented items (all verification items, no level distinction) → Unifiedly list in the "Pending User Confirmation List" and confirm with the user whether to complete them together: Show all ❌ items' evidence to personnel (Confirm once, not item by item repeatedly), ask "The following N items are not implemented properly, whether to complete them according to standards?" → User confirms item by item (complete / skip) → Only execute completion for items confirmed as "complete" → Re-run the item's command + new evidence (fixed); If still unable to meet requirements after completion → Escalate to manual verification (mark "needs manual verification"). Prohibit modifying code automatically without user confirmation, prohibit silently skipping any ❌ items as "unimportant" (There is a personnel confirmation gate throughout the completion process)
7. Output the 《Critical Standard Verification Report》 (mark verification scope; item-by-item ✅/❌ + evidence + pending user confirmation list), and summarize the results into the "Critical Standard Implementation Verification Table" in the acceptance report

[!WARNING] Mandatory Evidence + User Confirmation Gate (All unimplemented items are confirmed together, no level distinction) Each item must provide the actually executed grep/ast-grep command and hit lines. Only writing ✅/❌ without evidence = No verification, return for re-run. Prohibit "claiming to have done it without doing it". All unimplemented items (all verification items, no level distinction) → Must stop and let the user confirm whether to complete them together (Only modify code after personnel confirmation), do not automatically complete silently, do not skip confirmation due to "non-blocking/unimportant/for reference only". No matter how many unimplemented items there are, confirmation is required—even if 1 ❌ item is found, stop for confirmation, and do not bring ❌ items into acceptance.

Verification Scope Definition (Must Do Before Execution——Determine "Where to Scan" First, Then Run Commands)

The default path

src/main/java

is written in all standard check commands (sample value). Before execution, determine the actual scanning path according to the following rules, and replace the path in each command with the defined scope——Avoid "wanting to only scan the code modified this time but scanning all existing violations in the whole project".

Scenario A: User-specified directory/module/package (Most common——"Scan xx directory"/"Verify order module")

• User provides path → Path of all check commands = This path (

  grep ... <Specified Path>

  , e.g.,

  src/main/java/com/xxx/order

  ), not the whole project
• Mark "Verification Scope: <Specified Path>" in the report; Files outside the scope are not scanned and not counted as ❌
• If the specified is a module name (e.g., "order module") instead of a path → Locate the module root directory first (

  src/main/java/**/order

  ), confirm then scan according to this path

Scenario B: User says "a certain requirement/code modified this time/this round of changes"

• First define "which files were modified this time" (by priority):

  1. git status

     +

     git diff --stat

     (uncommitted changes)——Java files added/modified in working directory/staging area
  2. Last commit (

     git diff HEAD~1 --name-only

     )——If just committed
  3. User-provided file list verbally
• Check command path = Directory where these files belong (If files are scattered, check each file individually, or check according to their common parent directory)
• The report distinguishes two types of ❌: Introduced by this round of changes (blocking, enter pending confirmation list) / Existing historical violations (not introduced this time——Only prompt "Existing issues: N (not introduced this time, can be handled by gen-comments/gen-logs separately"), does not block this round)
• Unable to determine change scope (git unavailable/user cannot explain clearly) → Stop and ask the user, do not guess

Scenario C: User has no specification, only "run check-standards" (Whole project check-up)

• Scan the whole project (default path of commands); The report separates this round of changes vs existing violations (Distinguish by diff in Scenario B if git is available; Mark "Full check-up, no distinction between existing/new" if git is not available)

[!NOTE] Relationship Between Scope Definition and Product Correction Step 0 (Product Correction) targets intermediate products in docs/; This definition targets the verification scope of src/ code. They are independent: Even if only scanning code in a certain directory, product correction in docs/ is still executed in full (to prevent broken acceptance references)

Verification Item List

src/main/java

1. Method and Log Coverage (Must Verify for New Code——Comments/Logs Must Cover All Code, Including Extracted Private Methods)

Root cause of pain points: No logs in ServiceImpl methods, large sections of private methods extracted from Controller have no comments or logs, and old verification only scans public methods so misses checks. This group verifies mechanically at the "method level", covering public + private + extracted methods.

$MOD $RET $NAME($$$) { $$$ }

/** */

log.info

log.warn

log.error

log.debug

grep -rn "// 1\." src/main/java

// 1.

// 2.

// WHY:

grep -rln "@Slf4j" src/main/java

grep -rn "System.out" src/main/java

2. Framework and Products (Selection-Sensitive ⚠️ Judged According to Project Mode)

grep -n "springdoc|knife4j|springfox|swagger" pom.xml

grep -rln "@Tag|@Operation|@Api|@ApiOperation" src/main/java

grep -rln "@Schema|@ApiModelProperty" src/main/java

ls src/main/resources/logback*.xml src/main/resources/log4j2*.xml

grep -n "log4j2|logback" pom.xml

grep -rn "@Select|@Insert|@Update|@Delete|<script>" src/main/java

ls src/main/resources/mapper/*.xml

ls docs/*/3.*.2-Interface List (Universal for Frontend and Backend).md

3. SQL and Data Security

grep -rn "CREATE TABLE|SELECT |INSERT INTO|UPDATE " docs/*/3.*.1-Technical Solution*.md

--

grep -A 25 "CREATE TABLE" src/main/resources/db/schema.sql docs/*/3.*.1-Technical Solution*.md

grep -rn '\${' src/main/resources/mapper/*.xml

grep -rn '"SELECT |"INSERT |"UPDATE |"DELETE ' src/main/java

${}

grep -rn -i "^[[:space:]]*UPDATE |^[[:space:]]*DELETE " src/main/resources/mapper/*.xml

4. Transactions and Code Quality

grep -rn "@Transactional" src/main/java

grep -rn "@Autowired" src/main/java

grep -rn "Mapper" src/main/java/*/controller/*.java

grep -rn "Entity|@TableName" src/main/java/*/controller/*.java

grep -rn "throw new RuntimeException|catch (.*) {}" src/main/java

grep -rn "catch (.* e)|throw new.*(.* e)" src/main/java

grep -rn "Map<" src/main/java/*/controller/*.java

grep -rln "class R\b|class Result\b" src/main/java

grep -rn -i "md5|sha1|DigestUtils" src/main/java

grep -rn "pageSize|PageQuery" src/main/java/*/dto/*.java

grep -rn 'message = "' src/main/java

Parameter/Data/Input/Request/Field/Content/Information

Illegal/Invalid/Incorrect/Format Error

5. Scenario-Based + Other Items (Verify Only When Corresponding Type of File Exists / Manual Items)

grep -rln "@Scheduled" src/main/java

grep -rln "@RabbitListener|@KafkaListener" src/main/java

grep -rln "MultipartFile" src/main/java

grep -rn "password|token|secret" src/main/java

grep -rn "List<.*> records|List<.*> codes|Set<.*> values" src/main/java

grep -rn 'log\.\(debug|info|warn|error\)(".*{[^}]*}",' src/main/java

.getXxx(

.getName(

.get(0

.getUser().

.getId()

list.get(0)

map.get(k).xxx()

grep -rhn '@TableName("[^"]*")' src/main/java

@TableName("x")

[!WARNING] #1/#2/#3 Method-Level Verification Must Read Each Method Through (Prevent "Long Code Focus Loss") grep/ast-grep can only list methods and "where comments/logs exist", but cannot prove "which method is missing". #1 (Method Javadoc), #2 (Method Logs), #3 (Step Comments) must read each method of each Java file generated/modified in this round through:

• Extracted methods (private auxiliary methods) are high-risk areas for missing comments/logs——Check one by one whether verification/conversion methods extracted from Controller, assembly/query methods extracted from ServiceImpl have method Javadoc and ≥1 INFO/WARN/ERROR log in the method body
• #2 Prevent "Partial Coverage" Missing: Method starts with 1

  log.debug

  (or 1 INFO) but has 10+ lines of database query/circulation/assembly logic in the middle without INFO/WARN/ERROR → ❌ (debug does not count as logs, methods must have INFO in key stages)
• Read from the first line to the last line of the method, focus on the second half of the method and deeply nested branches; For long methods (>20 lines), confirm section by section that numbered comments cover the last step and each business logic section has logs
• Prohibit judging ✅ only by grep hit count; Methods not read through are treated as "not verified" and returned for re-verification

Output Format

=== Critical Standard Verification Report (5.2.<Function Item Serial Number>-<Function Name>-Standard Verification Report) ===
Project: <Path>    Time: <Timestamp>    Mode: Standard/Existing Adaptation    Verification Scope: Whole Project / <Specified Directory> / This Round of Changes (Defined by git diff)
Product Correction Record (Step 0, if none → "None, naming/paths are compliant"):
  docs/3.1-Service Product Classification and BANNER-Technical Solution.md → docs/<Module>V<Version>-<Timestamp>/3.1.1-Service Product Classification and BANNER-Technical Solution.md (missing .1)
  docs/<Module>…/5.2-T02-01-Frontend Product List and Details-Standard Verification Report.md → …/5.2.6-Frontend Product List and Details-Standard Verification Report.md (add function serial number + remove task ID)
[✅] 1 Full Coverage of Method-Level Comments   Evidence: UserController.java:12 login has Javadoc; OrderServiceImpl.java:8 buildVO private has Javadoc (12/12 methods passed after reading through)
[❌] 2 Full Coverage of Method-Level Logs   Evidence: OrderServiceImpl.java:33 getOrderList method body has no log calls (zero logs); :41 buildOrderVO private has no logs
[✅] 5 Full Class @Slf4j        Evidence: Full class @Slf4j, no System.out
[❌] 14 Transaction rollbackFor  Evidence: OrderServiceImpl.java:45 @Transactional (no rollbackFor)
[❌] 27 Sensitive Information in Logs    Evidence: AuthController.java:60 log.info contains plaintext token
...
Conclusion: 33 verification items: X Passed / Y Failed
⚠️ Pending User Confirmation List (All unimplemented items, confirm once, no level distinction):
  #2 Full Coverage of Method-Level Logs, #14 Transaction rollbackFor, #27 Sensitive Information in Logs …
  (Item by item: Complete/Skip)

• Save the report:

  docs/<Module Name>V<Version Number>-<YYYYMMDDHHMMSS>/5.2.<Function Item Serial Number>-<Function Name>-Standard Verification Report.md

  (When following ai-dev-workflow process, function item serial number is consistent with 3.x technical solution, e.g., function item 6 →

  5.2.6-Frontend Product List and Details-Standard Verification Report.md

  , task ID is prohibited in file name; When triggered independently without docs directory → Output the report directly in the dialogue + prompt the user whether to save it); Summarize all verification item conclusions (including #1 method comments / #2 method logs item-by-item verification results) into the Critical Standard Implementation Verification Table in the acceptance report
• All unimplemented items (no level distinction) → Confirm with the user whether to complete them together (Show evidence → Personnel confirm item by item complete/skip → Execute completion for confirmed items → Re-run)

[!NOTE] Distinction Between Two "Personnel" Actions

• User Confirmation Gate (Before execution): If unimplemented items are found → Confirm with the user "whether to complete" (complete/skip), AI takes action only after confirmation——Decide "whether to complete"
• Escalate to Manual Verification (After execution): If still ❌ after completion and re-run, or user chooses to skip → Mark the item as "needs manual verification", and personnel intervene to judge——Decide "what to do" Both require personnel presence, but at different times: Confirmation is before taking action, manual verification is when still failing after taking action.

Completion Standards

• Product naming and paths have been corrected (Step 0): Intermediate product naming in docs/ complies with standards (Technical Solution 3.x.1 / Interface List 3.x.2 / Verification Report 5.2.x / Acceptance Report 5.3.x, no task ID prefix), paths are in the module version directory; Correction list has been confirmed with the user, correction records are written into the report
• Verification scope has been defined (One of the three types: specified directory / this round of changes git diff / whole project), verification scope has been marked in the report; Check command path = defined scope (not whole project default)
• Mode has been judged (Standard/Existing Adaptation, read corresponding constraint files; If no constraint files, caliber has been noted in the report), selection-sensitive items (#6/#7/#8/#20) are judged according to project constraints/legacy project agreements, not one-size-fits-all with standard default values
• All 33 verification items have actually executed check commands and attached evidence (File:Line Number)——Including #1 method-level comments (public + private + extracted methods), #2 method-level logs, #3 step comments, #23 verification message specificity, #32 log parameter NPE, #33 duplicate mapping of same table
• #1/#2/#3 have been verified by reading each method through (Read each Java file generated/modified in this round from method head to method tail, focus on verifying comment and log coverage of private/extracted methods, second half of methods and deeply nested branches, did not judge ✅ only by grep hit count)
• All unimplemented items (no level distinction) have been confirmed with the user whether to complete them together——Items confirmed as "complete" have been completed and re-run successfully; Items selected as "skip" by user or still ❌ after completion → Have been marked as "needs manual verification" (not swallowed silently)
• Verification report has been output (Saved to

  docs/<Module Name>V<Version Number>-<YYYYMMDDHHMMSS>/5.2.<Function Item Serial Number>-<Function Name>-Standard Verification Report.md

  when following process)
• All verification item results have been summarized into the acceptance report verification table

Relationship with Other Skills

/check-standards

standards/comment-standards.md