[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73G6CPNQ6PR263QECSFQ3DX":3,"skill-same:01M73G6CPNQ6PR263QECSFQ3DX":49},{"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":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M73G6CPNQ6PR263QECSFQ3DX","create-slash-commands",null,"Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.","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\u002Ftaches--create-slash-commands\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: create-slash-commands\ndescription: Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.\norigin: \"https:\u002F\u002Fraw.githubusercontent.com\u002Fglittercowboy\u002Ftaches-cc-resources\u002Fmain\u002Fskills\u002Fcreate-slash-commands\u002FSKILL.md\"\n---\n\n\u003Cobjective>\nCreate effective slash commands for Claude Code that enable users to trigger reusable prompts with `\u002Fcommand-name` syntax. Slash commands expand as prompts in the current conversation, allowing teams to standardize workflows and operations. This skill teaches you to structure commands with XML tags, YAML frontmatter, dynamic context loading, and intelligent argument handling.\n\u003C\u002Fobjective>\n\n\u003Cquick_start>\n\n\u003Cworkflow>\n1. Create `.claude\u002Fcommands\u002F` directory (project) or use `~\u002F.claude\u002Fcommands\u002F` (personal)\n2. Create `command-name.md` file\n3. Add YAML frontmatter (at minimum: `description`)\n4. Write command prompt\n5. Test with `\u002Fcommand-name [args]`\n\u003C\u002Fworkflow>\n\n\u003Cexample>\n**File**: `.claude\u002Fcommands\u002Foptimize.md`\n\n```markdown\n---\ndescription: Analyze this code for performance issues and suggest optimizations\n---\n\nAnalyze the performance of this code and suggest three specific optimizations:\n```\n\n**Usage**: `\u002Foptimize`\n\nClaude receives the expanded prompt and analyzes the code in context.\n\u003C\u002Fexample>\n\u003C\u002Fquick_start>\n\n\u003Cxml_structure>\nAll generated slash commands should use XML tags in the body (after YAML frontmatter) for clarity and consistency.\n\n\u003Crequired_tags>\n\n**`\u003Cobjective>`** - What the command does and why it matters\n```markdown\n\u003Cobjective>\nWhat needs to happen and why this matters.\nContext about who uses this and what it accomplishes.\n\u003C\u002Fobjective>\n```\n\n**`\u003Cprocess>` or `\u003Csteps>`** - How to execute the command\n```markdown\n\u003Cprocess>\nSequential steps to accomplish the objective:\n1. First step\n2. Second step\n3. Final step\n\u003C\u002Fprocess>\n```\n\n**`\u003Csuccess_criteria>`** - How to know the command succeeded\n```markdown\n\u003Csuccess_criteria>\nClear, measurable criteria for successful completion.\n\u003C\u002Fsuccess_criteria>\n```\n\u003C\u002Frequired_tags>\n\n\u003Cconditional_tags>\n\n**`\u003Ccontext>`** - When loading dynamic state or files\n```markdown\n\u003Ccontext>\nCurrent state: ! `git status`\nRelevant files: @ package.json\n\u003C\u002Fcontext>\n```\n(Note: Remove the space after @ in actual usage)\n\n**`\u003Cverification>`** - When producing artifacts that need checking\n```markdown\n\u003Cverification>\nBefore completing, verify:\n- Specific test or check to perform\n- How to confirm it works\n\u003C\u002Fverification>\n```\n\n**`\u003Ctesting>`** - When running tests is part of the workflow\n```markdown\n\u003Ctesting>\nRun tests: ! `npm test`\nCheck linting: ! `npm run lint`\n\u003C\u002Ftesting>\n```\n\n**`\u003Coutput>`** - When creating\u002Fmodifying specific files\n```markdown\n\u003Coutput>\nFiles created\u002Fmodified:\n- `.\u002Fpath\u002Fto\u002Ffile.ext` - Description\n\u003C\u002Foutput>\n```\n\u003C\u002Fconditional_tags>\n\n\u003Cstructure_example>\n\n```markdown\n---\nname: example-command\ndescription: Does something useful\nargument-hint: [input]\n---\n\n\u003Cobjective>\nProcess $ARGUMENTS to accomplish [goal].\n\nThis helps [who] achieve [outcome].\n\u003C\u002Fobjective>\n\n\u003Ccontext>\nCurrent state: ! `relevant command`\nFiles: @ relevant\u002Ffiles\n\u003C\u002Fcontext>\n\n\u003Cprocess>\n1. Parse $ARGUMENTS\n2. Execute operation\n3. Verify results\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Operation completed without errors\n- Output matches expected format\n\u003C\u002Fsuccess_criteria>\n```\n\u003C\u002Fstructure_example>\n\n\u003Cintelligence_rules>\n\n**Simple commands** (single operation, no artifacts):\n- Required: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Example: `\u002Fcheck-todos`, `\u002Ffirst-principles`\n\n**Complex commands** (multi-step, produces artifacts):\n- Required: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Add: `\u003Ccontext>` (if loading state), `\u003Cverification>` (if creating files), `\u003Coutput>` (what gets created)\n- Example: `\u002Fcommit`, `\u002Fcreate-prompt`, `\u002Frun-prompt`\n\n**Commands with dynamic arguments**:\n- Use `$ARGUMENTS` in `\u003Cobjective>` or `\u003Cprocess>` tags\n- Include `argument-hint` in frontmatter\n- Make it clear what the arguments are for\n\n**Commands that produce files**:\n- Always include `\u003Coutput>` tag specifying what gets created\n- Always include `\u003Cverification>` tag with checks to perform\n\n**Commands that run tests\u002Fbuilds**:\n- Include `\u003Ctesting>` tag with specific commands\n- Include pass\u002Ffail criteria in `\u003Csuccess_criteria>`\n\u003C\u002Fintelligence_rules>\n\u003C\u002Fxml_structure>\n\n\u003Carguments_intelligence>\nThe skill should intelligently determine whether a slash command needs arguments.\n\n\u003Ccommands_that_need_arguments>\n\n**User provides specific input:**\n- `\u002Ffix-issue [issue-number]` - Needs issue number\n- `\u002Freview-pr [pr-number]` - Needs PR number\n- `\u002Foptimize [file-path]` - Needs file to optimize\n- `\u002Fcommit [type]` - Needs commit type (optional)\n\n**Pattern:** Task operates on user-specified data\n\nInclude `argument-hint: [description]` in frontmatter and reference `$ARGUMENTS` in the body.\n\u003C\u002Fcommands_that_need_arguments>\n\n\u003Ccommands_without_arguments>\n\n**Self-contained procedures:**\n- `\u002Fcheck-todos` - Operates on known file (TO-DOS.md)\n- `\u002Ffirst-principles` - Operates on current conversation\n- `\u002Fwhats-next` - Analyzes current context\n\n**Pattern:** Task operates on implicit context (current conversation, known files, project state)\n\nOmit `argument-hint` and don't reference `$ARGUMENTS`.\n\u003C\u002Fcommands_without_arguments>\n\n\u003Cincorporating_arguments>\n\n**In `\u003Cobjective>` tag:**\n```markdown\n\u003Cobjective>\nFix issue #$ARGUMENTS following project conventions.\n\nThis ensures bugs are resolved systematically with proper testing.\n\u003C\u002Fobjective>\n```\n\n**In `\u003Cprocess>` tag:**\n```markdown\n\u003Cprocess>\n1. Understand issue #$ARGUMENTS from issue tracker\n2. Locate relevant code\n3. Implement fix\n4. Add tests\n\u003C\u002Fprocess>\n```\n\n**In `\u003Ccontext>` tag:**\n```markdown\n\u003Ccontext>\nIssue details: @ issues\u002F$ARGUMENTS.md\nRelated files: ! `grep -r \"TODO.*$ARGUMENTS\" src\u002F`\n\u003C\u002Fcontext>\n```\n(Note: Remove the space after the exclamation mark in actual usage)\n\u003C\u002Fincorporating_arguments>\n\n\u003Cpositional_arguments>\n\nFor structured input, use `$1`, `$2`, `$3`:\n\n```markdown\n---\nargument-hint: \u003Cpr-number> \u003Cpriority> \u003Cassignee>\n---\n\n\u003Cobjective>\nReview PR #$1 with priority $2 and assign to $3.\n\u003C\u002Fobjective>\n```\n\n**Usage:** `\u002Freview-pr 456 high alice`\n\u003C\u002Fpositional_arguments>\n\u003C\u002Farguments_intelligence>\n\n\u003Cfile_structure>\n\n**Project commands**: `.claude\u002Fcommands\u002F`\n- Shared with team via version control\n- Shows `(project)` in `\u002Fhelp` list\n\n**Personal commands**: `~\u002F.claude\u002Fcommands\u002F`\n- Available across all your projects\n- Shows `(user)` in `\u002Fhelp` list\n\n**File naming**: `command-name.md` → invoked as `\u002Fcommand-name`\n\u003C\u002Ffile_structure>\n\n\u003Cyaml_frontmatter>\n\n\u003Cfield name=\"description\">\n**Required** - Describes what the command does\n\n```yaml\ndescription: Analyze this code for performance issues and suggest optimizations\n```\n\nShown in the `\u002Fhelp` command list.\n\u003C\u002Ffield>\n\n\u003Cfield name=\"allowed-tools\">\n**Optional** - Restricts which tools Claude can use\n\n```yaml\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n```\n\n**Formats**:\n- Array: `allowed-tools: [Read, Edit, Write]`\n- Single tool: `allowed-tools: SequentialThinking`\n- Bash restrictions: `allowed-tools: Bash(git add:*)`\n\nIf omitted: All tools available\n\u003C\u002Ffield>\n\u003C\u002Fyaml_frontmatter>\n\n\u003Carguments>\n\u003Call_arguments_string>\n\n**Command file**: `.claude\u002Fcommands\u002Ffix-issue.md`\n```markdown\n---\ndescription: Fix issue following coding standards\n---\n\nFix issue #$ARGUMENTS following our coding standards\n```\n\n**Usage**: `\u002Ffix-issue 123 high-priority`\n\n**Claude receives**: \"Fix issue #123 high-priority following our coding standards\"\n\u003C\u002Fall_arguments_string>\n\n\u003Cpositional_arguments_syntax>\n\n**Command file**: `.claude\u002Fcommands\u002Freview-pr.md`\n```markdown\n---\ndescription: Review PR with priority and assignee\n---\n\nReview PR #$1 with priority $2 and assign to $3\n```\n\n**Usage**: `\u002Freview-pr 456 high alice`\n\n**Claude receives**: \"Review PR #456 with priority high and assign to alice\"\n\nSee [references\u002Farguments.md](references\u002Farguments.md) for advanced patterns.\n\u003C\u002Fpositional_arguments_syntax>\n\u003C\u002Farguments>\n\n\u003Cdynamic_context>\n\nExecute bash commands before the prompt using the exclamation mark prefix directly before backticks (no space between).\n\n**Note:** Examples below show a space after the exclamation mark to prevent execution during skill loading. In actual slash commands, remove the space.\n\nExample:\n\n```markdown\n---\ndescription: Create a git commit\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n---\n\n## Context\n\n- Current git status: ! `git status`\n- Current git diff: ! `git diff HEAD`\n- Current branch: ! `git branch --show-current`\n- Recent commits: ! `git log --oneline -10`\n\n## Your task\n\nBased on the above changes, create a single git commit.\n```\n\nThe bash commands execute and their output is included in the expanded prompt.\n\u003C\u002Fdynamic_context>\n\n\u003Cfile_references>\n\nUse `@` prefix to reference specific files:\n\n```markdown\n---\ndescription: Review implementation\n---\n\nReview the implementation in @ src\u002Futils\u002Fhelpers.js\n```\n(Note: Remove the space after @ in actual usage)\n\nClaude can access the referenced file's contents.\n\u003C\u002Ffile_references>\n\n\u003Cbest_practices>\n\n**1. Always use XML structure**\n```yaml\n# All slash commands should have XML-structured bodies\n```\n\nAfter frontmatter, use XML tags:\n- `\u003Cobjective>` - What and why (always)\n- `\u003Cprocess>` - How to do it (always)\n- `\u003Csuccess_criteria>` - Definition of done (always)\n- Additional tags as needed (see xml_structure section)\n\n**2. Clear descriptions**\n```yaml\n# Good\ndescription: Analyze this code for performance issues and suggest optimizations\n\n# Bad\ndescription: Optimize stuff\n```\n\n**3. Use dynamic context for state-dependent tasks**\n```markdown\nCurrent git status: ! `git status`\nFiles changed: ! `git diff --name-only`\n```\n\n**4. Restrict tools when appropriate**\n```yaml\n# For git commands - prevent running arbitrary bash\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n\n# For analysis - thinking only\nallowed-tools: SequentialThinking\n```\n\n**5. Use $ARGUMENTS for flexibility**\n```markdown\nFind and fix issue #$ARGUMENTS\n```\n\n**6. Reference relevant files**\n```markdown\nReview @ package.json for dependencies\nAnalyze @ src\u002Fdatabase\u002F* for schema\n```\n(Note: Remove the space after @ in actual usage)\n\u003C\u002Fbest_practices>\n\n\u003Ccommon_patterns>\n\n**Simple analysis command**:\n```markdown\n---\ndescription: Review this code for security vulnerabilities\n---\n\n\u003Cobjective>\nReview code for security vulnerabilities and suggest fixes.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Scan code for common vulnerabilities (XSS, SQL injection, etc.)\n2. Identify specific issues with line numbers\n3. Suggest remediation for each issue\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- All major vulnerability types checked\n- Specific issues identified with locations\n- Actionable fixes provided\n\u003C\u002Fsuccess_criteria>\n```\n\n**Git workflow with context**:\n```markdown\n---\ndescription: Create a git commit\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n---\n\n\u003Cobjective>\nCreate a git commit for current changes following repository conventions.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\n- Current status: ! `git status`\n- Changes: ! `git diff HEAD`\n- Recent commits: ! `git log --oneline -5`\n\u003C\u002Fcontext>\n\n\u003Cprocess>\n1. Review staged and unstaged changes\n2. Stage relevant files\n3. Write commit message following recent commit style\n4. Create commit\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- All relevant changes staged\n- Commit message follows repository conventions\n- Commit created successfully\n\u003C\u002Fsuccess_criteria>\n```\n\n**Parameterized command**:\n```markdown\n---\ndescription: Fix issue following coding standards\nargument-hint: [issue-number]\n---\n\n\u003Cobjective>\nFix issue #$ARGUMENTS following project coding standards.\n\nThis ensures bugs are resolved systematically with proper testing.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Understand the issue described in ticket #$ARGUMENTS\n2. Locate the relevant code in codebase\n3. Implement a solution that addresses root cause\n4. Add appropriate tests\n5. Verify fix resolves the issue\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Issue fully understood and addressed\n- Solution follows coding standards\n- Tests added and passing\n- No regressions introduced\n\u003C\u002Fsuccess_criteria>\n```\n\n**File-specific command**:\n```markdown\n---\ndescription: Optimize code performance\nargument-hint: [file-path]\n---\n\n\u003Cobjective>\nAnalyze performance of @ $ARGUMENTS and suggest specific optimizations.\n\nThis helps improve application performance through targeted improvements.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Review code in @ $ARGUMENTS for performance issues\n2. Identify bottlenecks and inefficiencies\n3. Suggest three specific optimizations with rationale\n4. Estimate performance impact of each\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Performance issues clearly identified\n- Three concrete optimizations suggested\n- Implementation guidance provided\n- Performance impact estimated\n\u003C\u002Fsuccess_criteria>\n```\n\n**Usage**: `\u002Foptimize src\u002Futils\u002Fhelpers.js`\n\nSee [references\u002Fpatterns.md](references\u002Fpatterns.md) for more examples.\n\u003C\u002Fcommon_patterns>\n\n\u003Creference_guides>\n\n**Arguments reference**: [references\u002Farguments.md](references\u002Farguments.md)\n- $ARGUMENTS variable\n- Positional arguments ($1, $2, $3)\n- Parsing strategies\n- Examples from official docs\n\n**Patterns reference**: [references\u002Fpatterns.md](references\u002Fpatterns.md)\n- Git workflows\n- Code analysis\n- File operations\n- Security reviews\n- Examples from official docs\n\n**Tool restrictions**: [references\u002Ftool-restrictions.md](references\u002Ftool-restrictions.md)\n- Bash command patterns\n- Security best practices\n- When to restrict tools\n- Examples from official docs\n\u003C\u002Freference_guides>\n\n\u003Cgeneration_protocol>\n\n1. **Analyze the user's request**:\n   - What is the command's purpose?\n   - Does it need user input ($ARGUMENTS)?\n   - Does it produce files or artifacts?\n   - Does it require verification or testing?\n   - Is it simple (single-step) or complex (multi-step)?\n\n2. **Create frontmatter**:\n   ```yaml\n   ---\n   name: command-name\n   description: Clear description of what it does\n   argument-hint: [input] # Only if arguments needed\n   allowed-tools: [...] # Only if tool restrictions needed\n   ---\n   ```\n\n3. **Create XML-structured body**:\n\n   **Always include:**\n   - `\u003Cobjective>` - What and why\n   - `\u003Cprocess>` - How to do it (numbered steps)\n   - `\u003Csuccess_criteria>` - Definition of done\n\n   **Include when relevant:**\n   - `\u003Ccontext>` - Dynamic state (! `commands`) or file references (@ files)\n   - `\u003Cverification>` - Checks to perform if creating artifacts\n   - `\u003Ctesting>` - Test commands if tests are part of workflow\n   - `\u003Coutput>` - Files created\u002Fmodified\n\n4. **Integrate $ARGUMENTS properly**:\n   - If user input needed: Add `argument-hint` and use `$ARGUMENTS` in tags\n   - If self-contained: Omit `argument-hint` and `$ARGUMENTS`\n\n5. **Apply intelligence**:\n   - Simple commands: Keep it concise (objective + process + success criteria)\n   - Complex commands: Add context, verification, testing as needed\n   - Don't over-engineer simple commands\n   - Don't under-specify complex commands\n\n6. **Save the file**:\n   - Project: `.claude\u002Fcommands\u002Fcommand-name.md`\n   - Personal: `~\u002F.claude\u002Fcommands\u002Fcommand-name.md`\n\u003C\u002Fgeneration_protocol>\n\n\u003Csuccess_criteria>\nA well-structured slash command meets these criteria:\n\n**YAML Frontmatter**:\n- `description` field is clear and concise\n- `argument-hint` present if command accepts arguments\n- `allowed-tools` specified if tool restrictions needed\n\n**XML Structure**:\n- All three required tags present: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Conditional tags used appropriately based on complexity\n- No raw markdown headings in body\n- All XML tags properly closed\n\n**Arguments Handling**:\n- `$ARGUMENTS` used when command operates on user-specified data\n- Positional arguments (`$1`, `$2`, etc.) used when structured input needed\n- No `$ARGUMENTS` reference for self-contained commands\n\n**Functionality**:\n- Command expands correctly when invoked\n- Dynamic context loads properly (bash commands, file references)\n- Tool restrictions prevent unauthorized operations\n- Command accomplishes intended purpose reliably\n\n**Quality**:\n- Clear, actionable instructions in `\u003Cprocess>` tag\n- Measurable completion criteria in `\u003Csuccess_criteria>`\n- Appropriate level of detail (not over-engineered for simple tasks)\n- Examples provided when beneficial\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nCreate effective slash commands for Claude Code that enable users to trigger reusable prompts with `\u002Fcommand-name` syntax. Slash commands expand as prompts in the current conversation, allowing teams to standardize workflows and operations. This skill teaches you to structure commands with XML tags, YAML frontmatter, dynamic context loading, and intelligent argument handling.\n\u003C\u002Fobjective>\n\n\u003Cquick_start>\n\n\u003Cworkflow>\n1. Create `.claude\u002Fcommands\u002F` directory (project) or use `~\u002F.claude\u002Fcommands\u002F` (personal)\n2. Create `command-name.md` file\n3. Add YAML frontmatter (at minimum: `description`)\n4. Write command prompt\n5. Test with `\u002Fcommand-name [args]`\n\u003C\u002Fworkflow>\n\n\u003Cexample>\n**File**: `.claude\u002Fcommands\u002Foptimize.md`\n\n```markdown\n---\ndescription: Analyze this code for performance issues and suggest optimizations\n---\n\nAnalyze the performance of this code and suggest three specific optimizations:\n```\n\n**Usage**: `\u002Foptimize`\n\nClaude receives the expanded prompt and analyzes the code in context.\n\u003C\u002Fexample>\n\u003C\u002Fquick_start>\n\n\u003Cxml_structure>\nAll generated slash commands should use XML tags in the body (after YAML frontmatter) for clarity and consistency.\n\n\u003Crequired_tags>\n\n**`\u003Cobjective>`** - What the command does and why it matters\n```markdown\n\u003Cobjective>\nWhat needs to happen and why this matters.\nContext about who uses this and what it accomplishes.\n\u003C\u002Fobjective>\n```\n\n**`\u003Cprocess>` or `\u003Csteps>`** - How to execute the command\n```markdown\n\u003Cprocess>\nSequential steps to accomplish the objective:\n1. First step\n2. Second step\n3. Final step\n\u003C\u002Fprocess>\n```\n\n**`\u003Csuccess_criteria>`** - How to know the command succeeded\n```markdown\n\u003Csuccess_criteria>\nClear, measurable criteria for successful completion.\n\u003C\u002Fsuccess_criteria>\n```\n\u003C\u002Frequired_tags>\n\n\u003Cconditional_tags>\n\n**`\u003Ccontext>`** - When loading dynamic state or files\n```markdown\n\u003Ccontext>\nCurrent state: ! `git status`\nRelevant files: @ package.json\n\u003C\u002Fcontext>\n```\n(Note: Remove the space after @ in actual usage)\n\n**`\u003Cverification>`** - When producing artifacts that need checking\n```markdown\n\u003Cverification>\nBefore completing, verify:\n- Specific test or check to perform\n- How to confirm it works\n\u003C\u002Fverification>\n```\n\n**`\u003Ctesting>`** - When running tests is part of the workflow\n```markdown\n\u003Ctesting>\nRun tests: ! `npm test`\nCheck linting: ! `npm run lint`\n\u003C\u002Ftesting>\n```\n\n**`\u003Coutput>`** - When creating\u002Fmodifying specific files\n```markdown\n\u003Coutput>\nFiles created\u002Fmodified:\n- `.\u002Fpath\u002Fto\u002Ffile.ext` - Description\n\u003C\u002Foutput>\n```\n\u003C\u002Fconditional_tags>\n\n\u003Cstructure_example>\n\n```markdown\n---\nname: example-command\ndescription: Does something useful\nargument-hint: [input]\n---\n\n\u003Cobjective>\nProcess $ARGUMENTS to accomplish [goal].\n\nThis helps [who] achieve [outcome].\n\u003C\u002Fobjective>\n\n\u003Ccontext>\nCurrent state: ! `relevant command`\nFiles: @ relevant\u002Ffiles\n\u003C\u002Fcontext>\n\n\u003Cprocess>\n1. Parse $ARGUMENTS\n2. Execute operation\n3. Verify results\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Operation completed without errors\n- Output matches expected format\n\u003C\u002Fsuccess_criteria>\n```\n\u003C\u002Fstructure_example>\n\n\u003Cintelligence_rules>\n\n**Simple commands** (single operation, no artifacts):\n- Required: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Example: `\u002Fcheck-todos`, `\u002Ffirst-principles`\n\n**Complex commands** (multi-step, produces artifacts):\n- Required: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Add: `\u003Ccontext>` (if loading state), `\u003Cverification>` (if creating files), `\u003Coutput>` (what gets created)\n- Example: `\u002Fcommit`, `\u002Fcreate-prompt`, `\u002Frun-prompt`\n\n**Commands with dynamic arguments**:\n- Use `$ARGUMENTS` in `\u003Cobjective>` or `\u003Cprocess>` tags\n- Include `argument-hint` in frontmatter\n- Make it clear what the arguments are for\n\n**Commands that produce files**:\n- Always include `\u003Coutput>` tag specifying what gets created\n- Always include `\u003Cverification>` tag with checks to perform\n\n**Commands that run tests\u002Fbuilds**:\n- Include `\u003Ctesting>` tag with specific commands\n- Include pass\u002Ffail criteria in `\u003Csuccess_criteria>`\n\u003C\u002Fintelligence_rules>\n\u003C\u002Fxml_structure>\n\n\u003Carguments_intelligence>\nThe skill should intelligently determine whether a slash command needs arguments.\n\n\u003Ccommands_that_need_arguments>\n\n**User provides specific input:**\n- `\u002Ffix-issue [issue-number]` - Needs issue number\n- `\u002Freview-pr [pr-number]` - Needs PR number\n- `\u002Foptimize [file-path]` - Needs file to optimize\n- `\u002Fcommit [type]` - Needs commit type (optional)\n\n**Pattern:** Task operates on user-specified data\n\nInclude `argument-hint: [description]` in frontmatter and reference `$ARGUMENTS` in the body.\n\u003C\u002Fcommands_that_need_arguments>\n\n\u003Ccommands_without_arguments>\n\n**Self-contained procedures:**\n- `\u002Fcheck-todos` - Operates on known file (TO-DOS.md)\n- `\u002Ffirst-principles` - Operates on current conversation\n- `\u002Fwhats-next` - Analyzes current context\n\n**Pattern:** Task operates on implicit context (current conversation, known files, project state)\n\nOmit `argument-hint` and don't reference `$ARGUMENTS`.\n\u003C\u002Fcommands_without_arguments>\n\n\u003Cincorporating_arguments>\n\n**In `\u003Cobjective>` tag:**\n```markdown\n\u003Cobjective>\nFix issue #$ARGUMENTS following project conventions.\n\nThis ensures bugs are resolved systematically with proper testing.\n\u003C\u002Fobjective>\n```\n\n**In `\u003Cprocess>` tag:**\n```markdown\n\u003Cprocess>\n1. Understand issue #$ARGUMENTS from issue tracker\n2. Locate relevant code\n3. Implement fix\n4. Add tests\n\u003C\u002Fprocess>\n```\n\n**In `\u003Ccontext>` tag:**\n```markdown\n\u003Ccontext>\nIssue details: @ issues\u002F$ARGUMENTS.md\nRelated files: ! `grep -r \"TODO.*$ARGUMENTS\" src\u002F`\n\u003C\u002Fcontext>\n```\n(Note: Remove the space after the exclamation mark in actual usage)\n\u003C\u002Fincorporating_arguments>\n\n\u003Cpositional_arguments>\n\nFor structured input, use `$1`, `$2`, `$3`:\n\n```markdown\n---\nargument-hint: \u003Cpr-number> \u003Cpriority> \u003Cassignee>\n---\n\n\u003Cobjective>\nReview PR #$1 with priority $2 and assign to $3.\n\u003C\u002Fobjective>\n```\n\n**Usage:** `\u002Freview-pr 456 high alice`\n\u003C\u002Fpositional_arguments>\n\u003C\u002Farguments_intelligence>\n\n\u003Cfile_structure>\n\n**Project commands**: `.claude\u002Fcommands\u002F`\n- Shared with team via version control\n- Shows `(project)` in `\u002Fhelp` list\n\n**Personal commands**: `~\u002F.claude\u002Fcommands\u002F`\n- Available across all your projects\n- Shows `(user)` in `\u002Fhelp` list\n\n**File naming**: `command-name.md` → invoked as `\u002Fcommand-name`\n\u003C\u002Ffile_structure>\n\n\u003Cyaml_frontmatter>\n\n\u003Cfield name=\"description\">\n**Required** - Describes what the command does\n\n```yaml\ndescription: Analyze this code for performance issues and suggest optimizations\n```\n\nShown in the `\u002Fhelp` command list.\n\u003C\u002Ffield>\n\n\u003Cfield name=\"allowed-tools\">\n**Optional** - Restricts which tools Claude can use\n\n```yaml\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n```\n\n**Formats**:\n- Array: `allowed-tools: [Read, Edit, Write]`\n- Single tool: `allowed-tools: SequentialThinking`\n- Bash restrictions: `allowed-tools: Bash(git add:*)`\n\nIf omitted: All tools available\n\u003C\u002Ffield>\n\u003C\u002Fyaml_frontmatter>\n\n\u003Carguments>\n\u003Call_arguments_string>\n\n**Command file**: `.claude\u002Fcommands\u002Ffix-issue.md`\n```markdown\n---\ndescription: Fix issue following coding standards\n---\n\nFix issue #$ARGUMENTS following our coding standards\n```\n\n**Usage**: `\u002Ffix-issue 123 high-priority`\n\n**Claude receives**: \"Fix issue #123 high-priority following our coding standards\"\n\u003C\u002Fall_arguments_string>\n\n\u003Cpositional_arguments_syntax>\n\n**Command file**: `.claude\u002Fcommands\u002Freview-pr.md`\n```markdown\n---\ndescription: Review PR with priority and assignee\n---\n\nReview PR #$1 with priority $2 and assign to $3\n```\n\n**Usage**: `\u002Freview-pr 456 high alice`\n\n**Claude receives**: \"Review PR #456 with priority high and assign to alice\"\n\nSee [references\u002Farguments.md](references\u002Farguments.md) for advanced patterns.\n\u003C\u002Fpositional_arguments_syntax>\n\u003C\u002Farguments>\n\n\u003Cdynamic_context>\n\nExecute bash commands before the prompt using the exclamation mark prefix directly before backticks (no space between).\n\n**Note:** Examples below show a space after the exclamation mark to prevent execution during skill loading. In actual slash commands, remove the space.\n\nExample:\n\n```markdown\n---\ndescription: Create a git commit\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n---\n\n## Context\n\n- Current git status: ! `git status`\n- Current git diff: ! `git diff HEAD`\n- Current branch: ! `git branch --show-current`\n- Recent commits: ! `git log --oneline -10`\n\n## Your task\n\nBased on the above changes, create a single git commit.\n```\n\nThe bash commands execute and their output is included in the expanded prompt.\n\u003C\u002Fdynamic_context>\n\n\u003Cfile_references>\n\nUse `@` prefix to reference specific files:\n\n```markdown\n---\ndescription: Review implementation\n---\n\nReview the implementation in @ src\u002Futils\u002Fhelpers.js\n```\n(Note: Remove the space after @ in actual usage)\n\nClaude can access the referenced file's contents.\n\u003C\u002Ffile_references>\n\n\u003Cbest_practices>\n\n**1. Always use XML structure**\n```yaml\n# All slash commands should have XML-structured bodies\n```\n\nAfter frontmatter, use XML tags:\n- `\u003Cobjective>` - What and why (always)\n- `\u003Cprocess>` - How to do it (always)\n- `\u003Csuccess_criteria>` - Definition of done (always)\n- Additional tags as needed (see xml_structure section)\n\n**2. Clear descriptions**\n```yaml\n# Good\ndescription: Analyze this code for performance issues and suggest optimizations\n\n# Bad\ndescription: Optimize stuff\n```\n\n**3. Use dynamic context for state-dependent tasks**\n```markdown\nCurrent git status: ! `git status`\nFiles changed: ! `git diff --name-only`\n```\n\n**4. Restrict tools when appropriate**\n```yaml\n# For git commands - prevent running arbitrary bash\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n\n# For analysis - thinking only\nallowed-tools: SequentialThinking\n```\n\n**5. Use $ARGUMENTS for flexibility**\n```markdown\nFind and fix issue #$ARGUMENTS\n```\n\n**6. Reference relevant files**\n```markdown\nReview @ package.json for dependencies\nAnalyze @ src\u002Fdatabase\u002F* for schema\n```\n(Note: Remove the space after @ in actual usage)\n\u003C\u002Fbest_practices>\n\n\u003Ccommon_patterns>\n\n**Simple analysis command**:\n```markdown\n---\ndescription: Review this code for security vulnerabilities\n---\n\n\u003Cobjective>\nReview code for security vulnerabilities and suggest fixes.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Scan code for common vulnerabilities (XSS, SQL injection, etc.)\n2. Identify specific issues with line numbers\n3. Suggest remediation for each issue\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- All major vulnerability types checked\n- Specific issues identified with locations\n- Actionable fixes provided\n\u003C\u002Fsuccess_criteria>\n```\n\n**Git workflow with context**:\n```markdown\n---\ndescription: Create a git commit\nallowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)\n---\n\n\u003Cobjective>\nCreate a git commit for current changes following repository conventions.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\n- Current status: ! `git status`\n- Changes: ! `git diff HEAD`\n- Recent commits: ! `git log --oneline -5`\n\u003C\u002Fcontext>\n\n\u003Cprocess>\n1. Review staged and unstaged changes\n2. Stage relevant files\n3. Write commit message following recent commit style\n4. Create commit\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- All relevant changes staged\n- Commit message follows repository conventions\n- Commit created successfully\n\u003C\u002Fsuccess_criteria>\n```\n\n**Parameterized command**:\n```markdown\n---\ndescription: Fix issue following coding standards\nargument-hint: [issue-number]\n---\n\n\u003Cobjective>\nFix issue #$ARGUMENTS following project coding standards.\n\nThis ensures bugs are resolved systematically with proper testing.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Understand the issue described in ticket #$ARGUMENTS\n2. Locate the relevant code in codebase\n3. Implement a solution that addresses root cause\n4. Add appropriate tests\n5. Verify fix resolves the issue\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Issue fully understood and addressed\n- Solution follows coding standards\n- Tests added and passing\n- No regressions introduced\n\u003C\u002Fsuccess_criteria>\n```\n\n**File-specific command**:\n```markdown\n---\ndescription: Optimize code performance\nargument-hint: [file-path]\n---\n\n\u003Cobjective>\nAnalyze performance of @ $ARGUMENTS and suggest specific optimizations.\n\nThis helps improve application performance through targeted improvements.\n\u003C\u002Fobjective>\n\n\u003Cprocess>\n1. Review code in @ $ARGUMENTS for performance issues\n2. Identify bottlenecks and inefficiencies\n3. Suggest three specific optimizations with rationale\n4. Estimate performance impact of each\n\u003C\u002Fprocess>\n\n\u003Csuccess_criteria>\n- Performance issues clearly identified\n- Three concrete optimizations suggested\n- Implementation guidance provided\n- Performance impact estimated\n\u003C\u002Fsuccess_criteria>\n```\n\n**Usage**: `\u002Foptimize src\u002Futils\u002Fhelpers.js`\n\nSee [references\u002Fpatterns.md](references\u002Fpatterns.md) for more examples.\n\u003C\u002Fcommon_patterns>\n\n\u003Creference_guides>\n\n**Arguments reference**: [references\u002Farguments.md](references\u002Farguments.md)\n- $ARGUMENTS variable\n- Positional arguments ($1, $2, $3)\n- Parsing strategies\n- Examples from official docs\n\n**Patterns reference**: [references\u002Fpatterns.md](references\u002Fpatterns.md)\n- Git workflows\n- Code analysis\n- File operations\n- Security reviews\n- Examples from official docs\n\n**Tool restrictions**: [references\u002Ftool-restrictions.md](references\u002Ftool-restrictions.md)\n- Bash command patterns\n- Security best practices\n- When to restrict tools\n- Examples from official docs\n\u003C\u002Freference_guides>\n\n\u003Cgeneration_protocol>\n\n1. **Analyze the user's request**:\n   - What is the command's purpose?\n   - Does it need user input ($ARGUMENTS)?\n   - Does it produce files or artifacts?\n   - Does it require verification or testing?\n   - Is it simple (single-step) or complex (multi-step)?\n\n2. **Create frontmatter**:\n   ```yaml\n   ---\n   name: command-name\n   description: Clear description of what it does\n   argument-hint: [input] # Only if arguments needed\n   allowed-tools: [...] # Only if tool restrictions needed\n   ---\n   ```\n\n3. **Create XML-structured body**:\n\n   **Always include:**\n   - `\u003Cobjective>` - What and why\n   - `\u003Cprocess>` - How to do it (numbered steps)\n   - `\u003Csuccess_criteria>` - Definition of done\n\n   **Include when relevant:**\n   - `\u003Ccontext>` - Dynamic state (! `commands`) or file references (@ files)\n   - `\u003Cverification>` - Checks to perform if creating artifacts\n   - `\u003Ctesting>` - Test commands if tests are part of workflow\n   - `\u003Coutput>` - Files created\u002Fmodified\n\n4. **Integrate $ARGUMENTS properly**:\n   - If user input needed: Add `argument-hint` and use `$ARGUMENTS` in tags\n   - If self-contained: Omit `argument-hint` and `$ARGUMENTS`\n\n5. **Apply intelligence**:\n   - Simple commands: Keep it concise (objective + process + success criteria)\n   - Complex commands: Add context, verification, testing as needed\n   - Don't over-engineer simple commands\n   - Don't under-specify complex commands\n\n6. **Save the file**:\n   - Project: `.claude\u002Fcommands\u002Fcommand-name.md`\n   - Personal: `~\u002F.claude\u002Fcommands\u002Fcommand-name.md`\n\u003C\u002Fgeneration_protocol>\n\n\u003Csuccess_criteria>\nA well-structured slash command meets these criteria:\n\n**YAML Frontmatter**:\n- `description` field is clear and concise\n- `argument-hint` present if command accepts arguments\n- `allowed-tools` specified if tool restrictions needed\n\n**XML Structure**:\n- All three required tags present: `\u003Cobjective>`, `\u003Cprocess>`, `\u003Csuccess_criteria>`\n- Conditional tags used appropriately based on complexity\n- No raw markdown headings in body\n- All XML tags properly closed\n\n**Arguments Handling**:\n- `$ARGUMENTS` used when command operates on user-specified data\n- Positional arguments (`$1`, `$2`, etc.) used when structured input needed\n- No `$ARGUMENTS` reference for self-contained commands\n\n**Functionality**:\n- Command expands correctly when invoked\n- Dynamic context loads properly (bash commands, file references)\n- Tool restrictions prevent unauthorized operations\n- Command accomplishes intended purpose reliably\n\n**Quality**:\n- Clear, actionable instructions in `\u003Cprocess>` tag\n- Measurable completion criteria in `\u003Csuccess_criteria>`\n- Appropriate level of detail (not over-engineered for simple tasks)\n- Examples provided when beneficial\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"origin":24,"description":7},"https:\u002F\u002Fraw.githubusercontent.com\u002Fglittercowboy\u002Ftaches-cc-resources\u002Fmain\u002Fskills\u002Fcreate-slash-commands\u002FSKILL.md","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Ftaches--create-slash-commands",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":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill create-slash-commands",{"tool":41,"command":42},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill create-slash-commands",{"tool":44,"command":45},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill create-slash-commands","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Ftaches--create-slash-commands\u002FSKILL.md",true,[],[50,58,65,73,81,89],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":54,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"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":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"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":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":69,"sourceHtmlUrl":70,"categories":71,"keywords":72,"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":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":77,"sourceHtmlUrl":78,"categories":79,"keywords":80,"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":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":85,"sourceHtmlUrl":86,"categories":87,"keywords":88,"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":90,"name":91,"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":92,"categories":93,"keywords":94,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]