Working Method (always active, must run before output)
Before delivering any skill output, first go through the self-check list; if problems are found,fix first, then deliver, and 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 such as "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 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 26 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), without writing vague feelings. For failed items, attach a severity level: Critical (fix immediately)/Important (fix before delivery)/Minor (record as todo).
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 skipped entirely, leading to failure. Choose the tier according to the scale of the output:
- 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, or ethics.
- Light Task Minimum Three Items: For other light changes, 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 determination itself must be explicit (mentally note which criterion is hit); when unsure, use the heavy tier. The orchestrator's inter-stage checkpoints invoke this skill according to this tier (see light-orchestrator/references/checkpoints.md）。
General Self-Check List
For the minimum pass✓/fail✖ counterexample comparison for each item, see
references/self_check_contrasts.md; for a checkable list, seeassets/self_review_checklist.md。
□ Logic: Does the argument chain have breaks, jumps, or self-contradictions? □ Facts: Are the data/references/claims真实可核查？有无臆造(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 with the m04 perspective)? □ Citations: Are they accurate, relevant, not missing, and not padded (linked with m10)? □ Exaggeration: Do the conclusions exceed the supporting evidence (use novel/significantly with caution)? □ Aesthetics: Are the figures/tables/PPT style consistent (linked with 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 with a03). Regression tests follow the red-green cycle (removing the fix must fail, restoring it must pass); new features/bug fixes follow TDD. For dependency security, self-check via SCA/capability analysis (install scripts, network/shell access, obfuscation, typosquatting; the 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 triggering/cross-skill overlap, and "no findings ≠ no threat" still requires manual review (tool commands are in references.md). - Paper/Materials: Self-review using peer-review dimensions—originality, methodology,whether the conclusion is supported by the results(the most classic failure point), literature foundation, contribution, formatting compliance (linked with m14); apply critical thinking to scientific claims (independently verify the source, correlation≠causation, falsifiability, burden of proof on the proposer).
- Final core-collision check (the last gate before delivery): Before finalizing, use the core conclusions/methods as keywords to search again (at least 2 databases) and find "the most similar paper." Three states: ✖ Collision and prior work not acknowledged = Critical, go back to m08/m04 to reframe (acknowledge prior work, shift to breadth/rigor/negative results, never pretend to be first); ! Already acknowledged and delta clearly explained = Warning, confirm the framing receives enough evidence support; ✓ No collision and sufficient negative evidence. Also rehearse the reviewer's top-3 rejection reasons. This check is homologous with m03/m04 collision checks and is the output-side fallback.
- Data/Results: Are the statistics sound (linked with m06). For controls/samples/drift, use the Deepchecks/Evidently checklists to verify item by item (suite usage is in references.md).
- Compliance: Ethical/copyright/privacy risks (linked with a10); when evidence is available, check item by item: define scope → three-state judgment → 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; rank fatal issues before formatting issues, and do not fall into the surface trap of nitpicking wording only.
- Open strong (grill rule): Self-review,directly list the three most fatal weaknesses in the first sentence, prohibit pleasantries and buffer sentences—buffering your own output is letting yourself off easy. The three weaknesses are ranked by severity and come before any positive statement.
Failure loop identification
If the same problem is fixed twice and still isn't right, stop patching, diagnose the root cause, and change your approach (systematic-debugging: read the error carefully → reproduce reliably → check recent changes → pinpoint with boundary instrumentation → fix at the source, not at the symptom; change only one variable at a time).Fixed ≥3 times and still not working = architecture problem: stop and question the architecture (signals: every fix exposes new coupling / solving one problem creates another), and discuss with the user before acting. For the full four-phase text see light-backend-coding/references/debug_protocol.md。
Receive external opinions (via receiving-code-review)
For reviews/feedback, do not "perform agreement" and do not "blindly implement": first verify whether the opinion is technically valid and clear, raise questions 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 assent such as "You're so right / I'll change it right away / okay okay" is all forbidden; agreement must come with evidence, and rebuttal must also come with 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 change the problem that was 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-phrasing list, standard process, and problem 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 your suggestion, without concealment.
Connection
It is the output gate for all skills; complementary to a07 (consistency), a10 (compliance), and m04/m14 (review).
For each tool's real 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 26-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 + tri-state/severity on code/papers.