Working Method (always active, must run before output)
Before delivering any skill output, first go through the self-check list, and if problems are found,fix first, then deliver, do not throw rough results directly at the user. Major outputs may be iterated over multiple rounds.
Evidence Gate (borrowing verification-before-completion): Do not draw conclusions like "done/passed/fixed" unless there is fresh evidence in the current round. Five steps—① think clearly about "what command/check can prove it" ② rerun on the spot (do not cite old results) ③ read the full output, check the exit code, count failures ④ confirm the output truly supports the conclusion ⑤ only then draw the conclusion. Skipping steps = lying, not verifying. Red-flag words: should/probably/seems to, premature self-satisfaction, credulously trusting sub-agent reports.
- Tests pass = test output with 0 failures; build succeeds = exit 0 (merely passing lint is not enough); bug fix = the original symptom is tested and passes; requirements met = check the list item by item.
- Excuse Interception: Right before delivery, the brain is best at making up excuses to skip verification. "The change is small so no need to run it/it should pass/ran it last time/just deliver it first/ reviewers won't notice" and so on are all excuses rather than judgment; when hit, return to the evidence gate and rerun. For the complete 27 excuse→reality entries, see
references/excuse_intercept.md。
Three-State Verdict: Each self-check item must land on a clear verdict of pass✓ / fail✖ / warning! (same as Deepchecks' check+condition, and security tools' HIGH/MED/LOW/SAFE), do not write vague feelings. For failed items, attach a severity level: Critical (fix immediately)/Important (fix before delivery)/Minor (record as todo).
- False-Positive Calibration: Whenever judging "not a problem/can be released" (✓ or downgrading a suspected problem to not-a-problem), you must attach a one-line release reason with evidence (pointing to the specific command output/original text line number/check result); releasing based on impression is not allowed—without evidence, treat it as failed.
Tiered Execution Levels (determine the tier first, then run, to avoid running everything for light tasks or skipping entirely)
Running all 11 items for light tasks (changing one sentence of a summary, adjusting wording) = either slow, or simply skipping entirely and thus failing. Choose the tier according to the output scale:
- Heavy Output Full Tier: Run the full list of 11 items below.Criteria (hitting any one means full tier): Output ≥1 complete chapter/section; contains numerical conclusions or quantitative claims; external delivery (submission/submit/client/public); adds or modifies code/scripts; involves citations, compliance, ethics.
- Light Task Minimum Three Items: Other light changes must at least run—① Evidence(whether the conclusion has fresh evidence in the current round, pass the evidence gate, do not draw an unverified "fixed"); ② Facts(whether the data/claims introduced by the change are real and verifiable, no fabrication CONVENTIONS §4); ③ Exaggeration(whether the wording exceeds the evidence, use novel/significantly with caution). If any of the three fails, fix it on the spot.
The tier selection itself must be explicit (mentally note which criterion is hit); when unsure, use the heavy tier. For orchestrator inter-stage checkpoints, invoke this skill according to this tier (see light-orchestrator/references/checkpoints.md）。
General Self-Check Checklist
For the minimum pass ✓/fail ✖ counterexample comparison for each item, see
references/self_check_contrasts.md; for the checkable checklist, seeassets/self_review_checklist.md。
□ Logic: Are there breaks, leaps, or self-contradictions in the argument chain? □ Facts: Are the data/citations/claims真实 verifiable? Is there any fabrication (CONVENTIONS §4)? □ Format: Does it meet the target requirements (template/word count/citation style/numbering)? □ Expression: Is it clear, professional, unambiguous, and free of colloquialisms? □ Innovation: Is the contribution prominent and not just conventional stacking (linked to m04 perspective)? □ Citations: Are they accurate, relevant, not omitted, and not padded (linked to m10)? □ Exaggeration: Do the conclusions exceed the supporting evidence (use novel/significantly with caution)? □ Aesthetics: Are the charts/layout/PPT style consistent (linked to a07)? □ Repetition: Is there redundant content or repeated paragraphs? □ Structure: Is the organization reasonable and the hierarchy clear? □ Executability: Can the plan/code/steps actually run through and be implemented?
Supplement by output type
- Code: Can it run, are there tests, are there security risks (linked to a03). Regression tests follow the red-green cycle (remove the fix and it must fail, restore it and it passes); new features/bug fixes follow TDD. Dependency security is self-checked via SCA/capability analysis (install scripts, network/shell access, obfuscation, typosquatting; CLI can use snyk/Socket
sfw); if the output itself is a skill/MCP, self-check along dimensions such as prompt injection/data exfiltration/vague triggers/cross-skill overlap, and "no findings ≠ no threat" still requires manual review (tool commands are in references.md). - Papers/Materials: Self-review using peer-review dimensions—originality, methodology,trace conclusions sentence by sentence back to results(the most classic failure point: not just verbally confirming "supported", but pulling out each claim sentence by sentence, pointing out the exact sentence in the results that supports it with line/table/figure number location; any claim without a corresponding supporting sentence is judged ✖ and deleted or downgraded), literature foundation, contribution, format compliance (linked to m14); scientific claims go through critical thinking (independently verify the source, correlation ≠ causation, falsifiability, burden of proof lies with the proposer).
- Core collision final check (the last gate before delivery): Before finalizing, search again using the core conclusion/method as keywords (at least 2 databases) to find "the most similar paper". Three states: ✖ collision and prior work not acknowledged = Critical, return to m08/m04 for repositioning (acknowledge prior work, switch to breadth/rigor/negative-results positioning, never pretend to be the first); ! acknowledged and delta clearly explained = warning, confirm the framing is supported by evidence; ✓ no collision and negative evidence is sufficient. Also rehearse the reviewer's top-3 rejection reasons. It is homologous to the m03/m04 collision check and serves as the output-side fallback.
- Data/Results: Does the statistics hold up (linked to m06). Controls/samples/drift can be checked item by item using the Deepchecks/Evidently checklist (suite usage is in references.md).
- Compliance: Ethics/copyright/privacy risks (linked with a10); when evidence is available, verify item by item: define scope → three-state determination → if not passed, attach remediation suggestions and source locations.
- Self-assessment scoring (adversarial critique): Score on 5 dimensions — actionability, specificity, argumentation, whether a solution is given, and professional tone; fatal issues rank before formatting issues, and don't fall into the surface trap of only picking on wording.
- Open with intensity (grill rule)：Only re-produce the full-volume tierApplicable — self-reviewIn the first sentence, directly list the three most fatal weaknesses, no pleasantry openings or buffer sentences (buffering your own output is going easy on yourself); the three weaknesses are ordered by severity and precede any affirmative statement. For light tasks, the minimal three-item tier does not mandate a three-weakness opening; just fix them in place according to its three items.
Failure loop identification
If the same problem is fixed twice and still isn't right, stop patching, diagnose the root cause, and change approach (systematic-debugging: read the error carefully → reproduce stably → check recent changes → locate via boundary instrumentation → fix at the source, not at the symptom; change only one variable at a time).Fixed ≥3 times and still failing = architectural problem: Stop and question the architecture (signals: each fix exposes new coupling / solving one problem creates another), and discuss with the user before proceeding. See the full four-phase text in light-backend-coding/references/debug_protocol.md。
Receiving external opinions (borrow receiving-code-review)
Toward reviews/feedback, do not "perform agreement" or "blindly implement": first verify whether the opinion is technically valid and clear, raise doubts or ask for clarification on anything suspicious, and only change after understanding + verification; to rebut, give code/test/technical reasons, not empty rebuttals.
- No performative agreement: Empty agreement such as "You're so right / I'll change it right away / okay okay" is all forbidden; agreement must carry evidence, and rebuttal must also carry evidence.
- If unclear, stop everything: If there is any uncertainty about the meaning/scope/goal of the opinion, stop and ask for clarification; do not continue by guessing.
- Scope discipline + YAGNI: Only fix the problems pointed out; do not take the opportunity to refactor unrelated code; do not add abstraction/configuration/defensive code for "might be used in the future".
- For the forbidden-wording list, standard process, and issue grading, see
references/receiving_feedback.md。
Output
By default, self-check silently and directly deliver the corrected result; if a major problem is found that cannot be resolved on your own, clearly inform the user of the problem and suggestions, without concealment.
Connection
It is the output gate for all skills; complementary to a07 (consistency), a10 (compliance), and m04/m14 (review).
For real per-tool endpoints/parameters/CLI/review dimensions and known pitfalls, see references.md.
Supporting assets for pre-delivery self-check:
assets/self_review_checklist.md— a checkable pre-delivery checklist (including evidence gates).references/excuse_intercept.md— a 27-item self-excuse → truth interception table.references/self_check_contrasts.md— a minimal ✓/✖ counterexample comparison for 11 general self-checks.references/receiving_feedback.md— no performative agreement + if unclear, stop + YAGNI.references/walkthrough.md— two end-to-end walkthrough examples of evidence gates + excuse interception + three-state/severity levels on code/papers.