{"owner":"samchon","repo":"typia","hasSkills":true,"totalSkillsCount":33,"totalTokensCount":22633,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"typia":{"command":"npx","args":["-y","@modelcontextprotocol/server-typia"]}}},"found":[".agents/skills/project/SKILL.md",".agents/skills/discussion/SKILL.md",".agents/skills/multi-agent/SKILL.md",".agents/skills/pull-request/SKILL.md",".agents/skills/documentation/SKILL.md",".agents/skills/review/SKILL.md",".agents/skills/issue-campaign/SKILL.md",".agents/skills/benchmark/SKILL.md","AGENTS.md",".agents/skills/development/SKILL.md","packages/vercel/package.json","packages/vercel/README.md","packages/vercel/tsconfig.json","packages/utils/package.json","packages/utils/README.md","packages/utils/tsconfig.json","packages/typia/package.json","packages/typia/tsconfig.json","packages/typia/typedoc.json","packages/mcp/package.json","packages/mcp/README.md","packages/mcp/tsconfig.json","packages/langchain/package.json","packages/langchain/README.md","packages/langchain/tsconfig.json","packages/interface/package.json","packages/interface/README.md","packages/interface/tsconfig.json",".agents/skills/multi-agent/issue-campaign.md",".agents/skills/multi-agent/review.md",".agents/skills/issue-campaign/development.md",".agents/skills/benchmark/performance.md","packages/typia/test/protobuf_varint_corpus.json"],"skills":{".agents/skills/project/SKILL.md":"---\nname: project\ndescription: Defines the typia product contract, workspace layout, package boundaries, and canonical commands. Use when orienting in the repository, working inside any package, or choosing a build, test, or format command.\n---\n\n# Project Outline\n\n## Product Contract\n\nTypia is a TypeScript transformer library built around one idea: a pure TypeScript type definition should replace the runtime helpers that other tools require schemas, decorators, or hand-written guards for. The compile-time transform reads those types and emits the runtime validator, serializer, schema, or decoder inline.\n\nThe packages:\n\n- **`typia`**: the user-facing library and native transform. Exposes the runtime validators (`is`, `assert`, `assertGuard`, `validate`), enhanced JSON serde (`json.assertParse`, `json.assertStringify`, `json.schema`), LLM function-calling harness (`llm.application`, `llm.schema`, `llm.parse`, `llm.structuredOutput`, `llm.evaluation`), Protocol Buffer encoder/decoder (`protobuf.message`, `protobuf.assertEncode`, `protobuf.assertDecode`), and the random data generator (`random`).\n- **`@typia/interface`**: shared public typings (e.g. `IJsonSchemaCollection`, `ILlmSchema`, `IValidation`) consumed by every other package and by user code.\n- **`@typia/utils`**: runtime, OpenAPI, and LLM utility helpers (e.g. `LlmTypeChecker`) that live next to but outside the transform.\n- **`@typia/langchain`**: LangChain.js integration that adapts typia's LLM harness to LangChain tools.\n- **`@typia/mcp`**: Model Context Protocol integration.\n- **`@typia/vercel`**: Vercel AI SDK integration.\n- **`@typia/jev`**: Jev evaluation model integration, converting `llm.evaluation` questions to the Jev wire format.\n\nDownstream projects (`@nestia/core`, `@agentica`, `@autobe`) build on top of typia but are not part of this repository's contract. The exported `typia.*` surface, the `@typia/interface` typings, and the `ttsc.plugin` descriptor shape are public; renaming or removing any of them is a deliberate, separate change.\n\nA single Go program under `packages/typia/native` performs the compile-time transform that emits validators, stringifiers, schemas, and decoders in place of `typia.*<T>()` call sites. `packages/typia` registers a Go command package that `ttsc` (the TypeScript-Go compiler with native plugin support) compiles into a binary on first use through its plugin manifest:\n\n```json\n\"ttsc\": { \"plugin\": { \"transform\": \"typia/lib/transform\" } }\n```\n\nThe `packages/typia/src/transform.ts` file is a plugin descriptor, not a transformer; there is no TypeScript-side transform anymore. The descriptor resolves the installed `typia` package root and returns the Go entrypoint under `native/cmd/ttsc-typia`. The adapter packages do not register their own transforms. Consumers reach the binary through `ttsc` / `ttsx` and the published descriptor. ttsc keys each plugin build by content and stores it workspace-wide under `node_modules/.cache/ttsc` (it walks up to `pnpm-workspace.yaml`), so every package and test workspace shares one binary.\n\n## Layout\n\n- `packages/*`: the published packages, including the shared Go plugin under `packages/typia/native`. Public and contract Go tests live under `packages/typia/test`; native Go tests are colocated throughout `packages/typia/native/**`. The test `go.work` resolves `ttsc` and its shims through `../node_modules/`, while the native development `go.work` resolves the sibling `ttsc` checkout.\n- `tests/template`: `@typia/template`, a workspace package that ships the structure fixtures (`ObjectSimple`, `ArrayHierarchical`, ...) and the `TestServant` runtime helper consumed by the automated suites.\n- `tests/test-*`: feature-test workspaces:\n  - `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, `test-jev`, `test-utils`: function-per-file suites under `src/features/**/test_*.ts`, each file exporting one matching `test_<snake_case>` function discovered by `DynamicExecutor` (from `@nestia/e2e`).\n  - `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` also hold portable cases under `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` by `src/unit/index.ts` under `tsconfig.unit.json`, which has no native typia plugin. Their `start` runs the unit population before the integration population. Portable utility and adapter semantics belong in the unit population; preserve each exported case's inputs, assertions and failure identity when transferring it from a transformed suite.\n  - `test-typia-automated`, `test-utils-automated`: generator-driven matrix suites over their configured typia operations and `@typia/template` structures; their generated `src/features/` trees are rebuilt by the suite.\n  - `test-interface`: compile-time tests for exported `@typia/interface` types and public typia signatures; these cases execute no typia factory.\n  - `test-error`: transform-rejection verification; the build must fail and every fixture must be named by a typia diagnostic.\n- `tests/debug`: `@typia/debug`, a one-off `ttsx` runner for ad-hoc local repros.\n- `benchmark/`: `@typia/benchmark`, performance generators with archived results under `benchmark/results/**`. See `.agents/skills/benchmark/SKILL.md`.\n- `website/src/content/docs/**`: user-facing MDX guides published at https://typia.io/docs. See `.agents/skills/documentation/SKILL.md`.\n- `examples/`, `experiments/`, `scripts/`, `config/`: example sources, tarball staging, repo utilities, and shared build configuration.\n\n## Commands\n\nCI uses Node 24.x and Go 1.26.x, while the workspace pins pnpm exactly to 10.6.4.\n\n```bash\npnpm install\npnpm evidence\npnpm format\npnpm build\npnpm test\n```\n\n`pnpm test` runs every `tests/test-*` workspace through `pnpm test:packages`, then runs both Go trees through `pnpm test:toolchain`: `go -C packages/typia/test test ./...` and `go -C packages/typia/test test ../native/...`. It needs `go` on `PATH`. Run `pnpm install` first, or the test Go workspace cannot resolve `ttsc` and its shims through `../node_modules/`. Most feature workspaces execute TypeScript directly through `ttsx`; `test-error` uses a Node harness and `test-interface` invokes TypeScript `tsc --noEmit`. Plugin-building workspaces share the cache under `node_modules/.cache/ttsc`.\n\n`pnpm evidence` checks every enrolled production owner, test feature function, and root tooling configuration without building or generating test matrices. Every enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`; unit populations, types, runners and support declarations are outside this selection while their ordinary execution remains intact. `pnpm evidence:packages` and `pnpm evidence:tests` check their enrolled workspace populations separately. The template and both automated test workspaces are not enrolled; their ordinary generation and test commands retain their behavioral coverage.\n\nRelease-time commands (most contributors skip these): `pnpm package:rc`, `pnpm package:next`, `pnpm package:latest`, and `pnpm release`. `pnpm package:tgz` stages local tarballs in `experiments/tarballs/` for offline testing. See `.agents/skills/pull-request/SKILL.md` for the remote delivery flow.\n",".agents/skills/discussion/SKILL.md":"---\nname: discussion\ndescription: Runs structured multi-agent discussions for open-ended typia topics. Use only when the user explicitly asks for Discussion or a team debate with transcripts and conclusions; do not use for Self-Review, a solo or multi-agent review, research review, or issue discovery.\n---\n\n# Discussion\n\nDiscussion explores a topic without changing code or turning the exchange into a review queue. Reviews and issue discovery use the review skill instead.\n\n## Team\n\nForm the largest practical team, up to nine agents so the lead and participants fit the ten-agent session limit. Give every agent a self-contained brief with the topic, constraints, known evidence, output expectations, and the exact repository instructions and skills to read. Do not give a preferred conclusion or divide the topic into assigned slices.\n\n## Knowledge Base\n\nCreate `.discussions/<topic>/` with a short filesystem-safe name. Do not delete or overwrite an existing discussion directory unless the user explicitly requests it.\n\nEach agent maintains a personal wiki-style subdirectory under the topic directory. Agents read the live transcript and one another's statements between turns, continue researching, and revise their own notes.\n\n## Transcript\n\nRun three unrestricted transcript rounds as `round1.md`, `round2.md`, and `round3.md`. The lead moderates and records every statement in speaking order as a live transcript, not a retrospective summary. Do not narrow the topic unless the user does.\n\nAfter `round3.md`, the lead writes agreed conclusions, disagreements, and major open points to `summary.md`, reports the result, and waits. Discussion does not itself authorize implementation.\n",".agents/skills/multi-agent/SKILL.md":"---\nname: multi-agent\ndescription: \"Defines the explicitly parallel variants of typia review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review and unqualified review remain solo. Multi-agent issue campaigns parallelize discovery and implementation by default, but an explicit request may limit parallelism to discovery and return implementation to the solo campaign.\"\n---\n\n# Multi-Agent Workflows\n\nThis skill is the single entry point for every explicitly parallel review or campaign. Read the base solo skill first, then enter through the detailed document below for the requested workflow. That document names any shared multi-agent topic procedures it also requires.\n\n| Explicit request | Base skill | Detailed multi-agent procedure |\n| --- | --- | --- |\n| Team, parallel, or multi-agent review | [review](../review/SKILL.md) | [review.md](review.md) |\n| Parallel or multi-agent issue campaign | [issue-campaign](../issue-campaign/SKILL.md) | [issue-campaign.md](issue-campaign.md) |\n\n`typia` has no benchmark-campaign skill. Use [benchmark](../benchmark/SKILL.md) for measurement integrity, then the applicable issue-campaign workflow for authorized benchmark-driven implementation.\n\nDo not load this skill for Self-Review, an unqualified review, a discussion, or a campaign that does not explicitly request parallel agents.\n\n## Shared Parallelism Rules\n\n- Use the smallest number of agents that adds independent evidence or owns immediately executable disjoint work. Available thread capacity is not a reason to create an agent, and a review or discovery round is the one place where every available slot should carry a full independent pass.\n- Keep the total at ten agents including the lead, so at most nine children run at once.\n- Never create a waiter, poller, coordinator-only child, duplicate implementation owner, or agent that cannot begin useful work immediately.\n- Give every review or discovery agent the complete declared surface. Parallel review adds independent full passes; it never partitions coverage by package, file, concern, platform, or test lane.\n- Partition implementation only through verified dependency and file-ownership boundaries. One agent owns one coarse batch, branch, pull request, and worktree.\n- Keep the lead active on fact-checking, integration, conflict resolution, and decisions that do not duplicate an assigned agent.\n- Do not let agents re-delegate.\n- Self-Review remains solo for every author and every implementation branch. An independent verifier or critic is a separate agent auditing someone else's work, never a substitute for the author's own round.\n- Create worktrees only for parallel implementation batches, verification, mutation, and integrated cleanup. Solo implementation and review use the current checkout.\n- Remove every finished worktree, local branch, process, and assignment-owned temporary asset before declaring its assignment complete.\n\nThe solo campaign's [commit early-warning pass](../review/SKILL.md#commit-early-warning-pass) is a different topology and relaxes neither the full-surface rule nor the solo Self-Review rule above. A parallel review gives several reviewers the entire declared surface independently and the lead adjudicates their findings. The pass gives one read-only reader one commit's slice, reports candidates to the author who is still implementing, and leaves that author's own whole-surface round as the gate. A batch implementation agent here runs no pass, because agents do not re-delegate; the carve-out in the solo development procedure belongs to a solo campaign's main agent.\n",".agents/skills/pull-request/SKILL.md":"---\nname: pull-request\ndescription: Defines typia branch, commit, pull-request, check, and merge workflows. Use when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, update, or merge one on unprompted initiative.\n---\n\n# Pull Request Submission\n\nAct on this skill only when the user explicitly requests the corresponding remote action, or when a standing autonomous mandate authorizes it. Permission to edit locally is not permission to push or open a pull request, and permission to open or update is not permission to merge. The one exception is a standing autonomous mandate — an autonomous or remote-control campaign, or an explicit instruction to carry the work through merge: it is the request for every step it names, including push and merge, and the skill's check, verification, and self-review gates still apply to each step.\n\n## Branch From The Target\n\nBranch from the pull-request target (`master` unless stated otherwise); never commit or push directly to the target. Name the branch for the merged outcome with the repository's established type and scope, such as `feat/<scope>`, `fix/<scope>`, `docs/<scope>`, or `ci/<scope>`.\n\nSolo work never creates a clone or worktree. If the current checkout contains unrelated or protected work, stage only the authorized paths; if that cannot keep the pull request isolated, report the conflict rather than stashing, reverting, mixing, or relocating the work.\n\n## Commit Logical Units\n\nUse one commit per coherent unit when the diff is large. Follow the repository's `<type>(<scope>): <subject>` history with an imperative lowercase subject and no trailing period.\n\nRun the validation required by the development skill. Defer `pnpm format` to its final pre-merge cleanup gate; do not run it for each commit or push. Parallel issue-campaign implementation batches keep their dedicated Post-Campaign Cleanup formatter gate.\n\nStage explicit paths when the worktree is mixed. Never include unrelated user changes silently.\n\n## Write The Pull Request\n\nWrite the body at open as the historical intent statement. Include the intent, scope, deferred items, and exact local verification. State skipped checks and disabled campaign CI honestly.\n\nDo not rewrite the body after every follow-up push. Record later CI fixes, newly discovered design issues, promoted deferred work, and Self-Review results as formal GitHub pull-request reviews with the `COMMENT` event so the thread preserves chronology. Use inline review comments when an observation belongs to a changed line and the review body for commit-wide or round-wide results. Do not use ordinary issue-style pull-request comments for this ledger, and never `APPROVE` or `REQUEST_CHANGES` on your own pull request. The title describes the merged outcome in Conventional Commits style, not the work process.\n\nPush only the topic branch with upstream tracking. Use a file-backed body for multiline Markdown when opening through `gh`.\n\n## Issue Campaign Override\n\nBefore any issue-campaign push or pull request, complete `.agents/skills/issue-campaign/development.md`. A solo campaign uses one cycle pull request, the final pre-merge formatter gate, the ordinary check loop, and its integration-sensitive gate. Only `.agents/skills/multi-agent/issue-campaign.md` overrides that flow with worktree batches, exact-SHA campaign-run cancellation, local implementation gates, and Post-Campaign Cleanup.\n\n## Watch Checks After Every Ordinary Push\n\nAfter each ordinary push, including every Post-Campaign Cleanup push, monitor the pull-request checks until every check settles. Only CI-suspended campaign implementation waves skip this loop. On failure, fetch the relevant job log, diagnose the real cause, fix it in place, push a new commit, and resume monitoring. Do not treat a green unrelated job as acceptance for a failed required surface.\n\n## Merge On Explicit Request Or Standing Autonomous Mandate\n\nDo not merge, squash-merge, rebase, or update the target branch on unprompted initiative. Merge when the user explicitly asks, or when a standing autonomous mandate authorizes end-to-end delivery; use the repository's established merge method unless another is specified. Under an autonomous mandate the author that owns the pull request merges it themselves once the merge gate below passes, without separate approval.\n\nBefore merging an ordinary or Post-Campaign Cleanup pull request, confirm required checks pass. For a multi-agent campaign implementation pull request whose automatic CI is deliberately suspended, confirm its local-verification, independent-verification, and integration gates instead. If branch protection blocks the requested merge, report the blocker rather than bypassing it.\n",".agents/skills/documentation/SKILL.md":"---\nname: documentation\ndescription: Defines README, website-guide, and agent-instruction structure, audience, prose formatting, and voice for typia. Use before writing, modifying, renaming, or moving repository documentation.\n---\n\n# Documentation\n\n## READMEs\n\nREADME files are for the final reader of that package or directory. Start with what it is, when to use it, installation, the smallest working setup, and the common path.\n\nKeep README language direct and practical. Avoid compiler theory, protocol details, internal architecture, and edge cases unless the reader must know them to use the package. Move deep explanations into the website guides and link them only as the next step.\n\n## Guide Documents\n\nUser-facing guides live under `website/src/content/docs/**` as MDX and publish at https://typia.io/docs. The site uses Next.js and Nextra, exports a static site, and deploys to GitHub Pages. Keep one audience and one task per page.\n\nThe current tree is organized by feature area:\n\n- top-level pages `index.mdx`, `setup.mdx`, `pure.mdx`, `random.mdx`, and `misc.mdx` cover introduction, setup, and cross-cutting features;\n- `validators/`, `json/`, `protobuf/`, and `llm/` own their operation guides; and\n- `utilization/` owns framework integrations for MCP, Vercel AI SDK, LangChain, NestJS, tRPC, and Hono.\n\nThe root and each guide folder use `_meta.ts` for sidebar order and labels. Nextra reads keys in declaration order; `{ display: \"hidden\" }` keeps a page reachable while removing it from the sidebar. Update the matching `_meta.ts` whenever a guide is added, renamed, moved, hidden, or exposed.\n\nWhen emitted code is the point, pair the TypeScript source with its compiled JavaScript in side-by-side tabs so the reader can see what the transform replaces. Back performance claims with a specific benchmark result instead of an adjective. Follow the fresh website-build prerequisites in `.agents/skills/development/SKILL.md`.\n\n## Agent Instructions\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans and agents. Keep only the product-wide contract in `AGENTS.md`, the always-applicable procedure in `SKILL.md`, and conditional detail in a linked sibling document.\n\nConcise and clear means:\n\n- Include the context needed to act correctly. Do not make the reader infer prerequisites, exceptions, reasons, or stop conditions merely to shorten the document.\n- State each rule at its owning document and link to it elsewhere. Remove repeated wording, not necessary substance.\n- Give each paragraph one job. Separate purpose, rule, rationale, procedure, and consequence when combining them obscures the action.\n- Use structure to compress meaning: ordered lists for procedures, bullets for choices and checks, tables for repeated mappings, and code blocks for exact commands.\n- State the rule before its reason. Use a negative rule only when it prevents a named failure the affirmative rule does not already exclude.\n- Link to website guides, READMEs, or source comments instead of paraphrasing them.\n\n## Prose line breaks\n\nWrite each Markdown or MDX paragraph on one source line. Never hard-wrap a single paragraph at a fixed column: Markdown already soft-wraps it, while manual wrapping makes small edits reflow unrelated lines.\n\nOne source line does not mean one long paragraph. Insert a blank line whenever the idea changes. Keep structural line breaks for paragraphs, list items, headings, tables, and fenced code.\n\nThis is a manual convention, not a formatter gate. Root `pnpm format` runs Prettier over `**/*.ts` and formats changed Go files; it does not format `*.md` or `*.mdx`, and the repository does not set `proseWrap`. Preserve one-line paragraphs yourself.\n\n## Voice\n\nWrite in the plain, direct, technical voice of the human-authored typia docs. Do not write like an AI assistant.\n\n- No AI-cliche phrasing: \"not only X but also Y\", \"whether you're X or Y\", \"it's worth noting\", \"let's dive in\", and reflexive hedging.\n- No marketing adjectives such as \"seamless\", \"powerful\", \"robust\", or \"effortless\". State the behavior; where speed is the point, cite the benchmark.\n- No wrap-up sentence that just restates the paragraph. State the fact and stop.\n- Em-dashes already fit the existing typia prose; do not remove them mechanically or impose a punctuation ban.\n- Sidebar emoji in `_meta.ts` are part of the existing navigation voice. Keep them where they already fit; this exception does not turn guide prose into decorative copy.\n",".agents/skills/review/SKILL.md":"---\nname: review\ndescription: Defines exhaustive solo review, Self-Review, and solo repository-wide issue-discovery rounds for typia. Use for every self-review or unqualified review request and as the default review mode inside issue campaigns. This skill never spawns review agents; use the multi-agent skill only when the user explicitly requests a team, parallel, or multi-agent review.\n---\n\n# Review\n\n## Non-Negotiable Review Law\n\nRead the [contracts skill](../contracts/SKILL.md) when reviewing maintained production declarations or tests. Judge every acknowledgment against the actual declaration, native documentation, private helpers, and consequence surface. Evidence proves that an answer exists; review verifies every fact the chapter requests and revalidates existing answers affected by a change. A passing fixture or renamed wrapper does not prove that a disproven implementation assumption was corrected.\n\nOne reviewer performs every review in this skill from scratch over the entire declared surface. Do not spawn a subagent, delegate a concern, or load the discussion skill. Do not create a clone or worktree for solo review or Self-Review.\n\nChoose the principled conclusion. Review duration, difficulty, and consequence surface are reasons to inspect more deeply and verify more carefully, never reasons to overlook a sound improvement, accept an unsupported claim, or lower the completion standard.\n\nA complete round must satisfy all six rules:\n\n- **Whole surface:** read every changed file and hunk. For issue discovery, audit the entire campaign scope. Never partition by file, package, concern, platform, or pass, and never substitute another reviewer's coverage.\n- **Consequence surface:** inspect affected code paths, tests, generated artifacts, CI, packaging, documentation, and consumers. Trace side effects, state transitions, concurrency, platforms, boundaries, compatibility, and failure and recovery paths beyond the named symptom or diff.\n- **Fresh start:** use the current state and repeat the whole inspection. Earlier rounds, sampled files, and a recheck of only the latest fix do not count as coverage.\n- **Unlimited rounds:** whenever the reviewer applies an improvement or accepts a meaningful issue candidate, update the work and start another complete round. Stop only after a complete round produces nothing that survives verification.\n- **One immutable state:** a round runs against one recorded state, dependency lock, provisioned workspace contract, supported environment contract, and mandatory test matrix. Issue discovery and committed pull-request review use an exact commit. A solo review records its exact starting diff and refreshes that snapshot after every edit; a review round must not race a source change. The [multi-agent review procedure](../multi-agent/review.md) states how a team shares one snapshot.\n- **Auditable completeness:** the reviewer accounts for every tracked file and every mandatory public-operation, ownership, consumer, boundary, option, declaration-provenance, generated-artifact, packaging, and supported-platform matrix cell in the declared surface. Finding a candidate never ends or narrows the review. A skipped file, unprovisioned harness, unsupported claim, or unexecuted required cell makes the report `INCOMPLETE`, never `COMPLETE`.\n\n## Self-Review\n\nSelf-Review and an unqualified review request use this solo workflow:\n\n1. Establish the complete change surface, including the pull-request base-to-head diff and any uncommitted changes.\n2. Perform one complete round under the Non-Negotiable Review Law. Include correctness and boundaries, Windows and POSIX behavior, concurrency and state, data loss and security, cache and recovery invariants, public API and compatibility, test isolation, CI and packaging, generated output, documentation, and migration effects.\n3. Reproduce every suspected defect before accepting it.\n4. Apply every sound improvement and run the narrowest verification authorized by the owning workflow.\n5. If anything changed, restart at step 1 as a fresh full round.\n6. Finish only when a complete round finds nothing to improve. Report the final clean round and every verification that could not run.\n\nSelf-Review does not authorize creating, pushing, updating, or merging a pull request. If the user separately requests one of those actions, follow the pull-request skill.\n\n## Commit Early-Warning Pass\n\nA commit early-warning pass is not a review under this skill. It is the read-only per-commit reader a solo campaign author runs over every landed commit while still implementing, required and defined by the [solo campaign development document](../issue-campaign/development.md#implement-and-write-tests).\n\nIt delegates nothing the Non-Negotiable Review Law governs. The law governs the author's own round, which still runs alone over the whole surface before merge under all six rules. One commit is not a declared surface, a reported candidate is not an accepted finding, and the passes do not add up to a round.\n\nNever call the pass a Self-Review, and never report it as one. A reader who sees that name concludes the gate already ran, and the whole-surface round disappears without anyone deciding to drop it.\n\n## Solo Issue Discovery Rounds\n\nUse these rounds only through the solo issue-campaign skill.\n\n1. Freeze one exact commit and record the dependency lock, provisioning command, and supported environment contract before starting. Derive that environment contract from package engines, public documentation, repository CI, peer requirements, published package behavior, and explicit user decisions; do not narrow it ad hoc, and treat an unresolved conflict as a blocker on `CLEAN`.\n2. Inventory all tracked files, package and public API families, implementation owners, generated artifacts, test harnesses, workflows, documentation contracts, supported platforms, and open and closed issue or pull-request history before examining candidates. Reconcile that inventory with `git ls-files` and with the campaign's mandatory coverage matrix. A grep lens, a sampled file set, or a statement that the surface was reviewed is not coverage.\n3. Audit the entire inventory and execute the whole mandatory matrix. Audit source, tests, documentation, CI, packaging, generated artifacts, platform behavior, upstream and downstream provenance, and history against the development skill's **Forbidden** section. Continue through the full inventory after finding a candidate.\n4. Treat the matrix as a floor. Cover all applicable public operation families and direct, factory, and nested forms; equivalent TypeScript spellings, including aliases, interfaces, call and construct type literals, and classes; local, re-exported, module, package, user-global, default-library, ambient, and runtime-native provenance; union, intersection, generic, and transform-option interactions; static, dynamic, array, `any`, and `unknown` value contexts; positive, one-axis negative, boundary, malformed, maximum-width, one-past-boundary, and mutation controls; generated-byte and executed-runtime behavior; deterministic repeat emit; workspace, clean packed, and deployment consumers; and supported Node, module-resolution, operating-system, and CLI paths. Every interaction that reaches shared control flow is its own cell, and every positive cell has a one-axis negative twin. Run mutations only in a disposable checkout, keep the regression probe unchanged, and require the probe's canonical command to fail. When the round discovers a new owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells before the round can complete.\n5. Record every raw candidate, killed hypothesis, command, and artifact in the campaign knowledge base with the exact commit, environment, matrix hash, and census results. The round is `COMPLETE` only when the full inventory and current matrix finished; otherwise it is `INCOMPLETE` and cannot support a `CLEAN` campaign state.\n6. Reopen each candidate from primary evidence in a fresh state, reproduce it, verify ownership and provenance, trace its complete consequence surface, and compare existing issues and pull requests. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence, so a later round does not rediscover a rejected premise as new. Implementation mechanisms remain hypotheses.\n7. If any meaningful candidate survives, return to step 3 and run another complete round against the same frozen commit before publishing or implementing anything, and repeat until one round produces no surviving candidate. Discovery owns this loop; it never hands a partial candidate pool to publication or implementation because the first round already found work. A prior finding never permits narrowing the next round to its owner or neighbors.\n8. Publish only the surviving adjudicated form when the campaign is authorized to publish. After the authorized issue and implementation flow completes, freeze the new integrated commit and begin the next full-scope round.\n9. Stop only when one immutable-state round completes the entire repository inventory and mandatory matrix, no round is `INCOMPLETE`, and no meaningful candidate survives verification. Any verified in-repository correctness, contract, data-integrity, build, test-oracle, documentation, packaging, workflow, or **Forbidden** violation is meaningful regardless of severity, rarity, legacy status, or malformed-input trigger. Do not downgrade a proved defect to an observation to satisfy the stop rule. An unresolved, deferred, or unimplemented verified defect blocks `CLEAN`, and green existing suites cannot satisfy the stop rule.\n\n## Explicit Multi-Agent Reviews\n\nWhen the user explicitly asks for a team, parallel, or multi-agent review, load the [multi-agent skill](../multi-agent/SKILL.md) and its [review procedure](../multi-agent/review.md) instead of this workflow. It inherits the same whole-surface, immutable-state, and auditable-completeness law while defining independent parallel reviewers, agent briefing, and lead and critic adjudication.\n",".agents/skills/issue-campaign/SKILL.md":"---\nname: issue-campaign\ndescription: \"Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request.\"\n---\n\n# Issue Campaign\n\nAn issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that [development.md](development.md#implement-and-write-tests) requires for every landed commit.\n\nUse the [multi-agent skill](../multi-agent/SKILL.md) and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.\n\nThe user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.\n\nApply [AGENTS.md's **Choose the principled course** rule](../../../AGENTS.md#attitude) to every admission, disposition, implementation, and review decision.\n\nRead the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds; issue discovery is independent review, not discussion. Read [development.md](development.md) in full only when implementation is authorized.\n\n## Campaign Knowledge Base\n\nCreate `.wiki/<campaign>/` with a short filesystem-safe campaign name. Preserve any existing campaign directory and reconcile it rather than deleting or assuming a blank slate.\n\nKeep concise, current Markdown documents for:\n\n- repository provenance, architecture, validation ownership, and product boundaries;\n- experiments, reproductions, dogfooding, and related issue or pull-request history;\n- every raw candidate, its evidence, dependencies, and final disposition, including combinations, splits, rejections, and deferrals with the evidence supporting each decision;\n- the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, and official GitHub `createdAt`-to-`mergedAt` cycle timing;\n- the exact commit, dependency lock, provisioning command, supported environment contract, and tracked-file census for each discovery round;\n- a mandatory coverage matrix that crosses public operations, owners, consumers, declaration spellings and provenance, composition, transform options, input contexts and boundaries, generated artifacts, packaging, CLI, and supported platforms;\n- a per-issue consequence matrix and implementation impact record that names every caller, equivalent spelling, provenance, option, context, boundary, artifact, consumer, and platform revalidated by the fix; and\n- an integration-command manifest that records and hashes the exact commands, environment, tool versions, triggering change classes, expected artifacts, and clean-consumer setup required before and after each integration-sensitive merge.\n\nRecord raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.\n\nGive every tracked path and matrix cell a stable ID, and record one row per ID with `round`, `base SHA`, `matrix hash`, `path or cell ID`, `status`, `evidence`, and `candidate`.\n\nA status is one of four values, and it means something different for a path than for an executable cell:\n\n| Status | Tracked path | Executable matrix cell |\n| --- | --- | --- |\n| `PASS` | contents, history, owner, and linked cells were audited | the recorded oracle and controls passed |\n| `FAIL` | a candidate remains | the oracle or a control failed |\n| `N/A` | evidence that the path is outside an explicitly authorized contract | a product-contract reason |\n| `UNTESTED` | the audit is absent | the cell did not run |\n\nReconcile the path census with `git ls-files` and verify that the matrix covers every public operation and known historical dimension before the round begins. When the round discovers a missing owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells.\n\nReconcile the finished rows against the frozen census and final matrix. Any missing row, `UNTESTED`, unsupported `N/A`, or absent evidence makes the round `INCOMPLETE`.\n\nThe knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to `.wiki`.\n\n## Discover Issues\n\nRun the review skill's [Solo Issue Discovery Rounds](../review/SKILL.md#solo-issue-discovery-rounds) over the entire declared campaign scope. That procedure owns the frozen commit, environment contract, tracked-file census, mandatory coverage matrix, and the `COMPLETE` and `INCOMPLETE` round states. This section adds only what the campaign itself owns.\n\nOnly an explicit user instruction or existing public product contract can exclude a surface or environment. The campaign cannot narrow itself, and an unresolved support-policy question makes the round `INCOMPLETE`.\n\nSource is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions.\n\nNever combine results from different commits, and never accept a stale, unprovisioned, skipped, contaminated, sampled, or missing-type harness whose tags or declarations collapse to `any` or `unknown` as full-round evidence.\n\nTreat the development skill's [Forbidden](../development/SKILL.md#forbidden) section as an explicit retrospective audit contract, not only a rule for future changes. In every complete round, inspect the current implementation and its history for violations, including code that predates the campaign or passes every test. A verified violation is a meaningful issue candidate. Prove the classification from purpose, control flow, consequence, and history; resemblance or stylistic preference alone is not evidence.\n\nDo not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.\n\n### Every Round Is Full-Scope\n\nEvery round re-audits the entire declared scope from scratch against the state it was frozen on. A round is never partitioned: not by package, file, concern, platform, candidate class, validation lane, or pass, not by the areas the last cycle or the last round happened to touch, and not by splitting the scope across rounds so that each one covers a slice. What an earlier round read is never coverage for this one, whether it ran in an earlier cycle against a state a merge has since changed, or earlier in this cycle against the same commit. The [review skill's Non-Negotiable Review Law](../review/SKILL.md#non-negotiable-review-law) states the same rule for every round and review the campaign runs.\n\n### Discovery Ends Only On An Empty Round\n\nDiscovery repeats in two nested loops, and neither ends until a complete round comes up empty.\n\nInside one cycle, accepting a candidate does not end discovery. Begin another complete full-scope round against the same frozen commit and repeat until one round produces no meaningful candidate that survives verification. Only that empty round settles the cycle's issue set. Publishing or implementing from the first round that found something freezes the cycle around whatever that round happened to reach first, and the issues the next round would have added arrive too late to join it.\n\nAcross cycles, a merged cycle does not end the campaign. It produces one more discovery phase against the integrated repository, and that phase runs the inner loop to its own empty round. There is no limit on either loop, and the campaign ends only when a complete fresh round is not `INCOMPLETE`, produces no meaningful candidate that survives verification, and leaves no accepted issue unresolved.\n\nReport the campaign complete only from a round that actually came up empty. Ending after a cycle that merely felt thorough leaves the issues the next round would have found unrecorded.\n\n## Vet And Publish Issues\n\nThe same main agent owns every publication decision. For each candidate:\n\n1. Reopen its evidence and reproduce the behavior.\n2. Verify ownership, provenance, and any claimed classification under the development skill's **Forbidden** section.\n3. Trace the full consequence surface.\n4. Compare open and closed issues and pull requests.\n5. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence.\n\nRevalidate every disposition from primary evidence in a fresh state, including rejection, narrowing, combination, split, deferral, and confirmed-invalid conclusions, rather than trusting the note that first recorded it. A disposition that cannot be reproduced leaves the candidate surviving and blocks `CLEAN`; it cannot be hidden by omitting publication. The [multi-agent procedure](../multi-agent/issue-campaign.md) assigns this audit to an independent critic agent; a solo campaign performs it as a separate pass with its own recorded evidence.\n\nPublish only the adjudicated form and only with user authorization.\n\n### Self-Contained Issue Body\n\nWrite enough context for a fresh AI agent to begin implementation from the issue alone. Do not require access to local `.wiki`, the discovery conversation, or unstated repository knowledge. Cover these sections when they apply:\n\n- **Problem:** current and expected behavior, impact, and affected users.\n- **Evidence:** exact reproduction, outputs or artifacts, stable symbols, verified root cause, ownership, and provenance. For a violation of the development skill's **Forbidden** section, prove the classification from behavior, control flow, and history instead of merely naming the prohibition. Line numbers are navigation, not proof.\n- **Consequence surface:** affected consumers, states, platforms, compatibility and failure paths, plus the complete case matrix for the cause.\n- **Invariant:** the required behavior and architectural owner, without prescribing an implementation mechanism. Discovery explanations, closed issue approaches, and candidate mechanisms remain hypotheses for the implementer to validate; executed evidence establishes constraints and rejected alternatives, not a prescribed solution.\n- **Acceptance and verification:** positive, negative, boundary, and regression outcomes with narrow and broader proving commands.\n- **Coordination:** dependencies, exclusions, migration concerns, external blockers, and related open, closed, accepted, or rejected work.\n\nUse tables for repeated case mappings. Read the rendered issue back and keep its body as the current operative handoff; use comments only for chronology.\n\nBefore publication, reproduce the current failure and its independent oracle once more in a fresh state, and verify the invariant, complete owner and consumer census, supported-environment boundary, equivalent-spelling and provenance matrix, positive and negative twins, boundary cases, and a counterfactual proving that the reproduction distinguishes the expected behavior. Pass-after and fix-mutation evidence belong to implementation verification. Strike any prescribed implementation mechanism, including one that appears to fit the current evidence.\n\n## Develop And Repeat The Campaign\n\nRead [development.md](development.md) in full when the user authorizes implementation pull requests or the end of a campaign that entered implementation. It owns the single cycle pull request, empty claim, internal DAG order, test authoring, formatting, ordinary CI, red-CI repair, solo Self-Review, the integration-sensitive gate, merge, branch and temporary-asset cleanup, and renewed discovery.\n\nAn audit-only or issue-publication-only campaign does not load the development procedure or mutate repository, Actions, or GitHub state beyond the authorized publications.\n",".agents/skills/benchmark/SKILL.md":"---\nname: benchmark\ndescription: Defines typia benchmark fixture integrity, result reporting, and publication safeguards. Use before running or modifying @typia/benchmark, changing a fixture, or publishing benchmark results.\n---\n\n# Benchmark\n\nThis repository owns one benchmark system. Read its procedure in full before acting:\n\n- [performance.md](performance.md): `@typia/benchmark` throughput against competing runtime libraries, including generated programs, structure fixtures, and the per-CPU result archive.\n\n## Measurement Integrity\n\n- Measure the real product. Do not add benchmark-only branches, fixture-name checks, expected-answer checks, monkey patches, or agent restrictions that would be wrong for an unmeasured repository.\n- Give every comparator the setup its own documentation prescribes. Measuring a deliberately underconfigured competitor invalidates the comparison.\n- Preserve the workload defined by the selected procedure. A faster result obtained by validating, serializing, serving, or reading less input is not an optimization.\n- Treat a surprising result as evidence that the change is not yet understood. Inspect the raw report or trace before accepting, explaining away, or patching around it.\n\n## Fixture Changes\n\n`benchmark/src/programs/` mixes generated leaf programs with hand-maintained helpers. Edit generated `benchmark-*.ts` files through their source under `benchmark/src/template/`; edit shared `create*.ts` helpers and `benchmark/src/structures/` in place.\n\nFinish every fixture change before publishing it:\n\n1. Run the relevant template entrypoint, then the benchmark package's build commands until they finish green. `pnpm template` regenerates only the templates imported by `benchmark/src/template/index.ts`. Defer repository formatting to the development skill's final pre-merge cleanup gate.\n2. Confirm every comparator receives the same structure and input for the measured row.\n3. Review the generated-program diff. A stale or inconsistent generated program contaminates every later run.\n\nBenchmark READMEs and prose follow AGENTS.md `## Maintenance` and the documentation skill.\n\n## Report Results\n\nEvery result table reported in chat or committed to the result archive must be preserved for the active pull request. When the user has authorized PR updates under the pull-request skill, maintain one sticky comment beginning with `<!-- typia-benchmark-results -->`; update it with the latest table, report paths, and known invalid or missing categories.\n\nIf no pull request exists or no update is authorized, keep the result in the final report and mark the comment as pending. Post it only after the user creates or authorizes updating the pull request.\n\n## Campaign Batching\n\nWhen benchmark findings produce multiple implementation issues, load the issue-campaign skill and use its planning and claim procedure unchanged for the dependency DAG, claim freeze, and official GitHub `createdAt`-to-`mergedAt` duration: [Plan One Cycle Pull Request](../issue-campaign/development.md#plan-one-cycle-pull-request) for a solo campaign, or [Plan And Claim A Pull Request Wave](../multi-agent/issue-campaign.md#plan-and-claim-a-pull-request-wave) with its batch admission test, merge pressure, and grouping and split ledger when the user explicitly requested a parallel campaign. This benchmark skill continues to own workload, fixture, measurement, result, and publication integrity; do not redefine pull-request batching here.\n\n## Campaign Cleanup\n\nWhen a benchmark campaign uses a disposable worktree or an isolated measurement root, finish cleanup before marking that assignment complete. Preserve the committed result archive and compact command evidence, but remove every disposable worktree and its assigned mutable roots: `GOCACHE`, `GOTMPDIR`, `TTSC_CACHE_DIR`, generated-program scratch tree, dependency install tree, and temporary consumer or report staging tree. Go temporary assets are never reusable campaign evidence.\n\n1. Record the measured commit, command, result paths and hashes, environment, and any retained published result archive.\n2. Confirm the worktree and mutable roots contain no unreported source or result artifact.\n3. Remove the mutable roots and, for an assigned disposable worktree, run `git worktree remove --force <path>` for its exact path.\n4. Verify every removed root and, when applicable, worktree path no longer exists, run `git worktree prune`, delete the associated disposable local topic branch when one was created, and confirm no worktree registration remains.\n\nIf a measurement is abandoned or invalid, retain only the diagnostic record needed to explain it; remove its worktree and Go temporary assets by the same procedure.\n","AGENTS.md":"# AGENTS.md\n\n`typia` is a TypeScript transformer and runtime library that turns pure TypeScript types into inline validators, serializers, schemas, decoders, and random-data generators. It ships the `typia`, `@typia/interface`, `@typia/utils`, `@typia/langchain`, `@typia/mcp`, `@typia/vercel`, and `@typia/jev` packages.\n\n## Attitude\n\nFollow the literal request; it is the contract, not a hint at what the user \"really\" wants.\n\n- **Scope is the user's to widen.** Reinterpret the goal, weigh alternatives, or expand the task only on an explicit hand-off (\"figure it out\", \"you decide\"). Take a confident, specific ask as given.\n- **Fidelity binds the goal, not the effort.** Within that goal, act with full initiative: do the substeps it needs, verify your work, surface what you notice. Literal scope is no excuse for passive execution.\n- **Match the user's language.** Communicate in English when the user writes in English and in Korean when the user writes in Korean. Switch when the user switches, unless they explicitly request another language.\n- **Choose the principled course.** Decide from evidence, correctness, product boundaries, and the durable consequence. Time, difficulty, and consequence surface are reasons to investigate and validate more carefully, never reasons to settle for a shortcut, workaround, or weaker standard.\n- **Evidence precedes correction.** Treat issue reports, review proposals, and claims that something is wrong or missing as hypotheses. Verify the real code path, tests, generated artifacts, upstream ownership, and history before accepting the premise or changing behavior.\n- **Trace the consequence surface.** A named file or failing case is the starting point, not the investigation boundary. Follow the same cause through downstream consumers, side effects, state transitions, platforms, and boundary cases, then address the whole verified class of failure within the requested goal.\n- **Collect every symptom before correcting.** Finish the test run, CI run, reproduction, or review round that produced a finding before repairing it. Group all findings by cause, trace their consequences, and correct the complete verified set together.\n- **Default over ask.** On an ambiguous detail, pick the sensible default and say what you chose; reserve questions for forks only the user can settle.\n\n## Skills\n\nDurable project conventions and workflows live under `.agents/skills/`. Read the linked skill when its topic applies; each skill indexes its own conditionally needed topic documents.\n\n### Project Outline\n\nWhat typia is, the package family, the JS-descriptor / Go-plugin boundary, the workspace layout, product boundaries, and canonical commands, `.agents/skills/project/SKILL.md`.\n\n### Development\n\nWork rules, testing, validation, consequence analysis, and change integrity, `.agents/skills/development/SKILL.md`. Read before writing or modifying code.\n\n### Implementation Contracts\n\nSelf-acknowledgments for maintained production declarations, unit tests, and E2E tests, `.agents/skills/contracts/SKILL.md`. Read when implementing or reviewing those declarations or selecting Evidence checklists.\n\n### Documentation\n\nREADME, website guide, and agent-instruction authoring rules, `.agents/skills/documentation/SKILL.md`. Read before writing or modifying documentation.\n\n### Issue Campaigns\n\nDefault solo repository-wide issue discovery, issue publication, one CI-validated implementation pull request per cycle, and renewed discovery, `.agents/skills/issue-campaign/SKILL.md`. Read when the user asks for a broad audit, many issue candidates, or an issue-to-implementation campaign without explicitly requesting parallel agents; do not use it for one already-defined issue.\n\n### Review\n\nDefault solo Self-Review, unqualified review, and exhaustive issue-discovery rounds, `.agents/skills/review/SKILL.md`. The reviewer inspects the whole declared surface and repeats fresh rounds until a complete pass produces no sound improvement or meaningful issue candidate.\n\n### Multi-Agent Workflows\n\nExplicitly parallel review and issue-campaign variants live under one entry point, `.agents/skills/multi-agent/SKILL.md`. Read it only when the user explicitly asks for a team, parallel, or multi-agent workflow. Multi-agent issue campaigns parallelize discovery and implementation by default and switch to solo implementation only on an explicit discovery-only parallel request; Self-Review remains solo.\n\n### Discussion\n\nStructured multi-agent topic discussion with persistent research notes and transcripts, `.agents/skills/discussion/SKILL.md`. Read only when the user explicitly asks for a discussion; review and issue discovery do not imply discussion.\n\n### Pull Request Submission\n\nBranch, commit, pull request, check, and merge flow, `.agents/skills/pull-request/SKILL.md`. Read when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, or propose one on unprompted initiative.\n\n### Benchmark\n\nBenchmark runners, fixture integrity, measurement integrity, result archives, and publication, `.agents/skills/benchmark/SKILL.md`. Read before running, modifying, or publishing benchmark results.\n\n## Maintenance\n\n### Writing style\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans as well as agents. Read the documentation skill before editing either; it defines concise, clear agent-instruction writing and the prose-line rule.\n\n### AGENTS.md\n\nThis is the single shared entry point for both Claude Code (via `CLAUDE.md -> @AGENTS.md`) and Codex CLI. Keep it to the brief product identity, global attitude, and skill index. The H2s are `## Attitude`, `## Skills`, and `## Maintenance`; `## Attitude` is the one place global agent-behavior rules live.\n\nUpdate AGENTS.md only for repository-contract changes: a new skill area, a renamed or merged skill, a workflow that no longer fits an existing skill, a release-process change, or a coding-agent rule that applies globally before any skill loads.\n\n### Skills\n\n- **Location.** `.agents/skills/<kebab-name>/SKILL.md`. No numeric prefix. Each file opens with YAML frontmatter whose `name` matches the directory and whose third-person `description` states what the skill covers and when to use it.\n- **Core in SKILL.md, conditional topics as sibling documents.** Keep always-applicable procedure in SKILL.md. Move a topic needed only under a specific condition to a one-level-deep sibling document and link it with that read condition.\n- **Two trigger surfaces, one scope.** The frontmatter description is the full trigger contract, including exclusions. The AGENTS.md pointer mirrors that scope more briefly. Correct the frontmatter first when the scope changes.\n- **Create or merge.** Add a skill when a substantial repository concern would otherwise inflate AGENTS.md beyond an index. Merge sibling concerns when they share most of their structure.\n- **Repository skill files only.** Keep repository skills to `SKILL.md` and conditionally loaded sibling documents. Do not add separate `multi-agent-*` skills; the parallel variants live under the one `multi-agent` skill.\n- **Headings are plain.** No chapter numbers in skill or AGENTS.md headings. Use descriptive titles.\n- **Current set.** The repository skills are `project`, `contracts`, `development`, `documentation`, `issue-campaign`, `review`, `multi-agent`, `discussion`, `pull-request`, and `benchmark`.\n",".agents/skills/development/SKILL.md":"---\nname: development\ndescription: Defines typia implementation rules, testing standards, validation, consequence analysis, and change integrity. Use before writing or modifying source, tests, workflows, package wiring, fixtures, generated baselines, or algorithms.\n---\n\n# Development\n\n## Contents\n\n- [Forbidden](#forbidden)\n- [Work Rules](#work-rules)\n- [Consequence Analysis](#consequence-analysis)\n- [Plugin Configuration](#plugin-configuration)\n- [Testing](#testing)\n- [Validation](#validation)\n- [Change Integrity](#change-integrity)\n- [Evidence Adoption](#evidence-adoption)\n\n## Forbidden\n\nRead the [contracts skill](../contracts/SKILL.md) before changing maintained production declarations. Its common checklist owns implementation acknowledgments; scoped checklists apply by responsibility. When a failure disproves an assumption, correct its owner and remove superseded compensations in the same repair.\n\nThese four are never acceptable; choosing any one means the approach is already wrong.\n\n- **No monkey-patching or hardcoding.** Don't special-case a consumer, a fixture name, or an expected value to make output match. Fix the general logic.\n- **No test-passing-only logic.** Code exists to be correct, not to turn a check green. A branch whose only purpose is to satisfy one assertion is a bug in disguise.\n- **No forcing a broken design.** When the same failure keeps returning under patch after patch, the design is wrong. Stop, find the root cause, and fix the design instead of looping forever on symptoms.\n- **No whack-a-mole.** Don't patch the one case that surfaced and move on. Think expansively about every case the same root cause can produce, and seal them all with coverage so the class of failure cannot recur.\n\n## Work Rules\n\n- Choose the principled course. Time, difficulty, and the breadth of consequences require more careful analysis and validation; they never justify a shortcut, leaving a verified consequence unaddressed, or a weaker acceptance standard.\n- Match existing conventions. Before adding a file, function, or test, open a nearby peer and mirror its naming, location, and code style; don't create parallel structures.\n- Respect package boundaries. The shared native transform lives under `packages/typia/native`; don't fork a second transform into an adapter package or reintroduce a TypeScript-side transformer.\n- Keep package detection installation-safe. Resolve the target package root, as `packages/typia/src/transform.ts` does with `require.resolve(\"typia/package.json\")`; workspace path substrings and hard-coded fixture names fail for npm consumers.\n- Use the workspace catalogs. `pnpm-workspace.yaml` owns `samchon`, `typescript`, `rolldown`, and `utils`; the ttsc family, Evidence, tstl and tgrid use `catalog:samchon`, and internal package references use `workspace:^`.\n- Keep local outputs local. Do not commit `.env` files or the `.tgz` artifacts generated under `experiments/tarballs/`.\n- Preserve the public contract in `.agents/skills/project/SKILL.md`. Renaming or removing `typia.*`, `@typia/interface` types, or the plugin descriptor shape is a deliberate product change, not incidental cleanup.\n- When public behavior changes, update the matching page under `website/src/content/docs/**` in the same change. Follow `.agents/skills/documentation/SKILL.md`.\n- Run `pnpm format` only in the final pre-merge cleanup after implementation and CI repairs are complete, not before each commit or push. Commit its integrated result and require green CI on that final head before merging. If later edits require formatting, return to this final cleanup gate. Parallel issue-campaign implementation batches defer the repository-wide formatter to their dedicated Post-Campaign Cleanup pull request.\n\n## Consequence Analysis\n\nTreat a reported example as one witness of a cause, not the complete problem statement. Before changing code, trace the same cause through:\n\n- every caller and downstream consumer;\n- normal, error, and recovery state transitions;\n- concurrency, caching, and generated output;\n- Windows and POSIX behavior;\n- compatibility constraints and boundary inputs.\n\nFix the verified class of failure, not only the reported witness. Cover positive, negative, and boundary cases without expanding the user's product goal.\n\n## Plugin Configuration\n\n`ttsc` discovers typia by default from the `ttsc.plugin.transform` entry in `packages/typia/package.json`. Consumer projects add a `compilerOptions.plugins` entry with `transform: \"typia/lib/transform\"` only when they need to set optional transform flags.\n\n`packages/typia/src/transform.ts` is a JavaScript descriptor source, not a transformer. It resolves the installed typia package and returns the Go command at `packages/typia/native/cmd/ttsc-typia`; `ttsc` builds that source into the workspace cache. Keep type analysis, AST rewriting, diagnostics, and typia-owned options (`functional`, `numeric`, `finite`, and `undefined`) on the Go side.\n\nTest workspaces normally use `typia/lib/transform`. Source-only workspaces such as the benchmark may point at `typia/src/transform.ts`, but that still loads the same descriptor and native command. Do not add a second plugin host to make a local layout pass.\n\n## Testing\n\nRead the [testing contracts](../contracts/testing.md) for every test and the [E2E contracts](../contracts/e2e.md) when it exercises a necessary real component boundary. Classify by actual execution, not language, directory name, filesystem use, or duration. Maintained helpers answer production contracts when they own implementation decisions.\n\n**One test case per file, named after what it asserts.** This is the rule for new and changed cases in both languages, even where older files predate it.\n\n### Go tests\n\n- **Public and contract tests:** keep black-box and exported-API coverage under `packages/typia/test/**`, mirroring the native concern where practical. These tests import the native module through `packages/typia/test/go.mod` and run with `pnpm test:go:public`.\n- **Colocated native tests:** keep same-package implementation, command, transform, and emitter coverage beside the Go source as `packages/typia/native/**/*_test.go`. Untagged cases run with `pnpm test:go:native`.\n- **Native-internal tagged tests:** use `//go:build typia_native_internal` only when the case requires internal-only coverage. Root `pnpm test:go` does not enable that tag; run `go -C packages/typia/test test -tags typia_native_internal ../native/...` when tagged coverage is relevant.\n\nUse one `Test*` function per test file and mirror a nearby test's package, fixture, and cleanup pattern. Command-level transform regressions belong near `packages/typia/native/cmd/ttsc-typia`; public contract probes belong under `packages/typia/test`.\n\n### TypeScript suites\n\n`pnpm test:packages` starts every `tests/test-*` workspace. They have these shapes:\n\n- **Function-per-file:** `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, and `test-utils` discover `src/features/**/test_*.ts` through `DynamicExecutor`. Export exactly one `test_<snake_case>` function from a matching filename. `DynamicExecutor` selects and reports a test by its exported name, so a name that disagrees with its file makes the test unreachable by that file's name. `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` additionally run portable unit cases from `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` without the native plugin (`pnpm --filter ./tests/<workspace> test:unit`); they follow the same one-function-per-file naming rule.\n- **Generated matrices:** `test-typia-automated` and `test-utils-automated` delete and regenerate `src/features/**` when they run. Do not hand-edit those trees. Change the controller/template metadata or `@typia/template`; keep the committed ObjectSimple composite layer in `test-typia-automated/src/composite/**` hand-maintained.\n- **Transform rejection:** `test-error` compiles invalid call sites and asserts the diagnostics that reject them. A failed build publishes no output, so the suite reads no emitted JavaScript: it requires the build to fail, every fixture to typecheck, and every fixture to be named by a typia diagnostic. Add cases beside their feature group, and keep each fixture valid TypeScript that only typia rejects — a type error aborts the build before the transform runs and would leave the suite with nothing to observe.\n- **Type compilation:** `test-interface` is a compile-only TypeScript `tsc --noEmit` suite for `@typia/interface` type contracts and public typia signatures; type-only factory checks execute no factory.\n\nUse `TestValidator` and `DynamicExecutor` from `@nestia/e2e`, `@typia/template` structures and `TestServant`, and each suite's local `internal/` helpers. Do not reach into another suite's internals or duplicate a reusable structure inside one test workspace.\n\nAssert structural equality with `TestEquality` from `@typia/template/equality`. Its `equals` is symmetric and compares `Date`, `Map`, and `Set` by content; use `subset` only when an assertion pins some fields of a larger result on purpose, with the expected value first. Never call `TestValidator.equals`: it walks only its first argument's keys and sees no content in dates, maps, or sets, so it passes whatever the actual lost (#2401). Never call `TestValidator.error` either: on a synchronous task it swallows its own failure and passes whether or not the task throws (#2460). Assert a synchronous throw by comparing `TestEquality.thrown(task)` with the expected message, and an asynchronous one by awaiting `task().then(() => undefined, (error: unknown) => error)` and comparing what it rejects with. Compare prototypes and other identities with `===`.\n\nOpen every new or materially changed case with a doc comment in the same three-part shape: a one-line `Verifies ...` headline, a short paragraph stating the non-obvious _why_ (which branch or regression is being pinned), and a 2+-step numbered list summarizing the scenario.\n\n```ts\n/**\n * Verifies typia.llm.schema emits `anyOf` for a discriminated union.\n *\n * Locks the union branch of the LLM schema converter. A regression in branch\n * selection would silently emit one variant and lose the other from the\n * function-calling schema.\n *\n * 1. Declare two object variants with a shared discriminator.\n * 2. Generate the LLM schema for their union.\n * 3. Assert both variants remain in the emitted `anyOf`.\n */\nexport const test_llm_schema_anyof = (): void => {\n  /* ... */\n};\n```\n\n### Coverage, not happy paths\n\nA test that only feeds a transform its ordinary successful input and asserts that the result is accepted proves one path, not correctness. The native transformer spans validators, serializers, schemas, decoders, diagnostics, and generated helpers; each predicate or branch needs more than its happy path:\n\n- **The transformation direction.** When a call should be rewritten, assert observable emitted or runtime behavior that differs from the untransformed stub. For generators, start from hand-written input and verify the generated output, not only that an existing output compiles.\n- **A negative twin for every positive.** Wherever a predicate accepts, rewrites, narrows, serializes, or reports a diagnostic, pin an adjacent case one property away where it must not do so. An over-match stays invisible until the counter-example exists.\n- **Boundaries.** Cover the empty case, the single-element case, recursion limits, optional and nullable members, exact numeric limits, deepest nesting, and the tag or compiler option that flips the decision.\n- **Oracle-derived expectations.** Take expected behavior from TypeScript semantics and the authoritative JSON Schema, OpenAPI, Protocol Buffer, or adapter contract, never from whatever the current code happens to emit. A snapshot written against the implementation's own output locks its bugs in.\n\nThis is not a validator-only rule. The same happy-path bias hides serializer corruption, schema loss, compiler-process failures, and native diagnostic regressions, so every feature carries the burden.\n\n## Validation\n\nRun the narrowest command that proves the change first, then a broader command when shared behavior, the transform, packaging, or documentation changed. Report any command that could not be run.\n\n- **One public Go concern:** `pnpm test:go:public`.\n- **One native Go concern:** `pnpm test:go:native`; add the tagged command from [Go tests](#go-tests) when the changed path has `typia_native_internal` coverage.\n- **One TypeScript workspace:** `pnpm --filter ./tests/<name> start`.\n- **One package:** `pnpm --filter ./packages/<name> build`.\n- **Transform, descriptor, or shared package:** `pnpm test`; use `pnpm build` as the broader package compilation gate.\n- **Packaging:** run root `pnpm package:tgz`, then inspect or smoke-test a clean install. It builds every package and verifies the published entry points before packing (`pnpm pack` alone no longer builds; the manifests carry no `prepack`). Tarballs are generated under `experiments/tarballs/`; do not commit or hand-edit them.\n- **Website or guide changes:** reproduce the fresh CI prerequisites: place a ttsc checkout at `../ttsc`, run root `pnpm install` and `pnpm package:tgz`, then run `pnpm build` inside `website/`. The compiler-dependencies package installs the staged tarballs, and the playground Wasm build resolves the sibling ttsc Go modules.\n\nVerification shape depends on the change type:\n\n- **Bug fix:** name the failing case and the expected behavior; run a repro that fails before the fix and passes after.\n- **Feature:** name the observable behavior; exercise it end-to-end.\n- **Refactor:** name what should stay unchanged; rely on the existing test suite or a behavior-locking probe.\n- **Review:** name concrete risks, missing tests, or regressions.\n\n## Change Integrity\n\nTreat tests, fixtures, snapshots, CI workflows, package wiring, dependencies, core algorithms, generated baselines, and benchmark results as part of the specification. Changing them requires an explicit user request or a clear product reason, and the final report must call it out.\n\nGo source under `packages/typia/native` must ship under a `typia` version newer than the latest published package because npm consumers otherwise continue to install the previous native source tree. Assign that version once in a maintainer-owned release change; multiple unreleased native changes belong to the same future release instead of consuming one patch number each. Issue implementation pull requests never change package versions. A maintainer-owned release change may begin only after campaign completion, or after the user explicitly suspends the campaign and lifts the freeze, and it uses the version the user assigned.\n\nFor mechanical ports, migrations, or broad rewrites, preserve the existing algorithm and public behavior in reviewable slices. Prefer a concrete exemplar over abstract instructions, and inspect the diff before trusting a green test run.\n\n## Evidence Adoption\n\nEach production package's `evidence.config.json` selects the files that directly declare and export its maintained TypeScript and Go types and functions and references `contracts/common.md` under `../../.agents/skills`. Pure re-export barrels own no selected declaration; review their public wiring through package and consumer checks while selecting each symbol at its direct declaration. If declarations and foreign re-exports share a file, separate the declaration owner without dropping public aliases or changing behavior, and update the transformer's declaration identity when necessary. Properties retain native documentation and are reviewed through their type. Add portability and performance chapters only to the operations that own those decisions.\n\nEvery enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`. Selected tests answer `contracts/testing.md`; actual E2E boundaries also answer `contracts/e2e.md`. Unit populations, types, runners and support declarations are outside this Evidence selection while their ordinary test execution remains intact. The template and both automated workspaces have no Evidence configuration or script.\n\nRun root `pnpm evidence` to collect every enrolled owner without stopping at its first failure. Use `pnpm --filter <package> evidence` for one production owner and `pnpm evidence:tests` for tests. JSON configuration keeps the checker independent of compiling typia or evaluating a TypeScript configuration. The existing build workflow owns the CI gate; acknowledgments do not replace behavioral tests.\n\nFor an Evidence truth audit, complete the first source inspection and improvements across the entire selected population and its private helpers before any local build, test, checker run, or executable probe. Use source and history inspection during that pass. Formatting remains the final pre-merge cleanup gate. After the first pass, collect each necessary integrated validation once; repeat only for a new change, failure, or unresolved concern. A coordinator assigns disjoint owners, collects returned findings, resolves shared causes, and prevents duplicate inventories, builds, and validation by individual reviewers.\n\n1. Finish the complete report before repairing obligations. Group missing answers, code and documentation defects, selection mistakes, generated-source provenance, and incomplete analysis by cause.\n2. Inspect each selected declaration and its private helpers against every applicable chapter. Fix verified defects before writing the answer; the acknowledgment describes the resulting implementation.\n3. Write `@evidence contracts/<document>.md#<anchor> <reason>` in native documentation, separated from descriptive prose by a blank comment line. Address the actual question for that declaration. Use `@evidenceExclude` only for a genuinely inapplicable individual chapter with its concrete reason.\n4. Account for private helpers, anonymous callbacks, dynamically registered cases, script entry bodies, and compile-only cases from their source and runners. Make executable entries selectable within the configured population where practical; record remaining review-only coverage honestly. Preserve compiler visibility tags such as `@internal`; removing them can change emitted declarations. Explain unaddressable helpers in their actual calling operation's acknowledgment and record their review-only scope. After the complete first pass, use `pnpm exec evidence list --config <config>` or `pnpm exec evidence inspect '<target>' --config <config>` only for unresolved address or resolution questions.\n5. Check the complete population after the first pass and its improvements finish. Verify composed claims together, including local re-export resolution. Keep the issue open and PR draft while obligations or incomplete analysis remain, and record progress as formal PR reviews.\n\nDo not weaken severity, narrow a maintained population, add generic compliance prose, or exclude a whole document to silence obligations. Exclude generated output, copied fixture input, dependencies and build output only with verified provenance. Authored generators and helpers remain maintained source; their maintenance does not enroll them in Evidence. Generated cases in the two automated workspaces remain executed through their ordinary runners and are outside Evidence. Verify selected feature functions against their actual runners without expanding the configured population to every executed declaration.\n","packages/vercel/package.json":"{\n  \"name\": \"@typia/vercel\",\n  \"version\": \"15.1.0\",\n  \"description\": \"Vercel AI SDK integration for typia\",\n  \"main\": \"src/index.ts\",\n  \"exports\": {\n    \".\": \"./src/index.ts\",\n    \"./package.json\": \"./package.json\"\n  },\n  \"scripts\": {\n    \"build\": \"rimraf lib && ttsc && rolldown -c\",\n    \"dev\": \"ttsc --watch\",\n    \"evidence\": \"evidence\"\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"https://github.com/samchon/typia\"\n  },\n  \"author\": \"Jeongho Nam\",\n  \"license\": \"MIT\",\n  \"bugs\": {\n    \"url\": \"https://github.com/samchon/typia/issues\"\n  },\n  \"homepage\": \"https://typia.io\",\n  \"dependencies\": {\n    \"@typia/interface\": \"workspace:^\",\n    \"@typia/utils\": \"workspace:^\"\n  },\n  \"peerDependencies\": {\n    \"ai\": \">=6.0.0\"\n  },\n  \"devDependencies\": {\n    \"@types/json-schema\": \"^7.0.15\",\n    \"ai\": \"^6.0.116\",\n    \"rimraf\": \"catalog:utils\",\n    \"rolldown\": \"catalog:rolldown\",\n    \"tinyglobby\": \"^0.2.12\",\n    \"ttsc\": \"catalog:samchon\",\n    \"typescript\": \"catalog:typescript\"\n  },\n  \"sideEffects\": false,\n  \"files\": [\n    \"README.md\",\n    \"package.json\",\n    \"lib\",\n    \"src\"\n  ],\n  \"keywords\": [\n    \"vercel\",\n    \"ai-sdk\",\n    \"typia\",\n    \"llm\",\n    \"llm-function-calling\",\n    \"ai\",\n    \"tool-calling\",\n    \"openai\",\n    \"anthropic\",\n    \"claude\",\n    \"chatgpt\",\n    \"gemini\",\n    \"validation\",\n    \"json-schema\"\n  ],\n  \"packageManager\": \"pnpm@10.6.4\",\n  \"publishConfig\": {\n    \"access\": \"public\",\n    \"main\": \"lib/index.js\",\n    \"module\": \"lib/index.mjs\",\n    \"types\": \"lib/index.d.ts\",\n    \"exports\": {\n      \".\": {\n        \"types\": \"./lib/index.d.ts\",\n        \"import\": \"./lib/index.mjs\",\n        \"default\": \"./lib/index.js\"\n      },\n      \"./package.json\": \"./package.json\"\n    }\n  }\n}\n","packages/vercel/README.md":"# vercel Documentation\n\nPath: `packages/vercel/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/README.md)","packages/vercel/tsconfig.json":"# Vercel Skill\n\nPath: `packages/vercel/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/tsconfig.json)","packages/utils/package.json":"# Utils Skill\n\nPath: `packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/package.json)","packages/utils/README.md":"# utils Documentation\n\nPath: `packages/utils/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/README.md)","packages/utils/tsconfig.json":"# Utils Skill\n\nPath: `packages/utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/tsconfig.json)","packages/typia/package.json":"# Typia Skill\n\nPath: `packages/typia/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/package.json)","packages/typia/tsconfig.json":"# Typia Skill\n\nPath: `packages/typia/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/tsconfig.json)","packages/typia/typedoc.json":"# Typia Skill\n\nPath: `packages/typia/typedoc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/typedoc.json)","packages/mcp/package.json":"# Mcp Skill\n\nPath: `packages/mcp/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/package.json)","packages/mcp/README.md":"# mcp Documentation\n\nPath: `packages/mcp/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/README.md)","packages/mcp/tsconfig.json":"# Mcp Skill\n\nPath: `packages/mcp/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/tsconfig.json)","packages/langchain/package.json":"# Langchain Skill\n\nPath: `packages/langchain/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/package.json)","packages/langchain/README.md":"# langchain Documentation\n\nPath: `packages/langchain/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/README.md)","packages/langchain/tsconfig.json":"# Langchain Skill\n\nPath: `packages/langchain/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/tsconfig.json)","packages/interface/package.json":"# Interface Skill\n\nPath: `packages/interface/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/package.json)","packages/interface/README.md":"# interface Documentation\n\nPath: `packages/interface/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/README.md)","packages/interface/tsconfig.json":"# Interface Skill\n\nPath: `packages/interface/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/tsconfig.json)",".agents/skills/multi-agent/issue-campaign.md":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/issue-campaign.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/issue-campaign.md)",".agents/skills/multi-agent/review.md":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/review.md)",".agents/skills/issue-campaign/development.md":"# Issue-campaign Skill\n\nPath: `.agents/skills/issue-campaign/development.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/development.md)",".agents/skills/benchmark/performance.md":"# Benchmark Skill\n\nPath: `.agents/skills/benchmark/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/performance.md)","packages/typia/test/protobuf_varint_corpus.json":"# Test Skill\n\nPath: `packages/typia/test/protobuf_varint_corpus.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/test/protobuf_varint_corpus.json)"},"files":{".agents/skills/project/SKILL.md":"---\nname: project\ndescription: Defines the typia product contract, workspace layout, package boundaries, and canonical commands. Use when orienting in the repository, working inside any package, or choosing a build, test, or format command.\n---\n\n# Project Outline\n\n## Product Contract\n\nTypia is a TypeScript transformer library built around one idea: a pure TypeScript type definition should replace the runtime helpers that other tools require schemas, decorators, or hand-written guards for. The compile-time transform reads those types and emits the runtime validator, serializer, schema, or decoder inline.\n\nThe packages:\n\n- **`typia`**: the user-facing library and native transform. Exposes the runtime validators (`is`, `assert`, `assertGuard`, `validate`), enhanced JSON serde (`json.assertParse`, `json.assertStringify`, `json.schema`), LLM function-calling harness (`llm.application`, `llm.schema`, `llm.parse`, `llm.structuredOutput`, `llm.evaluation`), Protocol Buffer encoder/decoder (`protobuf.message`, `protobuf.assertEncode`, `protobuf.assertDecode`), and the random data generator (`random`).\n- **`@typia/interface`**: shared public typings (e.g. `IJsonSchemaCollection`, `ILlmSchema`, `IValidation`) consumed by every other package and by user code.\n- **`@typia/utils`**: runtime, OpenAPI, and LLM utility helpers (e.g. `LlmTypeChecker`) that live next to but outside the transform.\n- **`@typia/langchain`**: LangChain.js integration that adapts typia's LLM harness to LangChain tools.\n- **`@typia/mcp`**: Model Context Protocol integration.\n- **`@typia/vercel`**: Vercel AI SDK integration.\n- **`@typia/jev`**: Jev evaluation model integration, converting `llm.evaluation` questions to the Jev wire format.\n\nDownstream projects (`@nestia/core`, `@agentica`, `@autobe`) build on top of typia but are not part of this repository's contract. The exported `typia.*` surface, the `@typia/interface` typings, and the `ttsc.plugin` descriptor shape are public; renaming or removing any of them is a deliberate, separate change.\n\nA single Go program under `packages/typia/native` performs the compile-time transform that emits validators, stringifiers, schemas, and decoders in place of `typia.*<T>()` call sites. `packages/typia` registers a Go command package that `ttsc` (the TypeScript-Go compiler with native plugin support) compiles into a binary on first use through its plugin manifest:\n\n```json\n\"ttsc\": { \"plugin\": { \"transform\": \"typia/lib/transform\" } }\n```\n\nThe `packages/typia/src/transform.ts` file is a plugin descriptor, not a transformer; there is no TypeScript-side transform anymore. The descriptor resolves the installed `typia` package root and returns the Go entrypoint under `native/cmd/ttsc-typia`. The adapter packages do not register their own transforms. Consumers reach the binary through `ttsc` / `ttsx` and the published descriptor. ttsc keys each plugin build by content and stores it workspace-wide under `node_modules/.cache/ttsc` (it walks up to `pnpm-workspace.yaml`), so every package and test workspace shares one binary.\n\n## Layout\n\n- `packages/*`: the published packages, including the shared Go plugin under `packages/typia/native`. Public and contract Go tests live under `packages/typia/test`; native Go tests are colocated throughout `packages/typia/native/**`. The test `go.work` resolves `ttsc` and its shims through `../node_modules/`, while the native development `go.work` resolves the sibling `ttsc` checkout.\n- `tests/template`: `@typia/template`, a workspace package that ships the structure fixtures (`ObjectSimple`, `ArrayHierarchical`, ...) and the `TestServant` runtime helper consumed by the automated suites.\n- `tests/test-*`: feature-test workspaces:\n  - `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, `test-jev`, `test-utils`: function-per-file suites under `src/features/**/test_*.ts`, each file exporting one matching `test_<snake_case>` function discovered by `DynamicExecutor` (from `@nestia/e2e`).\n  - `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` also hold portable cases under `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` by `src/unit/index.ts` under `tsconfig.unit.json`, which has no native typia plugin. Their `start` runs the unit population before the integration population. Portable utility and adapter semantics belong in the unit population; preserve each exported case's inputs, assertions and failure identity when transferring it from a transformed suite.\n  - `test-typia-automated`, `test-utils-automated`: generator-driven matrix suites over their configured typia operations and `@typia/template` structures; their generated `src/features/` trees are rebuilt by the suite.\n  - `test-interface`: compile-time tests for exported `@typia/interface` types and public typia signatures; these cases execute no typia factory.\n  - `test-error`: transform-rejection verification; the build must fail and every fixture must be named by a typia diagnostic.\n- `tests/debug`: `@typia/debug`, a one-off `ttsx` runner for ad-hoc local repros.\n- `benchmark/`: `@typia/benchmark`, performance generators with archived results under `benchmark/results/**`. See `.agents/skills/benchmark/SKILL.md`.\n- `website/src/content/docs/**`: user-facing MDX guides published at https://typia.io/docs. See `.agents/skills/documentation/SKILL.md`.\n- `examples/`, `experiments/`, `scripts/`, `config/`: example sources, tarball staging, repo utilities, and shared build configuration.\n\n## Commands\n\nCI uses Node 24.x and Go 1.26.x, while the workspace pins pnpm exactly to 10.6.4.\n\n```bash\npnpm install\npnpm evidence\npnpm format\npnpm build\npnpm test\n```\n\n`pnpm test` runs every `tests/test-*` workspace through `pnpm test:packages`, then runs both Go trees through `pnpm test:toolchain`: `go -C packages/typia/test test ./...` and `go -C packages/typia/test test ../native/...`. It needs `go` on `PATH`. Run `pnpm install` first, or the test Go workspace cannot resolve `ttsc` and its shims through `../node_modules/`. Most feature workspaces execute TypeScript directly through `ttsx`; `test-error` uses a Node harness and `test-interface` invokes TypeScript `tsc --noEmit`. Plugin-building workspaces share the cache under `node_modules/.cache/ttsc`.\n\n`pnpm evidence` checks every enrolled production owner, test feature function, and root tooling configuration without building or generating test matrices. Every enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`; unit populations, types, runners and support declarations are outside this selection while their ordinary execution remains intact. `pnpm evidence:packages` and `pnpm evidence:tests` check their enrolled workspace populations separately. The template and both automated test workspaces are not enrolled; their ordinary generation and test commands retain their behavioral coverage.\n\nRelease-time commands (most contributors skip these): `pnpm package:rc`, `pnpm package:next`, `pnpm package:latest`, and `pnpm release`. `pnpm package:tgz` stages local tarballs in `experiments/tarballs/` for offline testing. See `.agents/skills/pull-request/SKILL.md` for the remote delivery flow.\n",".agents/skills/discussion/SKILL.md":"---\nname: discussion\ndescription: Runs structured multi-agent discussions for open-ended typia topics. Use only when the user explicitly asks for Discussion or a team debate with transcripts and conclusions; do not use for Self-Review, a solo or multi-agent review, research review, or issue discovery.\n---\n\n# Discussion\n\nDiscussion explores a topic without changing code or turning the exchange into a review queue. Reviews and issue discovery use the review skill instead.\n\n## Team\n\nForm the largest practical team, up to nine agents so the lead and participants fit the ten-agent session limit. Give every agent a self-contained brief with the topic, constraints, known evidence, output expectations, and the exact repository instructions and skills to read. Do not give a preferred conclusion or divide the topic into assigned slices.\n\n## Knowledge Base\n\nCreate `.discussions/<topic>/` with a short filesystem-safe name. Do not delete or overwrite an existing discussion directory unless the user explicitly requests it.\n\nEach agent maintains a personal wiki-style subdirectory under the topic directory. Agents read the live transcript and one another's statements between turns, continue researching, and revise their own notes.\n\n## Transcript\n\nRun three unrestricted transcript rounds as `round1.md`, `round2.md`, and `round3.md`. The lead moderates and records every statement in speaking order as a live transcript, not a retrospective summary. Do not narrow the topic unless the user does.\n\nAfter `round3.md`, the lead writes agreed conclusions, disagreements, and major open points to `summary.md`, reports the result, and waits. Discussion does not itself authorize implementation.\n",".agents/skills/multi-agent/SKILL.md":"---\nname: multi-agent\ndescription: \"Defines the explicitly parallel variants of typia review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review and unqualified review remain solo. Multi-agent issue campaigns parallelize discovery and implementation by default, but an explicit request may limit parallelism to discovery and return implementation to the solo campaign.\"\n---\n\n# Multi-Agent Workflows\n\nThis skill is the single entry point for every explicitly parallel review or campaign. Read the base solo skill first, then enter through the detailed document below for the requested workflow. That document names any shared multi-agent topic procedures it also requires.\n\n| Explicit request | Base skill | Detailed multi-agent procedure |\n| --- | --- | --- |\n| Team, parallel, or multi-agent review | [review](../review/SKILL.md) | [review.md](review.md) |\n| Parallel or multi-agent issue campaign | [issue-campaign](../issue-campaign/SKILL.md) | [issue-campaign.md](issue-campaign.md) |\n\n`typia` has no benchmark-campaign skill. Use [benchmark](../benchmark/SKILL.md) for measurement integrity, then the applicable issue-campaign workflow for authorized benchmark-driven implementation.\n\nDo not load this skill for Self-Review, an unqualified review, a discussion, or a campaign that does not explicitly request parallel agents.\n\n## Shared Parallelism Rules\n\n- Use the smallest number of agents that adds independent evidence or owns immediately executable disjoint work. Available thread capacity is not a reason to create an agent, and a review or discovery round is the one place where every available slot should carry a full independent pass.\n- Keep the total at ten agents including the lead, so at most nine children run at once.\n- Never create a waiter, poller, coordinator-only child, duplicate implementation owner, or agent that cannot begin useful work immediately.\n- Give every review or discovery agent the complete declared surface. Parallel review adds independent full passes; it never partitions coverage by package, file, concern, platform, or test lane.\n- Partition implementation only through verified dependency and file-ownership boundaries. One agent owns one coarse batch, branch, pull request, and worktree.\n- Keep the lead active on fact-checking, integration, conflict resolution, and decisions that do not duplicate an assigned agent.\n- Do not let agents re-delegate.\n- Self-Review remains solo for every author and every implementation branch. An independent verifier or critic is a separate agent auditing someone else's work, never a substitute for the author's own round.\n- Create worktrees only for parallel implementation batches, verification, mutation, and integrated cleanup. Solo implementation and review use the current checkout.\n- Remove every finished worktree, local branch, process, and assignment-owned temporary asset before declaring its assignment complete.\n\nThe solo campaign's [commit early-warning pass](../review/SKILL.md#commit-early-warning-pass) is a different topology and relaxes neither the full-surface rule nor the solo Self-Review rule above. A parallel review gives several reviewers the entire declared surface independently and the lead adjudicates their findings. The pass gives one read-only reader one commit's slice, reports candidates to the author who is still implementing, and leaves that author's own whole-surface round as the gate. A batch implementation agent here runs no pass, because agents do not re-delegate; the carve-out in the solo development procedure belongs to a solo campaign's main agent.\n",".agents/skills/pull-request/SKILL.md":"---\nname: pull-request\ndescription: Defines typia branch, commit, pull-request, check, and merge workflows. Use when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, update, or merge one on unprompted initiative.\n---\n\n# Pull Request Submission\n\nAct on this skill only when the user explicitly requests the corresponding remote action, or when a standing autonomous mandate authorizes it. Permission to edit locally is not permission to push or open a pull request, and permission to open or update is not permission to merge. The one exception is a standing autonomous mandate — an autonomous or remote-control campaign, or an explicit instruction to carry the work through merge: it is the request for every step it names, including push and merge, and the skill's check, verification, and self-review gates still apply to each step.\n\n## Branch From The Target\n\nBranch from the pull-request target (`master` unless stated otherwise); never commit or push directly to the target. Name the branch for the merged outcome with the repository's established type and scope, such as `feat/<scope>`, `fix/<scope>`, `docs/<scope>`, or `ci/<scope>`.\n\nSolo work never creates a clone or worktree. If the current checkout contains unrelated or protected work, stage only the authorized paths; if that cannot keep the pull request isolated, report the conflict rather than stashing, reverting, mixing, or relocating the work.\n\n## Commit Logical Units\n\nUse one commit per coherent unit when the diff is large. Follow the repository's `<type>(<scope>): <subject>` history with an imperative lowercase subject and no trailing period.\n\nRun the validation required by the development skill. Defer `pnpm format` to its final pre-merge cleanup gate; do not run it for each commit or push. Parallel issue-campaign implementation batches keep their dedicated Post-Campaign Cleanup formatter gate.\n\nStage explicit paths when the worktree is mixed. Never include unrelated user changes silently.\n\n## Write The Pull Request\n\nWrite the body at open as the historical intent statement. Include the intent, scope, deferred items, and exact local verification. State skipped checks and disabled campaign CI honestly.\n\nDo not rewrite the body after every follow-up push. Record later CI fixes, newly discovered design issues, promoted deferred work, and Self-Review results as formal GitHub pull-request reviews with the `COMMENT` event so the thread preserves chronology. Use inline review comments when an observation belongs to a changed line and the review body for commit-wide or round-wide results. Do not use ordinary issue-style pull-request comments for this ledger, and never `APPROVE` or `REQUEST_CHANGES` on your own pull request. The title describes the merged outcome in Conventional Commits style, not the work process.\n\nPush only the topic branch with upstream tracking. Use a file-backed body for multiline Markdown when opening through `gh`.\n\n## Issue Campaign Override\n\nBefore any issue-campaign push or pull request, complete `.agents/skills/issue-campaign/development.md`. A solo campaign uses one cycle pull request, the final pre-merge formatter gate, the ordinary check loop, and its integration-sensitive gate. Only `.agents/skills/multi-agent/issue-campaign.md` overrides that flow with worktree batches, exact-SHA campaign-run cancellation, local implementation gates, and Post-Campaign Cleanup.\n\n## Watch Checks After Every Ordinary Push\n\nAfter each ordinary push, including every Post-Campaign Cleanup push, monitor the pull-request checks until every check settles. Only CI-suspended campaign implementation waves skip this loop. On failure, fetch the relevant job log, diagnose the real cause, fix it in place, push a new commit, and resume monitoring. Do not treat a green unrelated job as acceptance for a failed required surface.\n\n## Merge On Explicit Request Or Standing Autonomous Mandate\n\nDo not merge, squash-merge, rebase, or update the target branch on unprompted initiative. Merge when the user explicitly asks, or when a standing autonomous mandate authorizes end-to-end delivery; use the repository's established merge method unless another is specified. Under an autonomous mandate the author that owns the pull request merges it themselves once the merge gate below passes, without separate approval.\n\nBefore merging an ordinary or Post-Campaign Cleanup pull request, confirm required checks pass. For a multi-agent campaign implementation pull request whose automatic CI is deliberately suspended, confirm its local-verification, independent-verification, and integration gates instead. If branch protection blocks the requested merge, report the blocker rather than bypassing it.\n",".agents/skills/documentation/SKILL.md":"---\nname: documentation\ndescription: Defines README, website-guide, and agent-instruction structure, audience, prose formatting, and voice for typia. Use before writing, modifying, renaming, or moving repository documentation.\n---\n\n# Documentation\n\n## READMEs\n\nREADME files are for the final reader of that package or directory. Start with what it is, when to use it, installation, the smallest working setup, and the common path.\n\nKeep README language direct and practical. Avoid compiler theory, protocol details, internal architecture, and edge cases unless the reader must know them to use the package. Move deep explanations into the website guides and link them only as the next step.\n\n## Guide Documents\n\nUser-facing guides live under `website/src/content/docs/**` as MDX and publish at https://typia.io/docs. The site uses Next.js and Nextra, exports a static site, and deploys to GitHub Pages. Keep one audience and one task per page.\n\nThe current tree is organized by feature area:\n\n- top-level pages `index.mdx`, `setup.mdx`, `pure.mdx`, `random.mdx`, and `misc.mdx` cover introduction, setup, and cross-cutting features;\n- `validators/`, `json/`, `protobuf/`, and `llm/` own their operation guides; and\n- `utilization/` owns framework integrations for MCP, Vercel AI SDK, LangChain, NestJS, tRPC, and Hono.\n\nThe root and each guide folder use `_meta.ts` for sidebar order and labels. Nextra reads keys in declaration order; `{ display: \"hidden\" }` keeps a page reachable while removing it from the sidebar. Update the matching `_meta.ts` whenever a guide is added, renamed, moved, hidden, or exposed.\n\nWhen emitted code is the point, pair the TypeScript source with its compiled JavaScript in side-by-side tabs so the reader can see what the transform replaces. Back performance claims with a specific benchmark result instead of an adjective. Follow the fresh website-build prerequisites in `.agents/skills/development/SKILL.md`.\n\n## Agent Instructions\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans and agents. Keep only the product-wide contract in `AGENTS.md`, the always-applicable procedure in `SKILL.md`, and conditional detail in a linked sibling document.\n\nConcise and clear means:\n\n- Include the context needed to act correctly. Do not make the reader infer prerequisites, exceptions, reasons, or stop conditions merely to shorten the document.\n- State each rule at its owning document and link to it elsewhere. Remove repeated wording, not necessary substance.\n- Give each paragraph one job. Separate purpose, rule, rationale, procedure, and consequence when combining them obscures the action.\n- Use structure to compress meaning: ordered lists for procedures, bullets for choices and checks, tables for repeated mappings, and code blocks for exact commands.\n- State the rule before its reason. Use a negative rule only when it prevents a named failure the affirmative rule does not already exclude.\n- Link to website guides, READMEs, or source comments instead of paraphrasing them.\n\n## Prose line breaks\n\nWrite each Markdown or MDX paragraph on one source line. Never hard-wrap a single paragraph at a fixed column: Markdown already soft-wraps it, while manual wrapping makes small edits reflow unrelated lines.\n\nOne source line does not mean one long paragraph. Insert a blank line whenever the idea changes. Keep structural line breaks for paragraphs, list items, headings, tables, and fenced code.\n\nThis is a manual convention, not a formatter gate. Root `pnpm format` runs Prettier over `**/*.ts` and formats changed Go files; it does not format `*.md` or `*.mdx`, and the repository does not set `proseWrap`. Preserve one-line paragraphs yourself.\n\n## Voice\n\nWrite in the plain, direct, technical voice of the human-authored typia docs. Do not write like an AI assistant.\n\n- No AI-cliche phrasing: \"not only X but also Y\", \"whether you're X or Y\", \"it's worth noting\", \"let's dive in\", and reflexive hedging.\n- No marketing adjectives such as \"seamless\", \"powerful\", \"robust\", or \"effortless\". State the behavior; where speed is the point, cite the benchmark.\n- No wrap-up sentence that just restates the paragraph. State the fact and stop.\n- Em-dashes already fit the existing typia prose; do not remove them mechanically or impose a punctuation ban.\n- Sidebar emoji in `_meta.ts` are part of the existing navigation voice. Keep them where they already fit; this exception does not turn guide prose into decorative copy.\n",".agents/skills/review/SKILL.md":"---\nname: review\ndescription: Defines exhaustive solo review, Self-Review, and solo repository-wide issue-discovery rounds for typia. Use for every self-review or unqualified review request and as the default review mode inside issue campaigns. This skill never spawns review agents; use the multi-agent skill only when the user explicitly requests a team, parallel, or multi-agent review.\n---\n\n# Review\n\n## Non-Negotiable Review Law\n\nRead the [contracts skill](../contracts/SKILL.md) when reviewing maintained production declarations or tests. Judge every acknowledgment against the actual declaration, native documentation, private helpers, and consequence surface. Evidence proves that an answer exists; review verifies every fact the chapter requests and revalidates existing answers affected by a change. A passing fixture or renamed wrapper does not prove that a disproven implementation assumption was corrected.\n\nOne reviewer performs every review in this skill from scratch over the entire declared surface. Do not spawn a subagent, delegate a concern, or load the discussion skill. Do not create a clone or worktree for solo review or Self-Review.\n\nChoose the principled conclusion. Review duration, difficulty, and consequence surface are reasons to inspect more deeply and verify more carefully, never reasons to overlook a sound improvement, accept an unsupported claim, or lower the completion standard.\n\nA complete round must satisfy all six rules:\n\n- **Whole surface:** read every changed file and hunk. For issue discovery, audit the entire campaign scope. Never partition by file, package, concern, platform, or pass, and never substitute another reviewer's coverage.\n- **Consequence surface:** inspect affected code paths, tests, generated artifacts, CI, packaging, documentation, and consumers. Trace side effects, state transitions, concurrency, platforms, boundaries, compatibility, and failure and recovery paths beyond the named symptom or diff.\n- **Fresh start:** use the current state and repeat the whole inspection. Earlier rounds, sampled files, and a recheck of only the latest fix do not count as coverage.\n- **Unlimited rounds:** whenever the reviewer applies an improvement or accepts a meaningful issue candidate, update the work and start another complete round. Stop only after a complete round produces nothing that survives verification.\n- **One immutable state:** a round runs against one recorded state, dependency lock, provisioned workspace contract, supported environment contract, and mandatory test matrix. Issue discovery and committed pull-request review use an exact commit. A solo review records its exact starting diff and refreshes that snapshot after every edit; a review round must not race a source change. The [multi-agent review procedure](../multi-agent/review.md) states how a team shares one snapshot.\n- **Auditable completeness:** the reviewer accounts for every tracked file and every mandatory public-operation, ownership, consumer, boundary, option, declaration-provenance, generated-artifact, packaging, and supported-platform matrix cell in the declared surface. Finding a candidate never ends or narrows the review. A skipped file, unprovisioned harness, unsupported claim, or unexecuted required cell makes the report `INCOMPLETE`, never `COMPLETE`.\n\n## Self-Review\n\nSelf-Review and an unqualified review request use this solo workflow:\n\n1. Establish the complete change surface, including the pull-request base-to-head diff and any uncommitted changes.\n2. Perform one complete round under the Non-Negotiable Review Law. Include correctness and boundaries, Windows and POSIX behavior, concurrency and state, data loss and security, cache and recovery invariants, public API and compatibility, test isolation, CI and packaging, generated output, documentation, and migration effects.\n3. Reproduce every suspected defect before accepting it.\n4. Apply every sound improvement and run the narrowest verification authorized by the owning workflow.\n5. If anything changed, restart at step 1 as a fresh full round.\n6. Finish only when a complete round finds nothing to improve. Report the final clean round and every verification that could not run.\n\nSelf-Review does not authorize creating, pushing, updating, or merging a pull request. If the user separately requests one of those actions, follow the pull-request skill.\n\n## Commit Early-Warning Pass\n\nA commit early-warning pass is not a review under this skill. It is the read-only per-commit reader a solo campaign author runs over every landed commit while still implementing, required and defined by the [solo campaign development document](../issue-campaign/development.md#implement-and-write-tests).\n\nIt delegates nothing the Non-Negotiable Review Law governs. The law governs the author's own round, which still runs alone over the whole surface before merge under all six rules. One commit is not a declared surface, a reported candidate is not an accepted finding, and the passes do not add up to a round.\n\nNever call the pass a Self-Review, and never report it as one. A reader who sees that name concludes the gate already ran, and the whole-surface round disappears without anyone deciding to drop it.\n\n## Solo Issue Discovery Rounds\n\nUse these rounds only through the solo issue-campaign skill.\n\n1. Freeze one exact commit and record the dependency lock, provisioning command, and supported environment contract before starting. Derive that environment contract from package engines, public documentation, repository CI, peer requirements, published package behavior, and explicit user decisions; do not narrow it ad hoc, and treat an unresolved conflict as a blocker on `CLEAN`.\n2. Inventory all tracked files, package and public API families, implementation owners, generated artifacts, test harnesses, workflows, documentation contracts, supported platforms, and open and closed issue or pull-request history before examining candidates. Reconcile that inventory with `git ls-files` and with the campaign's mandatory coverage matrix. A grep lens, a sampled file set, or a statement that the surface was reviewed is not coverage.\n3. Audit the entire inventory and execute the whole mandatory matrix. Audit source, tests, documentation, CI, packaging, generated artifacts, platform behavior, upstream and downstream provenance, and history against the development skill's **Forbidden** section. Continue through the full inventory after finding a candidate.\n4. Treat the matrix as a floor. Cover all applicable public operation families and direct, factory, and nested forms; equivalent TypeScript spellings, including aliases, interfaces, call and construct type literals, and classes; local, re-exported, module, package, user-global, default-library, ambient, and runtime-native provenance; union, intersection, generic, and transform-option interactions; static, dynamic, array, `any`, and `unknown` value contexts; positive, one-axis negative, boundary, malformed, maximum-width, one-past-boundary, and mutation controls; generated-byte and executed-runtime behavior; deterministic repeat emit; workspace, clean packed, and deployment consumers; and supported Node, module-resolution, operating-system, and CLI paths. Every interaction that reaches shared control flow is its own cell, and every positive cell has a one-axis negative twin. Run mutations only in a disposable checkout, keep the regression probe unchanged, and require the probe's canonical command to fail. When the round discovers a new owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells before the round can complete.\n5. Record every raw candidate, killed hypothesis, command, and artifact in the campaign knowledge base with the exact commit, environment, matrix hash, and census results. The round is `COMPLETE` only when the full inventory and current matrix finished; otherwise it is `INCOMPLETE` and cannot support a `CLEAN` campaign state.\n6. Reopen each candidate from primary evidence in a fresh state, reproduce it, verify ownership and provenance, trace its complete consequence surface, and compare existing issues and pull requests. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence, so a later round does not rediscover a rejected premise as new. Implementation mechanisms remain hypotheses.\n7. If any meaningful candidate survives, return to step 3 and run another complete round against the same frozen commit before publishing or implementing anything, and repeat until one round produces no surviving candidate. Discovery owns this loop; it never hands a partial candidate pool to publication or implementation because the first round already found work. A prior finding never permits narrowing the next round to its owner or neighbors.\n8. Publish only the surviving adjudicated form when the campaign is authorized to publish. After the authorized issue and implementation flow completes, freeze the new integrated commit and begin the next full-scope round.\n9. Stop only when one immutable-state round completes the entire repository inventory and mandatory matrix, no round is `INCOMPLETE`, and no meaningful candidate survives verification. Any verified in-repository correctness, contract, data-integrity, build, test-oracle, documentation, packaging, workflow, or **Forbidden** violation is meaningful regardless of severity, rarity, legacy status, or malformed-input trigger. Do not downgrade a proved defect to an observation to satisfy the stop rule. An unresolved, deferred, or unimplemented verified defect blocks `CLEAN`, and green existing suites cannot satisfy the stop rule.\n\n## Explicit Multi-Agent Reviews\n\nWhen the user explicitly asks for a team, parallel, or multi-agent review, load the [multi-agent skill](../multi-agent/SKILL.md) and its [review procedure](../multi-agent/review.md) instead of this workflow. It inherits the same whole-surface, immutable-state, and auditable-completeness law while defining independent parallel reviewers, agent briefing, and lead and critic adjudication.\n",".agents/skills/issue-campaign/SKILL.md":"---\nname: issue-campaign\ndescription: \"Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request.\"\n---\n\n# Issue Campaign\n\nAn issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that [development.md](development.md#implement-and-write-tests) requires for every landed commit.\n\nUse the [multi-agent skill](../multi-agent/SKILL.md) and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.\n\nThe user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.\n\nApply [AGENTS.md's **Choose the principled course** rule](../../../AGENTS.md#attitude) to every admission, disposition, implementation, and review decision.\n\nRead the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds; issue discovery is independent review, not discussion. Read [development.md](development.md) in full only when implementation is authorized.\n\n## Campaign Knowledge Base\n\nCreate `.wiki/<campaign>/` with a short filesystem-safe campaign name. Preserve any existing campaign directory and reconcile it rather than deleting or assuming a blank slate.\n\nKeep concise, current Markdown documents for:\n\n- repository provenance, architecture, validation ownership, and product boundaries;\n- experiments, reproductions, dogfooding, and related issue or pull-request history;\n- every raw candidate, its evidence, dependencies, and final disposition, including combinations, splits, rejections, and deferrals with the evidence supporting each decision;\n- the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, and official GitHub `createdAt`-to-`mergedAt` cycle timing;\n- the exact commit, dependency lock, provisioning command, supported environment contract, and tracked-file census for each discovery round;\n- a mandatory coverage matrix that crosses public operations, owners, consumers, declaration spellings and provenance, composition, transform options, input contexts and boundaries, generated artifacts, packaging, CLI, and supported platforms;\n- a per-issue consequence matrix and implementation impact record that names every caller, equivalent spelling, provenance, option, context, boundary, artifact, consumer, and platform revalidated by the fix; and\n- an integration-command manifest that records and hashes the exact commands, environment, tool versions, triggering change classes, expected artifacts, and clean-consumer setup required before and after each integration-sensitive merge.\n\nRecord raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.\n\nGive every tracked path and matrix cell a stable ID, and record one row per ID with `round`, `base SHA`, `matrix hash`, `path or cell ID`, `status`, `evidence`, and `candidate`.\n\nA status is one of four values, and it means something different for a path than for an executable cell:\n\n| Status | Tracked path | Executable matrix cell |\n| --- | --- | --- |\n| `PASS` | contents, history, owner, and linked cells were audited | the recorded oracle and controls passed |\n| `FAIL` | a candidate remains | the oracle or a control failed |\n| `N/A` | evidence that the path is outside an explicitly authorized contract | a product-contract reason |\n| `UNTESTED` | the audit is absent | the cell did not run |\n\nReconcile the path census with `git ls-files` and verify that the matrix covers every public operation and known historical dimension before the round begins. When the round discovers a missing owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells.\n\nReconcile the finished rows against the frozen census and final matrix. Any missing row, `UNTESTED`, unsupported `N/A`, or absent evidence makes the round `INCOMPLETE`.\n\nThe knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to `.wiki`.\n\n## Discover Issues\n\nRun the review skill's [Solo Issue Discovery Rounds](../review/SKILL.md#solo-issue-discovery-rounds) over the entire declared campaign scope. That procedure owns the frozen commit, environment contract, tracked-file census, mandatory coverage matrix, and the `COMPLETE` and `INCOMPLETE` round states. This section adds only what the campaign itself owns.\n\nOnly an explicit user instruction or existing public product contract can exclude a surface or environment. The campaign cannot narrow itself, and an unresolved support-policy question makes the round `INCOMPLETE`.\n\nSource is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions.\n\nNever combine results from different commits, and never accept a stale, unprovisioned, skipped, contaminated, sampled, or missing-type harness whose tags or declarations collapse to `any` or `unknown` as full-round evidence.\n\nTreat the development skill's [Forbidden](../development/SKILL.md#forbidden) section as an explicit retrospective audit contract, not only a rule for future changes. In every complete round, inspect the current implementation and its history for violations, including code that predates the campaign or passes every test. A verified violation is a meaningful issue candidate. Prove the classification from purpose, control flow, consequence, and history; resemblance or stylistic preference alone is not evidence.\n\nDo not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.\n\n### Every Round Is Full-Scope\n\nEvery round re-audits the entire declared scope from scratch against the state it was frozen on. A round is never partitioned: not by package, file, concern, platform, candidate class, validation lane, or pass, not by the areas the last cycle or the last round happened to touch, and not by splitting the scope across rounds so that each one covers a slice. What an earlier round read is never coverage for this one, whether it ran in an earlier cycle against a state a merge has since changed, or earlier in this cycle against the same commit. The [review skill's Non-Negotiable Review Law](../review/SKILL.md#non-negotiable-review-law) states the same rule for every round and review the campaign runs.\n\n### Discovery Ends Only On An Empty Round\n\nDiscovery repeats in two nested loops, and neither ends until a complete round comes up empty.\n\nInside one cycle, accepting a candidate does not end discovery. Begin another complete full-scope round against the same frozen commit and repeat until one round produces no meaningful candidate that survives verification. Only that empty round settles the cycle's issue set. Publishing or implementing from the first round that found something freezes the cycle around whatever that round happened to reach first, and the issues the next round would have added arrive too late to join it.\n\nAcross cycles, a merged cycle does not end the campaign. It produces one more discovery phase against the integrated repository, and that phase runs the inner loop to its own empty round. There is no limit on either loop, and the campaign ends only when a complete fresh round is not `INCOMPLETE`, produces no meaningful candidate that survives verification, and leaves no accepted issue unresolved.\n\nReport the campaign complete only from a round that actually came up empty. Ending after a cycle that merely felt thorough leaves the issues the next round would have found unrecorded.\n\n## Vet And Publish Issues\n\nThe same main agent owns every publication decision. For each candidate:\n\n1. Reopen its evidence and reproduce the behavior.\n2. Verify ownership, provenance, and any claimed classification under the development skill's **Forbidden** section.\n3. Trace the full consequence surface.\n4. Compare open and closed issues and pull requests.\n5. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence.\n\nRevalidate every disposition from primary evidence in a fresh state, including rejection, narrowing, combination, split, deferral, and confirmed-invalid conclusions, rather than trusting the note that first recorded it. A disposition that cannot be reproduced leaves the candidate surviving and blocks `CLEAN`; it cannot be hidden by omitting publication. The [multi-agent procedure](../multi-agent/issue-campaign.md) assigns this audit to an independent critic agent; a solo campaign performs it as a separate pass with its own recorded evidence.\n\nPublish only the adjudicated form and only with user authorization.\n\n### Self-Contained Issue Body\n\nWrite enough context for a fresh AI agent to begin implementation from the issue alone. Do not require access to local `.wiki`, the discovery conversation, or unstated repository knowledge. Cover these sections when they apply:\n\n- **Problem:** current and expected behavior, impact, and affected users.\n- **Evidence:** exact reproduction, outputs or artifacts, stable symbols, verified root cause, ownership, and provenance. For a violation of the development skill's **Forbidden** section, prove the classification from behavior, control flow, and history instead of merely naming the prohibition. Line numbers are navigation, not proof.\n- **Consequence surface:** affected consumers, states, platforms, compatibility and failure paths, plus the complete case matrix for the cause.\n- **Invariant:** the required behavior and architectural owner, without prescribing an implementation mechanism. Discovery explanations, closed issue approaches, and candidate mechanisms remain hypotheses for the implementer to validate; executed evidence establishes constraints and rejected alternatives, not a prescribed solution.\n- **Acceptance and verification:** positive, negative, boundary, and regression outcomes with narrow and broader proving commands.\n- **Coordination:** dependencies, exclusions, migration concerns, external blockers, and related open, closed, accepted, or rejected work.\n\nUse tables for repeated case mappings. Read the rendered issue back and keep its body as the current operative handoff; use comments only for chronology.\n\nBefore publication, reproduce the current failure and its independent oracle once more in a fresh state, and verify the invariant, complete owner and consumer census, supported-environment boundary, equivalent-spelling and provenance matrix, positive and negative twins, boundary cases, and a counterfactual proving that the reproduction distinguishes the expected behavior. Pass-after and fix-mutation evidence belong to implementation verification. Strike any prescribed implementation mechanism, including one that appears to fit the current evidence.\n\n## Develop And Repeat The Campaign\n\nRead [development.md](development.md) in full when the user authorizes implementation pull requests or the end of a campaign that entered implementation. It owns the single cycle pull request, empty claim, internal DAG order, test authoring, formatting, ordinary CI, red-CI repair, solo Self-Review, the integration-sensitive gate, merge, branch and temporary-asset cleanup, and renewed discovery.\n\nAn audit-only or issue-publication-only campaign does not load the development procedure or mutate repository, Actions, or GitHub state beyond the authorized publications.\n",".agents/skills/benchmark/SKILL.md":"---\nname: benchmark\ndescription: Defines typia benchmark fixture integrity, result reporting, and publication safeguards. Use before running or modifying @typia/benchmark, changing a fixture, or publishing benchmark results.\n---\n\n# Benchmark\n\nThis repository owns one benchmark system. Read its procedure in full before acting:\n\n- [performance.md](performance.md): `@typia/benchmark` throughput against competing runtime libraries, including generated programs, structure fixtures, and the per-CPU result archive.\n\n## Measurement Integrity\n\n- Measure the real product. Do not add benchmark-only branches, fixture-name checks, expected-answer checks, monkey patches, or agent restrictions that would be wrong for an unmeasured repository.\n- Give every comparator the setup its own documentation prescribes. Measuring a deliberately underconfigured competitor invalidates the comparison.\n- Preserve the workload defined by the selected procedure. A faster result obtained by validating, serializing, serving, or reading less input is not an optimization.\n- Treat a surprising result as evidence that the change is not yet understood. Inspect the raw report or trace before accepting, explaining away, or patching around it.\n\n## Fixture Changes\n\n`benchmark/src/programs/` mixes generated leaf programs with hand-maintained helpers. Edit generated `benchmark-*.ts` files through their source under `benchmark/src/template/`; edit shared `create*.ts` helpers and `benchmark/src/structures/` in place.\n\nFinish every fixture change before publishing it:\n\n1. Run the relevant template entrypoint, then the benchmark package's build commands until they finish green. `pnpm template` regenerates only the templates imported by `benchmark/src/template/index.ts`. Defer repository formatting to the development skill's final pre-merge cleanup gate.\n2. Confirm every comparator receives the same structure and input for the measured row.\n3. Review the generated-program diff. A stale or inconsistent generated program contaminates every later run.\n\nBenchmark READMEs and prose follow AGENTS.md `## Maintenance` and the documentation skill.\n\n## Report Results\n\nEvery result table reported in chat or committed to the result archive must be preserved for the active pull request. When the user has authorized PR updates under the pull-request skill, maintain one sticky comment beginning with `<!-- typia-benchmark-results -->`; update it with the latest table, report paths, and known invalid or missing categories.\n\nIf no pull request exists or no update is authorized, keep the result in the final report and mark the comment as pending. Post it only after the user creates or authorizes updating the pull request.\n\n## Campaign Batching\n\nWhen benchmark findings produce multiple implementation issues, load the issue-campaign skill and use its planning and claim procedure unchanged for the dependency DAG, claim freeze, and official GitHub `createdAt`-to-`mergedAt` duration: [Plan One Cycle Pull Request](../issue-campaign/development.md#plan-one-cycle-pull-request) for a solo campaign, or [Plan And Claim A Pull Request Wave](../multi-agent/issue-campaign.md#plan-and-claim-a-pull-request-wave) with its batch admission test, merge pressure, and grouping and split ledger when the user explicitly requested a parallel campaign. This benchmark skill continues to own workload, fixture, measurement, result, and publication integrity; do not redefine pull-request batching here.\n\n## Campaign Cleanup\n\nWhen a benchmark campaign uses a disposable worktree or an isolated measurement root, finish cleanup before marking that assignment complete. Preserve the committed result archive and compact command evidence, but remove every disposable worktree and its assigned mutable roots: `GOCACHE`, `GOTMPDIR`, `TTSC_CACHE_DIR`, generated-program scratch tree, dependency install tree, and temporary consumer or report staging tree. Go temporary assets are never reusable campaign evidence.\n\n1. Record the measured commit, command, result paths and hashes, environment, and any retained published result archive.\n2. Confirm the worktree and mutable roots contain no unreported source or result artifact.\n3. Remove the mutable roots and, for an assigned disposable worktree, run `git worktree remove --force <path>` for its exact path.\n4. Verify every removed root and, when applicable, worktree path no longer exists, run `git worktree prune`, delete the associated disposable local topic branch when one was created, and confirm no worktree registration remains.\n\nIf a measurement is abandoned or invalid, retain only the diagnostic record needed to explain it; remove its worktree and Go temporary assets by the same procedure.\n","AGENTS.md":"# AGENTS.md\n\n`typia` is a TypeScript transformer and runtime library that turns pure TypeScript types into inline validators, serializers, schemas, decoders, and random-data generators. It ships the `typia`, `@typia/interface`, `@typia/utils`, `@typia/langchain`, `@typia/mcp`, `@typia/vercel`, and `@typia/jev` packages.\n\n## Attitude\n\nFollow the literal request; it is the contract, not a hint at what the user \"really\" wants.\n\n- **Scope is the user's to widen.** Reinterpret the goal, weigh alternatives, or expand the task only on an explicit hand-off (\"figure it out\", \"you decide\"). Take a confident, specific ask as given.\n- **Fidelity binds the goal, not the effort.** Within that goal, act with full initiative: do the substeps it needs, verify your work, surface what you notice. Literal scope is no excuse for passive execution.\n- **Match the user's language.** Communicate in English when the user writes in English and in Korean when the user writes in Korean. Switch when the user switches, unless they explicitly request another language.\n- **Choose the principled course.** Decide from evidence, correctness, product boundaries, and the durable consequence. Time, difficulty, and consequence surface are reasons to investigate and validate more carefully, never reasons to settle for a shortcut, workaround, or weaker standard.\n- **Evidence precedes correction.** Treat issue reports, review proposals, and claims that something is wrong or missing as hypotheses. Verify the real code path, tests, generated artifacts, upstream ownership, and history before accepting the premise or changing behavior.\n- **Trace the consequence surface.** A named file or failing case is the starting point, not the investigation boundary. Follow the same cause through downstream consumers, side effects, state transitions, platforms, and boundary cases, then address the whole verified class of failure within the requested goal.\n- **Collect every symptom before correcting.** Finish the test run, CI run, reproduction, or review round that produced a finding before repairing it. Group all findings by cause, trace their consequences, and correct the complete verified set together.\n- **Default over ask.** On an ambiguous detail, pick the sensible default and say what you chose; reserve questions for forks only the user can settle.\n\n## Skills\n\nDurable project conventions and workflows live under `.agents/skills/`. Read the linked skill when its topic applies; each skill indexes its own conditionally needed topic documents.\n\n### Project Outline\n\nWhat typia is, the package family, the JS-descriptor / Go-plugin boundary, the workspace layout, product boundaries, and canonical commands, `.agents/skills/project/SKILL.md`.\n\n### Development\n\nWork rules, testing, validation, consequence analysis, and change integrity, `.agents/skills/development/SKILL.md`. Read before writing or modifying code.\n\n### Implementation Contracts\n\nSelf-acknowledgments for maintained production declarations, unit tests, and E2E tests, `.agents/skills/contracts/SKILL.md`. Read when implementing or reviewing those declarations or selecting Evidence checklists.\n\n### Documentation\n\nREADME, website guide, and agent-instruction authoring rules, `.agents/skills/documentation/SKILL.md`. Read before writing or modifying documentation.\n\n### Issue Campaigns\n\nDefault solo repository-wide issue discovery, issue publication, one CI-validated implementation pull request per cycle, and renewed discovery, `.agents/skills/issue-campaign/SKILL.md`. Read when the user asks for a broad audit, many issue candidates, or an issue-to-implementation campaign without explicitly requesting parallel agents; do not use it for one already-defined issue.\n\n### Review\n\nDefault solo Self-Review, unqualified review, and exhaustive issue-discovery rounds, `.agents/skills/review/SKILL.md`. The reviewer inspects the whole declared surface and repeats fresh rounds until a complete pass produces no sound improvement or meaningful issue candidate.\n\n### Multi-Agent Workflows\n\nExplicitly parallel review and issue-campaign variants live under one entry point, `.agents/skills/multi-agent/SKILL.md`. Read it only when the user explicitly asks for a team, parallel, or multi-agent workflow. Multi-agent issue campaigns parallelize discovery and implementation by default and switch to solo implementation only on an explicit discovery-only parallel request; Self-Review remains solo.\n\n### Discussion\n\nStructured multi-agent topic discussion with persistent research notes and transcripts, `.agents/skills/discussion/SKILL.md`. Read only when the user explicitly asks for a discussion; review and issue discovery do not imply discussion.\n\n### Pull Request Submission\n\nBranch, commit, pull request, check, and merge flow, `.agents/skills/pull-request/SKILL.md`. Read when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, or propose one on unprompted initiative.\n\n### Benchmark\n\nBenchmark runners, fixture integrity, measurement integrity, result archives, and publication, `.agents/skills/benchmark/SKILL.md`. Read before running, modifying, or publishing benchmark results.\n\n## Maintenance\n\n### Writing style\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans as well as agents. Read the documentation skill before editing either; it defines concise, clear agent-instruction writing and the prose-line rule.\n\n### AGENTS.md\n\nThis is the single shared entry point for both Claude Code (via `CLAUDE.md -> @AGENTS.md`) and Codex CLI. Keep it to the brief product identity, global attitude, and skill index. The H2s are `## Attitude`, `## Skills`, and `## Maintenance`; `## Attitude` is the one place global agent-behavior rules live.\n\nUpdate AGENTS.md only for repository-contract changes: a new skill area, a renamed or merged skill, a workflow that no longer fits an existing skill, a release-process change, or a coding-agent rule that applies globally before any skill loads.\n\n### Skills\n\n- **Location.** `.agents/skills/<kebab-name>/SKILL.md`. No numeric prefix. Each file opens with YAML frontmatter whose `name` matches the directory and whose third-person `description` states what the skill covers and when to use it.\n- **Core in SKILL.md, conditional topics as sibling documents.** Keep always-applicable procedure in SKILL.md. Move a topic needed only under a specific condition to a one-level-deep sibling document and link it with that read condition.\n- **Two trigger surfaces, one scope.** The frontmatter description is the full trigger contract, including exclusions. The AGENTS.md pointer mirrors that scope more briefly. Correct the frontmatter first when the scope changes.\n- **Create or merge.** Add a skill when a substantial repository concern would otherwise inflate AGENTS.md beyond an index. Merge sibling concerns when they share most of their structure.\n- **Repository skill files only.** Keep repository skills to `SKILL.md` and conditionally loaded sibling documents. Do not add separate `multi-agent-*` skills; the parallel variants live under the one `multi-agent` skill.\n- **Headings are plain.** No chapter numbers in skill or AGENTS.md headings. Use descriptive titles.\n- **Current set.** The repository skills are `project`, `contracts`, `development`, `documentation`, `issue-campaign`, `review`, `multi-agent`, `discussion`, `pull-request`, and `benchmark`.\n",".agents/skills/development/SKILL.md":"---\nname: development\ndescription: Defines typia implementation rules, testing standards, validation, consequence analysis, and change integrity. Use before writing or modifying source, tests, workflows, package wiring, fixtures, generated baselines, or algorithms.\n---\n\n# Development\n\n## Contents\n\n- [Forbidden](#forbidden)\n- [Work Rules](#work-rules)\n- [Consequence Analysis](#consequence-analysis)\n- [Plugin Configuration](#plugin-configuration)\n- [Testing](#testing)\n- [Validation](#validation)\n- [Change Integrity](#change-integrity)\n- [Evidence Adoption](#evidence-adoption)\n\n## Forbidden\n\nRead the [contracts skill](../contracts/SKILL.md) before changing maintained production declarations. Its common checklist owns implementation acknowledgments; scoped checklists apply by responsibility. When a failure disproves an assumption, correct its owner and remove superseded compensations in the same repair.\n\nThese four are never acceptable; choosing any one means the approach is already wrong.\n\n- **No monkey-patching or hardcoding.** Don't special-case a consumer, a fixture name, or an expected value to make output match. Fix the general logic.\n- **No test-passing-only logic.** Code exists to be correct, not to turn a check green. A branch whose only purpose is to satisfy one assertion is a bug in disguise.\n- **No forcing a broken design.** When the same failure keeps returning under patch after patch, the design is wrong. Stop, find the root cause, and fix the design instead of looping forever on symptoms.\n- **No whack-a-mole.** Don't patch the one case that surfaced and move on. Think expansively about every case the same root cause can produce, and seal them all with coverage so the class of failure cannot recur.\n\n## Work Rules\n\n- Choose the principled course. Time, difficulty, and the breadth of consequences require more careful analysis and validation; they never justify a shortcut, leaving a verified consequence unaddressed, or a weaker acceptance standard.\n- Match existing conventions. Before adding a file, function, or test, open a nearby peer and mirror its naming, location, and code style; don't create parallel structures.\n- Respect package boundaries. The shared native transform lives under `packages/typia/native`; don't fork a second transform into an adapter package or reintroduce a TypeScript-side transformer.\n- Keep package detection installation-safe. Resolve the target package root, as `packages/typia/src/transform.ts` does with `require.resolve(\"typia/package.json\")`; workspace path substrings and hard-coded fixture names fail for npm consumers.\n- Use the workspace catalogs. `pnpm-workspace.yaml` owns `samchon`, `typescript`, `rolldown`, and `utils`; the ttsc family, Evidence, tstl and tgrid use `catalog:samchon`, and internal package references use `workspace:^`.\n- Keep local outputs local. Do not commit `.env` files or the `.tgz` artifacts generated under `experiments/tarballs/`.\n- Preserve the public contract in `.agents/skills/project/SKILL.md`. Renaming or removing `typia.*`, `@typia/interface` types, or the plugin descriptor shape is a deliberate product change, not incidental cleanup.\n- When public behavior changes, update the matching page under `website/src/content/docs/**` in the same change. Follow `.agents/skills/documentation/SKILL.md`.\n- Run `pnpm format` only in the final pre-merge cleanup after implementation and CI repairs are complete, not before each commit or push. Commit its integrated result and require green CI on that final head before merging. If later edits require formatting, return to this final cleanup gate. Parallel issue-campaign implementation batches defer the repository-wide formatter to their dedicated Post-Campaign Cleanup pull request.\n\n## Consequence Analysis\n\nTreat a reported example as one witness of a cause, not the complete problem statement. Before changing code, trace the same cause through:\n\n- every caller and downstream consumer;\n- normal, error, and recovery state transitions;\n- concurrency, caching, and generated output;\n- Windows and POSIX behavior;\n- compatibility constraints and boundary inputs.\n\nFix the verified class of failure, not only the reported witness. Cover positive, negative, and boundary cases without expanding the user's product goal.\n\n## Plugin Configuration\n\n`ttsc` discovers typia by default from the `ttsc.plugin.transform` entry in `packages/typia/package.json`. Consumer projects add a `compilerOptions.plugins` entry with `transform: \"typia/lib/transform\"` only when they need to set optional transform flags.\n\n`packages/typia/src/transform.ts` is a JavaScript descriptor source, not a transformer. It resolves the installed typia package and returns the Go command at `packages/typia/native/cmd/ttsc-typia`; `ttsc` builds that source into the workspace cache. Keep type analysis, AST rewriting, diagnostics, and typia-owned options (`functional`, `numeric`, `finite`, and `undefined`) on the Go side.\n\nTest workspaces normally use `typia/lib/transform`. Source-only workspaces such as the benchmark may point at `typia/src/transform.ts`, but that still loads the same descriptor and native command. Do not add a second plugin host to make a local layout pass.\n\n## Testing\n\nRead the [testing contracts](../contracts/testing.md) for every test and the [E2E contracts](../contracts/e2e.md) when it exercises a necessary real component boundary. Classify by actual execution, not language, directory name, filesystem use, or duration. Maintained helpers answer production contracts when they own implementation decisions.\n\n**One test case per file, named after what it asserts.** This is the rule for new and changed cases in both languages, even where older files predate it.\n\n### Go tests\n\n- **Public and contract tests:** keep black-box and exported-API coverage under `packages/typia/test/**`, mirroring the native concern where practical. These tests import the native module through `packages/typia/test/go.mod` and run with `pnpm test:go:public`.\n- **Colocated native tests:** keep same-package implementation, command, transform, and emitter coverage beside the Go source as `packages/typia/native/**/*_test.go`. Untagged cases run with `pnpm test:go:native`.\n- **Native-internal tagged tests:** use `//go:build typia_native_internal` only when the case requires internal-only coverage. Root `pnpm test:go` does not enable that tag; run `go -C packages/typia/test test -tags typia_native_internal ../native/...` when tagged coverage is relevant.\n\nUse one `Test*` function per test file and mirror a nearby test's package, fixture, and cleanup pattern. Command-level transform regressions belong near `packages/typia/native/cmd/ttsc-typia`; public contract probes belong under `packages/typia/test`.\n\n### TypeScript suites\n\n`pnpm test:packages` starts every `tests/test-*` workspace. They have these shapes:\n\n- **Function-per-file:** `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, and `test-utils` discover `src/features/**/test_*.ts` through `DynamicExecutor`. Export exactly one `test_<snake_case>` function from a matching filename. `DynamicExecutor` selects and reports a test by its exported name, so a name that disagrees with its file makes the test unreachable by that file's name. `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` additionally run portable unit cases from `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` without the native plugin (`pnpm --filter ./tests/<workspace> test:unit`); they follow the same one-function-per-file naming rule.\n- **Generated matrices:** `test-typia-automated` and `test-utils-automated` delete and regenerate `src/features/**` when they run. Do not hand-edit those trees. Change the controller/template metadata or `@typia/template`; keep the committed ObjectSimple composite layer in `test-typia-automated/src/composite/**` hand-maintained.\n- **Transform rejection:** `test-error` compiles invalid call sites and asserts the diagnostics that reject them. A failed build publishes no output, so the suite reads no emitted JavaScript: it requires the build to fail, every fixture to typecheck, and every fixture to be named by a typia diagnostic. Add cases beside their feature group, and keep each fixture valid TypeScript that only typia rejects — a type error aborts the build before the transform runs and would leave the suite with nothing to observe.\n- **Type compilation:** `test-interface` is a compile-only TypeScript `tsc --noEmit` suite for `@typia/interface` type contracts and public typia signatures; type-only factory checks execute no factory.\n\nUse `TestValidator` and `DynamicExecutor` from `@nestia/e2e`, `@typia/template` structures and `TestServant`, and each suite's local `internal/` helpers. Do not reach into another suite's internals or duplicate a reusable structure inside one test workspace.\n\nAssert structural equality with `TestEquality` from `@typia/template/equality`. Its `equals` is symmetric and compares `Date`, `Map`, and `Set` by content; use `subset` only when an assertion pins some fields of a larger result on purpose, with the expected value first. Never call `TestValidator.equals`: it walks only its first argument's keys and sees no content in dates, maps, or sets, so it passes whatever the actual lost (#2401). Never call `TestValidator.error` either: on a synchronous task it swallows its own failure and passes whether or not the task throws (#2460). Assert a synchronous throw by comparing `TestEquality.thrown(task)` with the expected message, and an asynchronous one by awaiting `task().then(() => undefined, (error: unknown) => error)` and comparing what it rejects with. Compare prototypes and other identities with `===`.\n\nOpen every new or materially changed case with a doc comment in the same three-part shape: a one-line `Verifies ...` headline, a short paragraph stating the non-obvious _why_ (which branch or regression is being pinned), and a 2+-step numbered list summarizing the scenario.\n\n```ts\n/**\n * Verifies typia.llm.schema emits `anyOf` for a discriminated union.\n *\n * Locks the union branch of the LLM schema converter. A regression in branch\n * selection would silently emit one variant and lose the other from the\n * function-calling schema.\n *\n * 1. Declare two object variants with a shared discriminator.\n * 2. Generate the LLM schema for their union.\n * 3. Assert both variants remain in the emitted `anyOf`.\n */\nexport const test_llm_schema_anyof = (): void => {\n  /* ... */\n};\n```\n\n### Coverage, not happy paths\n\nA test that only feeds a transform its ordinary successful input and asserts that the result is accepted proves one path, not correctness. The native transformer spans validators, serializers, schemas, decoders, diagnostics, and generated helpers; each predicate or branch needs more than its happy path:\n\n- **The transformation direction.** When a call should be rewritten, assert observable emitted or runtime behavior that differs from the untransformed stub. For generators, start from hand-written input and verify the generated output, not only that an existing output compiles.\n- **A negative twin for every positive.** Wherever a predicate accepts, rewrites, narrows, serializes, or reports a diagnostic, pin an adjacent case one property away where it must not do so. An over-match stays invisible until the counter-example exists.\n- **Boundaries.** Cover the empty case, the single-element case, recursion limits, optional and nullable members, exact numeric limits, deepest nesting, and the tag or compiler option that flips the decision.\n- **Oracle-derived expectations.** Take expected behavior from TypeScript semantics and the authoritative JSON Schema, OpenAPI, Protocol Buffer, or adapter contract, never from whatever the current code happens to emit. A snapshot written against the implementation's own output locks its bugs in.\n\nThis is not a validator-only rule. The same happy-path bias hides serializer corruption, schema loss, compiler-process failures, and native diagnostic regressions, so every feature carries the burden.\n\n## Validation\n\nRun the narrowest command that proves the change first, then a broader command when shared behavior, the transform, packaging, or documentation changed. Report any command that could not be run.\n\n- **One public Go concern:** `pnpm test:go:public`.\n- **One native Go concern:** `pnpm test:go:native`; add the tagged command from [Go tests](#go-tests) when the changed path has `typia_native_internal` coverage.\n- **One TypeScript workspace:** `pnpm --filter ./tests/<name> start`.\n- **One package:** `pnpm --filter ./packages/<name> build`.\n- **Transform, descriptor, or shared package:** `pnpm test`; use `pnpm build` as the broader package compilation gate.\n- **Packaging:** run root `pnpm package:tgz`, then inspect or smoke-test a clean install. It builds every package and verifies the published entry points before packing (`pnpm pack` alone no longer builds; the manifests carry no `prepack`). Tarballs are generated under `experiments/tarballs/`; do not commit or hand-edit them.\n- **Website or guide changes:** reproduce the fresh CI prerequisites: place a ttsc checkout at `../ttsc`, run root `pnpm install` and `pnpm package:tgz`, then run `pnpm build` inside `website/`. The compiler-dependencies package installs the staged tarballs, and the playground Wasm build resolves the sibling ttsc Go modules.\n\nVerification shape depends on the change type:\n\n- **Bug fix:** name the failing case and the expected behavior; run a repro that fails before the fix and passes after.\n- **Feature:** name the observable behavior; exercise it end-to-end.\n- **Refactor:** name what should stay unchanged; rely on the existing test suite or a behavior-locking probe.\n- **Review:** name concrete risks, missing tests, or regressions.\n\n## Change Integrity\n\nTreat tests, fixtures, snapshots, CI workflows, package wiring, dependencies, core algorithms, generated baselines, and benchmark results as part of the specification. Changing them requires an explicit user request or a clear product reason, and the final report must call it out.\n\nGo source under `packages/typia/native` must ship under a `typia` version newer than the latest published package because npm consumers otherwise continue to install the previous native source tree. Assign that version once in a maintainer-owned release change; multiple unreleased native changes belong to the same future release instead of consuming one patch number each. Issue implementation pull requests never change package versions. A maintainer-owned release change may begin only after campaign completion, or after the user explicitly suspends the campaign and lifts the freeze, and it uses the version the user assigned.\n\nFor mechanical ports, migrations, or broad rewrites, preserve the existing algorithm and public behavior in reviewable slices. Prefer a concrete exemplar over abstract instructions, and inspect the diff before trusting a green test run.\n\n## Evidence Adoption\n\nEach production package's `evidence.config.json` selects the files that directly declare and export its maintained TypeScript and Go types and functions and references `contracts/common.md` under `../../.agents/skills`. Pure re-export barrels own no selected declaration; review their public wiring through package and consumer checks while selecting each symbol at its direct declaration. If declarations and foreign re-exports share a file, separate the declaration owner without dropping public aliases or changing behavior, and update the transformer's declaration identity when necessary. Properties retain native documentation and are reviewed through their type. Add portability and performance chapters only to the operations that own those decisions.\n\nEvery enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`. Selected tests answer `contracts/testing.md`; actual E2E boundaries also answer `contracts/e2e.md`. Unit populations, types, runners and support declarations are outside this Evidence selection while their ordinary test execution remains intact. The template and both automated workspaces have no Evidence configuration or script.\n\nRun root `pnpm evidence` to collect every enrolled owner without stopping at its first failure. Use `pnpm --filter <package> evidence` for one production owner and `pnpm evidence:tests` for tests. JSON configuration keeps the checker independent of compiling typia or evaluating a TypeScript configuration. The existing build workflow owns the CI gate; acknowledgments do not replace behavioral tests.\n\nFor an Evidence truth audit, complete the first source inspection and improvements across the entire selected population and its private helpers before any local build, test, checker run, or executable probe. Use source and history inspection during that pass. Formatting remains the final pre-merge cleanup gate. After the first pass, collect each necessary integrated validation once; repeat only for a new change, failure, or unresolved concern. A coordinator assigns disjoint owners, collects returned findings, resolves shared causes, and prevents duplicate inventories, builds, and validation by individual reviewers.\n\n1. Finish the complete report before repairing obligations. Group missing answers, code and documentation defects, selection mistakes, generated-source provenance, and incomplete analysis by cause.\n2. Inspect each selected declaration and its private helpers against every applicable chapter. Fix verified defects before writing the answer; the acknowledgment describes the resulting implementation.\n3. Write `@evidence contracts/<document>.md#<anchor> <reason>` in native documentation, separated from descriptive prose by a blank comment line. Address the actual question for that declaration. Use `@evidenceExclude` only for a genuinely inapplicable individual chapter with its concrete reason.\n4. Account for private helpers, anonymous callbacks, dynamically registered cases, script entry bodies, and compile-only cases from their source and runners. Make executable entries selectable within the configured population where practical; record remaining review-only coverage honestly. Preserve compiler visibility tags such as `@internal`; removing them can change emitted declarations. Explain unaddressable helpers in their actual calling operation's acknowledgment and record their review-only scope. After the complete first pass, use `pnpm exec evidence list --config <config>` or `pnpm exec evidence inspect '<target>' --config <config>` only for unresolved address or resolution questions.\n5. Check the complete population after the first pass and its improvements finish. Verify composed claims together, including local re-export resolution. Keep the issue open and PR draft while obligations or incomplete analysis remain, and record progress as formal PR reviews.\n\nDo not weaken severity, narrow a maintained population, add generic compliance prose, or exclude a whole document to silence obligations. Exclude generated output, copied fixture input, dependencies and build output only with verified provenance. Authored generators and helpers remain maintained source; their maintenance does not enroll them in Evidence. Generated cases in the two automated workspaces remain executed through their ordinary runners and are outside Evidence. Verify selected feature functions against their actual runners without expanding the configured population to every executed declaration.\n","packages/vercel/package.json":"{\n  \"name\": \"@typia/vercel\",\n  \"version\": \"15.1.0\",\n  \"description\": \"Vercel AI SDK integration for typia\",\n  \"main\": \"src/index.ts\",\n  \"exports\": {\n    \".\": \"./src/index.ts\",\n    \"./package.json\": \"./package.json\"\n  },\n  \"scripts\": {\n    \"build\": \"rimraf lib && ttsc && rolldown -c\",\n    \"dev\": \"ttsc --watch\",\n    \"evidence\": \"evidence\"\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"https://github.com/samchon/typia\"\n  },\n  \"author\": \"Jeongho Nam\",\n  \"license\": \"MIT\",\n  \"bugs\": {\n    \"url\": \"https://github.com/samchon/typia/issues\"\n  },\n  \"homepage\": \"https://typia.io\",\n  \"dependencies\": {\n    \"@typia/interface\": \"workspace:^\",\n    \"@typia/utils\": \"workspace:^\"\n  },\n  \"peerDependencies\": {\n    \"ai\": \">=6.0.0\"\n  },\n  \"devDependencies\": {\n    \"@types/json-schema\": \"^7.0.15\",\n    \"ai\": \"^6.0.116\",\n    \"rimraf\": \"catalog:utils\",\n    \"rolldown\": \"catalog:rolldown\",\n    \"tinyglobby\": \"^0.2.12\",\n    \"ttsc\": \"catalog:samchon\",\n    \"typescript\": \"catalog:typescript\"\n  },\n  \"sideEffects\": false,\n  \"files\": [\n    \"README.md\",\n    \"package.json\",\n    \"lib\",\n    \"src\"\n  ],\n  \"keywords\": [\n    \"vercel\",\n    \"ai-sdk\",\n    \"typia\",\n    \"llm\",\n    \"llm-function-calling\",\n    \"ai\",\n    \"tool-calling\",\n    \"openai\",\n    \"anthropic\",\n    \"claude\",\n    \"chatgpt\",\n    \"gemini\",\n    \"validation\",\n    \"json-schema\"\n  ],\n  \"packageManager\": \"pnpm@10.6.4\",\n  \"publishConfig\": {\n    \"access\": \"public\",\n    \"main\": \"lib/index.js\",\n    \"module\": \"lib/index.mjs\",\n    \"types\": \"lib/index.d.ts\",\n    \"exports\": {\n      \".\": {\n        \"types\": \"./lib/index.d.ts\",\n        \"import\": \"./lib/index.mjs\",\n        \"default\": \"./lib/index.js\"\n      },\n      \"./package.json\": \"./package.json\"\n    }\n  }\n}\n","packages/vercel/README.md":"# vercel Documentation\n\nPath: `packages/vercel/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/README.md)","packages/vercel/tsconfig.json":"# Vercel Skill\n\nPath: `packages/vercel/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/tsconfig.json)","packages/utils/package.json":"# Utils Skill\n\nPath: `packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/package.json)","packages/utils/README.md":"# utils Documentation\n\nPath: `packages/utils/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/README.md)","packages/utils/tsconfig.json":"# Utils Skill\n\nPath: `packages/utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/tsconfig.json)","packages/typia/package.json":"# Typia Skill\n\nPath: `packages/typia/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/package.json)","packages/typia/tsconfig.json":"# Typia Skill\n\nPath: `packages/typia/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/tsconfig.json)","packages/typia/typedoc.json":"# Typia Skill\n\nPath: `packages/typia/typedoc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/typedoc.json)","packages/mcp/package.json":"# Mcp Skill\n\nPath: `packages/mcp/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/package.json)","packages/mcp/README.md":"# mcp Documentation\n\nPath: `packages/mcp/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/README.md)","packages/mcp/tsconfig.json":"# Mcp Skill\n\nPath: `packages/mcp/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/tsconfig.json)","packages/langchain/package.json":"# Langchain Skill\n\nPath: `packages/langchain/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/package.json)","packages/langchain/README.md":"# langchain Documentation\n\nPath: `packages/langchain/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/README.md)","packages/langchain/tsconfig.json":"# Langchain Skill\n\nPath: `packages/langchain/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/tsconfig.json)","packages/interface/package.json":"# Interface Skill\n\nPath: `packages/interface/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/package.json)","packages/interface/README.md":"# interface Documentation\n\nPath: `packages/interface/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/README.md)","packages/interface/tsconfig.json":"# Interface Skill\n\nPath: `packages/interface/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/tsconfig.json)",".agents/skills/multi-agent/issue-campaign.md":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/issue-campaign.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/issue-campaign.md)",".agents/skills/multi-agent/review.md":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/review.md)",".agents/skills/issue-campaign/development.md":"# Issue-campaign Skill\n\nPath: `.agents/skills/issue-campaign/development.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/development.md)",".agents/skills/benchmark/performance.md":"# Benchmark Skill\n\nPath: `.agents/skills/benchmark/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/performance.md)","packages/typia/test/protobuf_varint_corpus.json":"# Test Skill\n\nPath: `packages/typia/test/protobuf_varint_corpus.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/test/protobuf_varint_corpus.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n`typia` is a TypeScript transformer and runtime library that turns pure TypeScript types into inline validators, serializers, schemas, decoders, and random-data generators. It ships the `typia`, `@typia/interface`, `@typia/utils`, `@typia/langchain`, `@typia/mcp`, `@typia/vercel`, and `@typia/jev` packages.\n\n## Attitude\n\nFollow the literal request; it is the contract, not a hint at what the user \"really\" wants.\n\n- **Scope is the user's to widen.** Reinterpret the goal, weigh alternatives, or expand the task only on an explicit hand-off (\"figure it out\", \"you decide\"). Take a confident, specific ask as given.\n- **Fidelity binds the goal, not the effort.** Within that goal, act with full initiative: do the substeps it needs, verify your work, surface what you notice. Literal scope is no excuse for passive execution.\n- **Match the user's language.** Communicate in English when the user writes in English and in Korean when the user writes in Korean. Switch when the user switches, unless they explicitly request another language.\n- **Choose the principled course.** Decide from evidence, correctness, product boundaries, and the durable consequence. Time, difficulty, and consequence surface are reasons to investigate and validate more carefully, never reasons to settle for a shortcut, workaround, or weaker standard.\n- **Evidence precedes correction.** Treat issue reports, review proposals, and claims that something is wrong or missing as hypotheses. Verify the real code path, tests, generated artifacts, upstream ownership, and history before accepting the premise or changing behavior.\n- **Trace the consequence surface.** A named file or failing case is the starting point, not the investigation boundary. Follow the same cause through downstream consumers, side effects, state transitions, platforms, and boundary cases, then address the whole verified class of failure within the requested goal.\n- **Collect every symptom before correcting.** Finish the test run, CI run, reproduction, or review round that produced a finding before repairing it. Group all findings by cause, trace their consequences, and correct the complete verified set together.\n- **Default over ask.** On an ambiguous detail, pick the sensible default and say what you chose; reserve questions for forks only the user can settle.\n\n## Skills\n\nDurable project conventions and workflows live under `.agents/skills/`. Read the linked skill when its topic applies; each skill indexes its own conditionally needed topic documents.\n\n### Project Outline\n\nWhat typia is, the package family, the JS-descriptor / Go-plugin boundary, the workspace layout, product boundaries, and canonical commands, `.agents/skills/project/SKILL.md`.\n\n### Development\n\nWork rules, testing, validation, consequence analysis, and change integrity, `.agents/skills/development/SKILL.md`. Read before writing or modifying code.\n\n### Implementation Contracts\n\nSelf-acknowledgments for maintained production declarations, unit tests, and E2E tests, `.agents/skills/contracts/SKILL.md`. Read when implementing or reviewing those declarations or selecting Evidence checklists.\n\n### Documentation\n\nREADME, website guide, and agent-instruction authoring rules, `.agents/skills/documentation/SKILL.md`. Read before writing or modifying documentation.\n\n### Issue Campaigns\n\nDefault solo repository-wide issue discovery, issue publication, one CI-validated implementation pull request per cycle, and renewed discovery, `.agents/skills/issue-campaign/SKILL.md`. Read when the user asks for a broad audit, many issue candidates, or an issue-to-implementation campaign without explicitly requesting parallel agents; do not use it for one already-defined issue.\n\n### Review\n\nDefault solo Self-Review, unqualified review, and exhaustive issue-discovery rounds, `.agents/skills/review/SKILL.md`. The reviewer inspects the whole declared surface and repeats fresh rounds until a complete pass produces no sound improvement or meaningful issue candidate.\n\n### Multi-Agent Workflows\n\nExplicitly parallel review and issue-campaign variants live under one entry point, `.agents/skills/multi-agent/SKILL.md`. Read it only when the user explicitly asks for a team, parallel, or multi-agent workflow. Multi-agent issue campaigns parallelize discovery and implementation by default and switch to solo implementation only on an explicit discovery-only parallel request; Self-Review remains solo.\n\n### Discussion\n\nStructured multi-agent topic discussion with persistent research notes and transcripts, `.agents/skills/discussion/SKILL.md`. Read only when the user explicitly asks for a discussion; review and issue discovery do not imply discussion.\n\n### Pull Request Submission\n\nBranch, commit, pull request, check, and merge flow, `.agents/skills/pull-request/SKILL.md`. Read when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, or propose one on unprompted initiative.\n\n### Benchmark\n\nBenchmark runners, fixture integrity, measurement integrity, result archives, and publication, `.agents/skills/benchmark/SKILL.md`. Read before running, modifying, or publishing benchmark results.\n\n## Maintenance\n\n### Writing style\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans as well as agents. Read the documentation skill before editing either; it defines concise, clear agent-instruction writing and the prose-line rule.\n\n### AGENTS.md\n\nThis is the single shared entry point for both Claude Code (via `CLAUDE.md -> @AGENTS.md`) and Codex CLI. Keep it to the brief product identity, global attitude, and skill index. The H2s are `## Attitude`, `## Skills`, and `## Maintenance`; `## Attitude` is the one place global agent-behavior rules live.\n\nUpdate AGENTS.md only for repository-contract changes: a new skill area, a renamed or merged skill, a workflow that no longer fits an existing skill, a release-process change, or a coding-agent rule that applies globally before any skill loads.\n\n### Skills\n\n- **Location.** `.agents/skills/<kebab-name>/SKILL.md`. No numeric prefix. Each file opens with YAML frontmatter whose `name` matches the directory and whose third-person `description` states what the skill covers and when to use it.\n- **Core in SKILL.md, conditional topics as sibling documents.** Keep always-applicable procedure in SKILL.md. Move a topic needed only under a specific condition to a one-level-deep sibling document and link it with that read condition.\n- **Two trigger surfaces, one scope.** The frontmatter description is the full trigger contract, including exclusions. The AGENTS.md pointer mirrors that scope more briefly. Correct the frontmatter first when the scope changes.\n- **Create or merge.** Add a skill when a substantial repository concern would otherwise inflate AGENTS.md beyond an index. Merge sibling concerns when they share most of their structure.\n- **Repository skill files only.** Keep repository skills to `SKILL.md` and conditionally loaded sibling documents. Do not add separate `multi-agent-*` skills; the parallel variants live under the one `multi-agent` skill.\n- **Headings are plain.** No chapter numbers in skill or AGENTS.md headings. Use descriptive titles.\n- **Current set.** The repository skills are `project`, `contracts`, `development`, `documentation`, `issue-campaign`, `review`, `multi-agent`, `discussion`, `pull-request`, and `benchmark`.\n","isInternal":false,"tokens":1557,"sizeBytes":7485},{"name":"performance.md","path":".agents/skills/benchmark/performance.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/performance.md","title":"Benchmark Skill","category":"anthropic-skill","format":"markdown","content":"# Benchmark Skill\n\nPath: `.agents/skills/benchmark/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/performance.md)","tokens":300,"sizeBytes":190},{"name":"SKILL.md","path":".agents/skills/benchmark/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/SKILL.md","title":"benchmark","category":"anthropic-skill","format":"markdown","content":"---\nname: benchmark\ndescription: Defines typia benchmark fixture integrity, result reporting, and publication safeguards. Use before running or modifying @typia/benchmark, changing a fixture, or publishing benchmark results.\n---\n\n# Benchmark\n\nThis repository owns one benchmark system. Read its procedure in full before acting:\n\n- [performance.md](performance.md): `@typia/benchmark` throughput against competing runtime libraries, including generated programs, structure fixtures, and the per-CPU result archive.\n\n## Measurement Integrity\n\n- Measure the real product. Do not add benchmark-only branches, fixture-name checks, expected-answer checks, monkey patches, or agent restrictions that would be wrong for an unmeasured repository.\n- Give every comparator the setup its own documentation prescribes. Measuring a deliberately underconfigured competitor invalidates the comparison.\n- Preserve the workload defined by the selected procedure. A faster result obtained by validating, serializing, serving, or reading less input is not an optimization.\n- Treat a surprising result as evidence that the change is not yet understood. Inspect the raw report or trace before accepting, explaining away, or patching around it.\n\n## Fixture Changes\n\n`benchmark/src/programs/` mixes generated leaf programs with hand-maintained helpers. Edit generated `benchmark-*.ts` files through their source under `benchmark/src/template/`; edit shared `create*.ts` helpers and `benchmark/src/structures/` in place.\n\nFinish every fixture change before publishing it:\n\n1. Run the relevant template entrypoint, then the benchmark package's build commands until they finish green. `pnpm template` regenerates only the templates imported by `benchmark/src/template/index.ts`. Defer repository formatting to the development skill's final pre-merge cleanup gate.\n2. Confirm every comparator receives the same structure and input for the measured row.\n3. Review the generated-program diff. A stale or inconsistent generated program contaminates every later run.\n\nBenchmark READMEs and prose follow AGENTS.md `## Maintenance` and the documentation skill.\n\n## Report Results\n\nEvery result table reported in chat or committed to the result archive must be preserved for the active pull request. When the user has authorized PR updates under the pull-request skill, maintain one sticky comment beginning with `<!-- typia-benchmark-results -->`; update it with the latest table, report paths, and known invalid or missing categories.\n\nIf no pull request exists or no update is authorized, keep the result in the final report and mark the comment as pending. Post it only after the user creates or authorizes updating the pull request.\n\n## Campaign Batching\n\nWhen benchmark findings produce multiple implementation issues, load the issue-campaign skill and use its planning and claim procedure unchanged for the dependency DAG, claim freeze, and official GitHub `createdAt`-to-`mergedAt` duration: [Plan One Cycle Pull Request](../issue-campaign/development.md#plan-one-cycle-pull-request) for a solo campaign, or [Plan And Claim A Pull Request Wave](../multi-agent/issue-campaign.md#plan-and-claim-a-pull-request-wave) with its batch admission test, merge pressure, and grouping and split ledger when the user explicitly requested a parallel campaign. This benchmark skill continues to own workload, fixture, measurement, result, and publication integrity; do not redefine pull-request batching here.\n\n## Campaign Cleanup\n\nWhen a benchmark campaign uses a disposable worktree or an isolated measurement root, finish cleanup before marking that assignment complete. Preserve the committed result archive and compact command evidence, but remove every disposable worktree and its assigned mutable roots: `GOCACHE`, `GOTMPDIR`, `TTSC_CACHE_DIR`, generated-program scratch tree, dependency install tree, and temporary consumer or report staging tree. Go temporary assets are never reusable campaign evidence.\n\n1. Record the measured commit, command, result paths and hashes, environment, and any retained published result archive.\n2. Confirm the worktree and mutable roots contain no unreported source or result artifact.\n3. Remove the mutable roots and, for an assigned disposable worktree, run `git worktree remove --force <path>` for its exact path.\n4. Verify every removed root and, when applicable, worktree path no longer exists, run `git worktree prune`, delete the associated disposable local topic branch when one was created, and confirm no worktree registration remains.\n\nIf a measurement is abandoned or invalid, retain only the diagnostic record needed to explain it; remove its worktree and Go temporary assets by the same procedure.\n","frontmatter":{"name":"benchmark","description":"Defines typia benchmark fixture integrity, result reporting, and publication safeguards. Use before running or modifying @typia/benchmark, changing a fixture, or publishing benchmark results."},"isInternal":false,"tokens":911,"sizeBytes":4712},{"name":"SKILL.md","path":".agents/skills/development/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/development/SKILL.md","title":"development","category":"anthropic-skill","format":"markdown","content":"---\nname: development\ndescription: Defines typia implementation rules, testing standards, validation, consequence analysis, and change integrity. Use before writing or modifying source, tests, workflows, package wiring, fixtures, generated baselines, or algorithms.\n---\n\n# Development\n\n## Contents\n\n- [Forbidden](#forbidden)\n- [Work Rules](#work-rules)\n- [Consequence Analysis](#consequence-analysis)\n- [Plugin Configuration](#plugin-configuration)\n- [Testing](#testing)\n- [Validation](#validation)\n- [Change Integrity](#change-integrity)\n- [Evidence Adoption](#evidence-adoption)\n\n## Forbidden\n\nRead the [contracts skill](../contracts/SKILL.md) before changing maintained production declarations. Its common checklist owns implementation acknowledgments; scoped checklists apply by responsibility. When a failure disproves an assumption, correct its owner and remove superseded compensations in the same repair.\n\nThese four are never acceptable; choosing any one means the approach is already wrong.\n\n- **No monkey-patching or hardcoding.** Don't special-case a consumer, a fixture name, or an expected value to make output match. Fix the general logic.\n- **No test-passing-only logic.** Code exists to be correct, not to turn a check green. A branch whose only purpose is to satisfy one assertion is a bug in disguise.\n- **No forcing a broken design.** When the same failure keeps returning under patch after patch, the design is wrong. Stop, find the root cause, and fix the design instead of looping forever on symptoms.\n- **No whack-a-mole.** Don't patch the one case that surfaced and move on. Think expansively about every case the same root cause can produce, and seal them all with coverage so the class of failure cannot recur.\n\n## Work Rules\n\n- Choose the principled course. Time, difficulty, and the breadth of consequences require more careful analysis and validation; they never justify a shortcut, leaving a verified consequence unaddressed, or a weaker acceptance standard.\n- Match existing conventions. Before adding a file, function, or test, open a nearby peer and mirror its naming, location, and code style; don't create parallel structures.\n- Respect package boundaries. The shared native transform lives under `packages/typia/native`; don't fork a second transform into an adapter package or reintroduce a TypeScript-side transformer.\n- Keep package detection installation-safe. Resolve the target package root, as `packages/typia/src/transform.ts` does with `require.resolve(\"typia/package.json\")`; workspace path substrings and hard-coded fixture names fail for npm consumers.\n- Use the workspace catalogs. `pnpm-workspace.yaml` owns `samchon`, `typescript`, `rolldown`, and `utils`; the ttsc family, Evidence, tstl and tgrid use `catalog:samchon`, and internal package references use `workspace:^`.\n- Keep local outputs local. Do not commit `.env` files or the `.tgz` artifacts generated under `experiments/tarballs/`.\n- Preserve the public contract in `.agents/skills/project/SKILL.md`. Renaming or removing `typia.*`, `@typia/interface` types, or the plugin descriptor shape is a deliberate product change, not incidental cleanup.\n- When public behavior changes, update the matching page under `website/src/content/docs/**` in the same change. Follow `.agents/skills/documentation/SKILL.md`.\n- Run `pnpm format` only in the final pre-merge cleanup after implementation and CI repairs are complete, not before each commit or push. Commit its integrated result and require green CI on that final head before merging. If later edits require formatting, return to this final cleanup gate. Parallel issue-campaign implementation batches defer the repository-wide formatter to their dedicated Post-Campaign Cleanup pull request.\n\n## Consequence Analysis\n\nTreat a reported example as one witness of a cause, not the complete problem statement. Before changing code, trace the same cause through:\n\n- every caller and downstream consumer;\n- normal, error, and recovery state transitions;\n- concurrency, caching, and generated output;\n- Windows and POSIX behavior;\n- compatibility constraints and boundary inputs.\n\nFix the verified class of failure, not only the reported witness. Cover positive, negative, and boundary cases without expanding the user's product goal.\n\n## Plugin Configuration\n\n`ttsc` discovers typia by default from the `ttsc.plugin.transform` entry in `packages/typia/package.json`. Consumer projects add a `compilerOptions.plugins` entry with `transform: \"typia/lib/transform\"` only when they need to set optional transform flags.\n\n`packages/typia/src/transform.ts` is a JavaScript descriptor source, not a transformer. It resolves the installed typia package and returns the Go command at `packages/typia/native/cmd/ttsc-typia`; `ttsc` builds that source into the workspace cache. Keep type analysis, AST rewriting, diagnostics, and typia-owned options (`functional`, `numeric`, `finite`, and `undefined`) on the Go side.\n\nTest workspaces normally use `typia/lib/transform`. Source-only workspaces such as the benchmark may point at `typia/src/transform.ts`, but that still loads the same descriptor and native command. Do not add a second plugin host to make a local layout pass.\n\n## Testing\n\nRead the [testing contracts](../contracts/testing.md) for every test and the [E2E contracts](../contracts/e2e.md) when it exercises a necessary real component boundary. Classify by actual execution, not language, directory name, filesystem use, or duration. Maintained helpers answer production contracts when they own implementation decisions.\n\n**One test case per file, named after what it asserts.** This is the rule for new and changed cases in both languages, even where older files predate it.\n\n### Go tests\n\n- **Public and contract tests:** keep black-box and exported-API coverage under `packages/typia/test/**`, mirroring the native concern where practical. These tests import the native module through `packages/typia/test/go.mod` and run with `pnpm test:go:public`.\n- **Colocated native tests:** keep same-package implementation, command, transform, and emitter coverage beside the Go source as `packages/typia/native/**/*_test.go`. Untagged cases run with `pnpm test:go:native`.\n- **Native-internal tagged tests:** use `//go:build typia_native_internal` only when the case requires internal-only coverage. Root `pnpm test:go` does not enable that tag; run `go -C packages/typia/test test -tags typia_native_internal ../native/...` when tagged coverage is relevant.\n\nUse one `Test*` function per test file and mirror a nearby test's package, fixture, and cleanup pattern. Command-level transform regressions belong near `packages/typia/native/cmd/ttsc-typia`; public contract probes belong under `packages/typia/test`.\n\n### TypeScript suites\n\n`pnpm test:packages` starts every `tests/test-*` workspace. They have these shapes:\n\n- **Function-per-file:** `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, and `test-utils` discover `src/features/**/test_*.ts` through `DynamicExecutor`. Export exactly one `test_<snake_case>` function from a matching filename. `DynamicExecutor` selects and reports a test by its exported name, so a name that disagrees with its file makes the test unreachable by that file's name. `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` additionally run portable unit cases from `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` without the native plugin (`pnpm --filter ./tests/<workspace> test:unit`); they follow the same one-function-per-file naming rule.\n- **Generated matrices:** `test-typia-automated` and `test-utils-automated` delete and regenerate `src/features/**` when they run. Do not hand-edit those trees. Change the controller/template metadata or `@typia/template`; keep the committed ObjectSimple composite layer in `test-typia-automated/src/composite/**` hand-maintained.\n- **Transform rejection:** `test-error` compiles invalid call sites and asserts the diagnostics that reject them. A failed build publishes no output, so the suite reads no emitted JavaScript: it requires the build to fail, every fixture to typecheck, and every fixture to be named by a typia diagnostic. Add cases beside their feature group, and keep each fixture valid TypeScript that only typia rejects — a type error aborts the build before the transform runs and would leave the suite with nothing to observe.\n- **Type compilation:** `test-interface` is a compile-only TypeScript `tsc --noEmit` suite for `@typia/interface` type contracts and public typia signatures; type-only factory checks execute no factory.\n\nUse `TestValidator` and `DynamicExecutor` from `@nestia/e2e`, `@typia/template` structures and `TestServant`, and each suite's local `internal/` helpers. Do not reach into another suite's internals or duplicate a reusable structure inside one test workspace.\n\nAssert structural equality with `TestEquality` from `@typia/template/equality`. Its `equals` is symmetric and compares `Date`, `Map`, and `Set` by content; use `subset` only when an assertion pins some fields of a larger result on purpose, with the expected value first. Never call `TestValidator.equals`: it walks only its first argument's keys and sees no content in dates, maps, or sets, so it passes whatever the actual lost (#2401). Never call `TestValidator.error` either: on a synchronous task it swallows its own failure and passes whether or not the task throws (#2460). Assert a synchronous throw by comparing `TestEquality.thrown(task)` with the expected message, and an asynchronous one by awaiting `task().then(() => undefined, (error: unknown) => error)` and comparing what it rejects with. Compare prototypes and other identities with `===`.\n\nOpen every new or materially changed case with a doc comment in the same three-part shape: a one-line `Verifies ...` headline, a short paragraph stating the non-obvious _why_ (which branch or regression is being pinned), and a 2+-step numbered list summarizing the scenario.\n\n```ts\n/**\n * Verifies typia.llm.schema emits `anyOf` for a discriminated union.\n *\n * Locks the union branch of the LLM schema converter. A regression in branch\n * selection would silently emit one variant and lose the other from the\n * function-calling schema.\n *\n * 1. Declare two object variants with a shared discriminator.\n * 2. Generate the LLM schema for their union.\n * 3. Assert both variants remain in the emitted `anyOf`.\n */\nexport const test_llm_schema_anyof = (): void => {\n  /* ... */\n};\n```\n\n### Coverage, not happy paths\n\nA test that only feeds a transform its ordinary successful input and asserts that the result is accepted proves one path, not correctness. The native transformer spans validators, serializers, schemas, decoders, diagnostics, and generated helpers; each predicate or branch needs more than its happy path:\n\n- **The transformation direction.** When a call should be rewritten, assert observable emitted or runtime behavior that differs from the untransformed stub. For generators, start from hand-written input and verify the generated output, not only that an existing output compiles.\n- **A negative twin for every positive.** Wherever a predicate accepts, rewrites, narrows, serializes, or reports a diagnostic, pin an adjacent case one property away where it must not do so. An over-match stays invisible until the counter-example exists.\n- **Boundaries.** Cover the empty case, the single-element case, recursion limits, optional and nullable members, exact numeric limits, deepest nesting, and the tag or compiler option that flips the decision.\n- **Oracle-derived expectations.** Take expected behavior from TypeScript semantics and the authoritative JSON Schema, OpenAPI, Protocol Buffer, or adapter contract, never from whatever the current code happens to emit. A snapshot written against the implementation's own output locks its bugs in.\n\nThis is not a validator-only rule. The same happy-path bias hides serializer corruption, schema loss, compiler-process failures, and native diagnostic regressions, so every feature carries the burden.\n\n## Validation\n\nRun the narrowest command that proves the change first, then a broader command when shared behavior, the transform, packaging, or documentation changed. Report any command that could not be run.\n\n- **One public Go concern:** `pnpm test:go:public`.\n- **One native Go concern:** `pnpm test:go:native`; add the tagged command from [Go tests](#go-tests) when the changed path has `typia_native_internal` coverage.\n- **One TypeScript workspace:** `pnpm --filter ./tests/<name> start`.\n- **One package:** `pnpm --filter ./packages/<name> build`.\n- **Transform, descriptor, or shared package:** `pnpm test`; use `pnpm build` as the broader package compilation gate.\n- **Packaging:** run root `pnpm package:tgz`, then inspect or smoke-test a clean install. It builds every package and verifies the published entry points before packing (`pnpm pack` alone no longer builds; the manifests carry no `prepack`). Tarballs are generated under `experiments/tarballs/`; do not commit or hand-edit them.\n- **Website or guide changes:** reproduce the fresh CI prerequisites: place a ttsc checkout at `../ttsc`, run root `pnpm install` and `pnpm package:tgz`, then run `pnpm build` inside `website/`. The compiler-dependencies package installs the staged tarballs, and the playground Wasm build resolves the sibling ttsc Go modules.\n\nVerification shape depends on the change type:\n\n- **Bug fix:** name the failing case and the expected behavior; run a repro that fails before the fix and passes after.\n- **Feature:** name the observable behavior; exercise it end-to-end.\n- **Refactor:** name what should stay unchanged; rely on the existing test suite or a behavior-locking probe.\n- **Review:** name concrete risks, missing tests, or regressions.\n\n## Change Integrity\n\nTreat tests, fixtures, snapshots, CI workflows, package wiring, dependencies, core algorithms, generated baselines, and benchmark results as part of the specification. Changing them requires an explicit user request or a clear product reason, and the final report must call it out.\n\nGo source under `packages/typia/native` must ship under a `typia` version newer than the latest published package because npm consumers otherwise continue to install the previous native source tree. Assign that version once in a maintainer-owned release change; multiple unreleased native changes belong to the same future release instead of consuming one patch number each. Issue implementation pull requests never change package versions. A maintainer-owned release change may begin only after campaign completion, or after the user explicitly suspends the campaign and lifts the freeze, and it uses the version the user assigned.\n\nFor mechanical ports, migrations, or broad rewrites, preserve the existing algorithm and public behavior in reviewable slices. Prefer a concrete exemplar over abstract instructions, and inspect the diff before trusting a green test run.\n\n## Evidence Adoption\n\nEach production package's `evidence.config.json` selects the files that directly declare and export its maintained TypeScript and Go types and functions and references `contracts/common.md` under `../../.agents/skills`. Pure re-export barrels own no selected declaration; review their public wiring through package and consumer checks while selecting each symbol at its direct declaration. If declarations and foreign re-exports share a file, separate the declaration owner without dropping public aliases or changing behavior, and update the transformer's declaration identity when necessary. Properties retain native documentation and are reviewed through their type. Add portability and performance chapters only to the operations that own those decisions.\n\nEvery enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`. Selected tests answer `contracts/testing.md`; actual E2E boundaries also answer `contracts/e2e.md`. Unit populations, types, runners and support declarations are outside this Evidence selection while their ordinary test execution remains intact. The template and both automated workspaces have no Evidence configuration or script.\n\nRun root `pnpm evidence` to collect every enrolled owner without stopping at its first failure. Use `pnpm --filter <package> evidence` for one production owner and `pnpm evidence:tests` for tests. JSON configuration keeps the checker independent of compiling typia or evaluating a TypeScript configuration. The existing build workflow owns the CI gate; acknowledgments do not replace behavioral tests.\n\nFor an Evidence truth audit, complete the first source inspection and improvements across the entire selected population and its private helpers before any local build, test, checker run, or executable probe. Use source and history inspection during that pass. Formatting remains the final pre-merge cleanup gate. After the first pass, collect each necessary integrated validation once; repeat only for a new change, failure, or unresolved concern. A coordinator assigns disjoint owners, collects returned findings, resolves shared causes, and prevents duplicate inventories, builds, and validation by individual reviewers.\n\n1. Finish the complete report before repairing obligations. Group missing answers, code and documentation defects, selection mistakes, generated-source provenance, and incomplete analysis by cause.\n2. Inspect each selected declaration and its private helpers against every applicable chapter. Fix verified defects before writing the answer; the acknowledgment describes the resulting implementation.\n3. Write `@evidence contracts/<document>.md#<anchor> <reason>` in native documentation, separated from descriptive prose by a blank comment line. Address the actual question for that declaration. Use `@evidenceExclude` only for a genuinely inapplicable individual chapter with its concrete reason.\n4. Account for private helpers, anonymous callbacks, dynamically registered cases, script entry bodies, and compile-only cases from their source and runners. Make executable entries selectable within the configured population where practical; record remaining review-only coverage honestly. Preserve compiler visibility tags such as `@internal`; removing them can change emitted declarations. Explain unaddressable helpers in their actual calling operation's acknowledgment and record their review-only scope. After the complete first pass, use `pnpm exec evidence list --config <config>` or `pnpm exec evidence inspect '<target>' --config <config>` only for unresolved address or resolution questions.\n5. Check the complete population after the first pass and its improvements finish. Verify composed claims together, including local re-export resolution. Keep the issue open and PR draft while obligations or incomplete analysis remain, and record progress as formal PR reviews.\n\nDo not weaken severity, narrow a maintained population, add generic compliance prose, or exclude a whole document to silence obligations. Exclude generated output, copied fixture input, dependencies and build output only with verified provenance. Authored generators and helpers remain maintained source; their maintenance does not enroll them in Evidence. Generated cases in the two automated workspaces remain executed through their ordinary runners and are outside Evidence. Verify selected feature functions against their actual runners without expanding the configured population to every executed declaration.\n","frontmatter":{"name":"development","description":"Defines typia implementation rules, testing standards, validation, consequence analysis, and change integrity. Use before writing or modifying source, tests, workflows, package wiring, fixtures, generated baselines, or algorithms."},"isInternal":false,"tokens":4026,"sizeBytes":19606},{"name":"SKILL.md","path":".agents/skills/discussion/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/discussion/SKILL.md","title":"discussion","category":"anthropic-skill","format":"markdown","content":"---\nname: discussion\ndescription: Runs structured multi-agent discussions for open-ended typia topics. Use only when the user explicitly asks for Discussion or a team debate with transcripts and conclusions; do not use for Self-Review, a solo or multi-agent review, research review, or issue discovery.\n---\n\n# Discussion\n\nDiscussion explores a topic without changing code or turning the exchange into a review queue. Reviews and issue discovery use the review skill instead.\n\n## Team\n\nForm the largest practical team, up to nine agents so the lead and participants fit the ten-agent session limit. Give every agent a self-contained brief with the topic, constraints, known evidence, output expectations, and the exact repository instructions and skills to read. Do not give a preferred conclusion or divide the topic into assigned slices.\n\n## Knowledge Base\n\nCreate `.discussions/<topic>/` with a short filesystem-safe name. Do not delete or overwrite an existing discussion directory unless the user explicitly requests it.\n\nEach agent maintains a personal wiki-style subdirectory under the topic directory. Agents read the live transcript and one another's statements between turns, continue researching, and revise their own notes.\n\n## Transcript\n\nRun three unrestricted transcript rounds as `round1.md`, `round2.md`, and `round3.md`. The lead moderates and records every statement in speaking order as a live transcript, not a retrospective summary. Do not narrow the topic unless the user does.\n\nAfter `round3.md`, the lead writes agreed conclusions, disagreements, and major open points to `summary.md`, reports the result, and waits. Discussion does not itself authorize implementation.\n","frontmatter":{"name":"discussion","description":"Runs structured multi-agent discussions for open-ended typia topics. Use only when the user explicitly asks for Discussion or a team debate with transcripts and conclusions; do not use for Self-Review, a solo or multi-agent review, research review, or issue discovery."},"isInternal":false,"tokens":321,"sizeBytes":1694},{"name":"SKILL.md","path":".agents/skills/documentation/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/documentation/SKILL.md","title":"documentation","category":"anthropic-skill","format":"markdown","content":"---\nname: documentation\ndescription: Defines README, website-guide, and agent-instruction structure, audience, prose formatting, and voice for typia. Use before writing, modifying, renaming, or moving repository documentation.\n---\n\n# Documentation\n\n## READMEs\n\nREADME files are for the final reader of that package or directory. Start with what it is, when to use it, installation, the smallest working setup, and the common path.\n\nKeep README language direct and practical. Avoid compiler theory, protocol details, internal architecture, and edge cases unless the reader must know them to use the package. Move deep explanations into the website guides and link them only as the next step.\n\n## Guide Documents\n\nUser-facing guides live under `website/src/content/docs/**` as MDX and publish at https://typia.io/docs. The site uses Next.js and Nextra, exports a static site, and deploys to GitHub Pages. Keep one audience and one task per page.\n\nThe current tree is organized by feature area:\n\n- top-level pages `index.mdx`, `setup.mdx`, `pure.mdx`, `random.mdx`, and `misc.mdx` cover introduction, setup, and cross-cutting features;\n- `validators/`, `json/`, `protobuf/`, and `llm/` own their operation guides; and\n- `utilization/` owns framework integrations for MCP, Vercel AI SDK, LangChain, NestJS, tRPC, and Hono.\n\nThe root and each guide folder use `_meta.ts` for sidebar order and labels. Nextra reads keys in declaration order; `{ display: \"hidden\" }` keeps a page reachable while removing it from the sidebar. Update the matching `_meta.ts` whenever a guide is added, renamed, moved, hidden, or exposed.\n\nWhen emitted code is the point, pair the TypeScript source with its compiled JavaScript in side-by-side tabs so the reader can see what the transform replaces. Back performance claims with a specific benchmark result instead of an adjective. Follow the fresh website-build prerequisites in `.agents/skills/development/SKILL.md`.\n\n## Agent Instructions\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans and agents. Keep only the product-wide contract in `AGENTS.md`, the always-applicable procedure in `SKILL.md`, and conditional detail in a linked sibling document.\n\nConcise and clear means:\n\n- Include the context needed to act correctly. Do not make the reader infer prerequisites, exceptions, reasons, or stop conditions merely to shorten the document.\n- State each rule at its owning document and link to it elsewhere. Remove repeated wording, not necessary substance.\n- Give each paragraph one job. Separate purpose, rule, rationale, procedure, and consequence when combining them obscures the action.\n- Use structure to compress meaning: ordered lists for procedures, bullets for choices and checks, tables for repeated mappings, and code blocks for exact commands.\n- State the rule before its reason. Use a negative rule only when it prevents a named failure the affirmative rule does not already exclude.\n- Link to website guides, READMEs, or source comments instead of paraphrasing them.\n\n## Prose line breaks\n\nWrite each Markdown or MDX paragraph on one source line. Never hard-wrap a single paragraph at a fixed column: Markdown already soft-wraps it, while manual wrapping makes small edits reflow unrelated lines.\n\nOne source line does not mean one long paragraph. Insert a blank line whenever the idea changes. Keep structural line breaks for paragraphs, list items, headings, tables, and fenced code.\n\nThis is a manual convention, not a formatter gate. Root `pnpm format` runs Prettier over `**/*.ts` and formats changed Go files; it does not format `*.md` or `*.mdx`, and the repository does not set `proseWrap`. Preserve one-line paragraphs yourself.\n\n## Voice\n\nWrite in the plain, direct, technical voice of the human-authored typia docs. Do not write like an AI assistant.\n\n- No AI-cliche phrasing: \"not only X but also Y\", \"whether you're X or Y\", \"it's worth noting\", \"let's dive in\", and reflexive hedging.\n- No marketing adjectives such as \"seamless\", \"powerful\", \"robust\", or \"effortless\". State the behavior; where speed is the point, cite the benchmark.\n- No wrap-up sentence that just restates the paragraph. State the fact and stop.\n- Em-dashes already fit the existing typia prose; do not remove them mechanically or impose a punctuation ban.\n- Sidebar emoji in `_meta.ts` are part of the existing navigation voice. Keep them where they already fit; this exception does not turn guide prose into decorative copy.\n","frontmatter":{"name":"documentation","description":"Defines README, website-guide, and agent-instruction structure, audience, prose formatting, and voice for typia. Use before writing, modifying, renaming, or moving repository documentation."},"isInternal":false,"tokens":978,"sizeBytes":4477},{"name":"development.md","path":".agents/skills/issue-campaign/development.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/development.md","title":"Issue-campaign Skill","category":"anthropic-skill","format":"markdown","content":"# Issue-campaign Skill\n\nPath: `.agents/skills/issue-campaign/development.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/development.md)","tokens":300,"sizeBytes":205},{"name":"SKILL.md","path":".agents/skills/issue-campaign/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/SKILL.md","title":"issue-campaign","category":"anthropic-skill","format":"markdown","content":"---\nname: issue-campaign\ndescription: \"Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request.\"\n---\n\n# Issue Campaign\n\nAn issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that [development.md](development.md#implement-and-write-tests) requires for every landed commit.\n\nUse the [multi-agent skill](../multi-agent/SKILL.md) and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.\n\nThe user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.\n\nApply [AGENTS.md's **Choose the principled course** rule](../../../AGENTS.md#attitude) to every admission, disposition, implementation, and review decision.\n\nRead the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds; issue discovery is independent review, not discussion. Read [development.md](development.md) in full only when implementation is authorized.\n\n## Campaign Knowledge Base\n\nCreate `.wiki/<campaign>/` with a short filesystem-safe campaign name. Preserve any existing campaign directory and reconcile it rather than deleting or assuming a blank slate.\n\nKeep concise, current Markdown documents for:\n\n- repository provenance, architecture, validation ownership, and product boundaries;\n- experiments, reproductions, dogfooding, and related issue or pull-request history;\n- every raw candidate, its evidence, dependencies, and final disposition, including combinations, splits, rejections, and deferrals with the evidence supporting each decision;\n- the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, and official GitHub `createdAt`-to-`mergedAt` cycle timing;\n- the exact commit, dependency lock, provisioning command, supported environment contract, and tracked-file census for each discovery round;\n- a mandatory coverage matrix that crosses public operations, owners, consumers, declaration spellings and provenance, composition, transform options, input contexts and boundaries, generated artifacts, packaging, CLI, and supported platforms;\n- a per-issue consequence matrix and implementation impact record that names every caller, equivalent spelling, provenance, option, context, boundary, artifact, consumer, and platform revalidated by the fix; and\n- an integration-command manifest that records and hashes the exact commands, environment, tool versions, triggering change classes, expected artifacts, and clean-consumer setup required before and after each integration-sensitive merge.\n\nRecord raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.\n\nGive every tracked path and matrix cell a stable ID, and record one row per ID with `round`, `base SHA`, `matrix hash`, `path or cell ID`, `status`, `evidence`, and `candidate`.\n\nA status is one of four values, and it means something different for a path than for an executable cell:\n\n| Status | Tracked path | Executable matrix cell |\n| --- | --- | --- |\n| `PASS` | contents, history, owner, and linked cells were audited | the recorded oracle and controls passed |\n| `FAIL` | a candidate remains | the oracle or a control failed |\n| `N/A` | evidence that the path is outside an explicitly authorized contract | a product-contract reason |\n| `UNTESTED` | the audit is absent | the cell did not run |\n\nReconcile the path census with `git ls-files` and verify that the matrix covers every public operation and known historical dimension before the round begins. When the round discovers a missing owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells.\n\nReconcile the finished rows against the frozen census and final matrix. Any missing row, `UNTESTED`, unsupported `N/A`, or absent evidence makes the round `INCOMPLETE`.\n\nThe knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to `.wiki`.\n\n## Discover Issues\n\nRun the review skill's [Solo Issue Discovery Rounds](../review/SKILL.md#solo-issue-discovery-rounds) over the entire declared campaign scope. That procedure owns the frozen commit, environment contract, tracked-file census, mandatory coverage matrix, and the `COMPLETE` and `INCOMPLETE` round states. This section adds only what the campaign itself owns.\n\nOnly an explicit user instruction or existing public product contract can exclude a surface or environment. The campaign cannot narrow itself, and an unresolved support-policy question makes the round `INCOMPLETE`.\n\nSource is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions.\n\nNever combine results from different commits, and never accept a stale, unprovisioned, skipped, contaminated, sampled, or missing-type harness whose tags or declarations collapse to `any` or `unknown` as full-round evidence.\n\nTreat the development skill's [Forbidden](../development/SKILL.md#forbidden) section as an explicit retrospective audit contract, not only a rule for future changes. In every complete round, inspect the current implementation and its history for violations, including code that predates the campaign or passes every test. A verified violation is a meaningful issue candidate. Prove the classification from purpose, control flow, consequence, and history; resemblance or stylistic preference alone is not evidence.\n\nDo not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.\n\n### Every Round Is Full-Scope\n\nEvery round re-audits the entire declared scope from scratch against the state it was frozen on. A round is never partitioned: not by package, file, concern, platform, candidate class, validation lane, or pass, not by the areas the last cycle or the last round happened to touch, and not by splitting the scope across rounds so that each one covers a slice. What an earlier round read is never coverage for this one, whether it ran in an earlier cycle against a state a merge has since changed, or earlier in this cycle against the same commit. The [review skill's Non-Negotiable Review Law](../review/SKILL.md#non-negotiable-review-law) states the same rule for every round and review the campaign runs.\n\n### Discovery Ends Only On An Empty Round\n\nDiscovery repeats in two nested loops, and neither ends until a complete round comes up empty.\n\nInside one cycle, accepting a candidate does not end discovery. Begin another complete full-scope round against the same frozen commit and repeat until one round produces no meaningful candidate that survives verification. Only that empty round settles the cycle's issue set. Publishing or implementing from the first round that found something freezes the cycle around whatever that round happened to reach first, and the issues the next round would have added arrive too late to join it.\n\nAcross cycles, a merged cycle does not end the campaign. It produces one more discovery phase against the integrated repository, and that phase runs the inner loop to its own empty round. There is no limit on either loop, and the campaign ends only when a complete fresh round is not `INCOMPLETE`, produces no meaningful candidate that survives verification, and leaves no accepted issue unresolved.\n\nReport the campaign complete only from a round that actually came up empty. Ending after a cycle that merely felt thorough leaves the issues the next round would have found unrecorded.\n\n## Vet And Publish Issues\n\nThe same main agent owns every publication decision. For each candidate:\n\n1. Reopen its evidence and reproduce the behavior.\n2. Verify ownership, provenance, and any claimed classification under the development skill's **Forbidden** section.\n3. Trace the full consequence surface.\n4. Compare open and closed issues and pull requests.\n5. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence.\n\nRevalidate every disposition from primary evidence in a fresh state, including rejection, narrowing, combination, split, deferral, and confirmed-invalid conclusions, rather than trusting the note that first recorded it. A disposition that cannot be reproduced leaves the candidate surviving and blocks `CLEAN`; it cannot be hidden by omitting publication. The [multi-agent procedure](../multi-agent/issue-campaign.md) assigns this audit to an independent critic agent; a solo campaign performs it as a separate pass with its own recorded evidence.\n\nPublish only the adjudicated form and only with user authorization.\n\n### Self-Contained Issue Body\n\nWrite enough context for a fresh AI agent to begin implementation from the issue alone. Do not require access to local `.wiki`, the discovery conversation, or unstated repository knowledge. Cover these sections when they apply:\n\n- **Problem:** current and expected behavior, impact, and affected users.\n- **Evidence:** exact reproduction, outputs or artifacts, stable symbols, verified root cause, ownership, and provenance. For a violation of the development skill's **Forbidden** section, prove the classification from behavior, control flow, and history instead of merely naming the prohibition. Line numbers are navigation, not proof.\n- **Consequence surface:** affected consumers, states, platforms, compatibility and failure paths, plus the complete case matrix for the cause.\n- **Invariant:** the required behavior and architectural owner, without prescribing an implementation mechanism. Discovery explanations, closed issue approaches, and candidate mechanisms remain hypotheses for the implementer to validate; executed evidence establishes constraints and rejected alternatives, not a prescribed solution.\n- **Acceptance and verification:** positive, negative, boundary, and regression outcomes with narrow and broader proving commands.\n- **Coordination:** dependencies, exclusions, migration concerns, external blockers, and related open, closed, accepted, or rejected work.\n\nUse tables for repeated case mappings. Read the rendered issue back and keep its body as the current operative handoff; use comments only for chronology.\n\nBefore publication, reproduce the current failure and its independent oracle once more in a fresh state, and verify the invariant, complete owner and consumer census, supported-environment boundary, equivalent-spelling and provenance matrix, positive and negative twins, boundary cases, and a counterfactual proving that the reproduction distinguishes the expected behavior. Pass-after and fix-mutation evidence belong to implementation verification. Strike any prescribed implementation mechanism, including one that appears to fit the current evidence.\n\n## Develop And Repeat The Campaign\n\nRead [development.md](development.md) in full when the user authorizes implementation pull requests or the end of a campaign that entered implementation. It owns the single cycle pull request, empty claim, internal DAG order, test authoring, formatting, ordinary CI, red-CI repair, solo Self-Review, the integration-sensitive gate, merge, branch and temporary-asset cleanup, and renewed discovery.\n\nAn audit-only or issue-publication-only campaign does not load the development procedure or mutate repository, Actions, or GitHub state beyond the authorized publications.\n","frontmatter":{"name":"issue-campaign","description":"Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request."},"isInternal":false,"tokens":2355,"sizeBytes":12310},{"name":"issue-campaign.md","path":".agents/skills/multi-agent/issue-campaign.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/issue-campaign.md","title":"Multi-agent Skill","category":"anthropic-skill","format":"markdown","content":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/issue-campaign.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/issue-campaign.md)","tokens":300,"sizeBytes":202},{"name":"review.md","path":".agents/skills/multi-agent/review.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/review.md","title":"Multi-agent Skill","category":"anthropic-skill","format":"markdown","content":"# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/review.md)","tokens":300,"sizeBytes":186},{"name":"SKILL.md","path":".agents/skills/multi-agent/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/SKILL.md","title":"multi-agent","category":"anthropic-skill","format":"markdown","content":"---\nname: multi-agent\ndescription: \"Defines the explicitly parallel variants of typia review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review and unqualified review remain solo. Multi-agent issue campaigns parallelize discovery and implementation by default, but an explicit request may limit parallelism to discovery and return implementation to the solo campaign.\"\n---\n\n# Multi-Agent Workflows\n\nThis skill is the single entry point for every explicitly parallel review or campaign. Read the base solo skill first, then enter through the detailed document below for the requested workflow. That document names any shared multi-agent topic procedures it also requires.\n\n| Explicit request | Base skill | Detailed multi-agent procedure |\n| --- | --- | --- |\n| Team, parallel, or multi-agent review | [review](../review/SKILL.md) | [review.md](review.md) |\n| Parallel or multi-agent issue campaign | [issue-campaign](../issue-campaign/SKILL.md) | [issue-campaign.md](issue-campaign.md) |\n\n`typia` has no benchmark-campaign skill. Use [benchmark](../benchmark/SKILL.md) for measurement integrity, then the applicable issue-campaign workflow for authorized benchmark-driven implementation.\n\nDo not load this skill for Self-Review, an unqualified review, a discussion, or a campaign that does not explicitly request parallel agents.\n\n## Shared Parallelism Rules\n\n- Use the smallest number of agents that adds independent evidence or owns immediately executable disjoint work. Available thread capacity is not a reason to create an agent, and a review or discovery round is the one place where every available slot should carry a full independent pass.\n- Keep the total at ten agents including the lead, so at most nine children run at once.\n- Never create a waiter, poller, coordinator-only child, duplicate implementation owner, or agent that cannot begin useful work immediately.\n- Give every review or discovery agent the complete declared surface. Parallel review adds independent full passes; it never partitions coverage by package, file, concern, platform, or test lane.\n- Partition implementation only through verified dependency and file-ownership boundaries. One agent owns one coarse batch, branch, pull request, and worktree.\n- Keep the lead active on fact-checking, integration, conflict resolution, and decisions that do not duplicate an assigned agent.\n- Do not let agents re-delegate.\n- Self-Review remains solo for every author and every implementation branch. An independent verifier or critic is a separate agent auditing someone else's work, never a substitute for the author's own round.\n- Create worktrees only for parallel implementation batches, verification, mutation, and integrated cleanup. Solo implementation and review use the current checkout.\n- Remove every finished worktree, local branch, process, and assignment-owned temporary asset before declaring its assignment complete.\n\nThe solo campaign's [commit early-warning pass](../review/SKILL.md#commit-early-warning-pass) is a different topology and relaxes neither the full-surface rule nor the solo Self-Review rule above. A parallel review gives several reviewers the entire declared surface independently and the lead adjudicates their findings. The pass gives one read-only reader one commit's slice, reports candidates to the author who is still implementing, and leaves that author's own whole-surface round as the gate. A batch implementation agent here runs no pass, because agents do not re-delegate; the carve-out in the solo development procedure belongs to a solo campaign's main agent.\n","frontmatter":{"name":"multi-agent","description":"Defines the explicitly parallel variants of typia review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review and unqualified review remain solo. Multi-agent issue campaigns parallelize discovery and implementation by default, but an explicit request may limit parallelism to discovery and return implementation to the solo campaign."},"isInternal":false,"tokens":726,"sizeBytes":3732},{"name":"SKILL.md","path":".agents/skills/project/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/project/SKILL.md","title":"project","category":"anthropic-skill","format":"markdown","content":"---\nname: project\ndescription: Defines the typia product contract, workspace layout, package boundaries, and canonical commands. Use when orienting in the repository, working inside any package, or choosing a build, test, or format command.\n---\n\n# Project Outline\n\n## Product Contract\n\nTypia is a TypeScript transformer library built around one idea: a pure TypeScript type definition should replace the runtime helpers that other tools require schemas, decorators, or hand-written guards for. The compile-time transform reads those types and emits the runtime validator, serializer, schema, or decoder inline.\n\nThe packages:\n\n- **`typia`**: the user-facing library and native transform. Exposes the runtime validators (`is`, `assert`, `assertGuard`, `validate`), enhanced JSON serde (`json.assertParse`, `json.assertStringify`, `json.schema`), LLM function-calling harness (`llm.application`, `llm.schema`, `llm.parse`, `llm.structuredOutput`, `llm.evaluation`), Protocol Buffer encoder/decoder (`protobuf.message`, `protobuf.assertEncode`, `protobuf.assertDecode`), and the random data generator (`random`).\n- **`@typia/interface`**: shared public typings (e.g. `IJsonSchemaCollection`, `ILlmSchema`, `IValidation`) consumed by every other package and by user code.\n- **`@typia/utils`**: runtime, OpenAPI, and LLM utility helpers (e.g. `LlmTypeChecker`) that live next to but outside the transform.\n- **`@typia/langchain`**: LangChain.js integration that adapts typia's LLM harness to LangChain tools.\n- **`@typia/mcp`**: Model Context Protocol integration.\n- **`@typia/vercel`**: Vercel AI SDK integration.\n- **`@typia/jev`**: Jev evaluation model integration, converting `llm.evaluation` questions to the Jev wire format.\n\nDownstream projects (`@nestia/core`, `@agentica`, `@autobe`) build on top of typia but are not part of this repository's contract. The exported `typia.*` surface, the `@typia/interface` typings, and the `ttsc.plugin` descriptor shape are public; renaming or removing any of them is a deliberate, separate change.\n\nA single Go program under `packages/typia/native` performs the compile-time transform that emits validators, stringifiers, schemas, and decoders in place of `typia.*<T>()` call sites. `packages/typia` registers a Go command package that `ttsc` (the TypeScript-Go compiler with native plugin support) compiles into a binary on first use through its plugin manifest:\n\n```json\n\"ttsc\": { \"plugin\": { \"transform\": \"typia/lib/transform\" } }\n```\n\nThe `packages/typia/src/transform.ts` file is a plugin descriptor, not a transformer; there is no TypeScript-side transform anymore. The descriptor resolves the installed `typia` package root and returns the Go entrypoint under `native/cmd/ttsc-typia`. The adapter packages do not register their own transforms. Consumers reach the binary through `ttsc` / `ttsx` and the published descriptor. ttsc keys each plugin build by content and stores it workspace-wide under `node_modules/.cache/ttsc` (it walks up to `pnpm-workspace.yaml`), so every package and test workspace shares one binary.\n\n## Layout\n\n- `packages/*`: the published packages, including the shared Go plugin under `packages/typia/native`. Public and contract Go tests live under `packages/typia/test`; native Go tests are colocated throughout `packages/typia/native/**`. The test `go.work` resolves `ttsc` and its shims through `../node_modules/`, while the native development `go.work` resolves the sibling `ttsc` checkout.\n- `tests/template`: `@typia/template`, a workspace package that ships the structure fixtures (`ObjectSimple`, `ArrayHierarchical`, ...) and the `TestServant` runtime helper consumed by the automated suites.\n- `tests/test-*`: feature-test workspaces:\n  - `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, `test-jev`, `test-utils`: function-per-file suites under `src/features/**/test_*.ts`, each file exporting one matching `test_<snake_case>` function discovered by `DynamicExecutor` (from `@nestia/e2e`).\n  - `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` also hold portable cases under `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` by `src/unit/index.ts` under `tsconfig.unit.json`, which has no native typia plugin. Their `start` runs the unit population before the integration population. Portable utility and adapter semantics belong in the unit population; preserve each exported case's inputs, assertions and failure identity when transferring it from a transformed suite.\n  - `test-typia-automated`, `test-utils-automated`: generator-driven matrix suites over their configured typia operations and `@typia/template` structures; their generated `src/features/` trees are rebuilt by the suite.\n  - `test-interface`: compile-time tests for exported `@typia/interface` types and public typia signatures; these cases execute no typia factory.\n  - `test-error`: transform-rejection verification; the build must fail and every fixture must be named by a typia diagnostic.\n- `tests/debug`: `@typia/debug`, a one-off `ttsx` runner for ad-hoc local repros.\n- `benchmark/`: `@typia/benchmark`, performance generators with archived results under `benchmark/results/**`. See `.agents/skills/benchmark/SKILL.md`.\n- `website/src/content/docs/**`: user-facing MDX guides published at https://typia.io/docs. See `.agents/skills/documentation/SKILL.md`.\n- `examples/`, `experiments/`, `scripts/`, `config/`: example sources, tarball staging, repo utilities, and shared build configuration.\n\n## Commands\n\nCI uses Node 24.x and Go 1.26.x, while the workspace pins pnpm exactly to 10.6.4.\n\n```bash\npnpm install\npnpm evidence\npnpm format\npnpm build\npnpm test\n```\n\n`pnpm test` runs every `tests/test-*` workspace through `pnpm test:packages`, then runs both Go trees through `pnpm test:toolchain`: `go -C packages/typia/test test ./...` and `go -C packages/typia/test test ../native/...`. It needs `go` on `PATH`. Run `pnpm install` first, or the test Go workspace cannot resolve `ttsc` and its shims through `../node_modules/`. Most feature workspaces execute TypeScript directly through `ttsx`; `test-error` uses a Node harness and `test-interface` invokes TypeScript `tsc --noEmit`. Plugin-building workspaces share the cache under `node_modules/.cache/ttsc`.\n\n`pnpm evidence` checks every enrolled production owner, test feature function, and root tooling configuration without building or generating test matrices. Every enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`; unit populations, types, runners and support declarations are outside this selection while their ordinary execution remains intact. `pnpm evidence:packages` and `pnpm evidence:tests` check their enrolled workspace populations separately. The template and both automated test workspaces are not enrolled; their ordinary generation and test commands retain their behavioral coverage.\n\nRelease-time commands (most contributors skip these): `pnpm package:rc`, `pnpm package:next`, `pnpm package:latest`, and `pnpm release`. `pnpm package:tgz` stages local tarballs in `experiments/tarballs/` for offline testing. See `.agents/skills/pull-request/SKILL.md` for the remote delivery flow.\n","frontmatter":{"name":"project","description":"Defines the typia product contract, workspace layout, package boundaries, and canonical commands. Use when orienting in the repository, working inside any package, or choosing a build, test, or format command."},"isInternal":false,"tokens":1719,"sizeBytes":7247},{"name":"SKILL.md","path":".agents/skills/pull-request/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/pull-request/SKILL.md","title":"pull-request","category":"anthropic-skill","format":"markdown","content":"---\nname: pull-request\ndescription: Defines typia branch, commit, pull-request, check, and merge workflows. Use when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, update, or merge one on unprompted initiative.\n---\n\n# Pull Request Submission\n\nAct on this skill only when the user explicitly requests the corresponding remote action, or when a standing autonomous mandate authorizes it. Permission to edit locally is not permission to push or open a pull request, and permission to open or update is not permission to merge. The one exception is a standing autonomous mandate — an autonomous or remote-control campaign, or an explicit instruction to carry the work through merge: it is the request for every step it names, including push and merge, and the skill's check, verification, and self-review gates still apply to each step.\n\n## Branch From The Target\n\nBranch from the pull-request target (`master` unless stated otherwise); never commit or push directly to the target. Name the branch for the merged outcome with the repository's established type and scope, such as `feat/<scope>`, `fix/<scope>`, `docs/<scope>`, or `ci/<scope>`.\n\nSolo work never creates a clone or worktree. If the current checkout contains unrelated or protected work, stage only the authorized paths; if that cannot keep the pull request isolated, report the conflict rather than stashing, reverting, mixing, or relocating the work.\n\n## Commit Logical Units\n\nUse one commit per coherent unit when the diff is large. Follow the repository's `<type>(<scope>): <subject>` history with an imperative lowercase subject and no trailing period.\n\nRun the validation required by the development skill. Defer `pnpm format` to its final pre-merge cleanup gate; do not run it for each commit or push. Parallel issue-campaign implementation batches keep their dedicated Post-Campaign Cleanup formatter gate.\n\nStage explicit paths when the worktree is mixed. Never include unrelated user changes silently.\n\n## Write The Pull Request\n\nWrite the body at open as the historical intent statement. Include the intent, scope, deferred items, and exact local verification. State skipped checks and disabled campaign CI honestly.\n\nDo not rewrite the body after every follow-up push. Record later CI fixes, newly discovered design issues, promoted deferred work, and Self-Review results as formal GitHub pull-request reviews with the `COMMENT` event so the thread preserves chronology. Use inline review comments when an observation belongs to a changed line and the review body for commit-wide or round-wide results. Do not use ordinary issue-style pull-request comments for this ledger, and never `APPROVE` or `REQUEST_CHANGES` on your own pull request. The title describes the merged outcome in Conventional Commits style, not the work process.\n\nPush only the topic branch with upstream tracking. Use a file-backed body for multiline Markdown when opening through `gh`.\n\n## Issue Campaign Override\n\nBefore any issue-campaign push or pull request, complete `.agents/skills/issue-campaign/development.md`. A solo campaign uses one cycle pull request, the final pre-merge formatter gate, the ordinary check loop, and its integration-sensitive gate. Only `.agents/skills/multi-agent/issue-campaign.md` overrides that flow with worktree batches, exact-SHA campaign-run cancellation, local implementation gates, and Post-Campaign Cleanup.\n\n## Watch Checks After Every Ordinary Push\n\nAfter each ordinary push, including every Post-Campaign Cleanup push, monitor the pull-request checks until every check settles. Only CI-suspended campaign implementation waves skip this loop. On failure, fetch the relevant job log, diagnose the real cause, fix it in place, push a new commit, and resume monitoring. Do not treat a green unrelated job as acceptance for a failed required surface.\n\n## Merge On Explicit Request Or Standing Autonomous Mandate\n\nDo not merge, squash-merge, rebase, or update the target branch on unprompted initiative. Merge when the user explicitly asks, or when a standing autonomous mandate authorizes end-to-end delivery; use the repository's established merge method unless another is specified. Under an autonomous mandate the author that owns the pull request merges it themselves once the merge gate below passes, without separate approval.\n\nBefore merging an ordinary or Post-Campaign Cleanup pull request, confirm required checks pass. For a multi-agent campaign implementation pull request whose automatic CI is deliberately suspended, confirm its local-verification, independent-verification, and integration gates instead. If branch protection blocks the requested merge, report the blocker rather than bypassing it.\n","frontmatter":{"name":"pull-request","description":"Defines typia branch, commit, pull-request, check, and merge workflows. Use when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, update, or merge one on unprompted initiative."},"isInternal":false,"tokens":944,"sizeBytes":4814},{"name":"SKILL.md","path":".agents/skills/review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/review/SKILL.md","title":"review","category":"anthropic-skill","format":"markdown","content":"---\nname: review\ndescription: Defines exhaustive solo review, Self-Review, and solo repository-wide issue-discovery rounds for typia. Use for every self-review or unqualified review request and as the default review mode inside issue campaigns. This skill never spawns review agents; use the multi-agent skill only when the user explicitly requests a team, parallel, or multi-agent review.\n---\n\n# Review\n\n## Non-Negotiable Review Law\n\nRead the [contracts skill](../contracts/SKILL.md) when reviewing maintained production declarations or tests. Judge every acknowledgment against the actual declaration, native documentation, private helpers, and consequence surface. Evidence proves that an answer exists; review verifies every fact the chapter requests and revalidates existing answers affected by a change. A passing fixture or renamed wrapper does not prove that a disproven implementation assumption was corrected.\n\nOne reviewer performs every review in this skill from scratch over the entire declared surface. Do not spawn a subagent, delegate a concern, or load the discussion skill. Do not create a clone or worktree for solo review or Self-Review.\n\nChoose the principled conclusion. Review duration, difficulty, and consequence surface are reasons to inspect more deeply and verify more carefully, never reasons to overlook a sound improvement, accept an unsupported claim, or lower the completion standard.\n\nA complete round must satisfy all six rules:\n\n- **Whole surface:** read every changed file and hunk. For issue discovery, audit the entire campaign scope. Never partition by file, package, concern, platform, or pass, and never substitute another reviewer's coverage.\n- **Consequence surface:** inspect affected code paths, tests, generated artifacts, CI, packaging, documentation, and consumers. Trace side effects, state transitions, concurrency, platforms, boundaries, compatibility, and failure and recovery paths beyond the named symptom or diff.\n- **Fresh start:** use the current state and repeat the whole inspection. Earlier rounds, sampled files, and a recheck of only the latest fix do not count as coverage.\n- **Unlimited rounds:** whenever the reviewer applies an improvement or accepts a meaningful issue candidate, update the work and start another complete round. Stop only after a complete round produces nothing that survives verification.\n- **One immutable state:** a round runs against one recorded state, dependency lock, provisioned workspace contract, supported environment contract, and mandatory test matrix. Issue discovery and committed pull-request review use an exact commit. A solo review records its exact starting diff and refreshes that snapshot after every edit; a review round must not race a source change. The [multi-agent review procedure](../multi-agent/review.md) states how a team shares one snapshot.\n- **Auditable completeness:** the reviewer accounts for every tracked file and every mandatory public-operation, ownership, consumer, boundary, option, declaration-provenance, generated-artifact, packaging, and supported-platform matrix cell in the declared surface. Finding a candidate never ends or narrows the review. A skipped file, unprovisioned harness, unsupported claim, or unexecuted required cell makes the report `INCOMPLETE`, never `COMPLETE`.\n\n## Self-Review\n\nSelf-Review and an unqualified review request use this solo workflow:\n\n1. Establish the complete change surface, including the pull-request base-to-head diff and any uncommitted changes.\n2. Perform one complete round under the Non-Negotiable Review Law. Include correctness and boundaries, Windows and POSIX behavior, concurrency and state, data loss and security, cache and recovery invariants, public API and compatibility, test isolation, CI and packaging, generated output, documentation, and migration effects.\n3. Reproduce every suspected defect before accepting it.\n4. Apply every sound improvement and run the narrowest verification authorized by the owning workflow.\n5. If anything changed, restart at step 1 as a fresh full round.\n6. Finish only when a complete round finds nothing to improve. Report the final clean round and every verification that could not run.\n\nSelf-Review does not authorize creating, pushing, updating, or merging a pull request. If the user separately requests one of those actions, follow the pull-request skill.\n\n## Commit Early-Warning Pass\n\nA commit early-warning pass is not a review under this skill. It is the read-only per-commit reader a solo campaign author runs over every landed commit while still implementing, required and defined by the [solo campaign development document](../issue-campaign/development.md#implement-and-write-tests).\n\nIt delegates nothing the Non-Negotiable Review Law governs. The law governs the author's own round, which still runs alone over the whole surface before merge under all six rules. One commit is not a declared surface, a reported candidate is not an accepted finding, and the passes do not add up to a round.\n\nNever call the pass a Self-Review, and never report it as one. A reader who sees that name concludes the gate already ran, and the whole-surface round disappears without anyone deciding to drop it.\n\n## Solo Issue Discovery Rounds\n\nUse these rounds only through the solo issue-campaign skill.\n\n1. Freeze one exact commit and record the dependency lock, provisioning command, and supported environment contract before starting. Derive that environment contract from package engines, public documentation, repository CI, peer requirements, published package behavior, and explicit user decisions; do not narrow it ad hoc, and treat an unresolved conflict as a blocker on `CLEAN`.\n2. Inventory all tracked files, package and public API families, implementation owners, generated artifacts, test harnesses, workflows, documentation contracts, supported platforms, and open and closed issue or pull-request history before examining candidates. Reconcile that inventory with `git ls-files` and with the campaign's mandatory coverage matrix. A grep lens, a sampled file set, or a statement that the surface was reviewed is not coverage.\n3. Audit the entire inventory and execute the whole mandatory matrix. Audit source, tests, documentation, CI, packaging, generated artifacts, platform behavior, upstream and downstream provenance, and history against the development skill's **Forbidden** section. Continue through the full inventory after finding a candidate.\n4. Treat the matrix as a floor. Cover all applicable public operation families and direct, factory, and nested forms; equivalent TypeScript spellings, including aliases, interfaces, call and construct type literals, and classes; local, re-exported, module, package, user-global, default-library, ambient, and runtime-native provenance; union, intersection, generic, and transform-option interactions; static, dynamic, array, `any`, and `unknown` value contexts; positive, one-axis negative, boundary, malformed, maximum-width, one-past-boundary, and mutation controls; generated-byte and executed-runtime behavior; deterministic repeat emit; workspace, clean packed, and deployment consumers; and supported Node, module-resolution, operating-system, and CLI paths. Every interaction that reaches shared control flow is its own cell, and every positive cell has a one-axis negative twin. Run mutations only in a disposable checkout, keep the regression probe unchanged, and require the probe's canonical command to fail. When the round discovers a new owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells before the round can complete.\n5. Record every raw candidate, killed hypothesis, command, and artifact in the campaign knowledge base with the exact commit, environment, matrix hash, and census results. The round is `COMPLETE` only when the full inventory and current matrix finished; otherwise it is `INCOMPLETE` and cannot support a `CLEAN` campaign state.\n6. Reopen each candidate from primary evidence in a fresh state, reproduce it, verify ownership and provenance, trace its complete consequence surface, and compare existing issues and pull requests. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence, so a later round does not rediscover a rejected premise as new. Implementation mechanisms remain hypotheses.\n7. If any meaningful candidate survives, return to step 3 and run another complete round against the same frozen commit before publishing or implementing anything, and repeat until one round produces no surviving candidate. Discovery owns this loop; it never hands a partial candidate pool to publication or implementation because the first round already found work. A prior finding never permits narrowing the next round to its owner or neighbors.\n8. Publish only the surviving adjudicated form when the campaign is authorized to publish. After the authorized issue and implementation flow completes, freeze the new integrated commit and begin the next full-scope round.\n9. Stop only when one immutable-state round completes the entire repository inventory and mandatory matrix, no round is `INCOMPLETE`, and no meaningful candidate survives verification. Any verified in-repository correctness, contract, data-integrity, build, test-oracle, documentation, packaging, workflow, or **Forbidden** violation is meaningful regardless of severity, rarity, legacy status, or malformed-input trigger. Do not downgrade a proved defect to an observation to satisfy the stop rule. An unresolved, deferred, or unimplemented verified defect blocks `CLEAN`, and green existing suites cannot satisfy the stop rule.\n\n## Explicit Multi-Agent Reviews\n\nWhen the user explicitly asks for a team, parallel, or multi-agent review, load the [multi-agent skill](../multi-agent/SKILL.md) and its [review procedure](../multi-agent/review.md) instead of this workflow. It inherits the same whole-surface, immutable-state, and auditable-completeness law while defining independent parallel reviewers, agent briefing, and lead and critic adjudication.\n","frontmatter":{"name":"review","description":"Defines exhaustive solo review, Self-Review, and solo repository-wide issue-discovery rounds for typia. Use for every self-review or unqualified review request and as the default review mode inside issue campaigns. This skill never spawns review agents; use the multi-agent skill only when the user explicitly requests a team, parallel, or multi-agent review."},"isInternal":false,"tokens":1938,"sizeBytes":10143},{"name":"package.json","path":"packages/interface/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/package.json","title":"Interface Skill","category":"anthropic-skill","format":"json","content":"# Interface Skill\n\nPath: `packages/interface/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/package.json)","tokens":300,"sizeBytes":174},{"name":"tsconfig.json","path":"packages/interface/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/tsconfig.json","title":"Interface Skill","category":"anthropic-skill","format":"json","content":"# Interface Skill\n\nPath: `packages/interface/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/tsconfig.json)","tokens":300,"sizeBytes":176},{"name":"package.json","path":"packages/langchain/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/package.json","title":"Langchain Skill","category":"anthropic-skill","format":"json","content":"# Langchain Skill\n\nPath: `packages/langchain/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/package.json)","tokens":300,"sizeBytes":174},{"name":"tsconfig.json","path":"packages/langchain/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/tsconfig.json","title":"Langchain Skill","category":"anthropic-skill","format":"json","content":"# Langchain Skill\n\nPath: `packages/langchain/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/tsconfig.json)","tokens":300,"sizeBytes":176},{"name":"package.json","path":"packages/mcp/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/package.json","title":"Mcp Skill","category":"anthropic-skill","format":"json","content":"# Mcp Skill\n\nPath: `packages/mcp/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/package.json)","tokens":300,"sizeBytes":156},{"name":"tsconfig.json","path":"packages/mcp/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/tsconfig.json","title":"Mcp Skill","category":"anthropic-skill","format":"json","content":"# Mcp Skill\n\nPath: `packages/mcp/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/tsconfig.json)","tokens":300,"sizeBytes":158},{"name":"package.json","path":"packages/typia/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/package.json","title":"Typia Skill","category":"anthropic-skill","format":"json","content":"# Typia Skill\n\nPath: `packages/typia/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/package.json)","tokens":300,"sizeBytes":162},{"name":"protobuf_varint_corpus.json","path":"packages/typia/test/protobuf_varint_corpus.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/test/protobuf_varint_corpus.json","title":"Test Skill","category":"anthropic-skill","format":"json","content":"# Test Skill\n\nPath: `packages/typia/test/protobuf_varint_corpus.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/test/protobuf_varint_corpus.json)","tokens":300,"sizeBytes":201},{"name":"tsconfig.json","path":"packages/typia/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/tsconfig.json","title":"Typia Skill","category":"anthropic-skill","format":"json","content":"# Typia Skill\n\nPath: `packages/typia/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/tsconfig.json)","tokens":300,"sizeBytes":164},{"name":"typedoc.json","path":"packages/typia/typedoc.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/typedoc.json","title":"Typia Skill","category":"anthropic-skill","format":"json","content":"# Typia Skill\n\nPath: `packages/typia/typedoc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/typedoc.json)","tokens":300,"sizeBytes":162},{"name":"package.json","path":"packages/utils/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/package.json","title":"Utils Skill","category":"anthropic-skill","format":"json","content":"# Utils Skill\n\nPath: `packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/package.json)","tokens":300,"sizeBytes":162},{"name":"tsconfig.json","path":"packages/utils/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/tsconfig.json","title":"Utils Skill","category":"anthropic-skill","format":"json","content":"# Utils Skill\n\nPath: `packages/utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/tsconfig.json)","tokens":300,"sizeBytes":164},{"name":"package.json","path":"packages/vercel/package.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/package.json","title":"@typia/vercel","category":"anthropic-skill","format":"json","content":"{\n  \"name\": \"@typia/vercel\",\n  \"version\": \"15.1.0\",\n  \"description\": \"Vercel AI SDK integration for typia\",\n  \"main\": \"src/index.ts\",\n  \"exports\": {\n    \".\": \"./src/index.ts\",\n    \"./package.json\": \"./package.json\"\n  },\n  \"scripts\": {\n    \"build\": \"rimraf lib && ttsc && rolldown -c\",\n    \"dev\": \"ttsc --watch\",\n    \"evidence\": \"evidence\"\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"https://github.com/samchon/typia\"\n  },\n  \"author\": \"Jeongho Nam\",\n  \"license\": \"MIT\",\n  \"bugs\": {\n    \"url\": \"https://github.com/samchon/typia/issues\"\n  },\n  \"homepage\": \"https://typia.io\",\n  \"dependencies\": {\n    \"@typia/interface\": \"workspace:^\",\n    \"@typia/utils\": \"workspace:^\"\n  },\n  \"peerDependencies\": {\n    \"ai\": \">=6.0.0\"\n  },\n  \"devDependencies\": {\n    \"@types/json-schema\": \"^7.0.15\",\n    \"ai\": \"^6.0.116\",\n    \"rimraf\": \"catalog:utils\",\n    \"rolldown\": \"catalog:rolldown\",\n    \"tinyglobby\": \"^0.2.12\",\n    \"ttsc\": \"catalog:samchon\",\n    \"typescript\": \"catalog:typescript\"\n  },\n  \"sideEffects\": false,\n  \"files\": [\n    \"README.md\",\n    \"package.json\",\n    \"lib\",\n    \"src\"\n  ],\n  \"keywords\": [\n    \"vercel\",\n    \"ai-sdk\",\n    \"typia\",\n    \"llm\",\n    \"llm-function-calling\",\n    \"ai\",\n    \"tool-calling\",\n    \"openai\",\n    \"anthropic\",\n    \"claude\",\n    \"chatgpt\",\n    \"gemini\",\n    \"validation\",\n    \"json-schema\"\n  ],\n  \"packageManager\": \"pnpm@10.6.4\",\n  \"publishConfig\": {\n    \"access\": \"public\",\n    \"main\": \"lib/index.js\",\n    \"module\": \"lib/index.mjs\",\n    \"types\": \"lib/index.d.ts\",\n    \"exports\": {\n      \".\": {\n        \"types\": \"./lib/index.d.ts\",\n        \"import\": \"./lib/index.mjs\",\n        \"default\": \"./lib/index.js\"\n      },\n      \"./package.json\": \"./package.json\"\n    }\n  }\n}\n","frontmatter":{"name":"@typia/vercel","version":"15.1.0","description":"Vercel AI SDK integration for typia","main":"src/index.ts","exports":{".":"./src/index.ts","./package.json":"./package.json"},"scripts":{"build":"rimraf lib && ttsc && rolldown -c","dev":"ttsc --watch","evidence":"evidence"},"repository":{"type":"git","url":"https://github.com/samchon/typia"},"author":"Jeongho Nam","license":"MIT","bugs":{"url":"https://github.com/samchon/typia/issues"},"homepage":"https://typia.io","dependencies":{"@typia/interface":"workspace:^","@typia/utils":"workspace:^"},"peerDependencies":{"ai":">=6.0.0"},"devDependencies":{"@types/json-schema":"^7.0.15","ai":"^6.0.116","rimraf":"catalog:utils","rolldown":"catalog:rolldown","tinyglobby":"^0.2.12","ttsc":"catalog:samchon","typescript":"catalog:typescript"},"sideEffects":false,"files":["README.md","package.json","lib","src"],"keywords":["vercel","ai-sdk","typia","llm","llm-function-calling","ai","tool-calling","openai","anthropic","claude","chatgpt","gemini","validation","json-schema"],"packageManager":"pnpm@10.6.4","publishConfig":{"access":"public","main":"lib/index.js","module":"lib/index.mjs","types":"lib/index.d.ts","exports":{".":{"types":"./lib/index.d.ts","import":"./lib/index.mjs","default":"./lib/index.js"},"./package.json":"./package.json"}}},"isInternal":false,"tokens":558,"sizeBytes":1696},{"name":"tsconfig.json","path":"packages/vercel/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/tsconfig.json","title":"Vercel Skill","category":"anthropic-skill","format":"json","content":"# Vercel Skill\n\nPath: `packages/vercel/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/tsconfig.json)","tokens":300,"sizeBytes":167},{"name":"README.md","path":"packages/interface/README.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/README.md","title":"interface Documentation","category":"plugin-manifest","format":"markdown","content":"# interface Documentation\n\nPath: `packages/interface/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/README.md)","tokens":300,"sizeBytes":176},{"name":"README.md","path":"packages/langchain/README.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/README.md","title":"langchain Documentation","category":"plugin-manifest","format":"markdown","content":"# langchain Documentation\n\nPath: `packages/langchain/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/README.md)","tokens":300,"sizeBytes":176},{"name":"README.md","path":"packages/mcp/README.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/README.md","title":"mcp Documentation","category":"plugin-manifest","format":"markdown","content":"# mcp Documentation\n\nPath: `packages/mcp/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/README.md)","tokens":300,"sizeBytes":158},{"name":"README.md","path":"packages/utils/README.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/README.md","title":"utils Documentation","category":"plugin-manifest","format":"markdown","content":"# utils Documentation\n\nPath: `packages/utils/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/README.md)","tokens":300,"sizeBytes":164},{"name":"README.md","path":"packages/vercel/README.md","rawUrl":"https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/README.md","title":"vercel Documentation","category":"plugin-manifest","format":"markdown","content":"# vercel Documentation\n\nPath: `packages/vercel/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/README.md)","tokens":300,"sizeBytes":167}],"systemPromptSnippet":"<yakaai_skills repo=\"samchon/typia\">\n<!-- File: AGENTS.md (Tokens: ~1557 | Category: root-instruction) -->\n# AGENTS.md\n\n`typia` is a TypeScript transformer and runtime library that turns pure TypeScript types into inline validators, serializers, schemas, decoders, and random-data generators. It ships the `typia`, `@typia/interface`, `@typia/utils`, `@typia/langchain`, `@typia/mcp`, `@typia/vercel`, and `@typia/jev` packages.\n\n## Attitude\n\nFollow the literal request; it is the contract, not a hint at what the user \"really\" wants.\n\n- **Scope is the user's to widen.** Reinterpret the goal, weigh alternatives, or expand the task only on an explicit hand-off (\"figure it out\", \"you decide\"). Take a confident, specific ask as given.\n- **Fidelity binds the goal, not the effort.** Within that goal, act with full initiative: do the substeps it needs, verify your work, surface what you notice. Literal scope is no excuse for passive execution.\n- **Match the user's language.** Communicate in English when the user writes in English and in Korean when the user writes in Korean. Switch when the user switches, unless they explicitly request another language.\n- **Choose the principled course.** Decide from evidence, correctness, product boundaries, and the durable consequence. Time, difficulty, and consequence surface are reasons to investigate and validate more carefully, never reasons to settle for a shortcut, workaround, or weaker standard.\n- **Evidence precedes correction.** Treat issue reports, review proposals, and claims that something is wrong or missing as hypotheses. Verify the real code path, tests, generated artifacts, upstream ownership, and history before accepting the premise or changing behavior.\n- **Trace the consequence surface.** A named file or failing case is the starting point, not the investigation boundary. Follow the same cause through downstream consumers, side effects, state transitions, platforms, and boundary cases, then address the whole verified class of failure within the requested goal.\n- **Collect every symptom before correcting.** Finish the test run, CI run, reproduction, or review round that produced a finding before repairing it. Group all findings by cause, trace their consequences, and correct the complete verified set together.\n- **Default over ask.** On an ambiguous detail, pick the sensible default and say what you chose; reserve questions for forks only the user can settle.\n\n## Skills\n\nDurable project conventions and workflows live under `.agents/skills/`. Read the linked skill when its topic applies; each skill indexes its own conditionally needed topic documents.\n\n### Project Outline\n\nWhat typia is, the package family, the JS-descriptor / Go-plugin boundary, the workspace layout, product boundaries, and canonical commands, `.agents/skills/project/SKILL.md`.\n\n### Development\n\nWork rules, testing, validation, consequence analysis, and change integrity, `.agents/skills/development/SKILL.md`. Read before writing or modifying code.\n\n### Implementation Contracts\n\nSelf-acknowledgments for maintained production declarations, unit tests, and E2E tests, `.agents/skills/contracts/SKILL.md`. Read when implementing or reviewing those declarations or selecting Evidence checklists.\n\n### Documentation\n\nREADME, website guide, and agent-instruction authoring rules, `.agents/skills/documentation/SKILL.md`. Read before writing or modifying documentation.\n\n### Issue Campaigns\n\nDefault solo repository-wide issue discovery, issue publication, one CI-validated implementation pull request per cycle, and renewed discovery, `.agents/skills/issue-campaign/SKILL.md`. Read when the user asks for a broad audit, many issue candidates, or an issue-to-implementation campaign without explicitly requesting parallel agents; do not use it for one already-defined issue.\n\n### Review\n\nDefault solo Self-Review, unqualified review, and exhaustive issue-discovery rounds, `.agents/skills/review/SKILL.md`. The reviewer inspects the whole declared surface and repeats fresh rounds until a complete pass produces no sound improvement or meaningful issue candidate.\n\n### Multi-Agent Workflows\n\nExplicitly parallel review and issue-campaign variants live under one entry point, `.agents/skills/multi-agent/SKILL.md`. Read it only when the user explicitly asks for a team, parallel, or multi-agent workflow. Multi-agent issue campaigns parallelize discovery and implementation by default and switch to solo implementation only on an explicit discovery-only parallel request; Self-Review remains solo.\n\n### Discussion\n\nStructured multi-agent topic discussion with persistent research notes and transcripts, `.agents/skills/discussion/SKILL.md`. Read only when the user explicitly asks for a discussion; review and issue discovery do not imply discussion.\n\n### Pull Request Submission\n\nBranch, commit, pull request, check, and merge flow, `.agents/skills/pull-request/SKILL.md`. Read when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, or propose one on unprompted initiative.\n\n### Benchmark\n\nBenchmark runners, fixture integrity, measurement integrity, result archives, and publication, `.agents/skills/benchmark/SKILL.md`. Read before running, modifying, or publishing benchmark results.\n\n## Maintenance\n\n### Writing style\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans as well as agents. Read the documentation skill before editing either; it defines concise, clear agent-instruction writing and the prose-line rule.\n\n### AGENTS.md\n\nThis is the single shared entry point for both Claude Code (via `CLAUDE.md -> @AGENTS.md`) and Codex CLI. Keep it to the brief product identity, global attitude, and skill index. The H2s are `## Attitude`, `## Skills`, and `## Maintenance`; `## Attitude` is the one place global agent-behavior rules live.\n\nUpdate AGENTS.md only for repository-contract changes: a new skill area, a renamed or merged skill, a workflow that no longer fits an existing skill, a release-process change, or a coding-agent rule that applies globally before any skill loads.\n\n### Skills\n\n- **Location.** `.agents/skills/<kebab-name>/SKILL.md`. No numeric prefix. Each file opens with YAML frontmatter whose `name` matches the directory and whose third-person `description` states what the skill covers and when to use it.\n- **Core in SKILL.md, conditional topics as sibling documents.** Keep always-applicable procedure in SKILL.md. Move a topic needed only under a specific condition to a one-level-deep sibling document and link it with that read condition.\n- **Two trigger surfaces, one scope.** The frontmatter description is the full trigger contract, including exclusions. The AGENTS.md pointer mirrors that scope more briefly. Correct the frontmatter first when the scope changes.\n- **Create or merge.** Add a skill when a substantial repository concern would otherwise inflate AGENTS.md beyond an index. Merge sibling concerns when they share most of their structure.\n- **Repository skill files only.** Keep repository skills to `SKILL.md` and conditionally loaded sibling documents. Do not add separate `multi-agent-*` skills; the parallel variants live under the one `multi-agent` skill.\n- **Headings are plain.** No chapter numbers in skill or AGENTS.md headings. Use descriptive titles.\n- **Current set.** The repository skills are `project`, `contracts`, `development`, `documentation`, `issue-campaign`, `review`, `multi-agent`, `discussion`, `pull-request`, and `benchmark`.\n\n<!-- File: .agents/skills/benchmark/performance.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Benchmark Skill\n\nPath: `.agents/skills/benchmark/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/benchmark/performance.md)\n\n<!-- File: .agents/skills/benchmark/SKILL.md (Tokens: ~911 | Category: anthropic-skill) -->\n---\nname: benchmark\ndescription: Defines typia benchmark fixture integrity, result reporting, and publication safeguards. Use before running or modifying @typia/benchmark, changing a fixture, or publishing benchmark results.\n---\n\n# Benchmark\n\nThis repository owns one benchmark system. Read its procedure in full before acting:\n\n- [performance.md](performance.md): `@typia/benchmark` throughput against competing runtime libraries, including generated programs, structure fixtures, and the per-CPU result archive.\n\n## Measurement Integrity\n\n- Measure the real product. Do not add benchmark-only branches, fixture-name checks, expected-answer checks, monkey patches, or agent restrictions that would be wrong for an unmeasured repository.\n- Give every comparator the setup its own documentation prescribes. Measuring a deliberately underconfigured competitor invalidates the comparison.\n- Preserve the workload defined by the selected procedure. A faster result obtained by validating, serializing, serving, or reading less input is not an optimization.\n- Treat a surprising result as evidence that the change is not yet understood. Inspect the raw report or trace before accepting, explaining away, or patching around it.\n\n## Fixture Changes\n\n`benchmark/src/programs/` mixes generated leaf programs with hand-maintained helpers. Edit generated `benchmark-*.ts` files through their source under `benchmark/src/template/`; edit shared `create*.ts` helpers and `benchmark/src/structures/` in place.\n\nFinish every fixture change before publishing it:\n\n1. Run the relevant template entrypoint, then the benchmark package's build commands until they finish green. `pnpm template` regenerates only the templates imported by `benchmark/src/template/index.ts`. Defer repository formatting to the development skill's final pre-merge cleanup gate.\n2. Confirm every comparator receives the same structure and input for the measured row.\n3. Review the generated-program diff. A stale or inconsistent generated program contaminates every later run.\n\nBenchmark READMEs and prose follow AGENTS.md `## Maintenance` and the documentation skill.\n\n## Report Results\n\nEvery result table reported in chat or committed to the result archive must be preserved for the active pull request. When the user has authorized PR updates under the pull-request skill, maintain one sticky comment beginning with `<!-- typia-benchmark-results -->`; update it with the latest table, report paths, and known invalid or missing categories.\n\nIf no pull request exists or no update is authorized, keep the result in the final report and mark the comment as pending. Post it only after the user creates or authorizes updating the pull request.\n\n## Campaign Batching\n\nWhen benchmark findings produce multiple implementation issues, load the issue-campaign skill and use its planning and claim procedure unchanged for the dependency DAG, claim freeze, and official GitHub `createdAt`-to-`mergedAt` duration: [Plan One Cycle Pull Request](../issue-campaign/development.md#plan-one-cycle-pull-request) for a solo campaign, or [Plan And Claim A Pull Request Wave](../multi-agent/issue-campaign.md#plan-and-claim-a-pull-request-wave) with its batch admission test, merge pressure, and grouping and split ledger when the user explicitly requested a parallel campaign. This benchmark skill continues to own workload, fixture, measurement, result, and publication integrity; do not redefine pull-request batching here.\n\n## Campaign Cleanup\n\nWhen a benchmark campaign uses a disposable worktree or an isolated measurement root, finish cleanup before marking that assignment complete. Preserve the committed result archive and compact command evidence, but remove every disposable worktree and its assigned mutable roots: `GOCACHE`, `GOTMPDIR`, `TTSC_CACHE_DIR`, generated-program scratch tree, dependency install tree, and temporary consumer or report staging tree. Go temporary assets are never reusable campaign evidence.\n\n1. Record the measured commit, command, result paths and hashes, environment, and any retained published result archive.\n2. Confirm the worktree and mutable roots contain no unreported source or result artifact.\n3. Remove the mutable roots and, for an assigned disposable worktree, run `git worktree remove --force <path>` for its exact path.\n4. Verify every removed root and, when applicable, worktree path no longer exists, run `git worktree prune`, delete the associated disposable local topic branch when one was created, and confirm no worktree registration remains.\n\nIf a measurement is abandoned or invalid, retain only the diagnostic record needed to explain it; remove its worktree and Go temporary assets by the same procedure.\n\n<!-- File: .agents/skills/development/SKILL.md (Tokens: ~4026 | Category: anthropic-skill) -->\n---\nname: development\ndescription: Defines typia implementation rules, testing standards, validation, consequence analysis, and change integrity. Use before writing or modifying source, tests, workflows, package wiring, fixtures, generated baselines, or algorithms.\n---\n\n# Development\n\n## Contents\n\n- [Forbidden](#forbidden)\n- [Work Rules](#work-rules)\n- [Consequence Analysis](#consequence-analysis)\n- [Plugin Configuration](#plugin-configuration)\n- [Testing](#testing)\n- [Validation](#validation)\n- [Change Integrity](#change-integrity)\n- [Evidence Adoption](#evidence-adoption)\n\n## Forbidden\n\nRead the [contracts skill](../contracts/SKILL.md) before changing maintained production declarations. Its common checklist owns implementation acknowledgments; scoped checklists apply by responsibility. When a failure disproves an assumption, correct its owner and remove superseded compensations in the same repair.\n\nThese four are never acceptable; choosing any one means the approach is already wrong.\n\n- **No monkey-patching or hardcoding.** Don't special-case a consumer, a fixture name, or an expected value to make output match. Fix the general logic.\n- **No test-passing-only logic.** Code exists to be correct, not to turn a check green. A branch whose only purpose is to satisfy one assertion is a bug in disguise.\n- **No forcing a broken design.** When the same failure keeps returning under patch after patch, the design is wrong. Stop, find the root cause, and fix the design instead of looping forever on symptoms.\n- **No whack-a-mole.** Don't patch the one case that surfaced and move on. Think expansively about every case the same root cause can produce, and seal them all with coverage so the class of failure cannot recur.\n\n## Work Rules\n\n- Choose the principled course. Time, difficulty, and the breadth of consequences require more careful analysis and validation; they never justify a shortcut, leaving a verified consequence unaddressed, or a weaker acceptance standard.\n- Match existing conventions. Before adding a file, function, or test, open a nearby peer and mirror its naming, location, and code style; don't create parallel structures.\n- Respect package boundaries. The shared native transform lives under `packages/typia/native`; don't fork a second transform into an adapter package or reintroduce a TypeScript-side transformer.\n- Keep package detection installation-safe. Resolve the target package root, as `packages/typia/src/transform.ts` does with `require.resolve(\"typia/package.json\")`; workspace path substrings and hard-coded fixture names fail for npm consumers.\n- Use the workspace catalogs. `pnpm-workspace.yaml` owns `samchon`, `typescript`, `rolldown`, and `utils`; the ttsc family, Evidence, tstl and tgrid use `catalog:samchon`, and internal package references use `workspace:^`.\n- Keep local outputs local. Do not commit `.env` files or the `.tgz` artifacts generated under `experiments/tarballs/`.\n- Preserve the public contract in `.agents/skills/project/SKILL.md`. Renaming or removing `typia.*`, `@typia/interface` types, or the plugin descriptor shape is a deliberate product change, not incidental cleanup.\n- When public behavior changes, update the matching page under `website/src/content/docs/**` in the same change. Follow `.agents/skills/documentation/SKILL.md`.\n- Run `pnpm format` only in the final pre-merge cleanup after implementation and CI repairs are complete, not before each commit or push. Commit its integrated result and require green CI on that final head before merging. If later edits require formatting, return to this final cleanup gate. Parallel issue-campaign implementation batches defer the repository-wide formatter to their dedicated Post-Campaign Cleanup pull request.\n\n## Consequence Analysis\n\nTreat a reported example as one witness of a cause, not the complete problem statement. Before changing code, trace the same cause through:\n\n- every caller and downstream consumer;\n- normal, error, and recovery state transitions;\n- concurrency, caching, and generated output;\n- Windows and POSIX behavior;\n- compatibility constraints and boundary inputs.\n\nFix the verified class of failure, not only the reported witness. Cover positive, negative, and boundary cases without expanding the user's product goal.\n\n## Plugin Configuration\n\n`ttsc` discovers typia by default from the `ttsc.plugin.transform` entry in `packages/typia/package.json`. Consumer projects add a `compilerOptions.plugins` entry with `transform: \"typia/lib/transform\"` only when they need to set optional transform flags.\n\n`packages/typia/src/transform.ts` is a JavaScript descriptor source, not a transformer. It resolves the installed typia package and returns the Go command at `packages/typia/native/cmd/ttsc-typia`; `ttsc` builds that source into the workspace cache. Keep type analysis, AST rewriting, diagnostics, and typia-owned options (`functional`, `numeric`, `finite`, and `undefined`) on the Go side.\n\nTest workspaces normally use `typia/lib/transform`. Source-only workspaces such as the benchmark may point at `typia/src/transform.ts`, but that still loads the same descriptor and native command. Do not add a second plugin host to make a local layout pass.\n\n## Testing\n\nRead the [testing contracts](../contracts/testing.md) for every test and the [E2E contracts](../contracts/e2e.md) when it exercises a necessary real component boundary. Classify by actual execution, not language, directory name, filesystem use, or duration. Maintained helpers answer production contracts when they own implementation decisions.\n\n**One test case per file, named after what it asserts.** This is the rule for new and changed cases in both languages, even where older files predate it.\n\n### Go tests\n\n- **Public and contract tests:** keep black-box and exported-API coverage under `packages/typia/test/**`, mirroring the native concern where practical. These tests import the native module through `packages/typia/test/go.mod` and run with `pnpm test:go:public`.\n- **Colocated native tests:** keep same-package implementation, command, transform, and emitter coverage beside the Go source as `packages/typia/native/**/*_test.go`. Untagged cases run with `pnpm test:go:native`.\n- **Native-internal tagged tests:** use `//go:build typia_native_internal` only when the case requires internal-only coverage. Root `pnpm test:go` does not enable that tag; run `go -C packages/typia/test test -tags typia_native_internal ../native/...` when tagged coverage is relevant.\n\nUse one `Test*` function per test file and mirror a nearby test's package, fixture, and cleanup pattern. Command-level transform regressions belong near `packages/typia/native/cmd/ttsc-typia`; public contract probes belong under `packages/typia/test`.\n\n### TypeScript suites\n\n`pnpm test:packages` starts every `tests/test-*` workspace. They have these shapes:\n\n- **Function-per-file:** `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, and `test-utils` discover `src/features/**/test_*.ts` through `DynamicExecutor`. Export exactly one `test_<snake_case>` function from a matching filename. `DynamicExecutor` selects and reports a test by its exported name, so a name that disagrees with its file makes the test unreachable by that file's name. `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` additionally run portable unit cases from `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` without the native plugin (`pnpm --filter ./tests/<workspace> test:unit`); they follow the same one-function-per-file naming rule.\n- **Generated matrices:** `test-typia-automated` and `test-utils-automated` delete and regenerate `src/features/**` when they run. Do not hand-edit those trees. Change the controller/template metadata or `@typia/template`; keep the committed ObjectSimple composite layer in `test-typia-automated/src/composite/**` hand-maintained.\n- **Transform rejection:** `test-error` compiles invalid call sites and asserts the diagnostics that reject them. A failed build publishes no output, so the suite reads no emitted JavaScript: it requires the build to fail, every fixture to typecheck, and every fixture to be named by a typia diagnostic. Add cases beside their feature group, and keep each fixture valid TypeScript that only typia rejects — a type error aborts the build before the transform runs and would leave the suite with nothing to observe.\n- **Type compilation:** `test-interface` is a compile-only TypeScript `tsc --noEmit` suite for `@typia/interface` type contracts and public typia signatures; type-only factory checks execute no factory.\n\nUse `TestValidator` and `DynamicExecutor` from `@nestia/e2e`, `@typia/template` structures and `TestServant`, and each suite's local `internal/` helpers. Do not reach into another suite's internals or duplicate a reusable structure inside one test workspace.\n\nAssert structural equality with `TestEquality` from `@typia/template/equality`. Its `equals` is symmetric and compares `Date`, `Map`, and `Set` by content; use `subset` only when an assertion pins some fields of a larger result on purpose, with the expected value first. Never call `TestValidator.equals`: it walks only its first argument's keys and sees no content in dates, maps, or sets, so it passes whatever the actual lost (#2401). Never call `TestValidator.error` either: on a synchronous task it swallows its own failure and passes whether or not the task throws (#2460). Assert a synchronous throw by comparing `TestEquality.thrown(task)` with the expected message, and an asynchronous one by awaiting `task().then(() => undefined, (error: unknown) => error)` and comparing what it rejects with. Compare prototypes and other identities with `===`.\n\nOpen every new or materially changed case with a doc comment in the same three-part shape: a one-line `Verifies ...` headline, a short paragraph stating the non-obvious _why_ (which branch or regression is being pinned), and a 2+-step numbered list summarizing the scenario.\n\n```ts\n/**\n * Verifies typia.llm.schema emits `anyOf` for a discriminated union.\n *\n * Locks the union branch of the LLM schema converter. A regression in branch\n * selection would silently emit one variant and lose the other from the\n * function-calling schema.\n *\n * 1. Declare two object variants with a shared discriminator.\n * 2. Generate the LLM schema for their union.\n * 3. Assert both variants remain in the emitted `anyOf`.\n */\nexport const test_llm_schema_anyof = (): void => {\n  /* ... */\n};\n```\n\n### Coverage, not happy paths\n\nA test that only feeds a transform its ordinary successful input and asserts that the result is accepted proves one path, not correctness. The native transformer spans validators, serializers, schemas, decoders, diagnostics, and generated helpers; each predicate or branch needs more than its happy path:\n\n- **The transformation direction.** When a call should be rewritten, assert observable emitted or runtime behavior that differs from the untransformed stub. For generators, start from hand-written input and verify the generated output, not only that an existing output compiles.\n- **A negative twin for every positive.** Wherever a predicate accepts, rewrites, narrows, serializes, or reports a diagnostic, pin an adjacent case one property away where it must not do so. An over-match stays invisible until the counter-example exists.\n- **Boundaries.** Cover the empty case, the single-element case, recursion limits, optional and nullable members, exact numeric limits, deepest nesting, and the tag or compiler option that flips the decision.\n- **Oracle-derived expectations.** Take expected behavior from TypeScript semantics and the authoritative JSON Schema, OpenAPI, Protocol Buffer, or adapter contract, never from whatever the current code happens to emit. A snapshot written against the implementation's own output locks its bugs in.\n\nThis is not a validator-only rule. The same happy-path bias hides serializer corruption, schema loss, compiler-process failures, and native diagnostic regressions, so every feature carries the burden.\n\n## Validation\n\nRun the narrowest command that proves the change first, then a broader command when shared behavior, the transform, packaging, or documentation changed. Report any command that could not be run.\n\n- **One public Go concern:** `pnpm test:go:public`.\n- **One native Go concern:** `pnpm test:go:native`; add the tagged command from [Go tests](#go-tests) when the changed path has `typia_native_internal` coverage.\n- **One TypeScript workspace:** `pnpm --filter ./tests/<name> start`.\n- **One package:** `pnpm --filter ./packages/<name> build`.\n- **Transform, descriptor, or shared package:** `pnpm test`; use `pnpm build` as the broader package compilation gate.\n- **Packaging:** run root `pnpm package:tgz`, then inspect or smoke-test a clean install. It builds every package and verifies the published entry points before packing (`pnpm pack` alone no longer builds; the manifests carry no `prepack`). Tarballs are generated under `experiments/tarballs/`; do not commit or hand-edit them.\n- **Website or guide changes:** reproduce the fresh CI prerequisites: place a ttsc checkout at `../ttsc`, run root `pnpm install` and `pnpm package:tgz`, then run `pnpm build` inside `website/`. The compiler-dependencies package installs the staged tarballs, and the playground Wasm build resolves the sibling ttsc Go modules.\n\nVerification shape depends on the change type:\n\n- **Bug fix:** name the failing case and the expected behavior; run a repro that fails before the fix and passes after.\n- **Feature:** name the observable behavior; exercise it end-to-end.\n- **Refactor:** name what should stay unchanged; rely on the existing test suite or a behavior-locking probe.\n- **Review:** name concrete risks, missing tests, or regressions.\n\n## Change Integrity\n\nTreat tests, fixtures, snapshots, CI workflows, package wiring, dependencies, core algorithms, generated baselines, and benchmark results as part of the specification. Changing them requires an explicit user request or a clear product reason, and the final report must call it out.\n\nGo source under `packages/typia/native` must ship under a `typia` version newer than the latest published package because npm consumers otherwise continue to install the previous native source tree. Assign that version once in a maintainer-owned release change; multiple unreleased native changes belong to the same future release instead of consuming one patch number each. Issue implementation pull requests never change package versions. A maintainer-owned release change may begin only after campaign completion, or after the user explicitly suspends the campaign and lifts the freeze, and it uses the version the user assigned.\n\nFor mechanical ports, migrations, or broad rewrites, preserve the existing algorithm and public behavior in reviewable slices. Prefer a concrete exemplar over abstract instructions, and inspect the diff before trusting a green test run.\n\n## Evidence Adoption\n\nEach production package's `evidence.config.json` selects the files that directly declare and export its maintained TypeScript and Go types and functions and references `contracts/common.md` under `../../.agents/skills`. Pure re-export barrels own no selected declaration; review their public wiring through package and consumer checks while selecting each symbol at its direct declaration. If declarations and foreign re-exports share a file, separate the declaration owner without dropping public aliases or changing behavior, and update the transformer's declaration identity when necessary. Properties retain native documentation and are reviewed through their type. Add portability and performance chapters only to the operations that own those decisions.\n\nEvery enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`. Selected tests answer `contracts/testing.md`; actual E2E boundaries also answer `contracts/e2e.md`. Unit populations, types, runners and support declarations are outside this Evidence selection while their ordinary test execution remains intact. The template and both automated workspaces have no Evidence configuration or script.\n\nRun root `pnpm evidence` to collect every enrolled owner without stopping at its first failure. Use `pnpm --filter <package> evidence` for one production owner and `pnpm evidence:tests` for tests. JSON configuration keeps the checker independent of compiling typia or evaluating a TypeScript configuration. The existing build workflow owns the CI gate; acknowledgments do not replace behavioral tests.\n\nFor an Evidence truth audit, complete the first source inspection and improvements across the entire selected population and its private helpers before any local build, test, checker run, or executable probe. Use source and history inspection during that pass. Formatting remains the final pre-merge cleanup gate. After the first pass, collect each necessary integrated validation once; repeat only for a new change, failure, or unresolved concern. A coordinator assigns disjoint owners, collects returned findings, resolves shared causes, and prevents duplicate inventories, builds, and validation by individual reviewers.\n\n1. Finish the complete report before repairing obligations. Group missing answers, code and documentation defects, selection mistakes, generated-source provenance, and incomplete analysis by cause.\n2. Inspect each selected declaration and its private helpers against every applicable chapter. Fix verified defects before writing the answer; the acknowledgment describes the resulting implementation.\n3. Write `@evidence contracts/<document>.md#<anchor> <reason>` in native documentation, separated from descriptive prose by a blank comment line. Address the actual question for that declaration. Use `@evidenceExclude` only for a genuinely inapplicable individual chapter with its concrete reason.\n4. Account for private helpers, anonymous callbacks, dynamically registered cases, script entry bodies, and compile-only cases from their source and runners. Make executable entries selectable within the configured population where practical; record remaining review-only coverage honestly. Preserve compiler visibility tags such as `@internal`; removing them can change emitted declarations. Explain unaddressable helpers in their actual calling operation's acknowledgment and record their review-only scope. After the complete first pass, use `pnpm exec evidence list --config <config>` or `pnpm exec evidence inspect '<target>' --config <config>` only for unresolved address or resolution questions.\n5. Check the complete population after the first pass and its improvements finish. Verify composed claims together, including local re-export resolution. Keep the issue open and PR draft while obligations or incomplete analysis remain, and record progress as formal PR reviews.\n\nDo not weaken severity, narrow a maintained population, add generic compliance prose, or exclude a whole document to silence obligations. Exclude generated output, copied fixture input, dependencies and build output only with verified provenance. Authored generators and helpers remain maintained source; their maintenance does not enroll them in Evidence. Generated cases in the two automated workspaces remain executed through their ordinary runners and are outside Evidence. Verify selected feature functions against their actual runners without expanding the configured population to every executed declaration.\n\n<!-- File: .agents/skills/discussion/SKILL.md (Tokens: ~321 | Category: anthropic-skill) -->\n---\nname: discussion\ndescription: Runs structured multi-agent discussions for open-ended typia topics. Use only when the user explicitly asks for Discussion or a team debate with transcripts and conclusions; do not use for Self-Review, a solo or multi-agent review, research review, or issue discovery.\n---\n\n# Discussion\n\nDiscussion explores a topic without changing code or turning the exchange into a review queue. Reviews and issue discovery use the review skill instead.\n\n## Team\n\nForm the largest practical team, up to nine agents so the lead and participants fit the ten-agent session limit. Give every agent a self-contained brief with the topic, constraints, known evidence, output expectations, and the exact repository instructions and skills to read. Do not give a preferred conclusion or divide the topic into assigned slices.\n\n## Knowledge Base\n\nCreate `.discussions/<topic>/` with a short filesystem-safe name. Do not delete or overwrite an existing discussion directory unless the user explicitly requests it.\n\nEach agent maintains a personal wiki-style subdirectory under the topic directory. Agents read the live transcript and one another's statements between turns, continue researching, and revise their own notes.\n\n## Transcript\n\nRun three unrestricted transcript rounds as `round1.md`, `round2.md`, and `round3.md`. The lead moderates and records every statement in speaking order as a live transcript, not a retrospective summary. Do not narrow the topic unless the user does.\n\nAfter `round3.md`, the lead writes agreed conclusions, disagreements, and major open points to `summary.md`, reports the result, and waits. Discussion does not itself authorize implementation.\n\n<!-- File: .agents/skills/documentation/SKILL.md (Tokens: ~978 | Category: anthropic-skill) -->\n---\nname: documentation\ndescription: Defines README, website-guide, and agent-instruction structure, audience, prose formatting, and voice for typia. Use before writing, modifying, renaming, or moving repository documentation.\n---\n\n# Documentation\n\n## READMEs\n\nREADME files are for the final reader of that package or directory. Start with what it is, when to use it, installation, the smallest working setup, and the common path.\n\nKeep README language direct and practical. Avoid compiler theory, protocol details, internal architecture, and edge cases unless the reader must know them to use the package. Move deep explanations into the website guides and link them only as the next step.\n\n## Guide Documents\n\nUser-facing guides live under `website/src/content/docs/**` as MDX and publish at https://typia.io/docs. The site uses Next.js and Nextra, exports a static site, and deploys to GitHub Pages. Keep one audience and one task per page.\n\nThe current tree is organized by feature area:\n\n- top-level pages `index.mdx`, `setup.mdx`, `pure.mdx`, `random.mdx`, and `misc.mdx` cover introduction, setup, and cross-cutting features;\n- `validators/`, `json/`, `protobuf/`, and `llm/` own their operation guides; and\n- `utilization/` owns framework integrations for MCP, Vercel AI SDK, LangChain, NestJS, tRPC, and Hono.\n\nThe root and each guide folder use `_meta.ts` for sidebar order and labels. Nextra reads keys in declaration order; `{ display: \"hidden\" }` keeps a page reachable while removing it from the sidebar. Update the matching `_meta.ts` whenever a guide is added, renamed, moved, hidden, or exposed.\n\nWhen emitted code is the point, pair the TypeScript source with its compiled JavaScript in side-by-side tabs so the reader can see what the transform replaces. Back performance claims with a specific benchmark result instead of an adjective. Follow the fresh website-build prerequisites in `.agents/skills/development/SKILL.md`.\n\n## Agent Instructions\n\n`AGENTS.md` and `SKILL.md` files are operational documents for humans and agents. Keep only the product-wide contract in `AGENTS.md`, the always-applicable procedure in `SKILL.md`, and conditional detail in a linked sibling document.\n\nConcise and clear means:\n\n- Include the context needed to act correctly. Do not make the reader infer prerequisites, exceptions, reasons, or stop conditions merely to shorten the document.\n- State each rule at its owning document and link to it elsewhere. Remove repeated wording, not necessary substance.\n- Give each paragraph one job. Separate purpose, rule, rationale, procedure, and consequence when combining them obscures the action.\n- Use structure to compress meaning: ordered lists for procedures, bullets for choices and checks, tables for repeated mappings, and code blocks for exact commands.\n- State the rule before its reason. Use a negative rule only when it prevents a named failure the affirmative rule does not already exclude.\n- Link to website guides, READMEs, or source comments instead of paraphrasing them.\n\n## Prose line breaks\n\nWrite each Markdown or MDX paragraph on one source line. Never hard-wrap a single paragraph at a fixed column: Markdown already soft-wraps it, while manual wrapping makes small edits reflow unrelated lines.\n\nOne source line does not mean one long paragraph. Insert a blank line whenever the idea changes. Keep structural line breaks for paragraphs, list items, headings, tables, and fenced code.\n\nThis is a manual convention, not a formatter gate. Root `pnpm format` runs Prettier over `**/*.ts` and formats changed Go files; it does not format `*.md` or `*.mdx`, and the repository does not set `proseWrap`. Preserve one-line paragraphs yourself.\n\n## Voice\n\nWrite in the plain, direct, technical voice of the human-authored typia docs. Do not write like an AI assistant.\n\n- No AI-cliche phrasing: \"not only X but also Y\", \"whether you're X or Y\", \"it's worth noting\", \"let's dive in\", and reflexive hedging.\n- No marketing adjectives such as \"seamless\", \"powerful\", \"robust\", or \"effortless\". State the behavior; where speed is the point, cite the benchmark.\n- No wrap-up sentence that just restates the paragraph. State the fact and stop.\n- Em-dashes already fit the existing typia prose; do not remove them mechanically or impose a punctuation ban.\n- Sidebar emoji in `_meta.ts` are part of the existing navigation voice. Keep them where they already fit; this exception does not turn guide prose into decorative copy.\n\n<!-- File: .agents/skills/issue-campaign/development.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Issue-campaign Skill\n\nPath: `.agents/skills/issue-campaign/development.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/issue-campaign/development.md)\n\n<!-- File: .agents/skills/issue-campaign/SKILL.md (Tokens: ~2355 | Category: anthropic-skill) -->\n---\nname: issue-campaign\ndescription: \"Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request.\"\n---\n\n# Issue Campaign\n\nAn issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that [development.md](development.md#implement-and-write-tests) requires for every landed commit.\n\nUse the [multi-agent skill](../multi-agent/SKILL.md) and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.\n\nThe user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.\n\nApply [AGENTS.md's **Choose the principled course** rule](../../../AGENTS.md#attitude) to every admission, disposition, implementation, and review decision.\n\nRead the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds; issue discovery is independent review, not discussion. Read [development.md](development.md) in full only when implementation is authorized.\n\n## Campaign Knowledge Base\n\nCreate `.wiki/<campaign>/` with a short filesystem-safe campaign name. Preserve any existing campaign directory and reconcile it rather than deleting or assuming a blank slate.\n\nKeep concise, current Markdown documents for:\n\n- repository provenance, architecture, validation ownership, and product boundaries;\n- experiments, reproductions, dogfooding, and related issue or pull-request history;\n- every raw candidate, its evidence, dependencies, and final disposition, including combinations, splits, rejections, and deferrals with the evidence supporting each decision;\n- the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, and official GitHub `createdAt`-to-`mergedAt` cycle timing;\n- the exact commit, dependency lock, provisioning command, supported environment contract, and tracked-file census for each discovery round;\n- a mandatory coverage matrix that crosses public operations, owners, consumers, declaration spellings and provenance, composition, transform options, input contexts and boundaries, generated artifacts, packaging, CLI, and supported platforms;\n- a per-issue consequence matrix and implementation impact record that names every caller, equivalent spelling, provenance, option, context, boundary, artifact, consumer, and platform revalidated by the fix; and\n- an integration-command manifest that records and hashes the exact commands, environment, tool versions, triggering change classes, expected artifacts, and clean-consumer setup required before and after each integration-sensitive merge.\n\nRecord raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.\n\nGive every tracked path and matrix cell a stable ID, and record one row per ID with `round`, `base SHA`, `matrix hash`, `path or cell ID`, `status`, `evidence`, and `candidate`.\n\nA status is one of four values, and it means something different for a path than for an executable cell:\n\n| Status | Tracked path | Executable matrix cell |\n| --- | --- | --- |\n| `PASS` | contents, history, owner, and linked cells were audited | the recorded oracle and controls passed |\n| `FAIL` | a candidate remains | the oracle or a control failed |\n| `N/A` | evidence that the path is outside an explicitly authorized contract | a product-contract reason |\n| `UNTESTED` | the audit is absent | the cell did not run |\n\nReconcile the path census with `git ls-files` and verify that the matrix covers every public operation and known historical dimension before the round begins. When the round discovers a missing owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells.\n\nReconcile the finished rows against the frozen census and final matrix. Any missing row, `UNTESTED`, unsupported `N/A`, or absent evidence makes the round `INCOMPLETE`.\n\nThe knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to `.wiki`.\n\n## Discover Issues\n\nRun the review skill's [Solo Issue Discovery Rounds](../review/SKILL.md#solo-issue-discovery-rounds) over the entire declared campaign scope. That procedure owns the frozen commit, environment contract, tracked-file census, mandatory coverage matrix, and the `COMPLETE` and `INCOMPLETE` round states. This section adds only what the campaign itself owns.\n\nOnly an explicit user instruction or existing public product contract can exclude a surface or environment. The campaign cannot narrow itself, and an unresolved support-policy question makes the round `INCOMPLETE`.\n\nSource is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions.\n\nNever combine results from different commits, and never accept a stale, unprovisioned, skipped, contaminated, sampled, or missing-type harness whose tags or declarations collapse to `any` or `unknown` as full-round evidence.\n\nTreat the development skill's [Forbidden](../development/SKILL.md#forbidden) section as an explicit retrospective audit contract, not only a rule for future changes. In every complete round, inspect the current implementation and its history for violations, including code that predates the campaign or passes every test. A verified violation is a meaningful issue candidate. Prove the classification from purpose, control flow, consequence, and history; resemblance or stylistic preference alone is not evidence.\n\nDo not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.\n\n### Every Round Is Full-Scope\n\nEvery round re-audits the entire declared scope from scratch against the state it was frozen on. A round is never partitioned: not by package, file, concern, platform, candidate class, validation lane, or pass, not by the areas the last cycle or the last round happened to touch, and not by splitting the scope across rounds so that each one covers a slice. What an earlier round read is never coverage for this one, whether it ran in an earlier cycle against a state a merge has since changed, or earlier in this cycle against the same commit. The [review skill's Non-Negotiable Review Law](../review/SKILL.md#non-negotiable-review-law) states the same rule for every round and review the campaign runs.\n\n### Discovery Ends Only On An Empty Round\n\nDiscovery repeats in two nested loops, and neither ends until a complete round comes up empty.\n\nInside one cycle, accepting a candidate does not end discovery. Begin another complete full-scope round against the same frozen commit and repeat until one round produces no meaningful candidate that survives verification. Only that empty round settles the cycle's issue set. Publishing or implementing from the first round that found something freezes the cycle around whatever that round happened to reach first, and the issues the next round would have added arrive too late to join it.\n\nAcross cycles, a merged cycle does not end the campaign. It produces one more discovery phase against the integrated repository, and that phase runs the inner loop to its own empty round. There is no limit on either loop, and the campaign ends only when a complete fresh round is not `INCOMPLETE`, produces no meaningful candidate that survives verification, and leaves no accepted issue unresolved.\n\nReport the campaign complete only from a round that actually came up empty. Ending after a cycle that merely felt thorough leaves the issues the next round would have found unrecorded.\n\n## Vet And Publish Issues\n\nThe same main agent owns every publication decision. For each candidate:\n\n1. Reopen its evidence and reproduce the behavior.\n2. Verify ownership, provenance, and any claimed classification under the development skill's **Forbidden** section.\n3. Trace the full consequence surface.\n4. Compare open and closed issues and pull requests.\n5. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence.\n\nRevalidate every disposition from primary evidence in a fresh state, including rejection, narrowing, combination, split, deferral, and confirmed-invalid conclusions, rather than trusting the note that first recorded it. A disposition that cannot be reproduced leaves the candidate surviving and blocks `CLEAN`; it cannot be hidden by omitting publication. The [multi-agent procedure](../multi-agent/issue-campaign.md) assigns this audit to an independent critic agent; a solo campaign performs it as a separate pass with its own recorded evidence.\n\nPublish only the adjudicated form and only with user authorization.\n\n### Self-Contained Issue Body\n\nWrite enough context for a fresh AI agent to begin implementation from the issue alone. Do not require access to local `.wiki`, the discovery conversation, or unstated repository knowledge. Cover these sections when they apply:\n\n- **Problem:** current and expected behavior, impact, and affected users.\n- **Evidence:** exact reproduction, outputs or artifacts, stable symbols, verified root cause, ownership, and provenance. For a violation of the development skill's **Forbidden** section, prove the classification from behavior, control flow, and history instead of merely naming the prohibition. Line numbers are navigation, not proof.\n- **Consequence surface:** affected consumers, states, platforms, compatibility and failure paths, plus the complete case matrix for the cause.\n- **Invariant:** the required behavior and architectural owner, without prescribing an implementation mechanism. Discovery explanations, closed issue approaches, and candidate mechanisms remain hypotheses for the implementer to validate; executed evidence establishes constraints and rejected alternatives, not a prescribed solution.\n- **Acceptance and verification:** positive, negative, boundary, and regression outcomes with narrow and broader proving commands.\n- **Coordination:** dependencies, exclusions, migration concerns, external blockers, and related open, closed, accepted, or rejected work.\n\nUse tables for repeated case mappings. Read the rendered issue back and keep its body as the current operative handoff; use comments only for chronology.\n\nBefore publication, reproduce the current failure and its independent oracle once more in a fresh state, and verify the invariant, complete owner and consumer census, supported-environment boundary, equivalent-spelling and provenance matrix, positive and negative twins, boundary cases, and a counterfactual proving that the reproduction distinguishes the expected behavior. Pass-after and fix-mutation evidence belong to implementation verification. Strike any prescribed implementation mechanism, including one that appears to fit the current evidence.\n\n## Develop And Repeat The Campaign\n\nRead [development.md](development.md) in full when the user authorizes implementation pull requests or the end of a campaign that entered implementation. It owns the single cycle pull request, empty claim, internal DAG order, test authoring, formatting, ordinary CI, red-CI repair, solo Self-Review, the integration-sensitive gate, merge, branch and temporary-asset cleanup, and renewed discovery.\n\nAn audit-only or issue-publication-only campaign does not load the development procedure or mutate repository, Actions, or GitHub state beyond the authorized publications.\n\n<!-- File: .agents/skills/multi-agent/issue-campaign.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/issue-campaign.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/issue-campaign.md)\n\n<!-- File: .agents/skills/multi-agent/review.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Multi-agent Skill\n\nPath: `.agents/skills/multi-agent/review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/.agents/skills/multi-agent/review.md)\n\n<!-- File: .agents/skills/multi-agent/SKILL.md (Tokens: ~726 | Category: anthropic-skill) -->\n---\nname: multi-agent\ndescription: \"Defines the explicitly parallel variants of typia review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review and unqualified review remain solo. Multi-agent issue campaigns parallelize discovery and implementation by default, but an explicit request may limit parallelism to discovery and return implementation to the solo campaign.\"\n---\n\n# Multi-Agent Workflows\n\nThis skill is the single entry point for every explicitly parallel review or campaign. Read the base solo skill first, then enter through the detailed document below for the requested workflow. That document names any shared multi-agent topic procedures it also requires.\n\n| Explicit request | Base skill | Detailed multi-agent procedure |\n| --- | --- | --- |\n| Team, parallel, or multi-agent review | [review](../review/SKILL.md) | [review.md](review.md) |\n| Parallel or multi-agent issue campaign | [issue-campaign](../issue-campaign/SKILL.md) | [issue-campaign.md](issue-campaign.md) |\n\n`typia` has no benchmark-campaign skill. Use [benchmark](../benchmark/SKILL.md) for measurement integrity, then the applicable issue-campaign workflow for authorized benchmark-driven implementation.\n\nDo not load this skill for Self-Review, an unqualified review, a discussion, or a campaign that does not explicitly request parallel agents.\n\n## Shared Parallelism Rules\n\n- Use the smallest number of agents that adds independent evidence or owns immediately executable disjoint work. Available thread capacity is not a reason to create an agent, and a review or discovery round is the one place where every available slot should carry a full independent pass.\n- Keep the total at ten agents including the lead, so at most nine children run at once.\n- Never create a waiter, poller, coordinator-only child, duplicate implementation owner, or agent that cannot begin useful work immediately.\n- Give every review or discovery agent the complete declared surface. Parallel review adds independent full passes; it never partitions coverage by package, file, concern, platform, or test lane.\n- Partition implementation only through verified dependency and file-ownership boundaries. One agent owns one coarse batch, branch, pull request, and worktree.\n- Keep the lead active on fact-checking, integration, conflict resolution, and decisions that do not duplicate an assigned agent.\n- Do not let agents re-delegate.\n- Self-Review remains solo for every author and every implementation branch. An independent verifier or critic is a separate agent auditing someone else's work, never a substitute for the author's own round.\n- Create worktrees only for parallel implementation batches, verification, mutation, and integrated cleanup. Solo implementation and review use the current checkout.\n- Remove every finished worktree, local branch, process, and assignment-owned temporary asset before declaring its assignment complete.\n\nThe solo campaign's [commit early-warning pass](../review/SKILL.md#commit-early-warning-pass) is a different topology and relaxes neither the full-surface rule nor the solo Self-Review rule above. A parallel review gives several reviewers the entire declared surface independently and the lead adjudicates their findings. The pass gives one read-only reader one commit's slice, reports candidates to the author who is still implementing, and leaves that author's own whole-surface round as the gate. A batch implementation agent here runs no pass, because agents do not re-delegate; the carve-out in the solo development procedure belongs to a solo campaign's main agent.\n\n<!-- File: .agents/skills/project/SKILL.md (Tokens: ~1719 | Category: anthropic-skill) -->\n---\nname: project\ndescription: Defines the typia product contract, workspace layout, package boundaries, and canonical commands. Use when orienting in the repository, working inside any package, or choosing a build, test, or format command.\n---\n\n# Project Outline\n\n## Product Contract\n\nTypia is a TypeScript transformer library built around one idea: a pure TypeScript type definition should replace the runtime helpers that other tools require schemas, decorators, or hand-written guards for. The compile-time transform reads those types and emits the runtime validator, serializer, schema, or decoder inline.\n\nThe packages:\n\n- **`typia`**: the user-facing library and native transform. Exposes the runtime validators (`is`, `assert`, `assertGuard`, `validate`), enhanced JSON serde (`json.assertParse`, `json.assertStringify`, `json.schema`), LLM function-calling harness (`llm.application`, `llm.schema`, `llm.parse`, `llm.structuredOutput`, `llm.evaluation`), Protocol Buffer encoder/decoder (`protobuf.message`, `protobuf.assertEncode`, `protobuf.assertDecode`), and the random data generator (`random`).\n- **`@typia/interface`**: shared public typings (e.g. `IJsonSchemaCollection`, `ILlmSchema`, `IValidation`) consumed by every other package and by user code.\n- **`@typia/utils`**: runtime, OpenAPI, and LLM utility helpers (e.g. `LlmTypeChecker`) that live next to but outside the transform.\n- **`@typia/langchain`**: LangChain.js integration that adapts typia's LLM harness to LangChain tools.\n- **`@typia/mcp`**: Model Context Protocol integration.\n- **`@typia/vercel`**: Vercel AI SDK integration.\n- **`@typia/jev`**: Jev evaluation model integration, converting `llm.evaluation` questions to the Jev wire format.\n\nDownstream projects (`@nestia/core`, `@agentica`, `@autobe`) build on top of typia but are not part of this repository's contract. The exported `typia.*` surface, the `@typia/interface` typings, and the `ttsc.plugin` descriptor shape are public; renaming or removing any of them is a deliberate, separate change.\n\nA single Go program under `packages/typia/native` performs the compile-time transform that emits validators, stringifiers, schemas, and decoders in place of `typia.*<T>()` call sites. `packages/typia` registers a Go command package that `ttsc` (the TypeScript-Go compiler with native plugin support) compiles into a binary on first use through its plugin manifest:\n\n```json\n\"ttsc\": { \"plugin\": { \"transform\": \"typia/lib/transform\" } }\n```\n\nThe `packages/typia/src/transform.ts` file is a plugin descriptor, not a transformer; there is no TypeScript-side transform anymore. The descriptor resolves the installed `typia` package root and returns the Go entrypoint under `native/cmd/ttsc-typia`. The adapter packages do not register their own transforms. Consumers reach the binary through `ttsc` / `ttsx` and the published descriptor. ttsc keys each plugin build by content and stores it workspace-wide under `node_modules/.cache/ttsc` (it walks up to `pnpm-workspace.yaml`), so every package and test workspace shares one binary.\n\n## Layout\n\n- `packages/*`: the published packages, including the shared Go plugin under `packages/typia/native`. Public and contract Go tests live under `packages/typia/test`; native Go tests are colocated throughout `packages/typia/native/**`. The test `go.work` resolves `ttsc` and its shims through `../node_modules/`, while the native development `go.work` resolves the sibling `ttsc` checkout.\n- `tests/template`: `@typia/template`, a workspace package that ships the structure fixtures (`ObjectSimple`, `ArrayHierarchical`, ...) and the `TestServant` runtime helper consumed by the automated suites.\n- `tests/test-*`: feature-test workspaces:\n  - `test-typia-schema`, `test-langchain`, `test-mcp`, `test-vercel`, `test-jev`, `test-utils`: function-per-file suites under `src/features/**/test_*.ts`, each file exporting one matching `test_<snake_case>` function discovered by `DynamicExecutor` (from `@nestia/e2e`).\n  - `test-utils`, `test-mcp`, `test-langchain`, `test-vercel`, and `test-jev` also hold portable cases under `src/unit/features/**/test_*.ts`, registered explicitly through `node:test` by `src/unit/index.ts` under `tsconfig.unit.json`, which has no native typia plugin. Their `start` runs the unit population before the integration population. Portable utility and adapter semantics belong in the unit population; preserve each exported case's inputs, assertions and failure identity when transferring it from a transformed suite.\n  - `test-typia-automated`, `test-utils-automated`: generator-driven matrix suites over their configured typia operations and `@typia/template` structures; their generated `src/features/` trees are rebuilt by the suite.\n  - `test-interface`: compile-time tests for exported `@typia/interface` types and public typia signatures; these cases execute no typia factory.\n  - `test-error`: transform-rejection verification; the build must fail and every fixture must be named by a typia diagnostic.\n- `tests/debug`: `@typia/debug`, a one-off `ttsx` runner for ad-hoc local repros.\n- `benchmark/`: `@typia/benchmark`, performance generators with archived results under `benchmark/results/**`. See `.agents/skills/benchmark/SKILL.md`.\n- `website/src/content/docs/**`: user-facing MDX guides published at https://typia.io/docs. See `.agents/skills/documentation/SKILL.md`.\n- `examples/`, `experiments/`, `scripts/`, `config/`: example sources, tarball staging, repo utilities, and shared build configuration.\n\n## Commands\n\nCI uses Node 24.x and Go 1.26.x, while the workspace pins pnpm exactly to 10.6.4.\n\n```bash\npnpm install\npnpm evidence\npnpm format\npnpm build\npnpm test\n```\n\n`pnpm test` runs every `tests/test-*` workspace through `pnpm test:packages`, then runs both Go trees through `pnpm test:toolchain`: `go -C packages/typia/test test ./...` and `go -C packages/typia/test test ../native/...`. It needs `go` on `PATH`. Run `pnpm install` first, or the test Go workspace cannot resolve `ttsc` and its shims through `../node_modules/`. Most feature workspaces execute TypeScript directly through `ttsx`; `test-error` uses a Node harness and `test-interface` invokes TypeScript `tsc --noEmit`. Plugin-building workspaces share the cache under `node_modules/.cache/ttsc`.\n\n`pnpm evidence` checks every enrolled production owner, test feature function, and root tooling configuration without building or generating test matrices. Every enrolled `tests/*/evidence.config.json` selects exactly `src/features/**/test_*.ts` with `symbol: \"function\"`; unit populations, types, runners and support declarations are outside this selection while their ordinary execution remains intact. `pnpm evidence:packages` and `pnpm evidence:tests` check their enrolled workspace populations separately. The template and both automated test workspaces are not enrolled; their ordinary generation and test commands retain their behavioral coverage.\n\nRelease-time commands (most contributors skip these): `pnpm package:rc`, `pnpm package:next`, `pnpm package:latest`, and `pnpm release`. `pnpm package:tgz` stages local tarballs in `experiments/tarballs/` for offline testing. See `.agents/skills/pull-request/SKILL.md` for the remote delivery flow.\n\n<!-- File: .agents/skills/pull-request/SKILL.md (Tokens: ~944 | Category: anthropic-skill) -->\n---\nname: pull-request\ndescription: Defines typia branch, commit, pull-request, check, and merge workflows. Use when the user explicitly asks to open, submit, update, or merge a pull request, or when a standing autonomous mandate authorizes end-to-end delivery; never open, push, update, or merge one on unprompted initiative.\n---\n\n# Pull Request Submission\n\nAct on this skill only when the user explicitly requests the corresponding remote action, or when a standing autonomous mandate authorizes it. Permission to edit locally is not permission to push or open a pull request, and permission to open or update is not permission to merge. The one exception is a standing autonomous mandate — an autonomous or remote-control campaign, or an explicit instruction to carry the work through merge: it is the request for every step it names, including push and merge, and the skill's check, verification, and self-review gates still apply to each step.\n\n## Branch From The Target\n\nBranch from the pull-request target (`master` unless stated otherwise); never commit or push directly to the target. Name the branch for the merged outcome with the repository's established type and scope, such as `feat/<scope>`, `fix/<scope>`, `docs/<scope>`, or `ci/<scope>`.\n\nSolo work never creates a clone or worktree. If the current checkout contains unrelated or protected work, stage only the authorized paths; if that cannot keep the pull request isolated, report the conflict rather than stashing, reverting, mixing, or relocating the work.\n\n## Commit Logical Units\n\nUse one commit per coherent unit when the diff is large. Follow the repository's `<type>(<scope>): <subject>` history with an imperative lowercase subject and no trailing period.\n\nRun the validation required by the development skill. Defer `pnpm format` to its final pre-merge cleanup gate; do not run it for each commit or push. Parallel issue-campaign implementation batches keep their dedicated Post-Campaign Cleanup formatter gate.\n\nStage explicit paths when the worktree is mixed. Never include unrelated user changes silently.\n\n## Write The Pull Request\n\nWrite the body at open as the historical intent statement. Include the intent, scope, deferred items, and exact local verification. State skipped checks and disabled campaign CI honestly.\n\nDo not rewrite the body after every follow-up push. Record later CI fixes, newly discovered design issues, promoted deferred work, and Self-Review results as formal GitHub pull-request reviews with the `COMMENT` event so the thread preserves chronology. Use inline review comments when an observation belongs to a changed line and the review body for commit-wide or round-wide results. Do not use ordinary issue-style pull-request comments for this ledger, and never `APPROVE` or `REQUEST_CHANGES` on your own pull request. The title describes the merged outcome in Conventional Commits style, not the work process.\n\nPush only the topic branch with upstream tracking. Use a file-backed body for multiline Markdown when opening through `gh`.\n\n## Issue Campaign Override\n\nBefore any issue-campaign push or pull request, complete `.agents/skills/issue-campaign/development.md`. A solo campaign uses one cycle pull request, the final pre-merge formatter gate, the ordinary check loop, and its integration-sensitive gate. Only `.agents/skills/multi-agent/issue-campaign.md` overrides that flow with worktree batches, exact-SHA campaign-run cancellation, local implementation gates, and Post-Campaign Cleanup.\n\n## Watch Checks After Every Ordinary Push\n\nAfter each ordinary push, including every Post-Campaign Cleanup push, monitor the pull-request checks until every check settles. Only CI-suspended campaign implementation waves skip this loop. On failure, fetch the relevant job log, diagnose the real cause, fix it in place, push a new commit, and resume monitoring. Do not treat a green unrelated job as acceptance for a failed required surface.\n\n## Merge On Explicit Request Or Standing Autonomous Mandate\n\nDo not merge, squash-merge, rebase, or update the target branch on unprompted initiative. Merge when the user explicitly asks, or when a standing autonomous mandate authorizes end-to-end delivery; use the repository's established merge method unless another is specified. Under an autonomous mandate the author that owns the pull request merges it themselves once the merge gate below passes, without separate approval.\n\nBefore merging an ordinary or Post-Campaign Cleanup pull request, confirm required checks pass. For a multi-agent campaign implementation pull request whose automatic CI is deliberately suspended, confirm its local-verification, independent-verification, and integration gates instead. If branch protection blocks the requested merge, report the blocker rather than bypassing it.\n\n<!-- File: .agents/skills/review/SKILL.md (Tokens: ~1938 | Category: anthropic-skill) -->\n---\nname: review\ndescription: Defines exhaustive solo review, Self-Review, and solo repository-wide issue-discovery rounds for typia. Use for every self-review or unqualified review request and as the default review mode inside issue campaigns. This skill never spawns review agents; use the multi-agent skill only when the user explicitly requests a team, parallel, or multi-agent review.\n---\n\n# Review\n\n## Non-Negotiable Review Law\n\nRead the [contracts skill](../contracts/SKILL.md) when reviewing maintained production declarations or tests. Judge every acknowledgment against the actual declaration, native documentation, private helpers, and consequence surface. Evidence proves that an answer exists; review verifies every fact the chapter requests and revalidates existing answers affected by a change. A passing fixture or renamed wrapper does not prove that a disproven implementation assumption was corrected.\n\nOne reviewer performs every review in this skill from scratch over the entire declared surface. Do not spawn a subagent, delegate a concern, or load the discussion skill. Do not create a clone or worktree for solo review or Self-Review.\n\nChoose the principled conclusion. Review duration, difficulty, and consequence surface are reasons to inspect more deeply and verify more carefully, never reasons to overlook a sound improvement, accept an unsupported claim, or lower the completion standard.\n\nA complete round must satisfy all six rules:\n\n- **Whole surface:** read every changed file and hunk. For issue discovery, audit the entire campaign scope. Never partition by file, package, concern, platform, or pass, and never substitute another reviewer's coverage.\n- **Consequence surface:** inspect affected code paths, tests, generated artifacts, CI, packaging, documentation, and consumers. Trace side effects, state transitions, concurrency, platforms, boundaries, compatibility, and failure and recovery paths beyond the named symptom or diff.\n- **Fresh start:** use the current state and repeat the whole inspection. Earlier rounds, sampled files, and a recheck of only the latest fix do not count as coverage.\n- **Unlimited rounds:** whenever the reviewer applies an improvement or accepts a meaningful issue candidate, update the work and start another complete round. Stop only after a complete round produces nothing that survives verification.\n- **One immutable state:** a round runs against one recorded state, dependency lock, provisioned workspace contract, supported environment contract, and mandatory test matrix. Issue discovery and committed pull-request review use an exact commit. A solo review records its exact starting diff and refreshes that snapshot after every edit; a review round must not race a source change. The [multi-agent review procedure](../multi-agent/review.md) states how a team shares one snapshot.\n- **Auditable completeness:** the reviewer accounts for every tracked file and every mandatory public-operation, ownership, consumer, boundary, option, declaration-provenance, generated-artifact, packaging, and supported-platform matrix cell in the declared surface. Finding a candidate never ends or narrows the review. A skipped file, unprovisioned harness, unsupported claim, or unexecuted required cell makes the report `INCOMPLETE`, never `COMPLETE`.\n\n## Self-Review\n\nSelf-Review and an unqualified review request use this solo workflow:\n\n1. Establish the complete change surface, including the pull-request base-to-head diff and any uncommitted changes.\n2. Perform one complete round under the Non-Negotiable Review Law. Include correctness and boundaries, Windows and POSIX behavior, concurrency and state, data loss and security, cache and recovery invariants, public API and compatibility, test isolation, CI and packaging, generated output, documentation, and migration effects.\n3. Reproduce every suspected defect before accepting it.\n4. Apply every sound improvement and run the narrowest verification authorized by the owning workflow.\n5. If anything changed, restart at step 1 as a fresh full round.\n6. Finish only when a complete round finds nothing to improve. Report the final clean round and every verification that could not run.\n\nSelf-Review does not authorize creating, pushing, updating, or merging a pull request. If the user separately requests one of those actions, follow the pull-request skill.\n\n## Commit Early-Warning Pass\n\nA commit early-warning pass is not a review under this skill. It is the read-only per-commit reader a solo campaign author runs over every landed commit while still implementing, required and defined by the [solo campaign development document](../issue-campaign/development.md#implement-and-write-tests).\n\nIt delegates nothing the Non-Negotiable Review Law governs. The law governs the author's own round, which still runs alone over the whole surface before merge under all six rules. One commit is not a declared surface, a reported candidate is not an accepted finding, and the passes do not add up to a round.\n\nNever call the pass a Self-Review, and never report it as one. A reader who sees that name concludes the gate already ran, and the whole-surface round disappears without anyone deciding to drop it.\n\n## Solo Issue Discovery Rounds\n\nUse these rounds only through the solo issue-campaign skill.\n\n1. Freeze one exact commit and record the dependency lock, provisioning command, and supported environment contract before starting. Derive that environment contract from package engines, public documentation, repository CI, peer requirements, published package behavior, and explicit user decisions; do not narrow it ad hoc, and treat an unresolved conflict as a blocker on `CLEAN`.\n2. Inventory all tracked files, package and public API families, implementation owners, generated artifacts, test harnesses, workflows, documentation contracts, supported platforms, and open and closed issue or pull-request history before examining candidates. Reconcile that inventory with `git ls-files` and with the campaign's mandatory coverage matrix. A grep lens, a sampled file set, or a statement that the surface was reviewed is not coverage.\n3. Audit the entire inventory and execute the whole mandatory matrix. Audit source, tests, documentation, CI, packaging, generated artifacts, platform behavior, upstream and downstream provenance, and history against the development skill's **Forbidden** section. Continue through the full inventory after finding a candidate.\n4. Treat the matrix as a floor. Cover all applicable public operation families and direct, factory, and nested forms; equivalent TypeScript spellings, including aliases, interfaces, call and construct type literals, and classes; local, re-exported, module, package, user-global, default-library, ambient, and runtime-native provenance; union, intersection, generic, and transform-option interactions; static, dynamic, array, `any`, and `unknown` value contexts; positive, one-axis negative, boundary, malformed, maximum-width, one-past-boundary, and mutation controls; generated-byte and executed-runtime behavior; deterministic repeat emit; workspace, clean packed, and deployment consumers; and supported Node, module-resolution, operating-system, and CLI paths. Every interaction that reaches shared control flow is its own cell, and every positive cell has a one-axis negative twin. Run mutations only in a disposable checkout, keep the regression probe unchanged, and require the probe's canonical command to fail. When the round discovers a new owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells before the round can complete.\n5. Record every raw candidate, killed hypothesis, command, and artifact in the campaign knowledge base with the exact commit, environment, matrix hash, and census results. The round is `COMPLETE` only when the full inventory and current matrix finished; otherwise it is `INCOMPLETE` and cannot support a `CLEAN` campaign state.\n6. Reopen each candidate from primary evidence in a fresh state, reproduce it, verify ownership and provenance, trace its complete consequence surface, and compare existing issues and pull requests. Record accept, partial acceptance, rewrite, combine, split, reject, or defer with the supporting evidence, so a later round does not rediscover a rejected premise as new. Implementation mechanisms remain hypotheses.\n7. If any meaningful candidate survives, return to step 3 and run another complete round against the same frozen commit before publishing or implementing anything, and repeat until one round produces no surviving candidate. Discovery owns this loop; it never hands a partial candidate pool to publication or implementation because the first round already found work. A prior finding never permits narrowing the next round to its owner or neighbors.\n8. Publish only the surviving adjudicated form when the campaign is authorized to publish. After the authorized issue and implementation flow completes, freeze the new integrated commit and begin the next full-scope round.\n9. Stop only when one immutable-state round completes the entire repository inventory and mandatory matrix, no round is `INCOMPLETE`, and no meaningful candidate survives verification. Any verified in-repository correctness, contract, data-integrity, build, test-oracle, documentation, packaging, workflow, or **Forbidden** violation is meaningful regardless of severity, rarity, legacy status, or malformed-input trigger. Do not downgrade a proved defect to an observation to satisfy the stop rule. An unresolved, deferred, or unimplemented verified defect blocks `CLEAN`, and green existing suites cannot satisfy the stop rule.\n\n## Explicit Multi-Agent Reviews\n\nWhen the user explicitly asks for a team, parallel, or multi-agent review, load the [multi-agent skill](../multi-agent/SKILL.md) and its [review procedure](../multi-agent/review.md) instead of this workflow. It inherits the same whole-surface, immutable-state, and auditable-completeness law while defining independent parallel reviewers, agent briefing, and lead and critic adjudication.\n\n<!-- File: packages/interface/package.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Interface Skill\n\nPath: `packages/interface/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/package.json)\n\n<!-- File: packages/interface/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Interface Skill\n\nPath: `packages/interface/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/tsconfig.json)\n\n<!-- File: packages/langchain/package.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Langchain Skill\n\nPath: `packages/langchain/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/package.json)\n\n<!-- File: packages/langchain/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Langchain Skill\n\nPath: `packages/langchain/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/tsconfig.json)\n\n<!-- File: packages/mcp/package.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Mcp Skill\n\nPath: `packages/mcp/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/package.json)\n\n<!-- File: packages/mcp/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Mcp Skill\n\nPath: `packages/mcp/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/mcp/tsconfig.json)\n\n<!-- File: packages/typia/package.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Typia Skill\n\nPath: `packages/typia/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/package.json)\n\n<!-- File: packages/typia/test/protobuf_varint_corpus.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Test Skill\n\nPath: `packages/typia/test/protobuf_varint_corpus.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/test/protobuf_varint_corpus.json)\n\n<!-- File: packages/typia/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Typia Skill\n\nPath: `packages/typia/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/tsconfig.json)\n\n<!-- File: packages/typia/typedoc.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Typia Skill\n\nPath: `packages/typia/typedoc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/typia/typedoc.json)\n\n<!-- File: packages/utils/package.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Utils Skill\n\nPath: `packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/package.json)\n\n<!-- File: packages/utils/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Utils Skill\n\nPath: `packages/utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/utils/tsconfig.json)\n\n<!-- File: packages/vercel/package.json (Tokens: ~558 | Category: anthropic-skill) -->\n{\n  \"name\": \"@typia/vercel\",\n  \"version\": \"15.1.0\",\n  \"description\": \"Vercel AI SDK integration for typia\",\n  \"main\": \"src/index.ts\",\n  \"exports\": {\n    \".\": \"./src/index.ts\",\n    \"./package.json\": \"./package.json\"\n  },\n  \"scripts\": {\n    \"build\": \"rimraf lib && ttsc && rolldown -c\",\n    \"dev\": \"ttsc --watch\",\n    \"evidence\": \"evidence\"\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"https://github.com/samchon/typia\"\n  },\n  \"author\": \"Jeongho Nam\",\n  \"license\": \"MIT\",\n  \"bugs\": {\n    \"url\": \"https://github.com/samchon/typia/issues\"\n  },\n  \"homepage\": \"https://typia.io\",\n  \"dependencies\": {\n    \"@typia/interface\": \"workspace:^\",\n    \"@typia/utils\": \"workspace:^\"\n  },\n  \"peerDependencies\": {\n    \"ai\": \">=6.0.0\"\n  },\n  \"devDependencies\": {\n    \"@types/json-schema\": \"^7.0.15\",\n    \"ai\": \"^6.0.116\",\n    \"rimraf\": \"catalog:utils\",\n    \"rolldown\": \"catalog:rolldown\",\n    \"tinyglobby\": \"^0.2.12\",\n    \"ttsc\": \"catalog:samchon\",\n    \"typescript\": \"catalog:typescript\"\n  },\n  \"sideEffects\": false,\n  \"files\": [\n    \"README.md\",\n    \"package.json\",\n    \"lib\",\n    \"src\"\n  ],\n  \"keywords\": [\n    \"vercel\",\n    \"ai-sdk\",\n    \"typia\",\n    \"llm\",\n    \"llm-function-calling\",\n    \"ai\",\n    \"tool-calling\",\n    \"openai\",\n    \"anthropic\",\n    \"claude\",\n    \"chatgpt\",\n    \"gemini\",\n    \"validation\",\n    \"json-schema\"\n  ],\n  \"packageManager\": \"pnpm@10.6.4\",\n  \"publishConfig\": {\n    \"access\": \"public\",\n    \"main\": \"lib/index.js\",\n    \"module\": \"lib/index.mjs\",\n    \"types\": \"lib/index.d.ts\",\n    \"exports\": {\n      \".\": {\n        \"types\": \"./lib/index.d.ts\",\n        \"import\": \"./lib/index.mjs\",\n        \"default\": \"./lib/index.js\"\n      },\n      \"./package.json\": \"./package.json\"\n    }\n  }\n}\n\n<!-- File: packages/vercel/tsconfig.json (Tokens: ~300 | Category: anthropic-skill) -->\n# Vercel Skill\n\nPath: `packages/vercel/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/vercel/tsconfig.json)\n\n<!-- File: packages/interface/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# interface Documentation\n\nPath: `packages/interface/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/interface/README.md)\n\n<!-- File: packages/langchain/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# langchain Documentation\n\nPath: `packages/langchain/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/samchon/typia/HEAD/packages/langchain/README.md)\n\n<!-- ... +3 more modular skills available via /api/skills/samchon/typia?path={path} -->\n</yakaai_skills>"}