← all publishers

using-system

@using-system source repo

Report this profile Claim this profile

• 10 skills
• 0 followers
• 8 hours ago last updated

1. ▌
   K6 Guides · using-system bundle

   Curated map of the official k6 load-testing docs - installation, running a script, scripting (checks/thresholds/scenarios), test types, protocols, and which questions a benchmark's inputs require before it can be authored. Use when authoring or reasoning about a k6 benchmark - pick the topic, open its reference file, and follow the linked official docs. Read by /odd-instrument-bench (which questions to ask), k6-benchmark-expert (authoring and validating), a stored benchmark's replay (running one), and the /odd-instrument-bench, /odd-observe, and /odd-verify preflights (ensuring k6 is present).
   0
   installs
2. ▌
   Get Status · using-system bundle

   Render the state of the ODD loop from the repository's committed .odd/ history and git alone - one screen by default (the loop state per lineage with its burn-down and next action), the full tables on request (per-service loop state, findings ledger, trends, open telemetry gaps) - read-only, no backend queries, no report written. Use when answering where the loop is, when /odd-status runs, or when a status must be computed offline from the clone.
   0
   installs
3. ▌
   Odd Memory · using-system bundle

   The .odd/ memory - its contract and one reference per kind. The contract states what every kind shares (where the memory lives, the frontmatter and the whole body, append-only reports versus living-source benchmarks, recall by frontmatter then by section, the no-secrets rule, the work branch and the lone commit, the reply that carries a synthesis and never the artifact); each reference says how to persist, recall and show its kind - observation reports, instrumentation reports, benchmarks, the maintainer-ruling ledgers (finding decisions, tree-entry classifications), custom stack files. Read when a report, a benchmark, a custom stack file or a decision is persisted, recalled, shown or inventoried, or when a finding is declined (wontfix) or such a decision reversed, or a tree entry is ruled runtime or non-runtime; never invoked on its own.
   0
   installs
4. ▌
   Otel Guides · using-system bundle

   Curated map of the official OpenTelemetry documentation by language. Use when planning or implementing OpenTelemetry instrumentation for a codebase - pick the language, open its reference file, and follow the linked official docs for traces, metrics, logs, instrumentation libraries, exporters, and SDK configuration. Covers C++, .NET, Erlang/Elixir, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Swift, and other community SDKs, plus the cross-language references for SDK configuration, semantic conventions, generative AI (the gen_ai conventions and the instrumentation library per LLM SDK or agent framework), the Collector, and profiling.
   0
   installs
5. ▌
   Run Scenario · using-system bundle

   Drive a reproducible request scenario against a locally running service - ad-hoc requests, or a stored k6 benchmark from .odd/benchmarks/ - and record it verbatim, so the telemetry it produces can be compared with a later run. Use when traffic must be generated before observing a service, when a stored k6 benchmark must be run, when an observation report needs a replayable scenario, or when verifying after a fix that the same scenario now measures better.
   0
   installs
6. ▌
   Package Layout · using-system bundle

   Where this package is installed and what each part of it is - every skill, its reference files, its scripts, and the sibling directories the install carries. Use when a mission block needs the skills' directory, when a contract must name a reference or a script by path, or when anything is about to look for the package on disk. The answer comes from the script's own location, so it is exact wherever a host installed the package, and nothing has to be searched for or written down in advance.
   0
   installs
7. ▌
   Setup Local Stack · using-system bundle

   Configure gcx against the local oddyssey Grafana stack and query its four signals (metrics, traces, logs, profiles) without touching the user's own gcx contexts. Owns the global configuration's "local" stack value. Use when the configured stack is "local", when querying the local stack (Grafana host port from the global configuration, default 3000), when configuring gcx locally, when a command needs the Tempo, Prometheus, Loki, or Pyroscope datasource UID. gcx is the mandatory query CLI for the stack - install it if missing (brew install gcx, or the official install script from github.com/grafana/gcx).
   0
   installs
8. ▌
   Backend Configuration · using-system bundle

   Own the configured observability backend, in two sections invoked by name. Check: display the configured stack and the instance the runs will hit, prove the CLI connected, guide the user when it is not, and hand the preflight over to the mission. Switch: verify the target backend's CLI is installed (offer a guided install when missing), persist the switch via odd_config_set, persist the per-stack stack_config values the missions will need, then run Check for the proof. Stack-agnostic - the stack list and everything about a given stack come from the observability-cli-guides skill. Use before dispatching an observe, verify or bench mission, when the configured stack must be confirmed or the CLI's connection proven, when the user needs guidance to set their CLI up, and when the user asks to change the configured backend or to persist targeting values. Never installs silently, never authenticates on the user's behalf, never stores or echoes a secret.
   0
   installs
9. ▌
   Observability CLI Guides · using-system bundle

   The package's knowledge of every observability stack it supports, one reference file per stack - the terminal query surface (how to authenticate and query metrics, traces, logs, and profiles from the CLI), how the stack's configuration is displayed and proven, and what its stack_config persists - plus the list of built-in stacks. Use when observing a run, local or remote, and when backend-configuration's Check or Switch need anything about a stack - Grafana (gcx), Datadog (Pup CLI), Dynatrace (dtctl and DQL), Azure Monitor (az), AWS CloudWatch and X-Ray (aws), and the local stack.
   0
   installs
10. ▌
    Test Plugin Harnessing · using-system bundle

    Measure and optimise one phase of an oddyssey run - preflight, drive, observation - against the published benchmark row for that model. Use when a phase is too slow or too expensive, when a harnessing change must be proven rather than asserted, or when a run is suspected of composing work the package should ship. Drives opencode headless, measures the phase, names where the time went, and separates what the package controls from provider latency. Never a substitute for launch-llms-benchmark, which grades findings; this grades the harness.
    0
    installs