{"owner":"portapack-mayhem","repo":"mayhem-firmware","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":1453,"categories":["copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"mayhem-firmware":{"command":"npx","args":["-y","@modelcontextprotocol/server-mayhem-firmware"]}}},"found":[".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{".github/copilot-instructions.md":"# Copilot Pull Request Review Instructions\n\nThese instructions define how to review pull requests for the PortaPack Mayhem firmware (an embedded, resource-constrained, dual-core ARM Cortex-M0/M4 project). They complement `AGENT.md`.\n\n## 1. Understand the stated goal\n\nBefore reviewing any code, answer these questions from the PR title, description and diff:\n\n- What does the PR claim to add or fix?\n- Does the diff address that stated goal? Identify concrete gaps between the claim and implementation.\n\n## 2. Minimal, focused changes\n\n- The diff must be as small as possible and address a single purpose.\n- Flag unrelated refactors, reformatting, renames, or drive-by fixes (scope creep).\n- Question Python tests or other test code that is not relevant to the change or does not fit the project's existing validation setup.\n- Flag unrelated Markdown, documentation, and other non-code files; include them only when they directly support the change.\n- Flag new `std::` facilities that are not already established in the project or relevant code area; do not object to existing usage, including `std::string`, solely because it is from the standard library.\n- Prefer existing project patterns and helpers over new ones.\n\n## 3. Hardware constraints\n\n- RAM and flash are very limited. Flag dynamic allocation, large stack or static buffers, and unneeded copies.\n- The firmware is dual-core (M0 application, M4 baseband). Check that code runs on the correct core and that shared memory and IPC messages are used safely (message sizes, ordering, no blocking in baseband/interrupt context, no unsynchronized shared state).\n- External apps and baseband images must fit their memory regions.\n- Baseband/DSP code must stay deterministic and fast.\n\n## 4. Hardware verification\n\n- Changes touching radio, baseband, peripherals, or timing must state how they were tested on real hardware (board model, firmware build).\n- If the PR does not say it was tested, or only claims it \"should work\", ask for explicit verification.\n\n## 5. Code quality (within project norms)\n\n- Follow the existing style and naming of surrounding code.\n- Check for undefined behavior, integer overflow, buffer bounds, uninitialized variables, and unsafe casts.\n- Check that new UI strings, app IDs, and message IDs follow existing conventions and remain unique/consecutive where required.\n\n## 6. Red flags (recommend rejection or major rework)\n\n- The problem is not real, or the change rests on a misunderstanding.\n- Large diffs for small problems; unrelated changes mixed in.\n- Introduces dynamic memory without strong justification.\n- Unsafe cross-core/IPC access.\n- Claims of hardware behavior with no verification.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/plugin.json)"},"files":{".github/copilot-instructions.md":"# Copilot Pull Request Review Instructions\n\nThese instructions define how to review pull requests for the PortaPack Mayhem firmware (an embedded, resource-constrained, dual-core ARM Cortex-M0/M4 project). They complement `AGENT.md`.\n\n## 1. Understand the stated goal\n\nBefore reviewing any code, answer these questions from the PR title, description and diff:\n\n- What does the PR claim to add or fix?\n- Does the diff address that stated goal? Identify concrete gaps between the claim and implementation.\n\n## 2. Minimal, focused changes\n\n- The diff must be as small as possible and address a single purpose.\n- Flag unrelated refactors, reformatting, renames, or drive-by fixes (scope creep).\n- Question Python tests or other test code that is not relevant to the change or does not fit the project's existing validation setup.\n- Flag unrelated Markdown, documentation, and other non-code files; include them only when they directly support the change.\n- Flag new `std::` facilities that are not already established in the project or relevant code area; do not object to existing usage, including `std::string`, solely because it is from the standard library.\n- Prefer existing project patterns and helpers over new ones.\n\n## 3. Hardware constraints\n\n- RAM and flash are very limited. Flag dynamic allocation, large stack or static buffers, and unneeded copies.\n- The firmware is dual-core (M0 application, M4 baseband). Check that code runs on the correct core and that shared memory and IPC messages are used safely (message sizes, ordering, no blocking in baseband/interrupt context, no unsynchronized shared state).\n- External apps and baseband images must fit their memory regions.\n- Baseband/DSP code must stay deterministic and fast.\n\n## 4. Hardware verification\n\n- Changes touching radio, baseband, peripherals, or timing must state how they were tested on real hardware (board model, firmware build).\n- If the PR does not say it was tested, or only claims it \"should work\", ask for explicit verification.\n\n## 5. Code quality (within project norms)\n\n- Follow the existing style and naming of surrounding code.\n- Check for undefined behavior, integer overflow, buffer bounds, uninitialized variables, and unsafe casts.\n- Check that new UI strings, app IDs, and message IDs follow existing conventions and remain unique/consecutive where required.\n\n## 6. Red flags (recommend rejection or major rework)\n\n- The problem is not real, or the change rests on a misunderstanding.\n- Large diffs for small problems; unrelated changes mixed in.\n- Introduces dynamic memory without strong justification.\n- Unsafe cross-core/IPC access.\n- Claims of hardware behavior with no verification.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot Pull Request Review Instructions\n\nThese instructions define how to review pull requests for the PortaPack Mayhem firmware (an embedded, resource-constrained, dual-core ARM Cortex-M0/M4 project). They complement `AGENT.md`.\n\n## 1. Understand the stated goal\n\nBefore reviewing any code, answer these questions from the PR title, description and diff:\n\n- What does the PR claim to add or fix?\n- Does the diff address that stated goal? Identify concrete gaps between the claim and implementation.\n\n## 2. Minimal, focused changes\n\n- The diff must be as small as possible and address a single purpose.\n- Flag unrelated refactors, reformatting, renames, or drive-by fixes (scope creep).\n- Question Python tests or other test code that is not relevant to the change or does not fit the project's existing validation setup.\n- Flag unrelated Markdown, documentation, and other non-code files; include them only when they directly support the change.\n- Flag new `std::` facilities that are not already established in the project or relevant code area; do not object to existing usage, including `std::string`, solely because it is from the standard library.\n- Prefer existing project patterns and helpers over new ones.\n\n## 3. Hardware constraints\n\n- RAM and flash are very limited. Flag dynamic allocation, large stack or static buffers, and unneeded copies.\n- The firmware is dual-core (M0 application, M4 baseband). Check that code runs on the correct core and that shared memory and IPC messages are used safely (message sizes, ordering, no blocking in baseband/interrupt context, no unsynchronized shared state).\n- External apps and baseband images must fit their memory regions.\n- Baseband/DSP code must stay deterministic and fast.\n\n## 4. Hardware verification\n\n- Changes touching radio, baseband, peripherals, or timing must state how they were tested on real hardware (board model, firmware build).\n- If the PR does not say it was tested, or only claims it \"should work\", ask for explicit verification.\n\n## 5. Code quality (within project norms)\n\n- Follow the existing style and naming of surrounding code.\n- Check for undefined behavior, integer overflow, buffer bounds, uninitialized variables, and unsafe casts.\n- Check that new UI strings, app IDs, and message IDs follow existing conventions and remain unique/consecutive where required.\n\n## 6. Red flags (recommend rejection or major rework)\n\n- The problem is not real, or the change rests on a misunderstanding.\n- Large diffs for small problems; unrelated changes mixed in.\n- Introduces dynamic memory without strong justification.\n- Unsafe cross-core/IPC access.\n- Claims of hardware behavior with no verification.\n","isInternal":false,"tokens":553,"sizeBytes":2681},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":211},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":197},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":190}],"systemPromptSnippet":"<yakaai_skills repo=\"portapack-mayhem/mayhem-firmware\">\n<!-- File: .github/copilot-instructions.md (Tokens: ~553 | Category: copilot-instructions) -->\n# Copilot Pull Request Review Instructions\n\nThese instructions define how to review pull requests for the PortaPack Mayhem firmware (an embedded, resource-constrained, dual-core ARM Cortex-M0/M4 project). They complement `AGENT.md`.\n\n## 1. Understand the stated goal\n\nBefore reviewing any code, answer these questions from the PR title, description and diff:\n\n- What does the PR claim to add or fix?\n- Does the diff address that stated goal? Identify concrete gaps between the claim and implementation.\n\n## 2. Minimal, focused changes\n\n- The diff must be as small as possible and address a single purpose.\n- Flag unrelated refactors, reformatting, renames, or drive-by fixes (scope creep).\n- Question Python tests or other test code that is not relevant to the change or does not fit the project's existing validation setup.\n- Flag unrelated Markdown, documentation, and other non-code files; include them only when they directly support the change.\n- Flag new `std::` facilities that are not already established in the project or relevant code area; do not object to existing usage, including `std::string`, solely because it is from the standard library.\n- Prefer existing project patterns and helpers over new ones.\n\n## 3. Hardware constraints\n\n- RAM and flash are very limited. Flag dynamic allocation, large stack or static buffers, and unneeded copies.\n- The firmware is dual-core (M0 application, M4 baseband). Check that code runs on the correct core and that shared memory and IPC messages are used safely (message sizes, ordering, no blocking in baseband/interrupt context, no unsynchronized shared state).\n- External apps and baseband images must fit their memory regions.\n- Baseband/DSP code must stay deterministic and fast.\n\n## 4. Hardware verification\n\n- Changes touching radio, baseband, peripherals, or timing must state how they were tested on real hardware (board model, firmware build).\n- If the PR does not say it was tested, or only claims it \"should work\", ask for explicit verification.\n\n## 5. Code quality (within project norms)\n\n- Follow the existing style and naming of surrounding code.\n- Check for undefined behavior, integer overflow, buffer bounds, uninitialized variables, and unsafe casts.\n- Check that new UI strings, app IDs, and message IDs follow existing conventions and remain unique/consecutive where required.\n\n## 6. Red flags (recommend rejection or major rework)\n\n- The problem is not real, or the change rests on a misunderstanding.\n- Large diffs for small problems; unrelated changes mixed in.\n- Introduces dynamic memory without strong justification.\n- Unsafe cross-core/IPC access.\n- Claims of hardware behavior with no verification.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/portapack-mayhem/mayhem-firmware/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}