[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAR806BXF23TM5H7MPBW8M":3,"skill-same:01M6DAR806BXF23TM5H7MPBW8M":78},{"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":30,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":13,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6DAR806BXF23TM5H7MPBW8M","writing-agents",null,"Guide for creating effective LLM subagent prompts and personas. This skill should be used when writing, reviewing, or improving agent definitions for Claude Code or similar multi-agent systems. Covers YAML frontmatter, system prompt structure, tool selection, and common pitfalls.","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Farchive\u002Fwriting-agents\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"writing","writing agents","code","yaml","subagent","system","tool","multi-agent","common","prompt","guide","prompts","selection","personas","structure","systems","2026-11-10 10:12:30",false,"---\nname: writing-agents\ndescription: Guide for creating effective LLM subagent prompts and personas. This skill should be used when writing, reviewing, or improving agent definitions for Claude Code or similar multi-agent systems. Covers YAML frontmatter, system prompt structure, tool selection, and common pitfalls.\n---\n\n# Writing Effective LLM Agents\n\nThis skill provides guidance for creating high-quality subagent prompts that enable effective task delegation in multi-agent systems like Claude Code.\n\n## Overview\n\nSubagents are specialized AI assistants that handle specific types of tasks. Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions. The quality of a subagent is measured by how reliably it accomplishes its intended tasks and how clearly it communicates results.\n\n### What Makes a Good Subagent\n\n1. **Focused scope** - Excels at one specific task or domain\n2. **Clear delegation trigger** - Description tells the parent agent exactly when to delegate\n3. **Operational instructions** - System prompt provides actionable steps, not abstract principles\n4. **Appropriate tool access** - Only the tools needed for the task\n5. **Structured output** - Consistent, predictable response format\n\n---\n\n## Agent File Structure\n\nAgent files use YAML frontmatter for configuration, followed by the system prompt in Markdown:\n\n```markdown\n---\nname: agent-name\ndescription: When and why to use this agent\ntools: Tool1, Tool2, Tool3\nmodel: inherit\n---\n\nSystem prompt content here...\n```\n\n### Required Frontmatter Fields\n\n| Field | Description | Example |\n|-------|-------------|---------|\n| `name` | Unique identifier using lowercase letters and hyphens | `code-reviewer` |\n| `description` | When the parent agent should delegate to this subagent | See \"Writing Effective Descriptions\" below |\n\n### Optional Frontmatter Fields\n\n| Field | Default | Description |\n|-------|---------|-------------|\n| `tools` | Inherits all | Comma-separated list of allowed tools |\n| `disallowedTools` | None | Tools to explicitly deny |\n| `model` | `inherit` | Model to use: `sonnet`, `opus`, `haiku`, or `inherit` |\n| `permissionMode` | `default` | Permission handling: `default`, `acceptEdits`, `dontAsk`, `bypassPermissions`, `plan` |\n| `skills` | None | Skills to preload into context |\n| `hooks` | None | Lifecycle hooks for validation |\n\n---\n\n## Writing Effective Descriptions\n\nThe `description` field determines when the parent agent delegates tasks. To write effective descriptions:\n\n### Make Descriptions Action-Oriented\n\nDescribe what the agent does and when to use it, not what it is.\n\n**Weak:**\n```yaml\ndescription: A code reviewer agent\n```\n\n**Strong:**\n```yaml\ndescription: Principal+ code reviewer for quality and correctness assessment. Use proactively after code modifications to review changes, trace execution paths, identify regressions, and provide evidence-based feedback ordered by severity.\n```\n\n### Include Delegation Triggers\n\nUse phrases like \"Use proactively when...\" or \"Use after...\" to signal automatic delegation.\n\n**Examples:**\n- `Use proactively after code changes to run tests and verify behavior`\n- `Use when defining scope, surfacing trade-offs, or creating implementation plans`\n- `Use immediately after writing code to review for quality issues`\n\n### Specify Expertise Level\n\nInclude seniority\u002Fexpertise level to set expectations for output quality.\n\n**Examples:**\n- `Staff+ software engineer for implementation tasks`\n- `Principal+ code reviewer for quality assessment`\n- `Senior security engineer for vulnerability analysis`\n\n---\n\n## System Prompt Structure\n\nThe body of the agent file becomes the system prompt. Structure it for operational clarity, not as a job description.\n\n### High-Value Sections\n\n#### 1. Role Statement (1-2 sentences)\n\nStart with a clear statement of identity and purpose.\n\n```markdown\nYou are a Staff+ QA Engineer verifying behavior with reproducible evidence and preventing regressions.\n```\n\n#### 2. \"When Invoked\" Action Steps\n\nProvide numbered steps for immediate execution upon invocation. This section drives actual behavior and should be included in every agent.\n\n```markdown\nWhen invoked:\n1. Run `git diff` to see recent changes\n2. Identify the scope and intent of the change\n3. Trace execution paths affected by the change\n4. Check for correctness, security, and test coverage\n5. Assess regression and compatibility risks\n6. Report findings by severity with file references\n```\n\n#### 3. Domain-Specific Checklist\n\nProvide concrete items to verify, not abstract principles.\n\n```markdown\nSecurity review checklist:\n- No secrets, API keys, or credentials in code or logs\n- Input validation on all untrusted data\n- Output encoding to prevent XSS\n- Parameterized queries to prevent SQL injection\n- Authentication checks on protected endpoints\n```\n\n#### 4. Output Format Specification\n\nDefine the exact response structure. Use numbered sections with bold labels.\n\n```markdown\nFor each review, provide:\n1. **Summary**: What the change does (1-2 sentences)\n2. **Critical issues**: Must-fix problems with file:line references\n3. **Warnings**: Should-fix concerns with evidence\n4. **Suggestions**: Optional improvements\n5. **Questions**: Clarifications needed before approval\n```\n\n#### 5. Red Flags \u002F Anti-Patterns\n\nList specific behaviors to avoid. Frame as actions, not personality traits.\n\n```markdown\nRed flags to avoid:\n- Making claims without file references or evidence\n- Suggesting broad refactors without clear benefit\n- Claiming success without verification evidence\n- Quick-fixing without understanding root cause\n```\n\n### Low-Value Sections to Avoid\n\n- **Mission statements** - Too abstract to drive behavior\n- **Core values** - Models already have values; focus on actions\n- **Lengthy background** - Wastes context window\n- **Personality descriptions** - Focus on actions, not identity\n- **Verbose explanations** - Be concise and actionable\n\n---\n\n## Tool Selection Guidelines\n\nGrant only the tools necessary for the task. Restricting tools prevents scope creep and enforces the agent's role.\n\n### Common Tool Configurations\n\n| Agent Type | Typical Tools | Rationale |\n|------------|---------------|-----------|\n| **Read-only reviewer** | Read, Grep, Glob, Bash | Inspect code and run git commands, no modification |\n| **Implementation** | Read, Edit, Write, Bash, Grep, Glob | Full modification capabilities |\n| **Planner** | Read, Grep, Glob | Read-only, no execution |\n| **Tester** | Read, Edit, Write, Bash, Grep, Glob | Write tests and run them |\n| **Security auditor** | Read, Bash, Grep, Glob | Read-only plus security tools via Bash |\n\n### Tool Restriction Patterns\n\n**To deny destructive tools for reviewers:**\n```yaml\ntools: Read, Bash, Grep, Glob\n# Implicitly denies Edit, Write\n```\n\n**To use fine-grained control:**\n```yaml\ntools: Read, Edit, Write, Bash, Grep, Glob\ndisallowedTools: Write\n# Can edit existing files but not create new ones\n```\n\n---\n\n## Common Pitfalls\n\n### Pitfall 1: Abstract Role Descriptions\n\n**Problem:** System prompts that read like job descriptions fail to drive action.\n\n```markdown\n# Avoid\n## Mission\nDeliver high-quality code with explicit reasoning.\n\n## Core Principles\n- Maintain code quality\n- Follow best practices\n```\n\n**Solution:** Replace with operational instructions.\n\n```markdown\n# Prefer\nYou are a Staff+ software engineer delivering correct, maintainable code changes.\n\nWhen invoked:\n1. Clarify scope and success criteria if ambiguous\n2. Inspect existing code before making changes\n3. Implement changes matching local style\n4. Verify outcomes with tests or concrete evidence\n5. Report what changed and how to verify\n```\n\n### Pitfall 2: Missing Output Format\n\n**Problem:** Agent produces inconsistent, hard-to-parse responses.\n\n**Solution:** Always specify exact output structure.\n\n```markdown\nFor each implementation, provide:\n1. **Summary**: What changed and why (with file paths)\n2. **Verification**: Commands to run and expected outcomes\n3. **Risks**: Edge cases, follow-ups, or concerns (if any)\n```\n\n### Pitfall 3: Vague Descriptions\n\n**Problem:** Parent agent cannot determine when to delegate.\n\n```markdown\n# Avoid\ndescription: Helps with code\n```\n\n**Solution:** Specify triggers and capabilities.\n\n```markdown\n# Prefer\ndescription: Staff+ QA engineer for test execution. Use proactively after code changes to run tests, verify behavior, and report failures with reproduction steps.\n```\n\n### Pitfall 4: Overly Broad Tool Access\n\n**Problem:** Reviewer agent with Edit access might \"fix\" issues instead of reporting them.\n\n**Solution:** Match tools to the agent's role. Read-only agents require read-only tools.\n\n### Pitfall 5: No Decision Gates\n\n**Problem:** Agent takes actions without appropriate checkpoints.\n\n**Solution:** Include explicit gates.\n\n```markdown\nDecision gates:\n- Do not implement without a clear plan for non-trivial work\n- Do not expand scope without explicit confirmation\n- If verification fails, perform root-cause analysis before retrying\n```\n\n### Pitfall 6: Missing Evidence Requirements\n\n**Problem:** Agent makes claims without substantiation.\n\n**Solution:** Require evidence in the output format.\n\n```markdown\n- Cite file paths and line numbers for all findings\n- Include exact commands run and their outputs\n- Separate verified facts from inferences\n```\n\n---\n\n## Model Selection Guidelines\n\n| Model | Best For | Trade-offs |\n|-------|----------|------------|\n| `haiku` | Fast, simple tasks (file search, basic analysis) | Lower capability, faster and cheaper |\n| `sonnet` | Balanced tasks (code review, moderate analysis) | Good capability\u002Fcost balance |\n| `opus` | Complex reasoning, architecture decisions | Highest capability, slower |\n| `inherit` | Match parent conversation | Default choice for most agents |\n\n**Recommendation:** Default to `inherit` unless there is a specific reason to override.\n\n---\n\n## Quality Checklist\n\nTo verify agent quality before finalizing:\n\n### Frontmatter\n- [ ] `name` uses lowercase-hyphenated format\n- [ ] `description` includes delegation triggers (\"Use proactively when...\")\n- [ ] `description` specifies expertise level\n- [ ] `tools` restricted to what is necessary\n- [ ] `model` appropriate for the task\n\n### System Prompt\n- [ ] Starts with clear role statement (1-2 sentences)\n- [ ] Includes \"When invoked:\" numbered action steps\n- [ ] Has domain-specific checklist\n- [ ] Specifies exact output format with sections\n- [ ] Lists red flags \u002F anti-patterns to avoid\n- [ ] Includes decision gates if applicable\n\n### Content Quality\n- [ ] Uses imperative\u002Foperational language, not abstract principles\n- [ ] Checklists contain concrete, verifiable items\n- [ ] Output format uses numbered sections with bold labels\n- [ ] No verbose mission statements or personality descriptions\n- [ ] Evidence requirements are explicit\n\n---\n\n## Reference\n\nFor complete examples, see the reference file: [Agent Examples](.\u002Freferences\u002Fexamples.md)\n\nFor the Claude Code subagents specification: [Claude Code Sub-agents Documentation](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fsub-agents)\n","# Writing Effective LLM Agents\n\nThis skill provides guidance for creating high-quality subagent prompts that enable effective task delegation in multi-agent systems like Claude Code.\n\n## Overview\n\nSubagents are specialized AI assistants that handle specific types of tasks. Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions. The quality of a subagent is measured by how reliably it accomplishes its intended tasks and how clearly it communicates results.\n\n### What Makes a Good Subagent\n\n1. **Focused scope** - Excels at one specific task or domain\n2. **Clear delegation trigger** - Description tells the parent agent exactly when to delegate\n3. **Operational instructions** - System prompt provides actionable steps, not abstract principles\n4. **Appropriate tool access** - Only the tools needed for the task\n5. **Structured output** - Consistent, predictable response format\n\n---\n\n## Agent File Structure\n\nAgent files use YAML frontmatter for configuration, followed by the system prompt in Markdown:\n\n```markdown\n---\nname: agent-name\ndescription: When and why to use this agent\ntools: Tool1, Tool2, Tool3\nmodel: inherit\n---\n\nSystem prompt content here...\n```\n\n### Required Frontmatter Fields\n\n| Field | Description | Example |\n|-------|-------------|---------|\n| `name` | Unique identifier using lowercase letters and hyphens | `code-reviewer` |\n| `description` | When the parent agent should delegate to this subagent | See \"Writing Effective Descriptions\" below |\n\n### Optional Frontmatter Fields\n\n| Field | Default | Description |\n|-------|---------|-------------|\n| `tools` | Inherits all | Comma-separated list of allowed tools |\n| `disallowedTools` | None | Tools to explicitly deny |\n| `model` | `inherit` | Model to use: `sonnet`, `opus`, `haiku`, or `inherit` |\n| `permissionMode` | `default` | Permission handling: `default`, `acceptEdits`, `dontAsk`, `bypassPermissions`, `plan` |\n| `skills` | None | Skills to preload into context |\n| `hooks` | None | Lifecycle hooks for validation |\n\n---\n\n## Writing Effective Descriptions\n\nThe `description` field determines when the parent agent delegates tasks. To write effective descriptions:\n\n### Make Descriptions Action-Oriented\n\nDescribe what the agent does and when to use it, not what it is.\n\n**Weak:**\n```yaml\ndescription: A code reviewer agent\n```\n\n**Strong:**\n```yaml\ndescription: Principal+ code reviewer for quality and correctness assessment. Use proactively after code modifications to review changes, trace execution paths, identify regressions, and provide evidence-based feedback ordered by severity.\n```\n\n### Include Delegation Triggers\n\nUse phrases like \"Use proactively when...\" or \"Use after...\" to signal automatic delegation.\n\n**Examples:**\n- `Use proactively after code changes to run tests and verify behavior`\n- `Use when defining scope, surfacing trade-offs, or creating implementation plans`\n- `Use immediately after writing code to review for quality issues`\n\n### Specify Expertise Level\n\nInclude seniority\u002Fexpertise level to set expectations for output quality.\n\n**Examples:**\n- `Staff+ software engineer for implementation tasks`\n- `Principal+ code reviewer for quality assessment`\n- `Senior security engineer for vulnerability analysis`\n\n---\n\n## System Prompt Structure\n\nThe body of the agent file becomes the system prompt. Structure it for operational clarity, not as a job description.\n\n### High-Value Sections\n\n#### 1. Role Statement (1-2 sentences)\n\nStart with a clear statement of identity and purpose.\n\n```markdown\nYou are a Staff+ QA Engineer verifying behavior with reproducible evidence and preventing regressions.\n```\n\n#### 2. \"When Invoked\" Action Steps\n\nProvide numbered steps for immediate execution upon invocation. This section drives actual behavior and should be included in every agent.\n\n```markdown\nWhen invoked:\n1. Run `git diff` to see recent changes\n2. Identify the scope and intent of the change\n3. Trace execution paths affected by the change\n4. Check for correctness, security, and test coverage\n5. Assess regression and compatibility risks\n6. Report findings by severity with file references\n```\n\n#### 3. Domain-Specific Checklist\n\nProvide concrete items to verify, not abstract principles.\n\n```markdown\nSecurity review checklist:\n- No secrets, API keys, or credentials in code or logs\n- Input validation on all untrusted data\n- Output encoding to prevent XSS\n- Parameterized queries to prevent SQL injection\n- Authentication checks on protected endpoints\n```\n\n#### 4. Output Format Specification\n\nDefine the exact response structure. Use numbered sections with bold labels.\n\n```markdown\nFor each review, provide:\n1. **Summary**: What the change does (1-2 sentences)\n2. **Critical issues**: Must-fix problems with file:line references\n3. **Warnings**: Should-fix concerns with evidence\n4. **Suggestions**: Optional improvements\n5. **Questions**: Clarifications needed before approval\n```\n\n#### 5. Red Flags \u002F Anti-Patterns\n\nList specific behaviors to avoid. Frame as actions, not personality traits.\n\n```markdown\nRed flags to avoid:\n- Making claims without file references or evidence\n- Suggesting broad refactors without clear benefit\n- Claiming success without verification evidence\n- Quick-fixing without understanding root cause\n```\n\n### Low-Value Sections to Avoid\n\n- **Mission statements** - Too abstract to drive behavior\n- **Core values** - Models already have values; focus on actions\n- **Lengthy background** - Wastes context window\n- **Personality descriptions** - Focus on actions, not identity\n- **Verbose explanations** - Be concise and actionable\n\n---\n\n## Tool Selection Guidelines\n\nGrant only the tools necessary for the task. Restricting tools prevents scope creep and enforces the agent's role.\n\n### Common Tool Configurations\n\n| Agent Type | Typical Tools | Rationale |\n|------------|---------------|-----------|\n| **Read-only reviewer** | Read, Grep, Glob, Bash | Inspect code and run git commands, no modification |\n| **Implementation** | Read, Edit, Write, Bash, Grep, Glob | Full modification capabilities |\n| **Planner** | Read, Grep, Glob | Read-only, no execution |\n| **Tester** | Read, Edit, Write, Bash, Grep, Glob | Write tests and run them |\n| **Security auditor** | Read, Bash, Grep, Glob | Read-only plus security tools via Bash |\n\n### Tool Restriction Patterns\n\n**To deny destructive tools for reviewers:**\n```yaml\ntools: Read, Bash, Grep, Glob\n# Implicitly denies Edit, Write\n```\n\n**To use fine-grained control:**\n```yaml\ntools: Read, Edit, Write, Bash, Grep, Glob\ndisallowedTools: Write\n# Can edit existing files but not create new ones\n```\n\n---\n\n## Common Pitfalls\n\n### Pitfall 1: Abstract Role Descriptions\n\n**Problem:** System prompts that read like job descriptions fail to drive action.\n\n```markdown\n# Avoid\n## Mission\nDeliver high-quality code with explicit reasoning.\n\n## Core Principles\n- Maintain code quality\n- Follow best practices\n```\n\n**Solution:** Replace with operational instructions.\n\n```markdown\n# Prefer\nYou are a Staff+ software engineer delivering correct, maintainable code changes.\n\nWhen invoked:\n1. Clarify scope and success criteria if ambiguous\n2. Inspect existing code before making changes\n3. Implement changes matching local style\n4. Verify outcomes with tests or concrete evidence\n5. Report what changed and how to verify\n```\n\n### Pitfall 2: Missing Output Format\n\n**Problem:** Agent produces inconsistent, hard-to-parse responses.\n\n**Solution:** Always specify exact output structure.\n\n```markdown\nFor each implementation, provide:\n1. **Summary**: What changed and why (with file paths)\n2. **Verification**: Commands to run and expected outcomes\n3. **Risks**: Edge cases, follow-ups, or concerns (if any)\n```\n\n### Pitfall 3: Vague Descriptions\n\n**Problem:** Parent agent cannot determine when to delegate.\n\n```markdown\n# Avoid\ndescription: Helps with code\n```\n\n**Solution:** Specify triggers and capabilities.\n\n```markdown\n# Prefer\ndescription: Staff+ QA engineer for test execution. Use proactively after code changes to run tests, verify behavior, and report failures with reproduction steps.\n```\n\n### Pitfall 4: Overly Broad Tool Access\n\n**Problem:** Reviewer agent with Edit access might \"fix\" issues instead of reporting them.\n\n**Solution:** Match tools to the agent's role. Read-only agents require read-only tools.\n\n### Pitfall 5: No Decision Gates\n\n**Problem:** Agent takes actions without appropriate checkpoints.\n\n**Solution:** Include explicit gates.\n\n```markdown\nDecision gates:\n- Do not implement without a clear plan for non-trivial work\n- Do not expand scope without explicit confirmation\n- If verification fails, perform root-cause analysis before retrying\n```\n\n### Pitfall 6: Missing Evidence Requirements\n\n**Problem:** Agent makes claims without substantiation.\n\n**Solution:** Require evidence in the output format.\n\n```markdown\n- Cite file paths and line numbers for all findings\n- Include exact commands run and their outputs\n- Separate verified facts from inferences\n```\n\n---\n\n## Model Selection Guidelines\n\n| Model | Best For | Trade-offs |\n|-------|----------|------------|\n| `haiku` | Fast, simple tasks (file search, basic analysis) | Lower capability, faster and cheaper |\n| `sonnet` | Balanced tasks (code review, moderate analysis) | Good capability\u002Fcost balance |\n| `opus` | Complex reasoning, architecture decisions | Highest capability, slower |\n| `inherit` | Match parent conversation | Default choice for most agents |\n\n**Recommendation:** Default to `inherit` unless there is a specific reason to override.\n\n---\n\n## Quality Checklist\n\nTo verify agent quality before finalizing:\n\n### Frontmatter\n- [ ] `name` uses lowercase-hyphenated format\n- [ ] `description` includes delegation triggers (\"Use proactively when...\")\n- [ ] `description` specifies expertise level\n- [ ] `tools` restricted to what is necessary\n- [ ] `model` appropriate for the task\n\n### System Prompt\n- [ ] Starts with clear role statement (1-2 sentences)\n- [ ] Includes \"When invoked:\" numbered action steps\n- [ ] Has domain-specific checklist\n- [ ] Specifies exact output format with sections\n- [ ] Lists red flags \u002F anti-patterns to avoid\n- [ ] Includes decision gates if applicable\n\n### Content Quality\n- [ ] Uses imperative\u002Foperational language, not abstract principles\n- [ ] Checklists contain concrete, verifiable items\n- [ ] Output format uses numbered sections with bold labels\n- [ ] No verbose mission statements or personality descriptions\n- [ ] Evidence requirements are explicit\n\n---\n\n## Reference\n\nFor complete examples, see the reference file: [Agent Examples](.\u002Freferences\u002Fexamples.md)\n\nFor the Claude Code subagents specification: [Claude Code Sub-agents Documentation](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fsub-agents)\n",{"name":5,"description":7},"main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Farchive\u002Fwriting-agents","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill writing-agents",{"tool":64,"command":65},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill writing-agents",{"tool":67,"command":68},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill writing-agents","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Farchive\u002Fwriting-agents\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fexamples.md","REFERENCE","参考文档",13527,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Farchive\u002Fwriting-agents\u002Freferences\u002Fexamples.md",[79,106,128,143,162,173],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":47},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105],"user run","user","run","docker","logs","use","host","as","triggers","permission","active","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":118,"publishedAt":47},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[112,115],{"categoryNo":113,"categoryName":114,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":116,"categoryName":117,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000030","开发工程师",[119,33,120,121,122,123,96,124,125,91,126,127],"requesting code review","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":136,"publishedAt":47},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[134,135],{"categoryNo":113,"categoryName":114,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":116,"categoryName":117,"taxonomyType":28,"taxonomyTypeDesc":29},[137,33,120,121,96,124,138,125,91,139,140,141,142],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":47},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[150,151,152,153,91,154,122,155,156,157,125,158,159,160,96,124,161,138],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":47},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[169,170,171,120,172,96,124,138,125,91,100],"plans","executing plans","plan","execute",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":47},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[180,181,182,91,125,124,183,96,184,127,185],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]