Agent skill

Signature Kernel

by pikax in pikax/verter

Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered…

MITAuto-check passed

Install Signature Kernel

skills CLI
$ npx skills add pikax/verter --skill signature-kernel -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install pikax/verter signature-kernel --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/signature-kernel .claude/skills/signature-kernel && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
signature-kernel
GitHub stars
113
Token cost
~5k tokens
SKILL.md length
2,103 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
MIT

At a glance

Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered…

  • Works in 6 steps: Module map → Ordered reduction is ONE pair of queries → Determinism: VerterStableV1 → …
  • SKILL.md covers 1. Module map, 2. Ordered reduction is ONE…, 3. Determinism: VerterStableV1 and 4. Epoch-safe storage and the…, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Signature Kernel is an agent skill from pikax/verter. Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered union/intersection reduction, VerterStableV1 deterministic ordering, the observation corpus and the determinism matrix

Its SKILL.md is about 5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Fast Rust-powered compiler, semantic extraction, and LSP for component frameworks. The licence is MIT.

Example prompts

  • “/signature-kernel”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Module map
  2. Ordered reduction is ONE pair of queries
  3. Determinism: VerterStableV1
  4. Epoch-safe storage and the lifetime contract
  5. Evidence
  6. Working rules

What it can do on your machine

Read from SKILL.md and the folder at commit 858624d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Signature Kernel loads about 5k tokens when it runs. Until then it costs about 81 tokens; SKILL.md has 2,103 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~81
When it runs · the whole SKILL.md, loaded when a task matches
~5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from pikax/verter at commit 858624d, republished under its MIT licence (© pikax). 2,103 words, ~5,038 tokens.

Download SKILL.mdSave it as .claude/skills/signature-kernel/SKILL.md (or your agent's skills folder).
name
signature-kernel
description
Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered union/intersection reduction, VerterStableV1 deterministic ordering, the observation corpus and the determinism matrix

Semantic Signature Kernel

The one authority for what a callable is, how two types are compared, and what order semantic composites are published in. Every signature set, every intersection/union reduction, and every deterministic ordering decision in the session crate comes from here; there is no second signature producer and no per-consumer ordering rule.

Normative contract: docs/arch/signature-kernel.md (revision 4.1, byte-locked by docs/evidence/signature-kernel/manifest.json). Where this skill and the contract disagree, the contract wins.


1. Module map

crates/verter_type_engine/src/signature_kernel/ (crate-private; its single consumer is project_semantic_dispatch/signature_discovery.rs):

ModuleOwns
records.rsThe record vocabulary and its handles: SignatureDescriptor, SignatureCandidate, SignatureTemplate, SignatureInputShape, ParameterLayout/ParameterSlot/RestSlot, BinderSpace/BinderDeclaration, SignatureResultRecipe, PredicateEffect (the effect half of a result read: a declared result's type predicate / assertion, the predicate the checker infers from a body, or a union signature's composite predicate), AppliedResult, TypeToken, GraphEpoch. Every id is epoch-qualified.
storage.rsAppendInterner<T> — the private append-only interner over boxcar::Vec with DEDUP_SHARDS (16) hash shards. Hash is computed outside the shard lock; equality decides collisions. A record is fully initialised before its handle is published, so boxcar's count() is never a published-handle range.
lifetime.rsSignatureStore: interning entry points, replace_epoch(), retain_result/drain_retained/retained_len, live_reader_count(), StoreError.
read_view.rsSemanticReadView::pin(&SignatureStore) — the request-pinned borrowed read. BorrowedSet::{Empty, One, Many}, ReadError, plus the descriptor_chain_walks / shard_lock_acquires probes the performance gates assert on.
positional.rsThe shared positional model: PositionalShape, PositionalMode, TypeAt, MinArityFlags, ProjectedTuple/ProjectedElement, SlotTypeFacts. Parameter matching, rest/receiver layout and arity are computed once here for every consumer.
provenance.rsSignatureProvenance, OverloadOrder, ArmIdentity, ConstituentSequence, DeclarationGroupId, MappedConstituent, OriginRelation, SourceLocatorId — where a candidate came from and in what authored order.
substitution.rsCallSubstitution, SubstTerm, compose_canonical, MAX_SUBSTITUTION_CHAIN_DEPTH. The two substitution stages (declared/outer map and frozen call-site map) compose canonically; a hand-built chain past the bound flattens rather than growing.
discovery.rspublish_signature, set_from_candidates, append_signatures, union_signatures, intersection_signatures, heritage_signatures, merged_declaration_signatures, resolution_order, signatures_identical, DiscoveryError.
result.rsDemand-driven results: ResultDemand, ReadSignatureResultKey, SignatureSetValue, SignatureResultValue, SignatureCandidateNodes.

Ordering and composite reduction live beside the kernel, in the dispatch crate:

PathOwns
semantic_query/stable_key.rsVerterStableV1 encoding and StableKey::cmp.
project_semantic_dispatch/canonical_algebra.rsintern_ordered_union / intern_ordered_intersection — the two crate-private canonical builders, plus compare_structural and CanonicalEvidence.
project_semantic_dispatch/build.rsbuild_reduce_union / build_reduce_intersection — the query builders behind SemanticQueryKey::ReduceUnion / ReduceIntersection.
project_semantic_dispatch/signature_discovery.rsThe cutover consumer: it drives discovery, positional matching and instantiation through the kernel records.

2. Ordered reduction is ONE pair of queries

Union and intersection construction is closed over exactly two query keys and exactly two crate-private builders:

text
SemanticQueryKey::ReduceUnion { members, nullability }      → build_reduce_union
SemanticQueryKey::ReduceIntersection { input, purpose, ctx } → build_reduce_intersection
        ↓                                                           ↓
canonical_algebra::intern_ordered_union          canonical_algebra::intern_ordered_intersection

Both builders perform recursive same-kind flattening, the lattice absorption laws, literal subsumption on unions, structural T | T = T / T & T = T through compare_structural, and proven-disjoint scalar collapse to never — an undecided relation is never guessed. Both thread CanonicalEvidence to deposit_canonical_evidence; an incomplete comparison sets cache_suppress (ReturnOnly, never a warm canonical result).

A union is built under an explicit NullabilityPolicy — strictNullChecks as construction input. Erased (the option off) drops null / undefined beside any other member, as the checker's getUnionType does, and a nullable-only list becomes null if it names null, else undefined. The policy is family identity on ReduceUnion and is recorded on the canonical stamp (CompositeOriginCategory::Canonical(NullabilityPolicy)), so the two settings never share a memo entry, a node, or the pre-seal skip. Intersections run the strict algebra.

ProjectSemanticDispatch::intern_normalized_union_or_intersection is the dispatch-level funnel every flow/meta-resolve/locator producer reaches these through; its unions run the strict algebra. The flow-return evaluator, which answers under its function's own project policy, constructs through intern_normalized_union with the frame's policy instead. Two composite constructions are deliberately outside the funnel, both CompositeList::ordered_carrier mints, and both for the same reason — an ordered carrier is an authored sequence, not a commutative intersection, and routing it through the reducer would change the origin category and therefore node identity:

  1. same-name method overload groups (walk.rs, build.rs);
  2. a possibly-callable member-value intersection (walk.rs merge_value_nodes_recursive). Call resolution over an intersection tries arms in declaration order, so a commutative sort would break overload precedence. The classification (value_may_contribute_call_signatures) fails CLOSED on anything undecidable from the graph alone, and callable merging itself belongs to SignaturesOfType → signature_kernel::discovery::intersection_signatures, never to a local concatenation of signature nodes (§15).

An interface/class declaration body with heritage is a third construction outside the funnel, the CompositeList::heritage mint (§6, rule 8): it is a declaration, not a commutative intersection, and is never re-decided.

Retired spellings. NormalizeUnion, NormalizeIntersection, SemanticMeet, canonical_intersection, build_normalize_union and UnionSelected are retired names. Each is an entry in RETIRED_SYMBOLS (crates/verter_session/tests/cases/g_misc0/no_legacy_walker.rs), enforced by retired_symbols_absent_from_production_source. Re-introducing one resurrects a second composite-construction authority beside the ordered reduction pair, which is exactly how two producers start ordering arms differently.


3. Determinism: VerterStableV1

StableKey::cmp compares (fingerprint, exact) — the FNV-1a hash of the exact key bytes FIRST, the exact bytes only on collision. Consequences worth keeping in mind:

  • Canonical union member order is fingerprint order, not authored order and not lexicographic order. Extract<'a'|'b'|'c', 'a'|'b'> renders "b" | "a".
  • An authored-order display pin in an older test is an arena-id-sort coincidence (arena id == lowering order), not a contract.
  • intern_ordered_union interns with ORDER-SENSITIVE identity (CompositeMembers::eq compares the member slice), so [a,b] and [b,a] are distinct nodes — there is no set-collision first-wins there.

Every SemanticNodeData variant has a VerterStableV1 encoding. The registration table STABLE_KEY_TABLE in crates/verter_session/tests/cases/g_block/semantic_determinism_matrix.rs enumerates the live variant set exactly (guard: stable_key_table_enumerates_every_semantic_node_data_category) and carries a residual column naming, per variant, any identity input the encoder currently approximates rather than consumes.


4. Epoch-safe storage and the lifetime contract

  • Handles are epoch-qualified. A handle minted in a retired epoch is rejected, not silently re-read (stale_epoch_handle_is_rejected).
  • replace_epoch() installs a new graph epoch. A reader pinned before the replacement finishes against its epoch (old_pinned_reader_finishes_against_its_epoch, pinned_view_reads_substitution_after_epoch_replacement).
  • Live readers are roots until drop (live_readers_are_roots_until_drop, live_reader_count_includes_pinned_retired_epoch).
  • Retained results outlive an epoch replacement until drained (retained_results_outlive_epoch_replacement_until_drained).
  • Interning rejects stale embedded handles across a replacement (intern_rejects_stale_embedded_handles_across_epoch_replacement), and a result lookup MISS never publishes (lookup_result_does_not_publish_on_miss).

The kernel store does not own the process byte budget: aggregate retention is SemanticRetentionAccount (see /type-cache-architecture → Aggregate retention account). A retained parse snapshot is a Pinned charge — charged unconditionally, never refused.

Semantic identity records are owned by their handles

Intersection recipes, semantic contexts, order domains and the large family-key payloads (RelateMemoKey, ResolveCallKey) are NOT ordinals into process-owned tables. semantic_query_memo/intern_table.rs owns the substrate:

  • Interned<T> is one owning Arc pointer. IntersectionInputId, SemanticContextId and OrderDomainId wrap one; they are Clone, not Copy, and expose the value (recipe(), context()) — there is no as_u32, no lookup_*, and no raw slot number another index could also mint.
  • Each kind declares itself with intern_domain!, which gives it a private WeakInternTable reached as InternDomain::index(). The index only DEDUPLICATES (digest → Weak); it owns no record. A record's destructor forgets its entry, and a surviving collision bucket and the index both shrink their backing capacity once drained.
  • Identity is exact value equality behind the digest: equal handles share a record, or match digest AND value. A digest collision never aliases.
  • Retained children: a record owns exactly what its value owns. An OrderedSteps recipe's EvaluateSubgroup recipes are its only same-kind children; a held parent keeps them valid. A kind with same-kind children overrides InternDomain::take_children, so a released chain is reclaimed iteratively — nesting depth never becomes destructor stack depth, including when a step slice is still watched by a Weak (the children are handed to the worklist by clone before the slice is released).
  • IntersectionInputId's Debug prints the recipe digest and top-level shape only; a nested subgroup is never expanded, so formatting a key is O(1) in nesting depth and sharing.
  • WeakInternTable::occupancy / IdentityIndexSnapshot::capture are the always-compiled lifetime counts (records, digests, digest-map and spilled collision capacity), surfaced as HostRetentionSnapshot::identity_indexes.
  • Walk recipe operands only through IntersectionInputRef::for_each_operand: iterative, and each distinct subgroup recipe is walked once however many parents share it (the family release sweep runs it under the memo lock).
  • Lock discipline: never drop something that can destroy a same-kind record while holding that kind's index lock.
  • SemanticContextId::production() is the one permanent record. SemanticPolicySetId is the policy set's own value (SemanticPolicySet::id()), so it needs no table.

Show full SKILL.md (838 more words)Show less

5. Evidence

docs/evidence/signature-kernel/:

FileRole
manifest.jsonContract byte-lock, pinned oracle identity (TypeScript 7.0.2 + per-platform toolchain digests), corpus identity and observation digest, generator versions.
semantic-difference-ledger.mdThe four-class release authority of §5.8. Every recorded difference is classified: exact agreement, presentation-only, VerterStableV1 order-induced (causal proof required), or independent semantic difference / incompleteness. A row never silently disappears.
determinism-matrix.mdPer-row status of the §5.9 perturbation matrix and what keeps a row undrivable.
performance-gates.mdThe §12 structural gates, the executable guard for each, and the 5% regression investigation policy.

Executable homes:

HomeRole
crates/verter_session/src/signature_corpus_rows_tests.rsTHE 26-row observation corpus (verter-signature-corpus-v0@typescript-7.0.2). Append-only: adding a row is one Row literal. Each row records the checker print, the --declaration --emitDeclarationOnly bytes, and the implementation's Verdict.
crates/verter_session/src/signature_corpus_tests.rsThe corpus driver and the flip law: a MatchesChecker row fails when the live answer stops matching, and an owed/degraded row fails when the live answer STARTS matching. Both directions are proven by signature_corpus_flip_law_fires_in_both_directions. A verdict can only move by a deliberate re-pin.
crates/verter_session/tests/cases/g_block/semantic_determinism_matrix.rsThe §5.9 perturbation matrix and the §5.4 stable-key table, each enumerated against its authority and consumed by replay drivers. Every comparison runs on TWO bases: the stable-text completed observation AND the generated-bytes digest.
crates/verter_session/tests/allocator_canaries.rssignature_kernel_warm_positional::warm_positional_read_does_not_allocate_or_lock — the §12 Empty/One gate, in a separate test binary because it installs a counting #[global_allocator].
crates/verter_type_engine/src/signature_kernel/*_tests.rsPer-module unit coverage (lifetime, storage, substitution, positional, provenance, discovery, read view).

Re-locking the contract digest. docs/arch/signature-kernel.md is byte-locked by manifest.json → contract.sha256, checked by typeinfo::oracle_core::identity::tests::evidence_manifest_digests_reproduce_from_checked_in_inputs. If the contract bytes change intentionally, re-lock the digest in the same change; never weaken the test.


6. Working rules

  1. One signature producer. A new consumer that needs callable shape goes through signature_discovery, never through its own walker over SemanticNodeData::Signature.
  2. One ordering rule. Rendering, display, and comparison all read the same VerterStableV1 order. A consumer that sorts arms itself is a defect.
  3. Two builders, both private. Raw interning stays crate-private behind ReduceUnion / ReduceIntersection. A thin adapter may remain only when it makes no semantic decision.
  4. Never game a determinism test. Serialising node allocation to make a replay agree is explicitly forbidden by §12. Fix the ordering input instead.
  5. A typed gap is not a fast success. Do not compare a partial Verter query to a complete TypeScript project check and label the ratio a speedup.
  6. A corpus verdict moves by re-pin only. Change the row literal in the same change that changes the answer, and move the matching ledger row with it.
  7. Semantic decisions read SignaturesOfType; representation may read the surface. A reader whose answer depends on which signatures a type HAS — callability, callable anchoring, runtime classification, overload choice, applicability — asks discovery (shared_signature_nodes / shared_signature_buckets), as the apparent-type anchor and the broad runtime classifier do. Rendering, serialization, hashing, traversal and surface carriage read an object's call_signatures / construct_signatures directly. That split is sound only because every list on an interned object is either the object's own authored list or discovery's answer for the composite it was merged from: the shallow intersection merge keeps arm members, but takes its call/construct entries from SignaturesOfType for the intersection (with_discovered_signatures), never from its own identity-deduplicated concatenation. A new merge that interns an object carrying signatures must do the same, or it creates a second signature authority.
  8. A declaration body with heritage is not an intersection type. An interface/class body with extends is an intersection NODE (bases in clause order, own body LAST) minted CompositeList::heritage (CompositeOriginCategory::Heritage; the single-declaration projection and the merged-declaration reducer mint it, and every order-preserving rebuild keeps it through CompositeList::rebuilt_from). SignaturesOfType reads the category and answers it with signature_kernel::discovery::heritage_signatures — own signatures first, then each base's in clause order, no identical-signature dedup, no mixin composition (TypeScript's resolveObjectTypeMembers) — so call resolution, the signature utilities, the relation engine and the shallow walker's heritage flush all agree, through an alias of the declaration and after instantiation too. Because the category is part of node identity, the body never shares a node with the authored Base & { … } over the same arms.
  9. Merged declarations list in order and resolve later-first. One declaration's own overloads are minted CompositeList::overload_group and a merged declaration's groups CompositeList::merged_overload_group (one arm per declaration; CompositeOriginCategory::{OverloadGroup, MergedOverloadGroup}, kept by every order-preserving rebuild). SignaturesOfType answers them with signature_kernel::discovery::merged_declaration_signatures — every declaration's signatures in declaration order, identical ones included — which the signature utilities and conditional inference read (the LAST signature). Call resolution alone reads shared_signature_nodes_in_resolution_order, the kernel's resolution_order (TypeScript's reorderCandidates): a later declaration's group before an earlier one's, and a signature whose parameter is WRITTEN as a literal type (FunctionParam::declared_literal, carried through instantiation) before the rest. No call site orders candidates itself. A function VALUE merged from several declarations is minted the same way by build_typeof (prepared_signature_groups, merged_declaration_signatures_node): a namespace member declared in several blocks, a global function declared in several declare global blocks, and a global function declared in several files (one arm per file, in declaration precedence order). A file's own top-level overloads are ONE declaration.

/type-resolution (query modes, macro traversal, the five-mode dispatch), /type-cache-architecture (key composition, candidate substrate, retention account), /component-meta (publication surface), /audit-infrastructure (ReduceUnion / ReduceIntersection work sites and origin-graph kinds).

© pikax, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/signature-kernel of pikax/verter.

Open the folder on GitHubat commit 858624d

Compare with similar skills

Signature Kernel next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Signature Kernel compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Signature Kernel this skillpikax/verter113—~5kAutomated safety check: PassMIT
Semantic Kernelgithub/awesome-copilot40k1 repos~756Automated safety check: PassMIT
Recordingcodewhale-hq/Codewhale41k—~540Automated safety check: PassMIT
Semantic Kernelmanagedcode/dotnet-skills486—~2.8kAutomated safety check: PassMIT
Kernel Organizationsgl-project/sglang37k—~1.3kAutomated safety check: PassApache-2.0
Architecture Decision Recordsaffaan-m/ECC276k4 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Semantic Kernel

    github/awesome-copilot

    Official

    Create, update, refactor, explain, or review Semantic Kernel solutions using shared guidance plus language-specific references for .NET and Python.

    40k GitHub starsUsed in 1 repo~756 tokens
    DevelopmentAuto-check passed
  • Recording

    codewhale-hq/Codewhale

    Capture screenshots on registered computers, record on macOS or HarmonyOS, and manage saved captures.

    41k GitHub stars~540 tokensUpdated today
    Productivity & AutomationAuto-check passed
  • Semantic Kernel

    managedcode/dotnet-skills

    Build AI-enabled .NET applications with Semantic Kernel using services, plugins, prompts, and function-calling patterns that remain testable and maintainable.

    486 GitHub stars~2.8k tokensUpdated today
    AI & LLM EngineeringAuto-check passed
  • Kernel Organization

    sgl-project/sglang

    Apply the SGLang kernels RFC when adding, moving, splitting, or reviewing kernel APIs, registry metadata, kernel tests, benchmarks, and model-specific implementations.

    37k GitHub stars~1.3k tokensUpdated today
    AI & LLM EngineeringAuto-check passed
  • Capture architectural decisions as numbered ADR markdown files in docs/adr/ with context, alternatives considered, consequences, and an index README.

    276k GitHub starsUsed in 4 repos~1.8k tokens
    DevelopmentAuto-check passed
  • 在Claude Code会话期间,将做出的架构决策捕获为结构化的架构决策记录(ADR)。自动检测决策时刻,记录上下文、考虑的替代方案和理由。维护一个ADR日志,以便未来的开发人员理解代码库为何以当前方式构建。

    276k GitHub starsUsed in 1 repo~863 tokens
    DevelopmentAuto-check passed

More from pikax/verter

All 14 skills in this repo
  • Debug Tooling

    pikax/verter

    In-process backtrace watchdog + LLDB attach wrapper + release-dbg profile for diagnosing hangs and slow paths in Verter benches and binaries on Windows / macOS / Linux.

    113 GitHub stars~1.9k tokensUpdated today
    Auto-check passed
  • Agent Prompts

    pikax/verter

    Generate copy-pasteable prompts for driving separate Claude Code sessions through refactor, review, or migration work.

    113 GitHub stars~5k tokensUpdated today
    Auto-check: warnings
  • Build dependency chains, rebuild sequences, profiling with MCP, and Analysis MCP server setup for Verter

    113 GitHub stars~4.3k tokensUpdated today
    Auto-check passed
  • Compiler Codegen

    pikax/verter

    Rust compiler pipeline, template codegen (VDOM/IDE), CodeTransform, cached directives, strict slots, IDE error recovery, style preprocessing, CompileTarget, compiler authority/policy/demand/admission

    113 GitHub stars~23k tokensUpdated today
    Auto-check passed
  • CTO/manager-of-managers methodology for autonomous multi-train plans where the user says "you are the MoM/CTO", "orchestrate the whole plan", "drive the migration end-to-end", "manager-of-managers"…

    113 GitHub stars~3.5k tokensUpdated today
    Auto-check passed
  • Rust Performance

    pikax/verter

    Rust performance optimization patterns: batch operations, allocation hierarchy, object pooling, CodeTransform API for vertercompiler

    113 GitHub stars~2.8k tokensUpdated today
    Auto-check passed

Questions about Signature Kernel

What does Signature Kernel do?

Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered…. Signature Kernel is an agent skill from pikax/verter.

How do I install Signature Kernel in Claude Code?

Run `npx skills add pikax/verter --skill signature-kernel -a claude-code`. Or copy the skill folder (.claude/skills/signature-kernel in pikax/verter) into .claude/skills/signature-kernel in your project. Claude Code loads it when a task matches its description.

How do I install Signature Kernel in Codex?

Run `npx skills add pikax/verter --skill signature-kernel -a codex`. Or copy the skill folder (.claude/skills/signature-kernel in pikax/verter) into .agents/skills/signature-kernel in your project. Codex loads it when a task matches its description.

Can I use Signature Kernel in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add pikax/verter --skill signature-kernel -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/signature-kernel, .gemini/skills/signature-kernel, .github/skills/signature-kernel and .opencode/skills/signature-kernel in your project.

What does Signature Kernel need to run?

SKILL.md names no scripts, command-line tools or credentials: Signature Kernel is instructions for the agent only.

Does Signature Kernel access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Signature Kernel safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Signature Kernel use?

Signature Kernel is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Signature Kernel use?

About 5k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Signature Kernel?

Skills that share tags, products or a category with Signature Kernel: Semantic Kernel (github/awesome-copilot, 40k stars), Recording (codewhale-hq/Codewhale, 41k stars), Semantic Kernel (managedcode/dotnet-skills, 486 stars) and Kernel Organization (sgl-project/sglang, 37k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Signature Kernel?

pikax (a GitHub user) maintains it in pikax/verter, which has 113 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 9, 2026.

Source: pikax/verter on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.