## TL;DR
The Dangerfile calls a method that isn't defined - usually a typo or a plugin gem that isn't installed. Read the method name and line number from the error, add or fix the plugin, and re-run Danger exactly the way CI does. The evaluation context only knows the built-in DSL plus loaded plugins, so anything else is "undefined".

## The error
```text
danger: failed to evaluate Dangerfile: undefined method
```

## Steps to fix
1. Read the full error: it names the undefined method and the Dangerfile line - open that line.
   - Expected: a single method call that doesn't match anything in the DSL.
2. Check whether the method comes from a plugin: look for the plugin gem in the Gemfile (Ruby Danger) or the import at the top of the Dangerfile (JS Danger); if it's missing, add it.
   - Expected: you can say whether the method should exist via a plugin or is simply a typo.
3. Make sure the plugin actually loads in CI: Ruby Danger loads plugins through the Gemfile and bundler, so re-run with the same bundler setup CI uses; confirm the lockfile includes the plugin.
   - Expected: local reproduction uses the identical dependency set as CI.
4. Run Danger locally the way CI does.
   - Expected: the Dangerfile evaluates cleanly and posts its comment.

## Use this when
- The Danger step fails in CI with "failed to evaluate Dangerfile: undefined method".
- A Dangerfile was just edited or a plugin was just added.
- Danger works locally but fails in CI (dependency drift).

## Not for this skill when
- Danger fails to post its comment rather than to evaluate (that's auth or API permissions).
- The error is a syntax error rather than an undefined method (fix the Ruby/JS syntax).
- You're on danger-swift (different toolchain, different fix).

## Variant phrasings
- dangerfile undefined method error
- danger failed to evaluate dangerfile
- danger ruby NoMethodError in CI
- danger plugin method not found

## Why it happens
A Dangerfile runs inside a DSL context: every method call must resolve against that context or a loaded plugin. A typo'd method name, a plugin gem that's in the docs but not in the Gemfile, or a lockfile that doesn't include the plugin all produce exactly this error at evaluation time. CI's clean install surface makes it stricter than a developer's machine with globally installed gems.

## Edge cases
- danger-js and danger-ruby have different DSLs - confirm which one CI runs before trusting a method name from the other one's docs.
- Plugin version drift: a method that exists in the plugin's latest release may not exist in the version pinned in the lockfile.
- Methods removed in a Danger major version: check the changelog when upgrading Danger itself.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZFzE96ak5DYIANRfNrg3lw