Semantic Kernel
github/awesome-copilot
Create, update, refactor, explain, or review Semantic Kernel solutions using shared guidance plus language-specific references for .NET and Python.
Verter semantic signature kernel — signature records/descriptors, epoch-safe interned storage and retirement, request-pinned borrowed reads, positional matching, call substitution, ordered…
$ npx skills add pikax/verter --skill signature-kernel -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install pikax/verter signature-kernel --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .claude/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernelType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add pikax/verter --skill signature-kernel -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install pikax/verter signature-kernel --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/signature-kernel .agents/skills/signature-kernel && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .agents/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add pikax/verter --skill signature-kernel -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install pikax/verter signature-kernel --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/signature-kernel .cursor/skills/signature-kernel && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .cursor/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/pikax/verter.git --path .claude/skills/signature-kernel--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add pikax/verter --skill signature-kernel -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install pikax/verter signature-kernel --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/signature-kernel .gemini/skills/signature-kernel && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .gemini/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install pikax/verter signature-kernelInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add pikax/verter --skill signature-kernel -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/signature-kernel .github/skills/signature-kernel && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .github/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add pikax/verter --skill signature-kernel -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install pikax/verter signature-kernel --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/pikax/verter.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/signature-kernel .opencode/skills/signature-kernel && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "signature-kernel" agent skill from https://github.com/pikax/verter/tree/main/.claude/skills/signature-kernel into .opencode/skills/signature-kernel/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "signature-kernel", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
signature-kernelVerter 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. 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.
6 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 858624d. It shows what the files ask for, not the result of running them.
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.
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.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from pikax/verter at commit 858624d, republished under its MIT licence (© pikax). 2,103 words, ~5,038 tokens.
.claude/skills/signature-kernel/SKILL.md (or your agent's skills folder).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.
crates/verter_type_engine/src/signature_kernel/ (crate-private; its single
consumer is project_semantic_dispatch/signature_discovery.rs):
| Module | Owns |
|---|---|
records.rs | The 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.rs | AppendInterner<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.rs | SignatureStore: interning entry points, replace_epoch(), retain_result/drain_retained/retained_len, live_reader_count(), StoreError. |
read_view.rs | SemanticReadView::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.rs | The 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.rs | SignatureProvenance, OverloadOrder, ArmIdentity, ConstituentSequence, DeclarationGroupId, MappedConstituent, OriginRelation, SourceLocatorId — where a candidate came from and in what authored order. |
substitution.rs | CallSubstitution, 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.rs | publish_signature, set_from_candidates, append_signatures, union_signatures, intersection_signatures, heritage_signatures, merged_declaration_signatures, resolution_order, signatures_identical, DiscoveryError. |
result.rs | Demand-driven results: ResultDemand, ReadSignatureResultKey, SignatureSetValue, SignatureResultValue, SignatureCandidateNodes. |
Ordering and composite reduction live beside the kernel, in the dispatch crate:
| Path | Owns |
|---|---|
semantic_query/stable_key.rs | VerterStableV1 encoding and StableKey::cmp. |
project_semantic_dispatch/canonical_algebra.rs | intern_ordered_union / intern_ordered_intersection — the two crate-private canonical builders, plus compare_structural and CanonicalEvidence. |
project_semantic_dispatch/build.rs | build_reduce_union / build_reduce_intersection — the query builders behind SemanticQueryKey::ReduceUnion / ReduceIntersection. |
project_semantic_dispatch/signature_discovery.rs | The cutover consumer: it drives discovery, positional matching and instantiation through the kernel records. |
Union and intersection construction is closed over exactly two query keys and exactly two crate-private builders:
SemanticQueryKey::ReduceUnion { members, nullability } → build_reduce_union
SemanticQueryKey::ReduceIntersection { input, purpose, ctx } → build_reduce_intersection
↓ ↓
canonical_algebra::intern_ordered_union canonical_algebra::intern_ordered_intersectionBoth 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:
walk.rs, build.rs);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.
VerterStableV1StableKey::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:
Extract<'a'|'b'|'c', 'a'|'b'> renders "b" | "a".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.
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_reader_count_includes_pinned_retired_epoch).retained_results_outlive_epoch_replacement_until_drained).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.
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.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.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.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).SemanticContextId::production() is the one permanent record.
SemanticPolicySetId is the policy set's own value (SemanticPolicySet::id()),
so it needs no table.docs/evidence/signature-kernel/:
| File | Role |
|---|---|
manifest.json | Contract byte-lock, pinned oracle identity (TypeScript 7.0.2 + per-platform toolchain digests), corpus identity and observation digest, generator versions. |
semantic-difference-ledger.md | The 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.md | Per-row status of the §5.9 perturbation matrix and what keeps a row undrivable. |
performance-gates.md | The §12 structural gates, the executable guard for each, and the 5% regression investigation policy. |
Executable homes:
| Home | Role |
|---|---|
crates/verter_session/src/signature_corpus_rows_tests.rs | THE 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.rs | The 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.rs | The §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.rs | signature_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.rs | Per-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.
signature_discovery, never through its own walker over
SemanticNodeData::Signature.VerterStableV1 order. A consumer that sorts arms itself is a defect.ReduceUnion / ReduceIntersection. A thin adapter may remain only when it
makes no semantic decision.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.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.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
Just SKILL.md in .claude/skills/signature-kernel of pikax/verter.
Open the folder on GitHubat commit 858624d
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Signature Kernel this skillpikax/verter | 113 | — | ~5k | Automated safety check: Pass | MIT | |
| Semantic Kernelgithub/awesome-copilot | 40k | 1 repos | ~756 | Automated safety check: Pass | MIT | |
| Recordingcodewhale-hq/Codewhale | 41k | — | ~540 | Automated safety check: Pass | MIT | |
| Semantic Kernelmanagedcode/dotnet-skills | 486 | — | ~2.8k | Automated safety check: Pass | MIT | |
| Kernel Organizationsgl-project/sglang | 37k | — | ~1.3k | Automated safety check: Pass | Apache-2.0 | |
| Architecture Decision Recordsaffaan-m/ECC | 276k | 4 repos | ~1.8k | Automated safety check: Pass | MIT |
github/awesome-copilot
Create, update, refactor, explain, or review Semantic Kernel solutions using shared guidance plus language-specific references for .NET and Python.
codewhale-hq/Codewhale
Capture screenshots on registered computers, record on macOS or HarmonyOS, and manage saved captures.
managedcode/dotnet-skills
Build AI-enabled .NET applications with Semantic Kernel using services, plugins, prompts, and function-calling patterns that remain testable and maintainable.
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.
affaan-m/ECC
Capture architectural decisions as numbered ADR markdown files in docs/adr/ with context, alternatives considered, consequences, and an index README.
affaan-m/ECC
在Claude Code会话期间,将做出的架构决策捕获为结构化的架构决策记录(ADR)。自动检测决策时刻,记录上下文、考虑的替代方案和理由。维护一个ADR日志,以便未来的开发人员理解代码库为何以当前方式构建。
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.
pikax/verter
Generate copy-pasteable prompts for driving separate Claude Code sessions through refactor, review, or migration work.
pikax/verter
Build dependency chains, rebuild sequences, profiling with MCP, and Analysis MCP server setup for Verter
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
pikax/verter
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"…
pikax/verter
Rust performance optimization patterns: batch operations, allocation hierarchy, object pooling, CodeTransform API for vertercompiler
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.
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.
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.
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.
SKILL.md names no scripts, command-line tools or credentials: Signature Kernel is instructions for the agent only.
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.
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.
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.
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.
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.
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.