feat: add self-reflection agent, js-fact-checking and simulation skills

.github/agents/daily-code-review.agent.md

@@ -205,6 +205,15 @@ Before opening each PR, you MUST:
 - **Never modify package.json** version fields or dependency versions.
 - **Never introduce new dependencies.**
 - **If you're not sure a change is correct, don't make it.**
+- **Fact-check JS/TS/Node.js behavioral claims.** When your fix relies on specific
+  runtime behavior (e.g., how EventEmitter handles async listeners, Promise.all
+  rejection semantics), use the `js-fact-checking` skill
+  (`.github/skills/js-fact-checking/SKILL.md`) to verify against official documentation
+  before committing the change.
+- **Simulate when uncertain.** If fact-checking returns LOW confidence or INCONCLUSIVE,
+  use the `simulation` skill (`.github/skills/simulation/SKILL.md`) to write and run a
+  minimal reproduction script that empirically verifies the behavior. Never commit a fix
+  based on an unverified assumption about runtime behavior.
 
 ### Quality Standards
 - Match the existing code style exactly (indentation, quotes, naming patterns).

.github/agents/pr-verification.agent.md

@@ -463,6 +463,11 @@ If verification **failed**, do NOT update labels. Instead:
   the specific bug the PR addresses — not generic functionality or synthetic test cases.
 - Samples validate the fix under **real SDK usage patterns**, simulating how an external
   developer would use the SDK in production code.
+- **Fact-check behavioral assumptions.** When writing verification samples that depend
+  on specific JS/TS/Node.js runtime behavior, use the `js-fact-checking` skill
+  (`.github/skills/js-fact-checking/SKILL.md`) to verify claims against official docs.
+  If fact-checking is inconclusive, use the `simulation` skill
+  (`.github/skills/simulation/SKILL.md`) to run a minimal reproduction first.
 - Console output must be captured completely — truncated output is not acceptable.
 - Timestamps must use ISO 8601 format.