nyxfoundation
- 8 skills
- 0 followers
- 10 hours ago last updated
- ▌
- ▌ Subgraph Extractor · nyxfoundationExtract program graphs from a single specification document following Nielson & Nielson's formal definition.
- ▌ Hive · nyxfoundationGround every "build / run the hive E2E test harness" question in hive — the Ethereum end-to-end test harness that runs Dockerized clients against simulator test suites (github.com/ethereum/hive), always read from the latest remote master. It is operational tooling (Go core + Rust hivesim-rs), not a spec or library; the source of truth for HOW to run it is the upstream README + docs/commandline.md + simulator READMEs at master, which evolve. Especially relevant to Verity via the simulators/lean suite and the lean clients in clients/. Use before building, running, or answering anything about running hive (especially the lean simulator) for Verity. Triggers: "hive", "ethereum/hive", "hivesim", "hive simulator", "hive sim", "--sim lean", "simulators/lean", "lean simulator", "client interop", "E2E test", "結合テスト", "互換性テスト", and any work building or running the hive test harness (especially the lean simulator) for Verity. Negative triggers: Do NOT activate for spinning up a local devnet to RUN it rather than test it
- ▌ Leanvm · nyxfoundationGround every question about post-quantum signature aggregation and the zkVM in leanVM — the authoritative spec and Rust reference implementation (github.com/leanEthereum/leanVM), always read from the latest remote main. Verity's verity-crypto crate depends on it directly. Use before implementing, reviewing, or answering anything about XMSS aggregation, Type-1/Type-2 proofs, the prover/verifier, the zkVM, the zkDSL, or WHIR. Triggers: "leanVM", "lean_vm", "leanVMを確認", "leanMultisig", "lean_multisig" (the repo's former name — old references still mean this skill), "署名集約", "aggregation", "Type-1 proof", "Type-2 proof", "zkVM", "zkDSL", "WHIR", "prover", "verifier", "verity-crypto", and any work touching signature aggregation or proof generation in Verity. Negative triggers: Do NOT activate for consensus container shapes / fork choice / state transition (use the leanSpec skill). Do NOT activate for pure docs-site work. Do NOT activate when working outside the Verity project.
- ▌ Leanspec · nyxfoundationGround every Verity spec question in leanSpec — the single authoritative specification (Python reference implementation), always read from the latest origin/main (lstar HEAD). Use before implementing, reviewing, or answering anything about Verity's protocol behavior, container shapes, constants, fork choice, state transition, signatures, or test vectors. Maps a topic to the authoritative leanSpec path for any protocol element. Triggers: "leanSpec", "leanSpecを確認", "仕様を確認", "Verityの仕様", "prime", "verity context", "where is the spec for", "container shape", "コンテナの形", "3SF", "fork choice", "state transition", "XMSS", "leanVM", "devnet spec", and starting any Verity implementation or review work. Negative triggers: Do NOT activate for pure docs-site work (mdBook page authoring or build/serve). Do NOT activate when working outside the Verity project.
- ▌ Leanmetrics · nyxfoundationGround every observability/metrics question in leanMetrics — the authoritative standard for Prometheus-compatible metrics across Lean Ethereum consensus clients (github.com/leanEthereum/leanMetrics), always read from the latest remote main. leanMetrics fixes the metric name strings, Prometheus types, Histogram buckets, label names/enum values, and collection events that every compliant client must match; Verity's verity-metrics crate implements it. Use before implementing, reviewing, or answering anything about exposing or monitoring consensus-client metrics. Triggers: "leanMetrics", "lean_metrics", "leanMetricsを確認", "メトリクス", "metrics", "prometheus", "grafana", "observability", "観測", "dashboard", "verity-metrics", any "lean_*" metric name (e.g. "lean_head_slot", "lean_block_aggregated_payloads"), and any work exposing or monitoring consensus-client metrics in Verity. Negative triggers: Do NOT activate for consensus container shapes / fork choice / state transition behavior (use the leanSpec skill). Do NOT act
- ▌ Leanquickstart · nyxfoundationGround every "spin up / run a local lean multi-client devnet" question in lean-quickstart — the utility for bootstrapping a localnet of Lean Ethereum multi-client nodes (github.com/blockblaz/lean-quickstart), always read from the latest remote main. It is operational tooling (Shell + Python + Ansible + Docker), not a spec or library; the source of truth for HOW to run it is the upstream README + scripts at main, which evolve. Use before running, configuring, or answering anything about starting a local Lean devnet for Verity. Triggers: "leanQuickstart", "lean-quickstart", "lean_quickstart", "localnet", "devnet", "ローカルネット", "デブネット", "spin-node", "spin-node.sh", "validator-config.yaml", "generate-genesis", "multi-client devnet", "マルチクライアント", and any work spinning up or running a local lean multi-client devnet for Verity. Negative triggers: Do NOT activate for consensus container shapes / fork choice / state transition (use the leanSpec skill). Do NOT activate for aggregation / zkVM / proof internals (use the le
- ▌ Docs2formalspec · nyxfoundationGenerate an RFC 2119-conformant specification document and a compiling Lean 4 formalization from documentation URLs or file paths.