[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73F7AVQK3RB8FNHSRE5MK7V":3,"skill-same:01M73F7AVQK3RB8FNHSRE5MK7V":51},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M73F7AVQK3RB8FNHSRE5MK7V","processor-design-from-scratch",null,"Use when designing and simulating a simple CPU\u002Fprocessor from first principles — instruction set design, fetch-decode-execute cycle, a minimal assembler. Not for general low-level programming or existing CPU architecture study. Triggers on: 'design a CPU from scratch', 'build a simple processor', 'implement an instruction set', 'fetch decode execute cycle', 'write a toy CPU simulator', 'build my own assembler'. Covers ISA design, the FDE cycle, register\u002FALU design, and software-simulated vs HDL implementation.","Horonomos-laps\u002FYana-AI","Horonomos-laps","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F355299122?v=4","01M76B3QPXE88ET2SQPDPVATZT"," Horonomos-laps","01M72ZQRJPCYPSSWT4D00VJR2A",13,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fprocessor-design-from-scratch\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: processor-design-from-scratch\ndescription: \"Use when designing and simulating a simple CPU\u002Fprocessor from first principles — instruction set design, fetch-decode-execute cycle, a minimal assembler. Not for general low-level programming or existing CPU architecture study. Triggers on: 'design a CPU from scratch', 'build a simple processor', 'implement an instruction set', 'fetch decode execute cycle', 'write a toy CPU simulator', 'build my own assembler'. Covers ISA design, the FDE cycle, register\u002FALU design, and software-simulated vs HDL implementation.\"\norigin: yana-ai — synthesized from classic computer-architecture pedagogy (Nand2Tetris-style toy CPU design, RISC-V's minimal-ISA philosophy) and community from-scratch tutorials indexed in codecrafters-io\u002Fbuild-your-own-x\nlicense: Apache-2.0\nversion: 1.0.0\ncompatibility: yana-ai >= 0.43.2\n---\n\n# \u002Fprocessor-design-from-scratch\n\n## When to Use\n\n- Designing a minimal instruction set architecture (ISA) and simulating a CPU for it in software, for teaching or a toy VM project.\n- Understanding the fetch-decode-execute cycle well enough to implement it, not just describe it.\n- Deciding between a software CPU simulator and an HDL (Verilog\u002FVHDL) implementation targeting real or emulated silicon (FPGA).\n\n## Do NOT use for\n\n- Studying\u002Fusing an existing real ISA (x86, ARM, RISC-V) for systems programming — that's reading a manual, not designing one; see OS\u002Fkernel-level skills for working with real hardware ISAs.\n- General emulator development for an *existing* console\u002Fcomputer's exact CPU — that's a different task (matching a spec precisely, cycle-accurate timing) from designing your own ISA from scratch.\n- Bytecode VM design for a programming language (stack machine for a language interpreter) — related in spirit but a different design space; a language VM optimizes for the language's semantics, not for real-hardware constraints like registers and memory addressing.\n\n---\n\n## Software Simulator vs HDL — Decide First\n\n```\nGoal is to understand CPU concepts, build a working simulator quickly?\n  → Software simulation (Steps 1-4 below) — a program that interprets your ISA,\n    running on your actual computer's real CPU underneath\n\nGoal is to actually synthesize real digital logic (FPGA or ASIC)?\n  → HDL (Verilog\u002FVHDL) — you're describing hardware circuits, not writing a program;\n    a fundamentally different skill (digital logic design), out of scope here —\n    Nand2Tetris is the standard learning path for that direction\n```\n\nThis skill covers the software-simulation path — it's the right starting point even if HDL is the eventual goal, since ISA design decisions transfer directly.\n\n## Step 1: Design the Instruction Set (ISA)\n\nKeep it minimal — a working toy CPU needs surprisingly few instruction categories:\n\n```\nArithmetic\u002FLogic:  ADD, SUB, AND, OR, XOR, NOT\nData movement:     LOAD (memory → register), STORE (register → memory), MOV (register → register)\nControl flow:      JMP (unconditional), JZ\u002FJNZ (jump if zero\u002Fnot-zero), CALL, RET\nImmediate:         LOADI (load a literal constant into a register)\nHALT\n```\n\nDecide **instruction format** (fixed-width is far simpler to decode than variable-width): e.g. a 16-bit instruction as `[4-bit opcode][4-bit dest reg][4-bit src reg][4-bit operand\u002Funused]`. Fixed-width means decode is always \"read N bits, mask out each field\" — no need to first determine instruction length before knowing how to parse it (the added complexity real ISAs like x86 accept for code-density reasons, not worth it for a first design).\n\nDecide **register count** (4-16 is plenty for a toy design) and whether you have a dedicated accumulator (all ALU ops implicitly use one fixed register) vs general-purpose registers (any register can be an ALU operand) — accumulator designs are simpler to implement, general-purpose designs are closer to what real ISAs do.\n\n## Step 2: The Fetch-Decode-Execute Cycle\n\nThis is the actual CPU \"loop\" — everything else is supporting infrastructure around it:\n\n```\nloop:\n  1. FETCH:   instruction = memory[program_counter]\n  2. DECODE:  opcode, operands = parse(instruction)\n  3. EXECUTE: perform the operation (ALU op, memory access, or PC jump)\n  4. ADVANCE: program_counter += instruction_width   (unless EXECUTE already jumped it)\n```\n\nImplementation is a big switch\u002Fdispatch on opcode:\n\n```python\ndef step(cpu):\n    instr = cpu.memory[cpu.pc]\n    opcode, dst, src, imm = decode(instr)\n    if opcode == ADD:   cpu.regs[dst] += cpu.regs[src]\n    elif opcode == LOAD: cpu.regs[dst] = cpu.memory[cpu.regs[src]]\n    elif opcode == JZ:  cpu.pc = imm if cpu.regs[dst] == 0 else cpu.pc + 1; return\n    # ... etc\n    cpu.pc += 1\n```\n\nThe critical detail: **jump instructions must set `pc` directly and skip the normal auto-increment** (the `return` above) — a common toy-CPU bug is incrementing `pc` after a jump instruction already set it, landing one instruction past the intended jump target.\n\n## Step 3: Registers, ALU, and Flags\n\n- **Registers**: just an array (`regs[0..N]`) — fast, fixed-size storage the ALU and data-movement instructions read\u002Fwrite directly, distinct from main memory (which is addressed, larger, and slower to access in real hardware — the distinction matters conceptually even in a software simulator with no real speed difference).\n- **ALU**: the functions implementing ADD\u002FSUB\u002FAND\u002FOR\u002Fetc. — in a software simulator these are just your host language's own arithmetic operators, called from the EXECUTE step.\n- **Flags** (zero, carry, negative, overflow): a small status register set after arithmetic ops, used by conditional jumps (`JZ` checks the zero flag rather than re-comparing values). Deciding to have explicit flags vs. conditional instructions that re-evaluate a condition directly (RISC-V's approach) is itself an ISA design choice — flags are simpler to bolt onto a first design.\n\n## Step 4: A Minimal Assembler\n\nOnce the ISA exists, hand-writing raw instruction words is painful — build a two-pass assembler:\n\n```\nPass 1: scan the source, record every LABEL's line number as an address\n        (needed because a jump can reference a label defined LATER in the file —\n        you can't resolve it until you've seen the whole program)\nPass 2: re-scan, emit actual instruction words, substituting each label\n        reference with its now-known address from pass 1's table\n```\n\n```asm\n        LOADI r0, 10\nloop:   SUB   r0, r0, 1\n        JNZ   r0, loop      ; label resolved in pass 2 using pass 1's table\n        HALT\n```\n\n## What NOT to Do\n\n- Don't design a variable-width instruction format for a first ISA — the decode complexity isn't worth it until you have a concrete code-density reason to need it.\n- Don't forget to skip the auto-increment on jump instructions — see Step 2; this is the most common toy-CPU bug and it's silent (the program runs, just wrong).\n- Don't conflate \"register\" and \"memory\" access cost\u002Fsemantics even in a simulator with no real performance difference — keeping the conceptual distinction is what makes the design transferable to understanding real hardware.\n- Don't try to support self-modifying code, interrupts, or virtual memory in a first design — these are real and important CPU features, but they're extensions to a working fetch-decode-execute loop, not part of getting one working.\n","# \u002Fprocessor-design-from-scratch\n\n## When to Use\n\n- Designing a minimal instruction set architecture (ISA) and simulating a CPU for it in software, for teaching or a toy VM project.\n- Understanding the fetch-decode-execute cycle well enough to implement it, not just describe it.\n- Deciding between a software CPU simulator and an HDL (Verilog\u002FVHDL) implementation targeting real or emulated silicon (FPGA).\n\n## Do NOT use for\n\n- Studying\u002Fusing an existing real ISA (x86, ARM, RISC-V) for systems programming — that's reading a manual, not designing one; see OS\u002Fkernel-level skills for working with real hardware ISAs.\n- General emulator development for an *existing* console\u002Fcomputer's exact CPU — that's a different task (matching a spec precisely, cycle-accurate timing) from designing your own ISA from scratch.\n- Bytecode VM design for a programming language (stack machine for a language interpreter) — related in spirit but a different design space; a language VM optimizes for the language's semantics, not for real-hardware constraints like registers and memory addressing.\n\n---\n\n## Software Simulator vs HDL — Decide First\n\n```\nGoal is to understand CPU concepts, build a working simulator quickly?\n  → Software simulation (Steps 1-4 below) — a program that interprets your ISA,\n    running on your actual computer's real CPU underneath\n\nGoal is to actually synthesize real digital logic (FPGA or ASIC)?\n  → HDL (Verilog\u002FVHDL) — you're describing hardware circuits, not writing a program;\n    a fundamentally different skill (digital logic design), out of scope here —\n    Nand2Tetris is the standard learning path for that direction\n```\n\nThis skill covers the software-simulation path — it's the right starting point even if HDL is the eventual goal, since ISA design decisions transfer directly.\n\n## Step 1: Design the Instruction Set (ISA)\n\nKeep it minimal — a working toy CPU needs surprisingly few instruction categories:\n\n```\nArithmetic\u002FLogic:  ADD, SUB, AND, OR, XOR, NOT\nData movement:     LOAD (memory → register), STORE (register → memory), MOV (register → register)\nControl flow:      JMP (unconditional), JZ\u002FJNZ (jump if zero\u002Fnot-zero), CALL, RET\nImmediate:         LOADI (load a literal constant into a register)\nHALT\n```\n\nDecide **instruction format** (fixed-width is far simpler to decode than variable-width): e.g. a 16-bit instruction as `[4-bit opcode][4-bit dest reg][4-bit src reg][4-bit operand\u002Funused]`. Fixed-width means decode is always \"read N bits, mask out each field\" — no need to first determine instruction length before knowing how to parse it (the added complexity real ISAs like x86 accept for code-density reasons, not worth it for a first design).\n\nDecide **register count** (4-16 is plenty for a toy design) and whether you have a dedicated accumulator (all ALU ops implicitly use one fixed register) vs general-purpose registers (any register can be an ALU operand) — accumulator designs are simpler to implement, general-purpose designs are closer to what real ISAs do.\n\n## Step 2: The Fetch-Decode-Execute Cycle\n\nThis is the actual CPU \"loop\" — everything else is supporting infrastructure around it:\n\n```\nloop:\n  1. FETCH:   instruction = memory[program_counter]\n  2. DECODE:  opcode, operands = parse(instruction)\n  3. EXECUTE: perform the operation (ALU op, memory access, or PC jump)\n  4. ADVANCE: program_counter += instruction_width   (unless EXECUTE already jumped it)\n```\n\nImplementation is a big switch\u002Fdispatch on opcode:\n\n```python\ndef step(cpu):\n    instr = cpu.memory[cpu.pc]\n    opcode, dst, src, imm = decode(instr)\n    if opcode == ADD:   cpu.regs[dst] += cpu.regs[src]\n    elif opcode == LOAD: cpu.regs[dst] = cpu.memory[cpu.regs[src]]\n    elif opcode == JZ:  cpu.pc = imm if cpu.regs[dst] == 0 else cpu.pc + 1; return\n    # ... etc\n    cpu.pc += 1\n```\n\nThe critical detail: **jump instructions must set `pc` directly and skip the normal auto-increment** (the `return` above) — a common toy-CPU bug is incrementing `pc` after a jump instruction already set it, landing one instruction past the intended jump target.\n\n## Step 3: Registers, ALU, and Flags\n\n- **Registers**: just an array (`regs[0..N]`) — fast, fixed-size storage the ALU and data-movement instructions read\u002Fwrite directly, distinct from main memory (which is addressed, larger, and slower to access in real hardware — the distinction matters conceptually even in a software simulator with no real speed difference).\n- **ALU**: the functions implementing ADD\u002FSUB\u002FAND\u002FOR\u002Fetc. — in a software simulator these are just your host language's own arithmetic operators, called from the EXECUTE step.\n- **Flags** (zero, carry, negative, overflow): a small status register set after arithmetic ops, used by conditional jumps (`JZ` checks the zero flag rather than re-comparing values). Deciding to have explicit flags vs. conditional instructions that re-evaluate a condition directly (RISC-V's approach) is itself an ISA design choice — flags are simpler to bolt onto a first design.\n\n## Step 4: A Minimal Assembler\n\nOnce the ISA exists, hand-writing raw instruction words is painful — build a two-pass assembler:\n\n```\nPass 1: scan the source, record every LABEL's line number as an address\n        (needed because a jump can reference a label defined LATER in the file —\n        you can't resolve it until you've seen the whole program)\nPass 2: re-scan, emit actual instruction words, substituting each label\n        reference with its now-known address from pass 1's table\n```\n\n```asm\n        LOADI r0, 10\nloop:   SUB   r0, r0, 1\n        JNZ   r0, loop      ; label resolved in pass 2 using pass 1's table\n        HALT\n```\n\n## What NOT to Do\n\n- Don't design a variable-width instruction format for a first ISA — the decode complexity isn't worth it until you have a concrete code-density reason to need it.\n- Don't forget to skip the auto-increment on jump instructions — see Step 2; this is the most common toy-CPU bug and it's silent (the program runs, just wrong).\n- Don't conflate \"register\" and \"memory\" access cost\u002Fsemantics even in a simulator with no real performance difference — keeping the conceptual distinction is what makes the design transferable to understanding real hardware.\n- Don't try to support self-modifying code, interrupts, or virtual memory in a first design — these are real and important CPU features, but they're extensions to a working fetch-decode-execute loop, not part of getting one working.\n",{"name":5,"origin":24,"license":15,"version":25,"description":7,"compatibility":26},"yana-ai — synthesized from classic computer-architecture pedagogy (Nand2Tetris-style toy CPU design, RISC-V's minimal-ISA philosophy) and community from-scratch tutorials indexed in codecrafters-io\u002Fbuild-your-own-x","1.0.0","yana-ai >= 0.43.2","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Fprocessor-design-from-scratch",1,"https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI","https:\u002F\u002Fyana.vutam.link\u002F","https:\u002F\u002Fgithub.com\u002FHoronomos-laps","https:\u002F\u002Fyana.vutam.link","An open-source governed runtime & execution environment for multi-agent AI systems.","2026-11-11 23:56:26",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill processor-design-from-scratch",{"tool":43,"command":44},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill processor-design-from-scratch",{"tool":46,"command":47},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill processor-design-from-scratch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fprocessor-design-from-scratch\u002FSKILL.md",true,[],[52,60,67,75,83,91],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":56,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M735GKET5YVYKAY62W2P5YXB","openai--sentry--sentry","Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.","MIT","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenai--sentry--sentry\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M73DCAP83T17HY7SMGK7MGFE","ito-basket-compare","Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fito-basket-compare\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":71,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M734CYEMZFDR3KH6SW0JP8TD","implementing-network-traffic-baselining","Build network traffic baselines from NetFlow\u002FIPFIX data using Python pandas for statistical analysis, z-score anomaly detection, and hourly\u002Fdaily traffic pattern profiling","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":79,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M73ASZ6NJRJM44Z2P84NGQ3Q","detecting-evasion-techniques-in-endpoint-logs","Detects defense evasion techniques used by adversaries in endpoint logs including log tampering, timestomping, process injection, and security tool disabling. Use when investigating suspicious endpoint behavior, building detection rules for evasion tactics, or conducting threat hunting for stealthy adversary activity. Activates for requests involving evasion detection, defense evasion analysis, log tampering detection, or MITRE ATT&CK TA0005.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":87,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M734AFNXD06Z78QRK0VKGT7Q","implementing-microsegmentation-with-guardicore","Implementing microsegmentation using Akamai Guardicore Segmentation to map application dependencies, create granular network policies, visualize east-west traffic flows, and enforce least-privilege communication between workloads across data centers and cloud.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]