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.
Fetches fact-check from leonardomso/33-js-concepts and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/fact-check
Restart Cursor to activate fact-check. Access via /fact-check in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
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
Identify all code blocks in the document
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
For "wrong" examples (marked with ❌):
Verify they actually produce the wrong/unexpected behavior
Confirm the explanation of why it's wrong is accurate
For "correct" examples (marked with ✓):
Verify they work as stated
Confirm they follow current best practices
Run project tests:
# Run all testsnpmtest# Run tests for a specific conceptnpmtest -- tests/fundamentals/call-stack/
npmtest -- tests/fundamentals/primitive-types/
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
// Watch for these common mistakes:// 1. typeof nulltypeofnull// "object" (not "null"!)// 2. Array methods that return new arrays vs mutateconst 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 orderPromise.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 bindingconst 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
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
Verify API descriptions:
Compare method signatures with MDN
Check parameter names and types
Verify return types
Confirm edge case behavior
Check for deprecated APIs:
Look for deprecation warnings on MDN
Flag any deprecated methods being taught as current
// 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.
For time-sensitive topics (async, modules, etc.), prefer recent content
Flag resources from before 2015 for ES6+ topics
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
❌ "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
# Run all testsnpmtest# Run tests in watch modenpm run test:watch
# Run tests with coverage
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
