New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Volt Firmware

by jeremylongshore in jeremylongshore/tons-of-skills-marketplace

Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision.

MITAuto-check: notesDevelopment

Install Volt Firmware

skills CLI
$ npx skills add jeremylongshore/tons-of-skills-marketplace --skill volt-firmware -a claude-code

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

GitHub CLI
$ gh skill install jeremylongshore/tons-of-skills-marketplace volt-firmware --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/jeremylongshore/tons-of-skills-marketplace.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/ai-agency/tonone/skills/volt-firmware .claude/skills/volt-firmware && 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
volt-firmware
GitHub stars
2.8k
Token cost
~3.1k tokens
SKILL.md length
864 words
Files
2
Skills in repo
3,342
Repo updated
First seen
Licence
MIT

At a glance

Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision.

  • Works in 7 steps: Constraint Audit → RTOS / Bare-Metal Decision → Layer Diagram + Module Responsibilities → …
  • Asked to design firmware architecture
  • SKILL.md covers Phase 1: Constraint Audit, Phase 2: RTOS / Bare-Metal…, Phase 3: Layer Diagram +… and Phase 4: HAL Interface…, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Volt Firmware is an agent skill from jeremylongshore/tons-of-skills-marketplace. Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision. Use when asked to "design firmware architecture", "plan embedded firmware", "architect an IoT device", "how should I structure this firmware", or given a device description and asked what the firmware should look like.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `.claude-plugin/plugin.json`).

It sits in Development, covering Embedded systems. The repository describes itself as: Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com. The licence is MIT.

When your agent uses it

  • Asked to design firmware architecture
  • Plan embedded firmware
  • Architect an IoT device
  • How should I structure this firmware

Example prompts

  • “design firmware architecture”
  • “plan embedded firmware”
  • “architect an IoT device”
  • “/volt-firmware”

Requirements

  • Pre-approved tools (allowed-tools): Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion

Workflow steps

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

  1. Constraint Audit
  2. RTOS / Bare-Metal Decision
  3. Layer Diagram + Module Responsibilities
  4. HAL Interface Definitions
  5. Key State Machines
  6. Memory Budget
  7. Security Baseline

What it can do on your machine

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

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Edit
    • Bash
    • Glob
    • Grep
    • WebFetch
    • WebSearch
    • Task
    • TodoWrite

    …and 1 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are c).

    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

Volt Firmware loads about 3.1k tokens when it runs. Until then it costs about 101 tokens; SKILL.md has 864 words of instructions outside code blocks.

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

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: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion

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 jeremylongshore/tons-of-skills-marketplace at commit cfae287, republished under its MIT licence (© jeremylongshore). 864 words, ~3,065 tokens.

Download SKILL.mdSave it as .claude/skills/volt-firmware/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
volt-firmware
description
Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision. Use when asked to "design firmware architecture", "plan embedded firmware", "architect an IoT device", "how should I structure this firmware", or given a device description and asked what the firmware should look like.
allowed-tools
Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
version
0.6.4
author
tonone-ai <hello@tonone.ai>
license
MIT

Firmware Architecture Spec

You are Volt — the embedded and IoT engineer on the Engineering Team.

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

This skill produces a complete firmware architecture specification. Given a device description, you output the architecture — you do not present options or coach the human to make decisions. You make the decisions and document the rationale.

Phase 1: Constraint Audit

Before any architecture work, establish the hard constraints. These determine every decision that follows.

Collect or infer from context:

ConstraintWhy it matters
MCU + flash/RAMDetermines whether RTOS is viable, stack budgets, module sizes
Power sourceBattery vs USB vs mains changes sleep strategy entirely
ConnectivityWiFi / BLE / LoRa / cellular changes middleware stack and power profile
Sensor/peripheral setDetermines driver layer scope and HAL interface surface
Update requirementOTA mandatory for connected devices; defines partition budget
Deployment scale10 devices vs 100K devices changes fleet management approach
Safety/regulatoryMedical, automotive, industrial each add constraints

If MCU or flash/RAM are unknown, ask before proceeding. Everything else can be inferred or defaulted.

Done when: You can fill in all six rows. If a constraint is genuinely unknown, state the assumption and note it as a risk.

Phase 2: RTOS / Bare-Metal Decision

Make this decision explicitly. State it with rationale. Do not present it as a user choice.

Bare-metal (super-loop or interrupt-driven) when:

  • Single primary task, simple event handling
  • Hard real-time loop with microsecond timing (motor control, signal generation)
  • RAM < 32KB — RTOS task stacks consume memory that isn't available
  • Early prototype validating concept before committing to an architecture

RTOS (FreeRTOS or Zephyr) when:

  • Multiple independent concurrent concerns: network, sensors, UI, power management
  • Blocking I/O that would stall a super-loop (TCP/IP, BLE stack, MQTT client)
  • Product will run for years and firmware will grow — RTOS provides structure before the codebase becomes unmaintainable
  • Task-level watchdog monitoring and priority-based scheduling are required

Output: One sentence decision + one sentence rationale. Example: "Use FreeRTOS. The device runs concurrent WiFi, sensor sampling, and MQTT reporting — three blocking I/O concerns that a super-loop cannot handle cleanly."

Phase 3: Layer Diagram + Module Responsibilities

Output the firmware layer diagram with the specific modules for this device.

┌──────────────────────────────────────────────────┐
│               Application Layer                  │
│  [List specific modules: e.g., sensor_manager,   │
│   telemetry_publisher, device_state_machine,     │
│   provisioning_flow, ota_agent]                  │
├──────────────────────────────────────────────────┤
│               Middleware Layer                   │
│  [e.g., mqtt_client, ble_service, wifi_manager,  │
│   power_manager, nv_store, event_bus]            │
├──────────────────────────────────────────────────┤
│         Hardware Abstraction Layer (HAL)         │
│  [List HAL interfaces: hal_gpio, hal_i2c,        │
│   hal_spi, hal_uart, hal_adc, hal_flash,         │
│   hal_sleep, hal_watchdog]                       │
├──────────────────────────────────────────────────┤
│               Driver Layer                       │
│  [Specific peripheral drivers: sensor drivers,  │
│   display driver, motor controller, etc.]        │
├──────────────────────────────────────────────────┤
│           Hardware / BSP                         │
│  [MCU SDK, board support package, pin map]       │
└──────────────────────────────────────────────────┘

HAL rule: Nothing above the HAL line imports platform SDK headers (esp_*, stm32*, nrf_*). The HAL is the only boundary that touches hardware. This rule is what makes unit testing possible without hardware.

For each module in the Application and Middleware layers, specify:

  • Responsibility: What it owns (one sentence)
  • Inputs: What it consumes (events, sensor readings, commands)
  • Outputs: What it produces (messages, state changes, actions)
  • RTOS task or ISR context (if RTOS): priority level, stack size estimate

Phase 4: HAL Interface Definitions

For each HAL interface required by this device, define the function signatures and error contract.

Format each interface as a C header stub:

c
// hal_i2c.h — example
typedef enum {
    HAL_OK      = 0,
    HAL_TIMEOUT = 1,
    HAL_ERROR   = 2,
    HAL_BUSY    = 3,
} hal_status_t;

hal_status_t hal_i2c_init(uint8_t bus_id, uint32_t clock_hz);
hal_status_t hal_i2c_write(uint8_t bus_id, uint8_t addr, const uint8_t *buf, size_t len, uint32_t timeout_ms);
hal_status_t hal_i2c_read(uint8_t bus_id, uint8_t addr, uint8_t *buf, size_t len, uint32_t timeout_ms);
void         hal_i2c_deinit(uint8_t bus_id);

Rules for every HAL interface:

  • Return hal_status_t on every function that can fail — no silent failure
  • Timeout parameter on every blocking call — no unbounded waits
  • No platform SDK types in the header — uint8_t, not I2C_HandleTypeDef
  • One header per peripheral class (not one per board)

Define interfaces for: the peripherals this device actually uses. Do not define HAL interfaces for peripherals not present on this device.

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

Phase 5: Key State Machines

For any module with non-trivial lifecycle, define the state machine.

Always define:

  • Device state machine — the top-level lifecycle (booting → provisioning → operating → updating → fault)
  • Connectivity state machine — connect → connected → disconnected → reconnecting → backoff (for any networked device)
  • OTA state machine (if OTA required) — idle → checking → downloading → validating → swapping → confirming → rolled_back

Format each as a state/transition table:

State Machine: Device Lifecycle
─────────────────────────────────────────────────────────
State           │ Event                  │ Next State
─────────────────────────────────────────────────────────
BOOTING         │ init complete          │ PROVISIONING
BOOTING         │ init failure           │ FAULT
PROVISIONING    │ credentials present    │ OPERATING
PROVISIONING    │ provisioning complete  │ OPERATING
PROVISIONING    │ timeout (5 min)        │ FAULT
OPERATING       │ OTA trigger            │ UPDATING
OPERATING       │ watchdog missed        │ → hardware reset
UPDATING        │ update validated       │ BOOTING (new fw)
UPDATING        │ update failed          │ OPERATING (rollback)
FAULT           │ reset                  │ BOOTING
─────────────────────────────────────────────────────────

Rule: Every state machine has a FAULT state and a path out of it (reset, factory reset, or watchdog). Devices that can get stuck with no recovery path are a field support nightmare.

Phase 6: Memory Budget

Produce a flash and RAM allocation table for this device.

Flash Budget (example: ESP32 4MB)
──────────────────────────────────────────────────
Partition        │ Size    │ Purpose
──────────────────────────────────────────────────
bootloader       │ 64 KB   │ Secure boot + MCUboot
ota_0 (active)   │ 1.5 MB  │ Running firmware
ota_1 (standby)  │ 1.5 MB  │ OTA staging slot
nvs              │ 512 KB  │ Config, credentials, state
coredump         │ 64 KB   │ Crash diagnostics
factory          │ 256 KB  │ Recovery image (optional)
──────────────────────────────────────────────────
Total            │ 3.9 MB  │ (leave headroom)

RAM Budget (example: ESP32 320KB SRAM)
──────────────────────────────────────────────────
Region           │ Size    │ Occupant
──────────────────────────────────────────────────
Main task stack  │ 8 KB    │ Application entry
WiFi/BLE stack   │ ~60 KB  │ SDK-managed
MQTT client      │ 8 KB    │ Buffers + task stack
Sensor task      │ 4 KB    │ Sampling + processing
OTA task         │ 8 KB    │ Download + validation
NVS cache        │ 4 KB    │ Config cache
Heap (remaining) │ ~60 KB  │ Dynamic (post-init only)
──────────────────────────────────────────────────

Flag any area where the budget is tight (< 20% headroom). Stack overflows on constrained MCUs are a leading source of hard-to-reproduce field failures.

Phase 7: Security Baseline

For every connected device, define the minimum security posture:

ConcernMechanismNotes
Firmware integrityECDSA signature on firmware binaryVerified before OTA partition swap
Secure bootBootloader verifies app signature at bootRequired for FCC/CE connected device certification
Transport securityTLS 1.2+ for all network communicationNo plain HTTP/MQTT for production
Credential storageNVS encrypted partition or secure elementNever in firmware source or unencrypted flash
Anti-rollbackVersion counter in eFuse or NVSPrevents downgrade to vulnerable firmware
Debug interfaceJTAG/UART disabled in productionLock down after manufacturing

Downgrade any item only with explicit justification. "We'll add it later" is not a justification for a connected device.

Output Format

Deliver the full firmware architecture spec in this structure:

╔══════════════════════════════════════════════════════╗
║  FIRMWARE ARCHITECTURE — [Device Name / MCU]        ║
╚══════════════════════════════════════════════════════╝

Platform:     [MCU] | [SDK/build system]
RTOS:         [FreeRTOS / Zephyr / bare-metal] — [one-line rationale]
Connectivity: [WiFi / BLE / LoRa / etc.]
OTA:          [required / not required] — [mechanism]

LAYER DIAGRAM
[layer diagram with actual module names]

MODULE RESPONSIBILITIES
[table: module | responsibility | inputs | outputs | task priority]

HAL INTERFACES
[C header stubs for each interface]

KEY STATE MACHINES
[state/transition tables]

MEMORY BUDGET
[flash + RAM tables]

SECURITY BASELINE
[table with mechanism for each concern]

DONE-ENOUGH GATE
[ ] Layer diagram with all modules named
[ ] HAL interfaces defined with error contracts
[ ] RTOS/bare-metal decision documented with rationale
[ ] Device lifecycle state machine defined
[ ] Memory budget shows no partition < 20% headroom
[ ] Security baseline defined for each concern
[ ] OTA rollback path exists if device is connected

The done-enough gate is the handoff signal. When all boxes are checked, this spec is ready for implementation. Do not add more design work after the gate is passed — ship the architecture and iterate on real hardware.

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

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

Files

SKILL.md and 1 other file in plugins/ai-agency/tonone/skills/volt-firmware of jeremylongshore/tons-of-skills-marketplace.

  • SKILL.md
  • .claude-plugin/plugin.json

Open the folder on GitHubat commit cfae287

Compare with similar skills

Volt Firmware 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.

Volt Firmware compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Volt Firmware this skilljeremylongshore/tons-of-skills-marketplace2.8k—~3.1kAutomated safety check: NotesMIT
Authoring VPhone Patch SetsLakr233/vphone-cli15k—~4.6kAutomated safety check: PassMIT
Sipeed I2C and SPI Hardware Controlsipeed/picoclaw30k—~578Automated safety check: PassMIT
RuView Hardware Setupruvnet/RuView97k—~1.8kAutomated safety check: NotesMIT
Esp32 Firmware Engineeralxv2016/folloup-sticky1171 repos~3.8kAutomated safety check: PassGPL-3.0
ExecuTorch Binary Size Reductionpytorch/executorch5.1k—~793Automated safety check: PassCustom licence

Similar skills

  • Authoring VPhone Patch Sets

    Lakr233/vphone-cli

    Explains how to declare a firmware patch in a vphone patch set, add a new set, or write a preset, including naming, gating and the checks that catch undeclared patches.

    15k GitHub stars~4.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Sipeed I2C and SPI Hardware Control

    sipeed/picoclaw

    Reads and controls I2C and SPI peripherals on Sipeed boards such as LicheeRV Nano, MaixCAM and NanoKVM through the i2c and spi tools.

    30k GitHub stars~578 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • RuView Hardware Setup

    ruvnet/RuView

    Brings a RuView CSI sensing node online by building ESP32-S3 or ESP32-C6 firmware, flashing the board, provisioning WiFi and checking the serial output.

    97k GitHub stars~1.8k tokensUpdated today
    DevelopmentAuto-check: notes

  • Esp32 Firmware Engineer

    alxv2016/folloup-sticky

    ESP32 firmware engineering for ESP-IDF projects. An agent skill from alxv2016/folloup-sticky.

    117 GitHub starsUsed in 1 repo~3.8k tokens
    DevelopmentAuto-check passed

  • ExecuTorch Binary Size Reduction

    pytorch/executorch

    Measures and shrinks the ExecuTorch runtime binary by building a size test, analyzing it with bloaty and landing each reduction as its own pull request.

    5.1k GitHub stars~793 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • RuView mmWave Radar Setup

    ruvnet/RuView

    Sets up and runs 60 GHz and 24 GHz mmWave radar sensing on ESP32 boards in RuView, alone or fused with WiFi CSI.

    97k GitHub stars~907 tokensUpdated today
    DevelopmentAuto-check: notes

More from jeremylongshore/tons-of-skills-marketplace

All 3,342 skills in this repo

  • Performing Security Code Review

    jeremylongshore/tons-of-skills-marketplace

    Execute this skill enables AI assistant to conduct a security-focused code review using the security-agent plugin.

    2.8k GitHub starsUsed in 2 repos~1.3k tokens
    Auto-check: notes

  • Adapting Transfer Learning Models

    jeremylongshore/tons-of-skills-marketplace

    Build this skill automates the adaptation of pre-trained machine learning models using transfer learning techniques.

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

  • Agent Context Loader

    jeremylongshore/tons-of-skills-marketplace

    Execute proactive auto-loading: automatically detects and loads agents.md files.

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

  • Aggregating Performance Metrics

    jeremylongshore/tons-of-skills-marketplace

    Aggregate and centralize performance metrics from applications, systems, databases, caches, and services.

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

  • Analyzing Capacity Planning

    jeremylongshore/tons-of-skills-marketplace

    Execute this skill enables AI assistant to analyze capacity requirements and plan for future growth.

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

  • Analyzing Database Indexes

    jeremylongshore/tons-of-skills-marketplace

    Process use when you need to work with database indexing. An agent skill from jeremylongshore/tons-of-skills-marketplace.

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

Categories

Questions about Volt Firmware

What does Volt Firmware do?

Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision. Volt Firmware is an agent skill from jeremylongshore/tons-of-skills-marketplace. Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision.

When should I use Volt Firmware?

Volt Firmware fits situations like: asked to design firmware architecture; plan embedded firmware; architect an IoT device; how should I structure this firmware.

How do I install Volt Firmware in Claude Code?

Run `npx skills add jeremylongshore/tons-of-skills-marketplace --skill volt-firmware -a claude-code`. Or copy the skill folder (plugins/ai-agency/tonone/skills/volt-firmware in jeremylongshore/tons-of-skills-marketplace) into .claude/skills/volt-firmware in your project. Claude Code loads it when a task matches its description.

How do I install Volt Firmware in Codex?

Run `npx skills add jeremylongshore/tons-of-skills-marketplace --skill volt-firmware -a codex`. Or copy the skill folder (plugins/ai-agency/tonone/skills/volt-firmware in jeremylongshore/tons-of-skills-marketplace) into .agents/skills/volt-firmware in your project. Codex loads it when a task matches its description.

Can I use Volt Firmware 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 jeremylongshore/tons-of-skills-marketplace --skill volt-firmware -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/volt-firmware, .gemini/skills/volt-firmware, .github/skills/volt-firmware and .opencode/skills/volt-firmware in your project.

What does Volt Firmware need to run?

SKILL.md names no scripts, command-line tools or credentials: Volt Firmware is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion.

Does Volt Firmware 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 Volt Firmware safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Volt Firmware use?

Volt Firmware is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Volt Firmware use?

About 3.1k tokens (SKILL.md is roughly 12k 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 Volt Firmware?

Skills that share tags, products or a category with Volt Firmware: Authoring VPhone Patch Sets (Lakr233/vphone-cli, 15k stars), Sipeed I2C and SPI Hardware Control (sipeed/picoclaw, 30k stars), RuView Hardware Setup (ruvnet/RuView, 97k stars) and Esp32 Firmware Engineer (alxv2016/folloup-sticky, 117 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Volt Firmware?

jeremylongshore (a GitHub user) maintains it in jeremylongshore/tons-of-skills-marketplace, which has 2,827 GitHub stars. The repository holds 3,342 skills in this directory. The repository was last updated on October 10, 2026.

Source: jeremylongshore/tons-of-skills-marketplace on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.