fact-check

---
name: fact-check
description: Verify technical accuracy of JavaScript concept pages by checking code examples, MDN/ECMAScript compliance, and external resources to prevent misinformation
---

# Skill: JavaScript Fact Checker

Use this skill to verify the technical accuracy of concept documentation pages for the 33 JavaScript Concepts project. This ensures we're not spreading misinformation about JavaScript.

## When to Use

- Before publishing a new concept page
- After significant edits to existing content
- When reviewing community contributions
- When updating pages with new JavaScript features
- Periodic accuracy audits of existing content

## What We're Protecting Against

- Incorrect JavaScript behavior claims
- Outdated information (pre-ES6 patterns presented as current)
- Code examples that don't produce stated outputs
- Broken or misleading external resource links
- Common misconceptions stated as fact
- Browser-specific behavior presented as universal
- Inaccurate API descriptions

---

## Fact-Checking Methodology

Follow these five phases in order for a complete fact check.

### Phase 1: Code Example Verification

Every code example in the concept page must be verified for accuracy.

#### Step-by-Step Process

1. **Identify all code blocks** in the document
2. **For each code block:**
   - Read the code and any output comments (e.g., `// "string"`)
   - Mentally execute the code or test in a JavaScript environment
   - Verify the output matches what's stated in comments
   - Check that variable names and logic are correct

3. **For "wrong" examples (marked with ❌):**
   - Verify they actually produce the wrong/unexpected behavior
   - Confirm the explanation of why it's wrong is accurate

4. **For "correct" examples (marked with ✓):**
   - Verify they work as stated
   - Confirm they follow current best practices

5. **Run project tests:**
   ```bash
   # Run all tests
   npm test
   
   # Run tests for a specific concept
   npm test -- tests/fundamentals/call-stack/
   npm test -- tests/fundamentals/primitive-types/
   ```

6. **Check test coverage:**
   - Look in `/tests/{category}/{concept-name}/`
   - Verify tests exist for major code examples
   - Flag examples without test coverage

#### Code Verification Checklist

| Check | How to Verify |
|-------|---------------|
| `console.log` outputs match comments | Run code or trace mentally |
| Variables are correctly named/used | Read through logic |
| Functions return expected values | Trace execution |
| Async code resolves in stated order | Understand event loop |
| Error examples actually throw | Test in try/catch |
| Array/object methods return correct types | Check MDN |
| `typeof` results are accurate | Test common cases |
| Strict mode behavior noted if relevant | Check if example depends on it |

#### Common Output Mistakes to Catch

```javascript
// Watch for these common mistakes:

// 1. typeof null
typeof null        // "object" (not "null"!)

// 2. Array methods that return new arrays vs mutate
const arr = [1, 2, 3]
arr.push(4)        // Returns 4 (length), not the array!
arr.map(x => x*2)  // Returns NEW array, doesn't mutate

// 3. Promise resolution order
Promise.resolve().then(() => console.log('micro'))
setTimeout(() => console.log('macro'), 0)
console.log('sync')
// Output: sync, micro, macro (NOT sync, macro, micro)

// 4. Comparison results
[] == false        // true
[] === false       // false
![]                // false (empty array is truthy!)

// 5. this binding
const obj = {
  name: 'Alice',
  greet: () => console.log(this.name)  // undefined! Arrow has no this
}
```

---

### Phase 2: MDN Documentation Verification

All claims about JavaScript APIs, methods, and behavior should align with MDN documentation.

#### Step-by-Step Process

1. **Check all MDN links:**
   - Click each MDN link in the document
   - Verify the link returns 200 (not 404)
   - Confirm the linked page matches what's being referenced

2. **Verify API descriptions:**
   - Compare method signatures with MDN
   - Check parameter names and types
   - Verify return types
   - Confirm edge case behavior

3. **Check for deprecated APIs:**
   - Look for deprecation warnings on MDN
   - Flag any deprecated methods being taught as current

4. **Verify browser compatibility claims:**
   - Cross-reference with MDN compatibility tables
   - Check Can I Use for broader support data

#### MDN Link Patterns

| Content Type | MDN URL Pattern |
|--------------|-----------------|
| Web APIs | `https://developer.mozilla.org/en-US/docs/Web/API/{APIName}` |
| Global Objects | `https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/{Object}` |
| Statements | `https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/{Statement}` |
| Operators | `https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/{Operator}` |
| HTTP | `https://developer.mozilla.org/en-US/docs/Web/HTTP` |

#### What to Verify Against MDN

| Claim Type | What to Check |
|------------|---------------|
| Method signature | Parameters, optional params, return type |
| Return value | Exact type and possible values |
| Side effects | Does it mutate? What does it affect? |
| Exceptions | What errors can it throw? |
| Browser support | Compatibility tables |
| Deprecation status | Any deprecation warnings? |

---

### Phase 3: ECMAScript Specification Compliance

For nuanced JavaScript behavior, verify against the ECMAScript specification.

#### When to Check the Spec

- Edge cases and unusual behavior
- Claims about "how JavaScript works internally"
- Type coercion rules
- Operator precedence
- Execution order guarantees
- Claims using words like "always", "never", "guaranteed"

#### How to Navigate the Spec

The ECMAScript specification is at: https://tc39.es/ecma262/

| Concept | Spec Section |
|---------|--------------|
| Type coercion | Abstract Operations (7.1) |
| Equality | Abstract Equality Comparison (7.2.14), Strict Equality (7.2.15) |
| typeof | The typeof Operator (13.5.3) |
| Objects | Ordinary and Exotic Objects' Behaviours (10) |
| Functions | ECMAScript Function Objects (10.2) |
| this binding | ResolveThisBinding (9.4.4) |
| Promises | Promise Objects (27.2) |
| Iteration | Iteration (27.1) |

#### Spec Verification Examples

```javascript
// Claim: "typeof null returns 'object' due to a bug"
// Spec says: typeof null → "object" (Table 41)
// Historical context: This is a known quirk from JS 1.0
// Verdict: ✓ Correct, though calling it a "bug" is slightly informal

// Claim: "Promises always resolve asynchronously"
// Spec says: Promise reaction jobs are enqueued (27.2.1.3.2)
// Verdict: ✓ Correct - even resolved promises schedule microtasks

// Claim: "=== is faster than =="
// Spec says: Nothing about performance
// Verdict: ⚠️ Needs nuance - this is implementation-dependent
```

---

### Phase 4: External Resource Verification

All external links (articles, videos, courses) must be verified.

#### Step-by-Step Process

1. **Check link accessibility:**
   - Click each external link
   - Verify it loads (not 404, not paywalled)
   - Note any redirects to different URLs

2. **Verify content accuracy:**
   - Skim the resource for obvious errors
   - Check it's JavaScript-focused (not C#, Python, Java)
   - Verify it's not teaching anti-patterns

3. **Check publication date:**
   - For time-sensitive topics (async, modules, etc.), prefer recent content
   - Flag resources from before 2015 for ES6+ topics

4. **Verify description accuracy:**
   - Does our description match what the resource actually covers?
   - Is the description specific (not generic)?

#### External Resource Checklist

| Check | Pass Criteria |
|-------|---------------|
| Link works | Returns 200, content loads |
| Not paywalled | Free to access (or clearly marked) |
| JavaScript-focused | Not primarily about other languages |
| Not outdated | Post-2015 for modern JS topics |
| Accurate description | Our description matches actual content |
| No anti-patterns | Doesn't teach bad practices |
| Reputable source | From known/trusted creators |

#### Red Flags in External Resources

- Uses `var` everywhere for ES6+ topics
- Uses callbacks for content about Promises/async
- Teaches jQuery as modern DOM manipulation
- Contains factual errors about JavaScript
- Video is >2 hours without timestamp links
- Content is primarily about another language
- Uses deprecated APIs without noting deprecation

---

### Phase 5: Technical Claims Audit

Review all prose claims about JavaScript behavior.

#### Claims That Need Verification

| Claim Type | How to Verify |
|------------|---------------|
| Performance claims | Need benchmarks or caveats |
| Browser behavior | Specify which browsers, check MDN |
| Historical claims | Verify dates/versions |
| "Always" or "never" statements | Check for exceptions |
| Comparisons (X vs Y) | Verify both sides accurately |

#### Red Flags in Technical Claims

- "Always" or "never" without exceptions noted
- Performance claims without benchmarks
- Browser behavior claims without specifying browsers
- Comparisons that oversimplify differences
- Historical claims without dates
- Claims about "how JavaScript works" without spec reference

#### Examples of Claims to Verify

```markdown
❌ "async/await is always better than Promises"
→ Verify: Not always - Promise.all() is better for parallel operations

❌ "JavaScript is an interpreted language"
→ Verify: Modern JS engines use JIT compilation

❌ "Objects are passed by reference"
→ Verify: Technically "passed by sharing" - the reference is passed by value

❌ "=== is faster than =="
→ Verify: Implementation-dependent, not guaranteed by spec

✓ "JavaScript is single-threaded"
→ Verify: Correct for the main thread (Web Workers are separate)

✓ "Promises always resolve asynchronously"
→ Verify: Correct per ECMAScript spec
```

---

## Common JavaScript Misconceptions

Watch for these misconceptions being stated as fact.

### Type System Misconceptions

| Misconception | Reality | How to Verify |
|---------------|---------|---------------|
| `typeof null === "object"` is intentional | It's a bug from JS 1.0 that can't be fixed for compatibility | Historical context, TC39 discussions |
| JavaScript has no types | JS is dynamically typed, not untyped | ECMAScript spec defines types |
| `==` is always wrong | `== null` checks both null and undefined, has valid uses | Many style guides allow this pattern |
| `NaN === NaN` is false "by mistake" | It's intentional per IEEE 754 floating point spec | IEEE 754 standard |

### Function Misconceptions

| Misconception | Reality | How to Verify |
|---------------|---------|---------------|
| Arrow functions are just shorter syntax | They have no `this`, `arguments`, `super`, or `new.target` | MDN, ECMAScript spec |
| `var` is hoisted to function scope with its value | Only declaration is hoisted, not initialization | Code test, MDN |
| Closures are a special opt-in feature | All functions in JS are closures | ECMAScript spec |
| IIFEs are obsolete | Still useful for one-time initialization | Modern codebases still use them |

### Async Misconceptions

| Misconception | Reality | How to Verify |
|---------------|---------|---------------|
| Promises run in parallel | JS is single-threaded; Promises are async, not parallel | Event loop explanation |
| `async/await` is different from Promises | It's syntactic sugar over Promises | MDN, can await any thenable |
| `setTimeout(fn, 0)` runs immediately | Runs after current execution + microtasks | Event loop, code test |
| `await` pauses the entire program | Only pauses the async function, not the event loop | Code test |

### Object Misconceptions

| Misconception | Reality | How to Verify |
|---------------|---------|---------------|
| Objects are "passed by reference" | References are passed by value ("pass by sharing") | Reassignment test |
| `const` makes objects immutable | `const` prevents reassignment, not mutation | Code test |
| Everything in JavaScript is an object | Primitives are not objects (though they have wrappers) | `typeof` tests, MDN |
| `Object.freeze()` creates deep immutability | It's shallow - nested objects can still be mutated | Code test |

### Performance Misconceptions

| Misconception | Reality | How to Verify |
|---------------|---------|---------------|
| `===` is always faster than `==` | Implementation-dependent, not spec-guaranteed | Benchmarks vary |
| `for` loops are faster than `forEach` | Modern engines optimize both; depends on use case | Benchmark |
| Arrow functions are faster | No performance difference, just different behavior | Benchmark |
| Avoiding DOM manipulation is always faster | Sometimes batch mutations are slower than individual | Depends on browser, use case |

---

## Test Integration

Running the project's test suite is a key part of fact-checking.

### Test Commands

```bash
# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Run tests with coverage
npm run test:coverage

# Run tests for specific concept
npm test -- tests/fundamentals/call-stack/
npm test -- tests/fundamentals/primitive-types/
npm test -- tests/fundamentals/value-reference-types/
npm test -- tests/fundamentals/type-coercion/
npm test -- tests/fundamentals/equality-operators/
npm test -- tests/fundamentals/scope-and-closures/
```

### Test Directory Structure

```
tests/
├── fundamentals/              # Concepts 1-6
│   ├── call-stack/
│   ├── primitive-types/
│   ├── value-reference-types/
│   ├── type-coercion/
│   ├── equality-operators/
│   └── scope-and-closures/
├── functions-execution/       # Concepts 7-8
│   ├── event-loop/
│   └── iife-modules/
└── web-platform/              # Concepts 9-10
    ├── dom/
    └── http-fetch/
```

### When Tests Are Missing

If a concept doesn't have tests:
1. Flag this in the report as "needs test coverage"
2. Manually verify code examples are correct
3. Consider adding tests as a follow-up task

---

## Verification Resources

### Primary Sources

| Resource | URL | Use For |
|----------|-----|---------|
| MDN Web Docs | https://developer.mozilla.org | API docs, guides, compatibility |
| ECMAScript Spec | https://tc39.es/ecma262 | Authoritative behavior |
| TC39 Proposals | https://github.com/tc39/proposals | New features, stages |
| Can I Use | https://caniuse.com | Browser compatibility |
| Node.js Docs | https://nodejs.org/docs | Node-specific APIs |
| V8 Blog | https://v8.dev/blog | Engine internals |

### Project Resources

| Resource | Path | Use For |
|----------|------|---------|
| Test Suite | `/tests/` | Verify code examples |
| Concept Pages | `/docs/concepts/` | Current content |
| Run Tests | `npm test` | Execute all tests |

---

## Fact Check Report Template

Use this template to document your findings.

```markdown
# Fact Check Report: [Concept Name]

**File:** `/docs/concepts/[slug].mdx`
**Date:** YYYY-MM-DD
**Reviewer:** [Name/Claude]
**Overall Status:** ✅ Verified | ⚠️ Minor Issues | ❌ Major Issues

---

## Executive Summary

[2-3 sentence summary of findings. State whether the page is accurate overall and highlight any critical issues.]

**Tests Run:** Yes/No
**Test Results:** X passing, Y failing
**External Links Checked:** X/Y valid

---

## Phase 1: Code Example Verification

| # | Description | Line | Status | Notes |
|---|-------------|------|--------|-------|
| 1 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |
| 2 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |
| 3 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |

### Code Issues Found

#### Issue 1: [Title]

**Location:** Line XX
**Severity:** Critical/Major/Minor
**Current Code:**
```javascript
// The problematic code
```
**Problem:** [Explanation of what's wrong]
**Correct Code:**
```javascript
// The corrected code
```

---

## Phase 2: MDN/Specification Verification

| Claim | Location | Source | Status | Notes |
|-------|----------|--------|--------|-------|
| [Claim made] | Line XX | MDN/Spec | ✅/⚠️/❌ | [Notes] |

### MDN Link Status

| Link Text | URL | Status |
|-----------|-----|--------|
| [Text] | [URL] | ✅ 200 / ❌ 404 |

### Specification Discrepancies

[If any claims don't match the ECMAScript spec, detail them here]

---

## Phase 3: External Resource Verification

| Resource | Type | Link | Content | Notes |
|----------|------|------|---------|-------|
| [Title] | Article/Video | ✅/❌ | ✅/⚠️/❌ | [Notes] |

### Broken Links

1. **Line XX:** [URL] - 404 Not Found
2. **Line YY:** [URL] - Domain expired

### Content Concerns

1. **[Resource name]:** [Concern - e.g., outdated, wrong language, anti-patterns]

### Description Accuracy

| Resource | Description Accurate? | Notes |
|----------|----------------------|-------|
| [Title] | ✅/❌ | [Notes] |

---

## Phase 4: Technical Claims Audit

| Claim | Location | Verdict | Notes |
|-------|----------|---------|-------|
| "[Claim]" | Line XX | ✅/⚠️/❌ | [Notes] |

### Claims Needing Revision

1. **Line XX:** "[Current claim]"
   - **Issue:** [What's wrong]
   - **Suggested:** "[Revised claim]"

---

## Phase 5: Test Results

**Test File:** `/tests/[category]/[concept]/[concept].test.js`
**Tests Run:** XX
**Passing:** XX
**Failing:** XX

### Failing Tests

| Test Name | Expected | Actual | Related Doc Line |
|-----------|----------|--------|------------------|
| [Test] | [Expected] | [Actual] | Line XX |

### Coverage Gaps

Examples in documentation without corresponding tests:
- [ ] Line XX: [Description of untested example]
- [ ] Line YY: [Description of untested example]

---

## Issues Summary

### Critical (Must Fix Before Publishing)

1. **[Issue title]**
   - Location: Line XX
   - Problem: [Description]
   - Fix: [How to fix]

### Major (Should Fix)

1. **[Issue title]**
   - Location: Line XX
   - Problem: [Description]
   - Fix: [How to fix]

### Minor (Nice to Have)

1. **[Issue title]**
   - Location: Line XX
   - Suggestion: [Improvement]

---

## Recommendations

1. **[Priority 1]:** [Specific actionable recommendation]
2. **[Priority 2]:** [Specific actionable recommendation]
3. **[Priority 3]:** [Specific actionable recommendation]

---

## Verification Checklist

- [ ] All code examples verified for correct output
- [ ] All MDN links checked and valid
- [ ] API descriptions match MDN documentation
- [ ] ECMAScript compliance verified (if applicable)
- [ ] All external resource links accessible
- [ ] Resource descriptions accurately represent content
- [ ] No common JavaScript misconceptions found
- [ ] Technical claims are accurate and nuanced
- [ ] Project tests run and reviewed
- [ ] Report complete and ready for handoff

---

## Sign-off

**Verified by:** [Name/Claude]
**Date:** YYYY-MM-DD
**Recommendation:** ✅ Ready to publish | ⚠️ Fix issues first | ❌ Major revision needed
```

---

## Quick Reference: Verification Commands

```bash
# Run all tests
npm test

# Run specific concept tests
npm test -- tests/fundamentals/call-stack/

# Check for broken links (if you have a link checker)
# Install: npm install -g broken-link-checker
# Run: blc https://developer.mozilla.org/... -ro

# Quick JavaScript REPL for testing
node
> typeof null
'object'
> [1,2,3].map(x => x * 2)
[ 2, 4, 6 ]
```

---

## Summary

When fact-checking a concept page:

1. **Run tests first** — `npm test` catches code errors automatically
2. **Verify every code example** — Output comments must match reality
3. **Check all MDN links** — Broken links and incorrect descriptions hurt credibility
4. **Verify external resources** — Must be accessible, accurate, and JavaScript-focused
5. **Audit technical claims** — Watch for misconceptions and unsupported statements
6. **Document everything** — Use the report template for consistent, thorough reviews

**Remember:** Our readers trust us to teach them correct JavaScript. A single piece of misinformation can create confusion that takes years to unlearn. Take fact-checking seriously.

---
> Converted and distributed by [TomeVault](https://tomevault.io) | [Claim this content](https://tomevault.io/claim/leonardomso/33-js-concepts)
<!-- tomevault:2.0:skill_md:2026-04-05 -->