[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M76983BD4KN0VRB2FAS44CSQ":3,"skill-same:01M76983BD4KN0VRB2FAS44CSQ":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M76983BD4KN0VRB2FAS44CSQ","plan",null,"Write a markdown plan to .hermes\u002Fplans\u002F; no execution.","LyrikNilpferd71\u002FHermes-Backup","LyrikNilpferd71","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F187173780?v=4","01M727S8GPB77P0S9ECRRMZT58","01M727S8HF63B0MD53F496MK1V",0,"MIT","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-09-27T14-00-39+0200\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: plan\ndescription: Write a markdown plan to .hermes\u002Fplans\u002F; no execution.\nversion: 2.0.0\nauthor: Hermes Agent (writing-craft adapted from obra\u002Fsuperpowers)\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [planning, plan-mode, implementation, workflow, design, documentation]\n    related_skills: [subagent-driven-development, test-driven-development, requesting-code-review]\n---\n\n# Plan Mode\n\nUse this skill when the user wants a plan instead of execution.\n\n## Core behavior\n\nFor this turn, you are planning only.\n\n- Do not implement code.\n- Do not edit project files except the plan markdown file.\n- Do not run mutating terminal commands, commit, push, or perform external actions.\n- You may inspect the repo or other context with read-only commands\u002Ftools when needed.\n- Your deliverable is a markdown plan saved inside the active workspace under `.hermes\u002Fplans\u002F`.\n\n## Output requirements\n\nWrite a markdown plan that is concrete and actionable.\n\nInclude, when relevant:\n- Goal\n- Current context \u002F assumptions\n- Proposed approach\n- Step-by-step plan\n- Files likely to change\n- Tests \u002F validation\n- Risks, tradeoffs, and open questions\n\nIf the task is code-related, include exact file paths, likely test targets, and verification steps.\n\n## Save location\n\nSave the plan with `write_file` under:\n- `.hermes\u002Fplans\u002FYYYY-MM-DD_HHMMSS-\u003Cslug>.md`\n\nTreat that as relative to the active working directory \u002F backend workspace. Hermes file tools are backend-aware, so using this relative path keeps the plan with the workspace on local, docker, ssh, modal, and daytona backends.\n\nIf the runtime provides a specific target path, use that exact path.\nIf not, create a sensible timestamped filename yourself under `.hermes\u002Fplans\u002F`.\n\n## Interaction style\n\n- If the request is clear enough, write the plan directly.\n- If no explicit instruction accompanies `\u002Fplan`, infer the task from the current conversation context.\n- If it is genuinely underspecified, ask a brief clarifying question instead of guessing.\n- After saving the plan, reply briefly with what you planned and the saved path.\n\n---\n\n# Writing the Plan Well\n\nThe rest of this skill is the craft of authoring a *good* implementation plan — the content that goes inside the markdown file above.\n\n## Overview\n\nWrite comprehensive implementation plans assuming the implementer has zero context for the codebase and questionable taste. Document everything they need: which files to touch, complete code, testing commands, docs to check, how to verify. Give them bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume the implementer is a skilled developer but knows almost nothing about the toolset or problem domain. Assume they don't know good test design very well.\n\n**Core principle:** A good plan makes implementation obvious. If someone has to guess, the plan is incomplete.\n\n## When a Full Implementation Plan Helps\n\n**Always use before:**\n- Implementing multi-step features\n- Breaking down complex requirements\n- Delegating to subagents via subagent-driven-development\n\n**Don't skip when:**\n- Feature seems simple (assumptions cause bugs)\n- You plan to implement it yourself (future you needs guidance)\n- Working alone (documentation matters)\n\n## Bite-Sized Task Granularity\n\n**Each task = 2-5 minutes of focused work.**\n\nEvery step is one action:\n- \"Write the failing test\" — step\n- \"Run it to make sure it fails\" — step\n- \"Implement the minimal code to make the test pass\" — step\n- \"Run the tests and make sure they pass\" — step\n- \"Commit\" — step\n\n**Too big:**\n```markdown\n### Task 1: Build authentication system\n[50 lines of code across 5 files]\n```\n\n**Right size:**\n```markdown\n### Task 1: Create User model with email field\n[10 lines, 1 file]\n\n### Task 2: Add password hash field to User\n[8 lines, 1 file]\n\n### Task 3: Create password hashing utility\n[15 lines, 1 file]\n```\n\n## Plan Document Structure\n\n### Header (Required)\n\nEvery plan MUST start with:\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For Hermes:** Use subagent-driven-development skill to implement this plan task-by-task.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n### Task Structure\n\nEach task follows this format:\n\n````markdown\n### Task N: [Descriptive Name]\n\n**Objective:** What this task accomplishes (one sentence)\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Fnew_file.py`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.py:45-67` (line numbers if known)\n- Test: `tests\u002Fpath\u002Fto\u002Ftest_file.py`\n\n**Step 1: Write failing test**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n**Step 2: Run test to verify failure**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_specific_behavior -v`\nExpected: FAIL — \"function not defined\"\n\n**Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n    return expected\n```\n\n**Step 4: Run test to verify pass**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_specific_behavior -v`\nExpected: PASS\n\n**Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## Writing Process\n\n### Step 1: Understand Requirements\n\nRead and understand:\n- Feature requirements\n- Design documents or user description\n- Acceptance criteria\n- Constraints\n\n### Step 2: Explore the Codebase\n\nUse Hermes tools to understand the project:\n\n```python\n# Understand project structure\nsearch_files(\"*.py\", target=\"files\", path=\"src\u002F\")\n\n# Look at similar features\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\n\n# Check existing tests\nsearch_files(\"*.py\", target=\"files\", path=\"tests\u002F\")\n\n# Read key files\nread_file(\"src\u002Fapp.py\")\n```\n\n### Step 3: Design Approach\n\nDecide:\n- Architecture pattern\n- File organization\n- Dependencies needed\n- Testing strategy\n\n### Step 4: Write Tasks\n\nCreate tasks in order:\n1. Setup\u002Finfrastructure\n2. Core functionality (TDD for each)\n3. Edge cases\n4. Integration\n5. Cleanup\u002Fdocumentation\n\n### Step 5: Add Complete Details\n\nFor each task, include:\n- **Exact file paths** (not \"the config file\" but `src\u002Fconfig\u002Fsettings.py`)\n- **Complete code examples** (not \"add validation\" but the actual code)\n- **Exact commands** with expected output\n- **Verification steps** that prove the task works\n\n### Step 6: Review the Plan\n\nCheck:\n- [ ] Tasks are sequential and logical\n- [ ] Each task is bite-sized (2-5 min)\n- [ ] File paths are exact\n- [ ] Code examples are complete (copy-pasteable)\n- [ ] Commands are exact with expected output\n- [ ] No missing context\n- [ ] DRY, YAGNI, TDD principles applied\n\n## Principles\n\n### DRY (Don't Repeat Yourself)\n\n**Bad:** Copy-paste validation in 3 places\n**Good:** Extract validation function, use everywhere\n\n### YAGNI (You Aren't Gonna Need It)\n\n**Bad:** Add \"flexibility\" for future requirements\n**Good:** Implement only what's needed now\n\n```python\n# Bad — YAGNI violation\nclass User:\n    def __init__(self, name, email):\n        self.name = name\n        self.email = email\n        self.preferences = {}  # Not needed yet!\n        self.metadata = {}     # Not needed yet!\n\n# Good — YAGNI\nclass User:\n    def __init__(self, name, email):\n        self.name = name\n        self.email = email\n```\n\n### TDD (Test-Driven Development)\n\nEvery task that produces code should include the full TDD cycle:\n1. Write failing test\n2. Run to verify failure\n3. Write minimal code\n4. Run to verify pass\n\nSee `test-driven-development` skill for details.\n\n### Frequent Commits\n\nCommit after every task:\n```bash\ngit add [files]\ngit commit -m \"type: description\"\n```\n\n## Common Mistakes\n\n### Vague Tasks\n\n**Bad:** \"Add authentication\"\n**Good:** \"Create User model with email and password_hash fields\"\n\n### Incomplete Code\n\n**Bad:** \"Step 1: Add validation function\"\n**Good:** \"Step 1: Add validation function\" followed by the complete function code\n\n### Missing Verification\n\n**Bad:** \"Step 3: Test it works\"\n**Good:** \"Step 3: Run `pytest tests\u002Ftest_auth.py -v`, expected: 3 passed\"\n\n### Missing File Paths\n\n**Bad:** \"Create the model file\"\n**Good:** \"Create: `src\u002Fmodels\u002Fuser.py`\"\n\n## Execution Handoff\n\nAfter saving the plan, offer the execution approach:\n\n**\"Plan complete and saved. Ready to execute using subagent-driven-development — I'll dispatch a fresh subagent per task with two-stage review (spec compliance then code quality). Shall I proceed?\"**\n\nWhen executing, use the `subagent-driven-development` skill:\n- Fresh `delegate_task` per task with full context\n- Spec compliance review after each task\n- Code quality review after spec passes\n- Proceed only when both reviews approve\n\n## Remember\n\n```\nBite-sized tasks (2-5 min each)\nExact file paths\nComplete code (copy-pasteable)\nExact commands with expected output\nVerification steps\nDRY, YAGNI, TDD\nFrequent commits\n```\n\n**A good plan makes implementation obvious.**\n","# Plan Mode\n\nUse this skill when the user wants a plan instead of execution.\n\n## Core behavior\n\nFor this turn, you are planning only.\n\n- Do not implement code.\n- Do not edit project files except the plan markdown file.\n- Do not run mutating terminal commands, commit, push, or perform external actions.\n- You may inspect the repo or other context with read-only commands\u002Ftools when needed.\n- Your deliverable is a markdown plan saved inside the active workspace under `.hermes\u002Fplans\u002F`.\n\n## Output requirements\n\nWrite a markdown plan that is concrete and actionable.\n\nInclude, when relevant:\n- Goal\n- Current context \u002F assumptions\n- Proposed approach\n- Step-by-step plan\n- Files likely to change\n- Tests \u002F validation\n- Risks, tradeoffs, and open questions\n\nIf the task is code-related, include exact file paths, likely test targets, and verification steps.\n\n## Save location\n\nSave the plan with `write_file` under:\n- `.hermes\u002Fplans\u002FYYYY-MM-DD_HHMMSS-\u003Cslug>.md`\n\nTreat that as relative to the active working directory \u002F backend workspace. Hermes file tools are backend-aware, so using this relative path keeps the plan with the workspace on local, docker, ssh, modal, and daytona backends.\n\nIf the runtime provides a specific target path, use that exact path.\nIf not, create a sensible timestamped filename yourself under `.hermes\u002Fplans\u002F`.\n\n## Interaction style\n\n- If the request is clear enough, write the plan directly.\n- If no explicit instruction accompanies `\u002Fplan`, infer the task from the current conversation context.\n- If it is genuinely underspecified, ask a brief clarifying question instead of guessing.\n- After saving the plan, reply briefly with what you planned and the saved path.\n\n---\n\n# Writing the Plan Well\n\nThe rest of this skill is the craft of authoring a *good* implementation plan — the content that goes inside the markdown file above.\n\n## Overview\n\nWrite comprehensive implementation plans assuming the implementer has zero context for the codebase and questionable taste. Document everything they need: which files to touch, complete code, testing commands, docs to check, how to verify. Give them bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume the implementer is a skilled developer but knows almost nothing about the toolset or problem domain. Assume they don't know good test design very well.\n\n**Core principle:** A good plan makes implementation obvious. If someone has to guess, the plan is incomplete.\n\n## When a Full Implementation Plan Helps\n\n**Always use before:**\n- Implementing multi-step features\n- Breaking down complex requirements\n- Delegating to subagents via subagent-driven-development\n\n**Don't skip when:**\n- Feature seems simple (assumptions cause bugs)\n- You plan to implement it yourself (future you needs guidance)\n- Working alone (documentation matters)\n\n## Bite-Sized Task Granularity\n\n**Each task = 2-5 minutes of focused work.**\n\nEvery step is one action:\n- \"Write the failing test\" — step\n- \"Run it to make sure it fails\" — step\n- \"Implement the minimal code to make the test pass\" — step\n- \"Run the tests and make sure they pass\" — step\n- \"Commit\" — step\n\n**Too big:**\n```markdown\n### Task 1: Build authentication system\n[50 lines of code across 5 files]\n```\n\n**Right size:**\n```markdown\n### Task 1: Create User model with email field\n[10 lines, 1 file]\n\n### Task 2: Add password hash field to User\n[8 lines, 1 file]\n\n### Task 3: Create password hashing utility\n[15 lines, 1 file]\n```\n\n## Plan Document Structure\n\n### Header (Required)\n\nEvery plan MUST start with:\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For Hermes:** Use subagent-driven-development skill to implement this plan task-by-task.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n### Task Structure\n\nEach task follows this format:\n\n````markdown\n### Task N: [Descriptive Name]\n\n**Objective:** What this task accomplishes (one sentence)\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Fnew_file.py`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.py:45-67` (line numbers if known)\n- Test: `tests\u002Fpath\u002Fto\u002Ftest_file.py`\n\n**Step 1: Write failing test**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n**Step 2: Run test to verify failure**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_specific_behavior -v`\nExpected: FAIL — \"function not defined\"\n\n**Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n    return expected\n```\n\n**Step 4: Run test to verify pass**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_specific_behavior -v`\nExpected: PASS\n\n**Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## Writing Process\n\n### Step 1: Understand Requirements\n\nRead and understand:\n- Feature requirements\n- Design documents or user description\n- Acceptance criteria\n- Constraints\n\n### Step 2: Explore the Codebase\n\nUse Hermes tools to understand the project:\n\n```python\n# Understand project structure\nsearch_files(\"*.py\", target=\"files\", path=\"src\u002F\")\n\n# Look at similar features\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\n\n# Check existing tests\nsearch_files(\"*.py\", target=\"files\", path=\"tests\u002F\")\n\n# Read key files\nread_file(\"src\u002Fapp.py\")\n```\n\n### Step 3: Design Approach\n\nDecide:\n- Architecture pattern\n- File organization\n- Dependencies needed\n- Testing strategy\n\n### Step 4: Write Tasks\n\nCreate tasks in order:\n1. Setup\u002Finfrastructure\n2. Core functionality (TDD for each)\n3. Edge cases\n4. Integration\n5. Cleanup\u002Fdocumentation\n\n### Step 5: Add Complete Details\n\nFor each task, include:\n- **Exact file paths** (not \"the config file\" but `src\u002Fconfig\u002Fsettings.py`)\n- **Complete code examples** (not \"add validation\" but the actual code)\n- **Exact commands** with expected output\n- **Verification steps** that prove the task works\n\n### Step 6: Review the Plan\n\nCheck:\n- [ ] Tasks are sequential and logical\n- [ ] Each task is bite-sized (2-5 min)\n- [ ] File paths are exact\n- [ ] Code examples are complete (copy-pasteable)\n- [ ] Commands are exact with expected output\n- [ ] No missing context\n- [ ] DRY, YAGNI, TDD principles applied\n\n## Principles\n\n### DRY (Don't Repeat Yourself)\n\n**Bad:** Copy-paste validation in 3 places\n**Good:** Extract validation function, use everywhere\n\n### YAGNI (You Aren't Gonna Need It)\n\n**Bad:** Add \"flexibility\" for future requirements\n**Good:** Implement only what's needed now\n\n```python\n# Bad — YAGNI violation\nclass User:\n    def __init__(self, name, email):\n        self.name = name\n        self.email = email\n        self.preferences = {}  # Not needed yet!\n        self.metadata = {}     # Not needed yet!\n\n# Good — YAGNI\nclass User:\n    def __init__(self, name, email):\n        self.name = name\n        self.email = email\n```\n\n### TDD (Test-Driven Development)\n\nEvery task that produces code should include the full TDD cycle:\n1. Write failing test\n2. Run to verify failure\n3. Write minimal code\n4. Run to verify pass\n\nSee `test-driven-development` skill for details.\n\n### Frequent Commits\n\nCommit after every task:\n```bash\ngit add [files]\ngit commit -m \"type: description\"\n```\n\n## Common Mistakes\n\n### Vague Tasks\n\n**Bad:** \"Add authentication\"\n**Good:** \"Create User model with email and password_hash fields\"\n\n### Incomplete Code\n\n**Bad:** \"Step 1: Add validation function\"\n**Good:** \"Step 1: Add validation function\" followed by the complete function code\n\n### Missing Verification\n\n**Bad:** \"Step 3: Test it works\"\n**Good:** \"Step 3: Run `pytest tests\u002Ftest_auth.py -v`, expected: 3 passed\"\n\n### Missing File Paths\n\n**Bad:** \"Create the model file\"\n**Good:** \"Create: `src\u002Fmodels\u002Fuser.py`\"\n\n## Execution Handoff\n\nAfter saving the plan, offer the execution approach:\n\n**\"Plan complete and saved. Ready to execute using subagent-driven-development — I'll dispatch a fresh subagent per task with two-stage review (spec compliance then code quality). Shall I proceed?\"**\n\nWhen executing, use the `subagent-driven-development` skill:\n- Fresh `delegate_task` per task with full context\n- Spec compliance review after each task\n- Code quality review after spec passes\n- Proceed only when both reviews approve\n\n## Remember\n\n```\nBite-sized tasks (2-5 min each)\nExact file paths\nComplete code (copy-pasteable)\nExact commands with expected output\nVerification steps\nDRY, YAGNI, TDD\nFrequent commits\n```\n\n**A good plan makes implementation obvious.**\n",{"name":5,"author":23,"license":14,"version":24,"metadata":25,"platforms":38,"description":7},"Hermes Agent (writing-craft adapted from obra\u002Fsuperpowers)","2.0.0",{"hermes":26},{"tags":27,"related_skills":34},[28,29,30,31,32,33],"planning","plan-mode","implementation","workflow","design","documentation",[35,36,37],"subagent-driven-development","test-driven-development","requesting-code-review",[39,40,41],"linux","macos","windows","main","404fd33aabef3b6bc1cc913117ba2160ade62625","snapshots\u002F2026-09-27T14-00-39+0200\u002Fskills\u002Fsoftware-development\u002Fplan","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71","2026-11-08 20:00:57",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add LyrikNilpferd71\u002FHermes-Backup --skill plan",{"tool":54,"command":55},"bunx","bunx skills add LyrikNilpferd71\u002FHermes-Backup --skill plan",{"tool":57,"command":58},"pnpm","pnpm dlx skills add LyrikNilpferd71\u002FHermes-Backup --skill plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-09-27T14-00-39+0200\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",true,[],[63,70,77,83,88,95],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":18},"01M76BBCCNA7WQ82Q8QNZH8PBK","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":18},"01M76BB8YS41CA3NKW0YMSSB88","systematic-debugging","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[],[],{"skillNo":78,"name":35,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":18},"01M76BB680FPNT998E1GM2QW10","Execute plans via delegate_task subagents (2-stage review).","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fsubagent-driven-development\u002FSKILL.md",[],[],{"skillNo":84,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":18},"01M76BB3C4ZB9S4RWPMM8MX0YB","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":18},"01M76BB0NK28KMP51YDB5R3EXA","hermes-agent-skill-authoring","Author in-repo SKILL.md files: frontmatter and structure.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fhermes-agent-skill-authoring\u002FSKILL.md",[],[],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":18},"01M76BAYV58H0CKNSTZE3ZH4NY","debugging-hermes-tui-commands","Debug Hermes TUI slash commands: Python, gateway, Ink UI.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fdebugging-hermes-tui-commands\u002FSKILL.md",[],[]]