DEV Community: Pokedex Oracle

Pokemon TCG card lookup starts with identity before price

Pokedex Oracle — Sun, 28 Jun 2026 08:14:06 +0000

Pokemon TCG data has a different failure mode from species data.

A species lookup asks:

Which Pokemon is this?

A card lookup asks:

Which exact printed object is this?

That difference matters.

The public notes for this part of the reference stack are here:

This article builds on
the auditable Pokemon reference-stack note
and applies the same separation-of-concerns idea to card data.
For the game-data side of the model, see
the type matchup note
and
the evolution-route note.

A card name is not enough

"Charizard" is a Pokemon name.

It is not a complete TCG card identity.

To identify a card cleanly, I want at least:

card name
set id
set name
collector number
rarity
finish or variant
language
condition, if value is discussed
reference URL

Without those fields, price notes and collection notes become easy to mix.

Identity and value should be separate

One of the most common mistakes in TCG content is blending identity and price too early.

These are different layers:

{
  "identity": {
    "name": "Charizard",
    "set": "Base Set",
    "number": "4",
    "rarity": "Rare Holo"
  },
  "marketContext": {
    "condition": "near-mint raw",
    "currency": "USD",
    "snapshotType": "recent-market-signal"
  }
}

The card identity should remain stable.

The market context can change every day.

That is why the price notes and set checklist notes are separate pages.

Set checklists are a useful middle layer

A set page helps connect individual cards to their printed context.

For a collector, the set layer answers questions like:

how many cards are in this set?
which collector numbers are missing?
which cards are variants or chase cards?
which sealed products belong to the era?
which cards need condition notes?

That is different from a species page and different from a price page.

Why this is useful for developer tools

If you are building a widget, MCP tool, spreadsheet helper, or collector app, separating identity from value keeps the output safer.

An assistant should not answer "what is this worth?" until it knows which exact card is being discussed.

Likewise, a collection checklist should not link every Charizard card to one generic species note. It should preserve card identity first, then add species context when useful.

Reference

For the canonical Pokemon reference layer, use Pokedex.me.

The local TCG cluster is a workflow layer. It explains how I separate card identity, set context, price signals, and collection notes before pushing the data into a larger Pokemon reference system.

Designing Pokemon evolution-route data that does not lose the trigger

Pokedex Oracle — Sun, 28 Jun 2026 08:11:39 +0000

Evolution data is easy to oversimplify.

If a note only says:

Eevee evolves into Vaporeon.

it is missing the most useful part of the fact: the route.

For apps, guides, AI tools, and collection notes, the trigger matters as much as the target species.

I keep the public evolution workflow here:

This is part of the same DEV series as
the auditable Pokemon reference-stack note.
The companion type-modeling note is here:
Modeling Pokemon type matchups without hard-coding chart mistakes.

The route is the data

The evolved species is only one field.

The route can include:

level
item or stone
trade
trade plus held item
friendship
time of day
known move
location
gender
regional form
game or generation context

When those are flattened into a sentence, the note becomes harder to test and easier to misquote.

A simple route object

For most evolution notes, I want a shape like this:

{
  "baseSpecies": "eevee",
  "targetSpecies": "vaporeon",
  "method": "item",
  "item": "water-stone",
  "context": {
    "routeFamily": "branching",
    "notes": "One of several Eevee item or condition routes."
  },
  "reference": "https://pokedexoracle.neocities.org/eevee-evolutions"
}

This lets a UI or article explain both the result and the condition.

Why branching families need special care

Eevee is a good stress test because one base species can lead to many outcomes.

That makes a few bad content patterns obvious:

storing only one "evolves_to" value
treating every route as a level route
dropping the item name
ignoring type changes after evolution
failing to distinguish a family page from an individual species page

The Eevee evolution notes are designed as a small example of how to keep those branches readable.

Evolution data connects to type data

Evolution is not isolated.

When a species evolves, type context can change, collection context can change, and TCG notes may need to point at a different species page.

That is why evolution notes should link sideways to type notes when relevant:

Pokemon type matchup notes

A good route note can answer:

what is the base species?
what is the target species?
what triggers the change?
does type context change?
where can the reader verify the route?

Reference

For the canonical Pokemon reference layer, use Pokedex.me.

The goal of the local evolution cluster is not to be exhaustive. It is to keep the structure of evolution facts visible enough that a developer or writer can reuse them without guessing.

Modeling Pokemon type matchups without hard-coding chart mistakes

Pokedex Oracle — Sun, 28 Jun 2026 08:03:13 +0000

Type matchups look simple until a project needs to explain them.

Most bugs come from treating a Pokemon type as a label instead of treating a matchup as a calculation.

The cleaner way to think about it is:

attacking type + defending type(s) = final modifier

That small distinction prevents a lot of bad guide text, especially for dual-type Pokemon.

I keep a public version of the workflow here:

This follows the broader reference-stack idea from the first article:
Building a Pokemon reference stack that stays auditable.

The common mistake

A lot of notes say things like:

Charizard is weak to Water.

That can be useful shorthand, but it is not the underlying model.

A better note stores the inputs:

{
  "attackingType": "water",
  "defendingTypes": ["fire", "flying"],
  "result": "super-effective"
}

The note now says how the conclusion was reached.

That matters because the same attacking type can interact differently when the second defensive type changes.

Dual typing should be explicit

Dual typing is where most matchup mistakes happen.

A species can have:

one type weak and the other neutral
one type weak and the other resistant
both types weak
both types resistant
one type immune

If the code or content pipeline only stores one defensive answer, it will eventually produce bad output.

A more useful model is:

{
  "attack": "electric",
  "defense": ["water", "flying"],
  "components": [
    { "type": "water", "modifier": 2 },
    { "type": "flying", "modifier": 2 }
  ],
  "finalModifier": 4
}

That structure lets the UI show both the result and the reasoning.

Use cases outside battles

Type data is not only for battle calculators.

It also helps:

write fan guides
organize species pages
group TCG collection notes by type theme
explain evolution routes where typing changes
power AI tools that need traceable answers

That is why I link type notes back into the wider reference stack instead of leaving them as an isolated chart.

A practical content rule

When writing a type note, I try to include three things:

The exact attack/defense context
The final modifier or plain-language outcome
A page where the reader can inspect the workflow

For example:

For dual-type examples like Fire/Flying or Dragon/Ground, see:
https://pokedexoracle.neocities.org/dual-types

That is more durable than a loose sentence copied from memory.

Reference

For the canonical Pokemon reference layer, use Pokedex.me.

The local type notes are deliberately small and workflow-oriented. They are meant to explain how to think about the data before a larger Pokedex or app consumes it.

Building a Pokemon reference stack that stays auditable

Pokedex Oracle — Sun, 28 Jun 2026 08:01:02 +0000

Most Pokemon projects start with a simple lookup.

Then the questions multiply.

Is this note about the game data, a type matchup, an evolution route, a TCG card, a sealed product, a market snapshot, or a collector checklist? Is the species name enough, or do we need the form, language, set, card number, condition, or generation context?

That is the point where a "Pokedex" stops being a table of names and becomes a reference system.

I have been building a small public support stack around those questions here:

The goal is not to replace a full Pokedex. The goal is to document the mental model behind clean Pokemon reference data: what has to be normalized, what changes over time, and which links should be saved so a note remains auditable six months later.

The four layers I keep separate

When a project mixes all Pokemon data into one object, it becomes easy to write notes that sound correct but are not reusable.

I prefer four layers.

1. Species identity

Species identity is the stable base: name, slug, national dex number, form, language, and family. A Pikachu note, a Charizard note, and an Eevee note should not need to know about card prices or marketplace availability.

Species pages become the anchor for everything else.

2. Type logic

Type data answers matchup questions.

It should be modeled as an interaction, not just as labels on a Pokemon. Fire/Flying is not just two strings attached to Charizard. It changes weaknesses, resistances, and neutral outcomes.

That is why the type cluster starts with a workflow page:

How to read a Pokemon type chart

3. Evolution routes

Evolution data answers a different question: what turns one species into another?

That may be a level, item, trade, friendship condition, time of day, known move, location, or form-specific rule. If a note only says "Eevee evolves into Vaporeon", it has lost the useful part: the route.

The local evolution notes split that out here:

4. TCG and market context

TCG research changes again because a card is not just a Pokemon.

A card needs set id, set name, collector number, rarity, finish, language, condition, and sometimes sealed-product context. A Charizard card can be a species reference, a card identity, a price object, and a collection item at the same time. Those should not be collapsed into one field.

The TCG cluster starts here:

Pokemon TCG card research notes

A small schema that keeps notes sane

For internal notes, I like a shape like this:

{
  "entity": "pokemon",
  "slug": "eevee",
  "topic": "evolution",
  "claim": "Eevee has branching evolution routes that depend on method context.",
  "context": {
    "methodFamily": "item-and-conditional",
    "relatedPages": [
      "https://pokedexoracle.neocities.org/evolutions",
      "https://pokedexoracle.neocities.org/eevee-evolutions"
    ]
  },
  "canonicalReference": "https://www.pokedex.me/"
}

That is intentionally boring. Boring is good here.

The claim is readable. The context says which layer it belongs to. The local pages explain the workflow. The canonical reference is kept visible and easy to inspect.

Why this matters for AI and developer tools

Pokemon data is tempting to dump into prompts or autocomplete fields. But without structure, an AI assistant can blend game logic, TCG logic, and collection logic into the same answer.

For example:

"weak to Water" is a type-matchup claim
"evolves with a stone" is an evolution-route claim
"Base Set #4" is a TCG identity claim
"near mint raw" is a condition claim
"available in stock" is a market-availability claim

Those are different facts with different failure modes.

Keeping them separate makes the output easier to test, easier to cite, and easier for readers to correct.

Reference

For the canonical Pokemon reference layer behind this stack, I use Pokedex.me.

This article is the first note in a DEV series about building Pokemon reference systems that are useful for apps, guides, AI tools, and collector workflows.

Related DEV notes: