Packaging a Product into a Skill: A Cyber-Banxian for an Agent Contest

There's a contest going on for AI Agent skills, and one of its tracks is called "邪修" — roughly, "the heretical path." You're supposed to build something fun, weird, and a little reckless. The opposite of a productivity skill.

A cyber half-immortal sits between three burning candles, three coins on the table, code raining down behind him

I read the brief and immediately had two reactions.

First: I want in.

Second: most "fun" skills end up being a thin prompt that asks the LLM to roleplay something while making things up on the fly. That's not fun, that's slop with a costume.

Then I remembered I'd spent 29 days building PanPanMao — a Chinese fortune-telling platform — and most of that 29 days was not the LLM part. It was the boring real-domain part: porting actual divination algorithms from textbooks, transcribing the 64 hexagrams of the I Ching with their interpretations, encoding the edge cases (don't divine on lottery numbers, don't divine on someone's illness, don't divine the same question twice), and writing the voice guide for what a believable mystical narrator sounds like.

All of that was sitting in a monorepo. None of it was reusable outside that one product.

So the move was obvious: take the three Eastern divination engines (小六壬 / 梅花易数 / 六爻), strip them out of the React frontend, and package them into a single skill that any agent platform — Claude Code, Codex, Coze — can call. The skill would be both 邪修 (fun, in-character, reckless persona) and not slop (real algorithms, real knowledge base, real domain rules).

This post is about that packaging exercise. It's the inaugural post for a new series — AX Skill Workshop — where I'll write about skills I build and what I learn from each one.

What you have when a product is "done right"

When I went back to look at PanPanMao with skill-builder eyes, I was surprised by how cleanly the three divination engines decomposed:

domains/zhanbu/
├── liuren/
│   ├── algorithm/       # pure calculation: time → 6 deity positions
│   ├── knowledge/       # 6 deities × 12 hours × scenarios = ~72 combos
│   └── prompts/         # voice templates for the mystical narrator
├── meihua/
│   ├── algorithm/       # number → upper/lower trigram + changing line
│   ├── knowledge/       # 64 hexagrams with full interpretations
│   └── prompts/
└── liuyao/
    ├── algorithm/       # 6 coin tosses → 6 lines + world/response + six relatives
    ├── knowledge/       # 64 hexagrams × 3 parts (the deepest one)
    └── prompts/

Each domain has the same three layers: calculation, knowledge, voice. That separation was an accident of how I'd organized the product. But it turns out to be exactly what a portable skill needs.

A skill is also three layers: a script that does something deterministic, a knowledge base the model consults, and a persona that wraps the output. The product had built that decomposition in service of testability and per-domain ownership. The skill version is a different shape of the same three pieces.

This is the meta-lesson I want to pull forward and prove out across the series: a product built with clear separation between algorithm, knowledge, and voice already has a skill inside it. You're not authoring a new artifact. You're republishing the parts.

The contest constraint shaped the design more than I expected

I sat down with Claude in brainstorming mode and walked through eight design decisions before writing any code. Most of those decisions were forced by the 邪修 framing. I want to walk through the four that mattered most.

Decision 1: Single persona, not dual mode

The first instinct was to ship two modes — a "serious mode" for users who want a no-nonsense divination and a "half-immortal mode" for the contest aesthetic. The reasoning was that the underlying algorithms and knowledge are the same; only the wrapping prompt differs.

I argued for it. Claude pushed back: in the 邪修 track, "serious mode" is a tell that you're hedging. The contest is about commitment to a bit. A judge looking at a dual-mode skill is going to ask, "If you wanted serious, why are you in this track?"

Single persona it is. The "half-immortal" — 半仙 in Chinese, a self-deprecating term for a folk-tradition diviner who's part oracle, part stand-up comedian — is the whole skill. Want a serious tool? Use the product directly.

Decision 2: The half-immortal picks the method

There are three divination methods in this skill. The user shouldn't have to know which one applies to which kind of question. Worse, asking the user to pick destroys the persona — a real diviner would tell you which method to use, not let you order off a menu.

So the routing is:

• 小六壬 for small, immediate things: which lunch spot, where did I leave my keys, will today's meeting go well. Started by counting on fingers across a 6-position cycle by hour.
• 梅花易数 for spontaneous questions where you "felt something" — a thought that arrives unbidden, an omen that needs reading. Started by giving the diviner a few numbers off the top of your head.
• 六爻 for serious, long-arc decisions: marriage, job change, lawsuit. Six coin tosses, six lines, full hexagram interpretation with relationships and timing.

The half-immortal hears your question, makes the call, names the method, and explains why this method for this question — which is the most professional-feeling thing the skill does. A user who asked "should I renew my contract" is told, in character: "this is a long-arc question, not a today-or-tomorrow one. We need to throw the coins."

Decision 3: Python does the math, the LLM does the meaning

Six-line hexagram divination involves: six coin tosses → six binary lines → primary hexagram lookup in a 64-entry table → identify changing lines → derive the "transformed" hexagram → assign the 12 earthly branches → assign the six family relations (parent, sibling, child, wealth, official) based on the primary hexagram's palace → assign the six spirits based on the day's heavenly stem → identify the "world" and "response" positions → check for emptiness and conflicts.

The LLM cannot do this. Or rather, it can, almost, with errors that look right. And in a 3-minute demo video for a contest, one wrong line and the skill is dead.

The split is sharp:

• Python script outputs deterministic JSON with the cast hexagram, every annotation, the changing lines, and a list of knowledge_pointers — relative paths to markdown files the LLM should consult.
• The LLM reads only the pointed-to markdown sections, not the whole knowledge base, and renders the half-immortal's interpretation.

Three scripts (liuren.py, meihua.py, liuyao.py) plus a shared _common.py for the lunar calendar, trigram tables, and JSON I/O. About 500 lines total, ported pretty directly from the TypeScript that runs in the product. One dependency (lunardate).

The judges audit the ZIP and they see: real algorithm engine, not a prompt pretending to be one. That's worth more than any clever prompt.

Decision 4: "Things I won't divine" stay in character

Real folk-tradition diviners have a list of things they won't read for you. Don't divine on illness — go to a doctor. Don't divine on lottery numbers — that's not what this is for. Don't divine someone else's private business. Don't divine the same question twice in one day.

The naive way to handle this in a skill is a hard refusal: keyword detection, sorry-I-can't-help. That's safe but it kills the persona.

The better way is the way real diviners actually do it. The half-immortal acknowledges your question, points out it's not a question for the cards, and offers what the cards can tell you instead — usually the emotional or strategic frame around the situation. "Your mother's illness is for the doctor to read, not the cards. But the cards can tell you something about your own state in this — and it's saying you're holding too much. Sit with that."

PanPanMao already had this list, encoded as edge cases with appropriate diversion language. It ports straight to a markdown file in the skill. The persona stays whole, the safety holds, and ironically the diviner seems more authentic for having limits.

The remaining four decisions (target platform format, single skill vs three, knowledge embedding strategy, multi-turn handling) are in the design doc. Less interesting for this post; happy to dig into any of them in a follow-up.

The three-folder architecture

Here is what the ZIP looks like:

banxian-skill/
├── skill.md                       # half-immortal persona + routing + flow
├── README.md                      # judge-friendly project intro
├── scripts/
│   ├── liuren.py                  # 小六壬 engine
│   ├── meihua.py                  # 梅花易数 engine
│   ├── liuyao.py                  # 六爻 engine
│   ├── _common.py                 # lunar calendar, trigrams, JSON I/O
│   └── _lookup/
│       ├── hexagrams_64.json      # 64-hexagram master table
│       ├── najia.json             # heavenly-stem/earthly-branch assignments
│       └── ...
├── data/
│   ├── liuren/                    # 6-deity meanings, 12-hour table, 72 combos
│   ├── meihua/                    # 64-hexagram meanings, changing-line rules
│   ├── liuyao/                    # 64-hexagram interpretations × 3 parts
│   └── _shared/
│       ├── edge-cases.md          # what the half-immortal won't divine
│       └── method-router.md       # method-selection rules
└── examples/                      # 3 worked demos for judges and users

A judge opening this ZIP can audit it in five minutes:

• README.md for what the skill does. Thirty seconds.
• skill.md for the persona and main flow. One minute.
• scripts/ to confirm there's a real engine. One minute.
• data/ to confirm there's real domain knowledge. Two minutes.
• Run examples/01-career.md to see actual output. Thirty seconds.

The audit path is the architecture. Three folders, three things, three different kinds of evidence.

The transferable pattern

The thing I want to pull out of this exercise — the reason it's the first post in this series — is the transformation pattern.

Any product that has been built carefully on top of a real domain has, latent inside it, a skill. To extract it, you look for the same three layers I found in PanPanMao:

If your product is a thin CRUD layer over a generic API, there's no skill in there — the value is in the integration, not the domain. But if your product encodes opinion about a domain (which divination methods to use when, which edge cases to refuse, what tone to take), then the opinions are the skill.

PanPanMao also has 八字, tarot, dream interpretation, astrology — same architecture, three more potential skills sitting in the same monorepo. I'll do at least one of them next.

This is the bet of the AX Skill Workshop series: products built right come with skills already inside them, and pulling them out is mostly cataloging, not creating.

What I'm shipping into the contest

A single ZIP, with the structure above, plus:

• A 200-character business value statement (contest requirement)
• A 3-minute video demo where the half-immortal answers a contract-renewal question and a where-did-I-leave-my-wallet question, picking different methods for each
• An entry in the 邪修 track

The persona, if I've done my job, sounds like an old neighborhood diviner who reads tech Twitter on weekends. He says "嘶你这事儿问得有水平" with the same cadence he'd say "this hexagram is showing me a transition." He won't read your stock picks but he'll tell you something honest about why you keep checking the stock app every five minutes.

That's the costume. Underneath: PanPanMao's actual algorithms, PanPanMao's actual knowledge base, PanPanMao's actual edge-case rules — running outside PanPanMao, callable from any agent.

The product was the workshop where the parts were forged. The skill is just one of the things you can make once you have the parts.

---

This is part 1 of AX Skill Workshop — a series about skills I build for AI agents, what each one taught me, and the patterns that transfer between them. Next up: probably another PanPanMao extraction, then something for a non-divination domain. Suggestions welcome.