agentsclimarketplace

Ascii memory map

Skill rohingosling/claude-skills/plugins/g-render-ascii-memory-map/skills/ascii-memory-map

Claude Code plugin marketplace. Curated collection of publicly-shared agent skills.

Install
npx -y skills add rohingosling/claude-skills --skill ascii-memory-map

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Render an ASCII box-drawing memory map (an address-space layout diagram) from a JSON description. Use whenever a response needs a memory map, memory layout, address map, or address-space diagram for ANY architecture (Commodore VIC-20/C64, x86 real-mode/segmented, ARM/MCU flash+SRAM, flat 32/64-bit, etc.). Separates the map's DATA from its RENDERING and offloads all box drawing, column alignment, address formatting, and size-proportional block heights to a deterministic Python renderer, so the model only authors compact JSON.

SKILL.md

7.6 KB, as published. Nobody here has run it

Render an ASCII memory map using the Python script at ${CLAUDE_SKILL_DIR}/scripts/render_ascii_memory_map.py.

Author the map as JSON (the data), choose presentation flags (the rendering), run the script, and paste its output into a fenced code block. Let the script do all box drawing, alignment, address formatting, and height scaling — do not hand-draw memory maps.

Positioning rules (the text-placement taxonomy)

Every piece of text has exactly one home, decided by what it refers to:

ClassWhat it isWhere it goes
AddressA hex/decimal boundary coordinateLeft gutter, on the divider that opens the block (its low-address edge)
LabelThe block's short nameInside the box, first body row
DescriptionOptional elaboration (extent, contents)Inside the box, further body rows
Comment / noteExtrinsic annotation — register writes, bit patterns, caveats, consequencesRight of the box, anchored to the first body row with an arrow; continuations align beneath, no arrow

Decisive test: text that names or describes the contents of a span is intrinsic → goes inside (label/description); text that says something about the span (a value, a constraint, a cross-reference) is extrinsic → goes outside (comment). A bare boundary coordinate goes in the gutter. Divider and border lines carry only the address — never a label or a comment. The renderer enforces all of this.

Instructions

  1. Construct a JSON object describing the memory map (schema below). Store addresses as numeric/hex strings — the renderer formats them for display, so the same data can be shown as $0400, 0x0400, 0400h, 0040:0000, or 01024 by changing one flag.

  2. Write the JSON to a temporary file in the current project's working directory (e.g. memmap.json).

  3. Run the renderer (use python3 on macOS/Linux, python on Windows):

    python3 "${CLAUDE_SKILL_DIR}/scripts/render_ascii_memory_map.py" memmap.json [flags]
    

    Defaults can also be set inside the JSON in a "render": { ... } object; CLI flags override the JSON, which overrides the built-in defaults.

  4. Copy the output into the target markdown inside a fenced code block.

  5. Delete the temporary JSON file.

JSON schema

Top-level keys:

KeyTypeMeaning
titlestringOptional heading printed above the map
renderobjectOptional default values for any flag below (underscore_case keys, e.g. "address_format": "c")
blocksarrayThe memory regions (required)

Each block:

FieldTypeMeaning
startint or stringStart address (required). Strings accept $XXXX, 0xXXXX, XXXXh, SSSS:OOOO, or a bare numeral (hex by default)
endint or stringInclusive end address (last byte). Optional — if omitted, inferred from the next block's start
sizeint or stringAlternative to end; accepts 2K, 0x800, 4096, 64KB
labelstringThe region name (inside the box)
descriptionstring or arrayExtra inside-the-box line(s)
commentsstring or arrayOutside-the-box note(s); the first is arrow-anchored, the rest align beneath
rowsintForce this block's body height (overrides scaling)

Parameters

FlagDefaultPurpose
--address-formatcommodorecommodore ($0400), c (0x0400), intel (0400h), plain (0400), segmented (0040:0000), decimal, decimal-padded
--address-widthautoDigit count (4 = 16-bit, 8 = 32-bit…); auto-sized from the largest address if omitted
--input-radixhexHow to read bare numeric strings in the JSON (hex / decimal); integers are always decimal
--hex-caseupperupper / lower hex digits
--origintoptop = low address at top (addresses increase downward); bottom = low address at bottom
--scaleonon / off — size-proportional block heights
--scale-modeloglog / linear / sqrt taper
--min-rows / --max-rows1 / 6Clamp for scaled block heights
--styleunicodeunicode / heavy / double / ascii (`+ -
--widthautoInterior box width: auto (longest label) or an integer
--comment-arrow◄─Outside-note connector (<- in ascii style)
--no-commentsoffSuppress all outside notes
--show-sizeoffAppend each region's computed size inside its box
--show-endoffShow the end address on the closing boundary
--show-gapsoffDraw unmapped ranges between blocks as their own gap blocks
--gap-label· · ·Label used for auto-generated gap blocks
--paragraph16Bytes per segment for segmented addresses
--titleOverride the JSON title

Height scaling

With --scale on (default), a block's body height is max( rows_needed_for_text, clamp( round(min_rows + f(size)·(max_rows−min_rows)), min_rows, max_rows ) ), where f is a log/linear/sqrt normalisation of the block's size between the smallest and largest sized blocks. The log taper means one very large region is only a few rows taller than its neighbours — a visual cue to relative size, not a to-scale drawing. Tiny blocks stay readable at min_rows; text always fits regardless of scaling. Sizes are taken from end/size, or inferred from the next block's start.

Example

JSON (memmap.json):

{
  "title": "C64 — VIC bank 0 ($0000-$3FFF)",
  "blocks": [
    { "start": "$0000", "end": "$03FF", "label": "zero page / stack / system",
      "comments": ["$0001 CHAREN: bit 2 = 0 → char ROM at $D000"] },
    { "start": "$0400", "end": "$07FF", "label": "screen RAM (video matrix)",
      "comments": ["matrix base; $D018 bits 4-7 = %0001"] },
    { "start": "$3800", "end": "$3FFF", "label": "Westminster charset (2 KB)",
      "description": ["ROM copy + overlaid glyphs"],
      "comments": ["char base; $D018 bits 1-3 = %111 → $D018 = $1E"] }
  ]
}

Command:

python3 "${CLAUDE_SKILL_DIR}/scripts/render_ascii_memory_map.py" memmap.json --scale off

Output:

C64 — VIC bank 0 ($0000-$3FFF)

 $0000  ┌────────────────────────────┐
        │ zero page / stack / system │ ◄─ $0001 CHAREN: bit 2 = 0 → char ROM at $D000
 $0400  ├────────────────────────────┤
        │ screen RAM (video matrix)  │ ◄─ matrix base; $D018 bits 4-7 = %0001
 $3800  ├────────────────────────────┤
        │ Westminster charset (2 KB) │ ◄─ char base; $D018 bits 1-3 = %111 → $D018 = $1E
        │ ROM copy + overlaid glyphs │
        └────────────────────────────┘

A ready-to-run example is bundled at ${CLAUDE_SKILL_DIR}/examples/c64-bank0.json.

User argument

$ARGUMENTS

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.