diff --git a/skills/documentation/agent-memory/SKILL.md b/skills/documentation/agent-memory/SKILL.md index acde55e5..e0dcc0c0 100644 --- a/skills/documentation/agent-memory/SKILL.md +++ b/skills/documentation/agent-memory/SKILL.md @@ -1,20 +1,44 @@ --- id: agent-memory name: Agent Memory -description: Step-by-step guidance for agent memory. +description: Structure agent memory docs so context stays discoverable, bounded, and maintainable without implying hidden system state. category: Documentation +requires: [] +examples: + - "Design agent memory docs so important context stays discoverable and appropriately scoped." + - "Review agent memory docs for taxonomy gaps, retrieval friction, and freshness risk." --- # Agent Memory -Support agent memory workflows with clear steps and best practices. +Use this skill when the user needs agent memory docs organized so important context can be captured, found, and updated without implying hidden memory or invisible indexed state. -## When to Use +## Start By Clarifying +- What information deserves durable capture versus short-lived discussion. +- How readers should locate the right context later. +- Which taxonomy, tags, or summary conventions will keep retrieval manageable. +- What freshness signals or ownership rules prevent silent decay. +- Where the boundaries are between documented knowledge and inferred context. -- You need help with agent memory. -- You want a clear, actionable next step. +## Workflow +1. Define the knowledge objects, categories, and retrieval paths readers will use. +2. Choose a structure for summaries, tags, links, and source references. +3. Document what should be captured, what should be omitted, and how updates happen. +4. Add examples of good entries, summaries, or indexing conventions. +5. Review for taxonomy sprawl, stale knowledge, and unclear source-of-truth rules. -## Output +## Good Output +- Knowledge structure or taxonomy recommendation. +- Rules for summaries, tags, references, and freshness. +- Ambiguities where context capture could become misleading or too broad. +- Maintenance guidance so the knowledge system stays usable. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting everything and creating an unsearchable memory dump. +- Using vague labels that do not help future retrieval. +- Failing to separate verified facts from interpretation or working notes. +- Implying persistent memory or indexing capabilities that are not actually present. + +## Boundaries +- Do not imply undocumented retrieval or memory systems exist. +- Prefer explicit taxonomy and source references over invisible context magic. diff --git a/skills/documentation/ai-context/SKILL.md b/skills/documentation/ai-context/SKILL.md index f459ac02..1c398aa6 100644 --- a/skills/documentation/ai-context/SKILL.md +++ b/skills/documentation/ai-context/SKILL.md @@ -1,20 +1,44 @@ --- id: ai-context name: AI Context -description: Step-by-step guidance for AI context. +description: Structure AI context docs so context stays discoverable, bounded, and maintainable without implying hidden system state. category: Documentation +requires: [] +examples: + - "Design AI context docs so important context stays discoverable and appropriately scoped." + - "Review AI context docs for taxonomy gaps, retrieval friction, and freshness risk." --- # AI Context -Support ai context workflows with clear steps and best practices. +Use this skill when the user needs AI context docs organized so important context can be captured, found, and updated without implying hidden memory or invisible indexed state. -## When to Use +## Start By Clarifying +- What information deserves durable capture versus short-lived discussion. +- How readers should locate the right context later. +- Which taxonomy, tags, or summary conventions will keep retrieval manageable. +- What freshness signals or ownership rules prevent silent decay. +- Where the boundaries are between documented knowledge and inferred context. -- You need help with ai context. -- You want a clear, actionable next step. +## Workflow +1. Define the knowledge objects, categories, and retrieval paths readers will use. +2. Choose a structure for summaries, tags, links, and source references. +3. Document what should be captured, what should be omitted, and how updates happen. +4. Add examples of good entries, summaries, or indexing conventions. +5. Review for taxonomy sprawl, stale knowledge, and unclear source-of-truth rules. -## Output +## Good Output +- Knowledge structure or taxonomy recommendation. +- Rules for summaries, tags, references, and freshness. +- Ambiguities where context capture could become misleading or too broad. +- Maintenance guidance so the knowledge system stays usable. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting everything and creating an unsearchable memory dump. +- Using vague labels that do not help future retrieval. +- Failing to separate verified facts from interpretation or working notes. +- Implying persistent memory or indexing capabilities that are not actually present. + +## Boundaries +- Do not imply undocumented retrieval or memory systems exist. +- Prefer explicit taxonomy and source references over invisible context magic. diff --git a/skills/documentation/api-design/SKILL.md b/skills/documentation/api-design/SKILL.md index 6ded5ad6..0ea117bb 100644 --- a/skills/documentation/api-design/SKILL.md +++ b/skills/documentation/api-design/SKILL.md @@ -1,20 +1,44 @@ --- id: api-design name: API Design -description: Step-by-step guidance for API design. +description: Document API design docs with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document API design docs so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into API design docs with checkpoints, ownership, and review gates." --- # API Design -Support api design workflows with clear steps and best practices. +Use this skill when the user needs API design docs that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with api design. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/api-documentation-generator/SKILL.md b/skills/documentation/api-documentation-generator/SKILL.md index 6e8becea..6c94909b 100644 --- a/skills/documentation/api-documentation-generator/SKILL.md +++ b/skills/documentation/api-documentation-generator/SKILL.md @@ -1,20 +1,44 @@ --- id: api-documentation-generator name: API Documentation Generator -description: Step-by-step guidance for API documentation. +description: Create and maintain API reference docs with accurate contracts, examples, edge cases, and version-aware detail. category: Documentation +requires: [] +examples: + - "Create API reference docs with examples, constraints, and edge-case coverage." + - "Review API reference docs for gaps in contracts, parameters, compatibility notes, or failure cases." --- # API Documentation Generator -Support api documentation workflows with clear steps and best practices. +Use this skill when the user needs API reference docs that readers can trust as a durable lookup source rather than a vague narrative summary. -## When to Use +## Start By Clarifying +- What entities, endpoints, fields, functions, or concepts are actually in scope. +- Which versions, compatibility boundaries, or deprecations matter. +- What inputs, outputs, defaults, and error cases readers most often misunderstand. +- Which examples are necessary to make the reference usable, not just complete. +- What surrounding guide material should be linked rather than duplicated. -- You need help with api documentation generator. -- You want a clear, actionable next step. +## Workflow +1. Define the reference surface and group it into durable reader-facing sections. +2. Document contracts, required fields, defaults, side effects, and failure modes explicitly. +3. Add examples that show normal use, edge cases, and compatibility caveats. +4. Call out version boundaries, deprecations, and non-obvious constraints. +5. Review for omissions that would force readers back into code or guesswork. -## Output +## Good Output +- Reference structure by resource, concept, or API surface. +- Missing contract details, examples, or compatibility notes. +- Places where defaults, limits, or failure behavior need stronger explanation. +- Cross-links needed to connect reference material to task-oriented guides. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting names without documenting behavior or constraints. +- Skipping error cases because the happy path feels sufficient. +- Hiding version-specific caveats until readers hit production issues. +- Letting the reference drift from actual source behavior. + +## Boundaries +- Do not imply undocumented behavior is guaranteed. +- Prefer precise contracts and examples over broad marketing-style wording. diff --git a/skills/documentation/architecture-decision-records/SKILL.md b/skills/documentation/architecture-decision-records/SKILL.md index 544ea8b0..1e1ead62 100644 --- a/skills/documentation/architecture-decision-records/SKILL.md +++ b/skills/documentation/architecture-decision-records/SKILL.md @@ -1,20 +1,44 @@ --- id: architecture-decision-records name: Architecture Decision Records -description: Step-by-step guidance for architecture decision records. +description: Document architecture decision records with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document architecture decision records so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into architecture decision records with checkpoints, ownership, and review gates." --- # Architecture Decision Records -Support architecture decision records workflows with clear steps and best practices. +Use this skill when the user needs architecture decision records that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with architecture decision records. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/backend-to-frontend-handoff-docs/SKILL.md b/skills/documentation/backend-to-frontend-handoff-docs/SKILL.md index 23847c8f..937f369a 100644 --- a/skills/documentation/backend-to-frontend-handoff-docs/SKILL.md +++ b/skills/documentation/backend-to-frontend-handoff-docs/SKILL.md @@ -1,20 +1,44 @@ --- id: backend-to-frontend-handoff-docs name: Backend-to-Frontend Handoff Docs -description: Step-by-step guidance for backend-to-frontend handoff docs. +description: Document backend-to-frontend handoff docs with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document backend-to-frontend handoff docs so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into backend-to-frontend handoff docs with checkpoints, ownership, and review gates." --- -# Backend To Frontend Handoff Docs +# Backend-to-Frontend Handoff Docs -Support backend to frontend handoff docs workflows with clear steps and best practices. +Use this skill when the user needs backend-to-frontend handoff docs that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with backend to frontend handoff docs. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/cc-skill-project-guidelines-example/SKILL.md b/skills/documentation/cc-skill-project-guidelines-example/SKILL.md deleted file mode 100644 index f50fd3f6..00000000 --- a/skills/documentation/cc-skill-project-guidelines-example/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: cc-skill-project-guidelines-example -name: CC Skill Project Guidelines Example -description: Step-by-step guidance for cc project guidelines example. -category: Documentation ---- - -# CC Skill Project Guidelines Example - -Support cc project guidelines example workflows with clear steps and best practices. - -## When to Use - -- You need help with cc skill project guidelines example. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/claude-code-guide/SKILL.md b/skills/documentation/claude-code-guide/SKILL.md deleted file mode 100644 index 6b811877..00000000 --- a/skills/documentation/claude-code-guide/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: claude-code-guide -name: Claude Code Guide -description: Step-by-step guidance for claude code. -category: Documentation ---- - -# Claude Code Guide - -Support claude code workflows with clear steps and best practices. - -## When to Use - -- You need help with claude code guide. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/code-documentation-code-explain/SKILL.md b/skills/documentation/code-documentation-code-explain/SKILL.md deleted file mode 100644 index 585f928e..00000000 --- a/skills/documentation/code-documentation-code-explain/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: code-documentation-code-explain -name: Code Documentation Code Explain -description: Step-by-step guidance for code documentation code explain. -category: Documentation ---- - -# Code Documentation Code Explain - -Support code documentation code explain workflows with clear steps and best practices. - -## When to Use - -- You need help with code documentation code explain. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/code-documentation-doc-generate/SKILL.md b/skills/documentation/code-documentation-doc-generate/SKILL.md deleted file mode 100644 index 6ed97684..00000000 --- a/skills/documentation/code-documentation-doc-generate/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: code-documentation-doc-generate -name: Code Documentation Doc Generate -description: Step-by-step guidance for code documentation doc generate. -category: Documentation ---- - -# Code Documentation Doc Generate - -Support code documentation doc generate workflows with clear steps and best practices. - -## When to Use - -- You need help with code documentation doc generate. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/coding-tutor/SKILL.md b/skills/documentation/coding-tutor/SKILL.md deleted file mode 100644 index cc4a9da3..00000000 --- a/skills/documentation/coding-tutor/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: coding-tutor -name: Coding Tutor -description: Step-by-step guidance for coding. -category: Documentation ---- - -# Coding Tutor - -Support coding workflows with clear steps and best practices. - -## When to Use - -- You need help with coding tutor. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/command-development/SKILL.md b/skills/documentation/command-development/SKILL.md index 13b50a32..d027ce6b 100644 --- a/skills/documentation/command-development/SKILL.md +++ b/skills/documentation/command-development/SKILL.md @@ -1,20 +1,44 @@ --- id: command-development name: Command Development -description: Step-by-step guidance for command development. +description: Develop command development handbooks with step-by-step guidance, examples, troubleshooting, and update ownership. category: Documentation +requires: [] +examples: + - "Create command development handbooks with step-by-step workflows, examples, and troubleshooting." + - "Audit command development handbooks for missing validation steps, stale procedures, and weak edge-case guidance." --- # Command Development -Support command development workflows with clear steps and best practices. +Use this skill when the user is building command development handbooks and needs a guide that people can actually follow under normal work and edge conditions. -## When to Use +## Start By Clarifying +- What tasks the handbook should support from start to finish. +- Which readers are beginners versus experienced maintainers. +- What tooling, environment, or safety assumptions must be explicit. +- Which examples, troubleshooting paths, or validation steps are essential. +- How the handbook will stay aligned with reality as systems evolve. -- You need help with command development. -- You want a clear, actionable next step. +## Workflow +1. Define the handbook scope and the task sequence readers need most. +2. Write the guide around workflows, checkpoints, and recovery paths rather than just concepts. +3. Add examples, troubleshooting cues, and validation steps for common failure modes. +4. Surface prerequisites, limits, and risky assumptions early. +5. Review for stale steps, missing edge cases, and unclear ownership. -## Output +## Good Output +- Task-oriented handbook structure. +- Examples, validation checkpoints, and troubleshooting sections worth adding. +- Risks or stale assumptions that make the current guide hard to trust. +- Update and ownership guidance for long-term maintenance. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Explaining theory while leaving readers unable to execute the task. +- Omitting troubleshooting because the happy path seems obvious. +- Leaving commands, version assumptions, or paths to decay silently. +- Packing too many unrelated workflows into one handbook. + +## Boundaries +- Do not present unchecked steps as validated procedure. +- Prefer practical workflows and failure handling over generic advice. diff --git a/skills/documentation/concept-workflow/SKILL.md b/skills/documentation/concept-workflow/SKILL.md index bbc59c06..b13b6f56 100644 --- a/skills/documentation/concept-workflow/SKILL.md +++ b/skills/documentation/concept-workflow/SKILL.md @@ -1,20 +1,44 @@ --- id: concept-workflow name: Concept Workflow -description: Step-by-step guidance for concept workflow. +description: Document concept workflow docs with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document concept workflow docs so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into concept workflow docs with checkpoints, ownership, and review gates." --- # Concept Workflow -Support concept workflow workflows with clear steps and best practices. +Use this skill when the user needs concept workflow docs that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with concept workflow. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/crafting-effective-readmes/SKILL.md b/skills/documentation/crafting-effective-readmes/SKILL.md index 858aa12f..46d645d6 100644 --- a/skills/documentation/crafting-effective-readmes/SKILL.md +++ b/skills/documentation/crafting-effective-readmes/SKILL.md @@ -1,20 +1,44 @@ --- id: crafting-effective-readmes name: Crafting Effective READMEs -description: Step-by-step guidance for crafting effective readmes. +description: Write and improve README docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft README docs for this project so readers can act without guessing." + - "Review README docs for missing prerequisites, stale assumptions, and unclear steps." --- # Crafting Effective READMEs -Support crafting effective readmes workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring README docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with crafting effective readmes. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/create-skill-file/SKILL.md b/skills/documentation/create-skill-file/SKILL.md index 9f0258a7..76072475 100644 --- a/skills/documentation/create-skill-file/SKILL.md +++ b/skills/documentation/create-skill-file/SKILL.md @@ -1,20 +1,46 @@ --- id: create-skill-file name: Create Skill File -description: Step-by-step guidance for create file. +description: Write and review skill file documentation with clear frontmatter, examples, boundaries, and maintenance expectations. category: Documentation +requires: [] +examples: + - "Help me create a skill file that follows the repository format and reads clearly." + - "Review this skill file draft for frontmatter, examples, boundaries, and instruction quality." --- # Create Skill File -Support create file workflows with clear steps and best practices. +Use this skill when the user is authoring or reviewing a skill file and needs it to be structurally correct, readable, and aligned with repository expectations. -## When to Use +## Start By Clarifying +- What problem the skill is supposed to solve. +- Whether the skill is guidance-only or depends on supported backend tooling. +- Which audience will use the skill and what prompts should trigger it. +- What examples best show the intended use without being redundant. +- What boundaries should be explicit so the skill does not overclaim capability. -- You need help with create skill file. -- You want a clear, actionable next step. +## Workflow +1. Define the skill's purpose, scope, and intended user requests. +2. Write compliant frontmatter with `id`, `name`, `description`, `category`, `requires`, and `examples`. +3. Draft instructions around user outcomes, decision points, and common failure modes. +4. Add examples that demonstrate real usage patterns rather than generic filler. +5. Review the file for overlap, unsupported claims, and missing boundaries before treating it as ready. -## Output +## Good Output +- Skill-file structure with correct frontmatter. +- Clear instructions that explain when and how the skill should help. +- Examples that improve discoverability and expectation-setting. +- Boundary notes that prevent hidden-tool or hidden-state assumptions. +- Review notes on overlap, clarity, or maintenance risk. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing a skill name without giving the body a real workflow or job to do. +- Using generic examples that could fit any skill in the repo. +- Leaving unsupported backend assumptions in a guidance-only skill. +- Creating a skill that duplicates an existing stronger canonical skill. +- Treating frontmatter as valid while missing the actual reader-facing clarity. + +## Boundaries +- Do not imply nonexistent tools, local services, hidden state, or privileged integrations. +- Prefer clear scope, examples, and behavioral guidance over placeholder boilerplate. diff --git a/skills/documentation/createskill/SKILL.md b/skills/documentation/createskill/SKILL.md deleted file mode 100644 index 4bc9c2ff..00000000 --- a/skills/documentation/createskill/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: createskill -name: Create Skill -description: Step-by-step guidance for createskill. -category: Documentation ---- - -# Create Skill - -Support createskill workflows with clear steps and best practices. - -## When to Use - -- You need help with createskill. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/debugging-strategies/SKILL.md b/skills/documentation/debugging-strategies/SKILL.md index a7d88e0d..05e2e105 100644 --- a/skills/documentation/debugging-strategies/SKILL.md +++ b/skills/documentation/debugging-strategies/SKILL.md @@ -1,20 +1,44 @@ --- id: debugging-strategies name: Debugging Strategies -description: Step-by-step guidance for debugging strategies. +description: Develop debugging strategy docs with step-by-step guidance, examples, troubleshooting, and update ownership. category: Documentation +requires: [] +examples: + - "Create debugging strategy docs with step-by-step workflows, examples, and troubleshooting." + - "Audit debugging strategy docs for missing validation steps, stale procedures, and weak edge-case guidance." --- # Debugging Strategies -Support debugging strategies workflows with clear steps and best practices. +Use this skill when the user is building debugging strategy docs and needs a guide that people can actually follow under normal work and edge conditions. -## When to Use +## Start By Clarifying +- What tasks the handbook should support from start to finish. +- Which readers are beginners versus experienced maintainers. +- What tooling, environment, or safety assumptions must be explicit. +- Which examples, troubleshooting paths, or validation steps are essential. +- How the handbook will stay aligned with reality as systems evolve. -- You need help with debugging strategies. -- You want a clear, actionable next step. +## Workflow +1. Define the handbook scope and the task sequence readers need most. +2. Write the guide around workflows, checkpoints, and recovery paths rather than just concepts. +3. Add examples, troubleshooting cues, and validation steps for common failure modes. +4. Surface prerequisites, limits, and risky assumptions early. +5. Review for stale steps, missing edge cases, and unclear ownership. -## Output +## Good Output +- Task-oriented handbook structure. +- Examples, validation checkpoints, and troubleshooting sections worth adding. +- Risks or stale assumptions that make the current guide hard to trust. +- Update and ownership guidance for long-term maintenance. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Explaining theory while leaving readers unable to execute the task. +- Omitting troubleshooting because the happy path seems obvious. +- Leaving commands, version assumptions, or paths to decay silently. +- Packing too many unrelated workflows into one handbook. + +## Boundaries +- Do not present unchecked steps as validated procedure. +- Prefer practical workflows and failure handling over generic advice. diff --git a/skills/documentation/doc-coauthoring/SKILL.md b/skills/documentation/doc-coauthoring/SKILL.md index cc916f0f..83a57aa2 100644 --- a/skills/documentation/doc-coauthoring/SKILL.md +++ b/skills/documentation/doc-coauthoring/SKILL.md @@ -1,20 +1,44 @@ --- id: doc-coauthoring name: Doc Coauthoring -description: Step-by-step guidance for doc coauthoring. +description: Write and improve doc coauthoring workflows with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft doc coauthoring workflows for this project so readers can act without guessing." + - "Review doc coauthoring workflows for missing prerequisites, stale assumptions, and unclear steps." --- # Doc Coauthoring -Support doc coauthoring workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring doc coauthoring workflows and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with doc coauthoring. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/docs-architect/SKILL.md b/skills/documentation/docs-architect/SKILL.md index 4156836b..3f70c1ec 100644 --- a/skills/documentation/docs-architect/SKILL.md +++ b/skills/documentation/docs-architect/SKILL.md @@ -1,20 +1,44 @@ --- id: docs-architect name: Docs Architect -description: Step-by-step guidance for docs architect. +description: Write and improve documentation architecture plans with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft documentation architecture plans for this project so readers can act without guessing." + - "Review documentation architecture plans for missing prerequisites, stale assumptions, and unclear steps." --- # Docs Architect -Support docs architect workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring documentation architecture plans and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with docs architect. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/docs-style/SKILL.md b/skills/documentation/docs-style/SKILL.md index a1ba0fe4..2e939653 100644 --- a/skills/documentation/docs-style/SKILL.md +++ b/skills/documentation/docs-style/SKILL.md @@ -1,20 +1,44 @@ --- id: docs-style name: Docs Style -description: Step-by-step guidance for docs style. +description: Write and improve docs style guides with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft docs style guides for this project so readers can act without guessing." + - "Review docs style guides for missing prerequisites, stale assumptions, and unclear steps." --- # Docs Style -Support docs style workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring docs style guides and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with docs style. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/docs-sync/SKILL.md b/skills/documentation/docs-sync/SKILL.md index 07bf8ba5..f6bac4fa 100644 --- a/skills/documentation/docs-sync/SKILL.md +++ b/skills/documentation/docs-sync/SKILL.md @@ -1,20 +1,44 @@ --- id: docs-sync name: Docs Sync -description: Step-by-step guidance for docs sync. +description: Write and improve docs sync workflows with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft docs sync workflows for this project so readers can act without guessing." + - "Review docs sync workflows for missing prerequisites, stale assumptions, and unclear steps." --- # Docs Sync -Support docs sync workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring docs sync workflows and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with docs sync. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/docstring/SKILL.md b/skills/documentation/docstring/SKILL.md deleted file mode 100644 index 158b910c..00000000 --- a/skills/documentation/docstring/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: docstring -name: Docstring -description: Step-by-step guidance for docstring. -category: Documentation ---- - -# Docstring - -Support docstring workflows with clear steps and best practices. - -## When to Use - -- You need help with docstring. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/documentation-generation-doc-generate/SKILL.md b/skills/documentation/documentation-generation-doc-generate/SKILL.md deleted file mode 100644 index ba96dc9d..00000000 --- a/skills/documentation/documentation-generation-doc-generate/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: documentation-generation-doc-generate -name: Documentation Generation Doc Generate -description: Step-by-step guidance for documentation generation doc generate. -category: Documentation ---- - -# Documentation Generation Doc Generate - -Support documentation generation doc generate workflows with clear steps and best practices. - -## When to Use - -- You need help with documentation generation doc generate. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/documentation-templates/SKILL.md b/skills/documentation/documentation-templates/SKILL.md deleted file mode 100644 index f912eea0..00000000 --- a/skills/documentation/documentation-templates/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: documentation-templates -name: Documentation Templates -description: Step-by-step guidance for documentation templates. -category: Documentation ---- - -# Documentation Templates - -Support documentation templates workflows with clear steps and best practices. - -## When to Use - -- You need help with documentation templates. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/documentation/SKILL.md b/skills/documentation/documentation/SKILL.md deleted file mode 100644 index ea3ea7a1..00000000 --- a/skills/documentation/documentation/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: documentation -name: Documentation -description: Step-by-step guidance for documentation. -category: Documentation ---- - -# Documentation - -Support documentation workflows with clear steps and best practices. - -## When to Use - -- You need help with documentation. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/environment-setup-guide/SKILL.md b/skills/documentation/environment-setup-guide/SKILL.md index c07f1639..d7dc179e 100644 --- a/skills/documentation/environment-setup-guide/SKILL.md +++ b/skills/documentation/environment-setup-guide/SKILL.md @@ -1,20 +1,44 @@ --- id: environment-setup-guide name: Environment Setup Guide -description: Step-by-step guidance for environment setup. +description: Write and improve environment setup guides with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft environment setup guides for this project so readers can act without guessing." + - "Review environment setup guides for missing prerequisites, stale assumptions, and unclear steps." --- # Environment Setup Guide -Support environment setup workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring environment setup guides and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with environment setup guide. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/example-skill/SKILL.md b/skills/documentation/example-skill/SKILL.md deleted file mode 100644 index e219fba2..00000000 --- a/skills/documentation/example-skill/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: example-skill -name: Example Skill -description: Step-by-step guidance for example. -category: Documentation ---- - -# Example Skill - -Support example workflows with clear steps and best practices. - -## When to Use - -- You need help with example skill. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/feishu-wiki/SKILL.md b/skills/documentation/feishu-wiki/SKILL.md deleted file mode 100644 index 6a28e12b..00000000 --- a/skills/documentation/feishu-wiki/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: feishu-wiki -name: Feishu Wiki -description: Step-by-step guidance for feishu wiki. -category: Documentation ---- - -# Feishu Wiki - -Support feishu wiki workflows with clear steps and best practices. - -## When to Use - -- You need help with feishu wiki. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/fuzzing-dictionary/SKILL.md b/skills/documentation/fuzzing-dictionary/SKILL.md deleted file mode 100644 index a1cc1f49..00000000 --- a/skills/documentation/fuzzing-dictionary/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: fuzzing-dictionary -name: Fuzzing Dictionary -description: Step-by-step guidance for fuzzing dictionary. -category: Documentation ---- - -# Fuzzing Dictionary - -Support fuzzing dictionary workflows with clear steps and best practices. - -## When to Use - -- You need help with fuzzing dictionary. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/gemini/SKILL.md b/skills/documentation/gemini/SKILL.md deleted file mode 100644 index 6bcdecd7..00000000 --- a/skills/documentation/gemini/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: gemini -name: Gemini -description: Step-by-step guidance for gemini. -category: Documentation ---- - -# Gemini - -Support gemini workflows with clear steps and best practices. - -## When to Use - -- You need help with gemini. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/harness-writing/SKILL.md b/skills/documentation/harness-writing/SKILL.md index 74c853e4..5da9a762 100644 --- a/skills/documentation/harness-writing/SKILL.md +++ b/skills/documentation/harness-writing/SKILL.md @@ -1,20 +1,44 @@ --- id: harness-writing name: Harness Writing -description: Step-by-step guidance for harness. +description: Develop test harness docs with step-by-step guidance, examples, troubleshooting, and update ownership. category: Documentation +requires: [] +examples: + - "Create test harness docs with step-by-step workflows, examples, and troubleshooting." + - "Audit test harness docs for missing validation steps, stale procedures, and weak edge-case guidance." --- # Harness Writing -Support harness workflows with clear steps and best practices. +Use this skill when the user is building test harness docs and needs a guide that people can actually follow under normal work and edge conditions. -## When to Use +## Start By Clarifying +- What tasks the handbook should support from start to finish. +- Which readers are beginners versus experienced maintainers. +- What tooling, environment, or safety assumptions must be explicit. +- Which examples, troubleshooting paths, or validation steps are essential. +- How the handbook will stay aligned with reality as systems evolve. -- You need help with harness writing. -- You want a clear, actionable next step. +## Workflow +1. Define the handbook scope and the task sequence readers need most. +2. Write the guide around workflows, checkpoints, and recovery paths rather than just concepts. +3. Add examples, troubleshooting cues, and validation steps for common failure modes. +4. Surface prerequisites, limits, and risky assumptions early. +5. Review for stale steps, missing edge cases, and unclear ownership. -## Output +## Good Output +- Task-oriented handbook structure. +- Examples, validation checkpoints, and troubleshooting sections worth adding. +- Risks or stale assumptions that make the current guide hard to trust. +- Update and ownership guidance for long-term maintenance. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Explaining theory while leaving readers unable to execute the task. +- Omitting troubleshooting because the happy path seems obvious. +- Leaving commands, version assumptions, or paths to decay silently. +- Packing too many unrelated workflows into one handbook. + +## Boundaries +- Do not present unchecked steps as validated procedure. +- Prefer practical workflows and failure handling over generic advice. diff --git a/skills/documentation/hbcreative/SKILL.md b/skills/documentation/hbcreative/SKILL.md deleted file mode 100644 index bc89f0dd..00000000 --- a/skills/documentation/hbcreative/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: hbcreative -name: HBCreative -description: Step-by-step guidance for hbcreative. -category: Documentation ---- - -# HBCreative - -Support hbcreative workflows with clear steps and best practices. - -## When to Use - -- You need help with hbcreative. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/hook-development/SKILL.md b/skills/documentation/hook-development/SKILL.md index ea49be88..b8661167 100644 --- a/skills/documentation/hook-development/SKILL.md +++ b/skills/documentation/hook-development/SKILL.md @@ -1,20 +1,44 @@ --- id: hook-development name: Hook Development -description: Step-by-step guidance for hook development. +description: Develop hook development docs with step-by-step guidance, examples, troubleshooting, and update ownership. category: Documentation +requires: [] +examples: + - "Create hook development docs with step-by-step workflows, examples, and troubleshooting." + - "Audit hook development docs for missing validation steps, stale procedures, and weak edge-case guidance." --- # Hook Development -Support hook development workflows with clear steps and best practices. +Use this skill when the user is building hook development docs and needs a guide that people can actually follow under normal work and edge conditions. -## When to Use +## Start By Clarifying +- What tasks the handbook should support from start to finish. +- Which readers are beginners versus experienced maintainers. +- What tooling, environment, or safety assumptions must be explicit. +- Which examples, troubleshooting paths, or validation steps are essential. +- How the handbook will stay aligned with reality as systems evolve. -- You need help with hook development. -- You want a clear, actionable next step. +## Workflow +1. Define the handbook scope and the task sequence readers need most. +2. Write the guide around workflows, checkpoints, and recovery paths rather than just concepts. +3. Add examples, troubleshooting cues, and validation steps for common failure modes. +4. Surface prerequisites, limits, and risky assumptions early. +5. Review for stale steps, missing edge cases, and unclear ownership. -## Output +## Good Output +- Task-oriented handbook structure. +- Examples, validation checkpoints, and troubleshooting sections worth adding. +- Risks or stale assumptions that make the current guide hard to trust. +- Update and ownership guidance for long-term maintenance. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Explaining theory while leaving readers unable to execute the task. +- Omitting troubleshooting because the happy path seems obvious. +- Leaving commands, version assumptions, or paths to decay silently. +- Packing too many unrelated workflows into one handbook. + +## Boundaries +- Do not present unchecked steps as validated procedure. +- Prefer practical workflows and failure handling over generic advice. diff --git a/skills/documentation/index-knowledge/SKILL.md b/skills/documentation/index-knowledge/SKILL.md index 2ea0b2e9..3a6caca5 100644 --- a/skills/documentation/index-knowledge/SKILL.md +++ b/skills/documentation/index-knowledge/SKILL.md @@ -1,20 +1,44 @@ --- id: index-knowledge name: Index Knowledge -description: Step-by-step guidance for index knowledge. +description: Structure knowledge indexing docs so context stays discoverable, bounded, and maintainable without implying hidden system state. category: Documentation +requires: [] +examples: + - "Design knowledge indexing docs so important context stays discoverable and appropriately scoped." + - "Review knowledge indexing docs for taxonomy gaps, retrieval friction, and freshness risk." --- # Index Knowledge -Support index knowledge workflows with clear steps and best practices. +Use this skill when the user needs knowledge indexing docs organized so important context can be captured, found, and updated without implying hidden memory or invisible indexed state. -## When to Use +## Start By Clarifying +- What information deserves durable capture versus short-lived discussion. +- How readers should locate the right context later. +- Which taxonomy, tags, or summary conventions will keep retrieval manageable. +- What freshness signals or ownership rules prevent silent decay. +- Where the boundaries are between documented knowledge and inferred context. -- You need help with index knowledge. -- You want a clear, actionable next step. +## Workflow +1. Define the knowledge objects, categories, and retrieval paths readers will use. +2. Choose a structure for summaries, tags, links, and source references. +3. Document what should be captured, what should be omitted, and how updates happen. +4. Add examples of good entries, summaries, or indexing conventions. +5. Review for taxonomy sprawl, stale knowledge, and unclear source-of-truth rules. -## Output +## Good Output +- Knowledge structure or taxonomy recommendation. +- Rules for summaries, tags, references, and freshness. +- Ambiguities where context capture could become misleading or too broad. +- Maintenance guidance so the knowledge system stays usable. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting everything and creating an unsearchable memory dump. +- Using vague labels that do not help future retrieval. +- Failing to separate verified facts from interpretation or working notes. +- Implying persistent memory or indexing capabilities that are not actually present. + +## Boundaries +- Do not imply undocumented retrieval or memory systems exist. +- Prefer explicit taxonomy and source references over invisible context magic. diff --git a/skills/documentation/install-skills/SKILL.md b/skills/documentation/install-skills/SKILL.md index da9e022e..cc83824d 100644 --- a/skills/documentation/install-skills/SKILL.md +++ b/skills/documentation/install-skills/SKILL.md @@ -1,20 +1,44 @@ --- id: install-skills name: Install Skills -description: Step-by-step guidance for install skills. +description: Plan and maintain skill installation docs with clear information architecture, publishing workflow, and source-of-truth boundaries. category: Documentation +requires: [] +examples: + - "Set up skill installation docs with structure, publishing rules, and maintenance ownership." + - "Review skill installation docs for navigation problems, stale content risk, and weak source-of-truth boundaries." --- # Install Skills -Support install skills workflows with clear steps and best practices. +Use this skill when the user is structuring or reviewing skill installation docs and needs documentation that fits the platform without pretending to have hidden publishing or backend powers. -## When to Use +## Start By Clarifying +- What content belongs on the platform and what should remain elsewhere. +- Who owns publishing, review, and long-term maintenance. +- How readers discover content through navigation, search, or links. +- What source-of-truth rules prevent drift between platform pages and other docs. +- Which examples, screenshots, or platform-specific conventions need active upkeep. -- You need help with install skills. -- You want a clear, actionable next step. +## Workflow +1. Define the information architecture and where each document type belongs. +2. Set authorship, review, and publishing expectations before adding content at scale. +3. Write or reorganize pages around reader tasks and stable navigation paths. +4. Add freshness cues, ownership notes, and update triggers for high-change content. +5. Review the platform for searchability, duplication, and stale or conflicting pages. -## Output +## Good Output +- Recommended page structure and navigation model. +- Source-of-truth boundaries and ownership expectations. +- Publishing or review workflow guidance. +- Risks around stale content, duplicated pages, or misleading examples. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Treating the platform as the information architecture instead of designing one. +- Duplicating content in multiple places with no freshness rule. +- Publishing screenshots or examples that age quickly without maintenance ownership. +- Implying platform capabilities or automation that the user has not confirmed. + +## Boundaries +- Do not imply direct access to publishing systems unless the user provides it. +- Prefer platform-aware structure and governance over tool-magic claims. diff --git a/skills/documentation/issue-triage/SKILL.md b/skills/documentation/issue-triage/SKILL.md index be53e120..3c826fb5 100644 --- a/skills/documentation/issue-triage/SKILL.md +++ b/skills/documentation/issue-triage/SKILL.md @@ -1,20 +1,44 @@ --- id: issue-triage name: Issue Triage -description: Step-by-step guidance for issue triage. +description: Document issue triage docs with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document issue triage docs so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into issue triage docs with checkpoints, ownership, and review gates." --- # Issue Triage -Support issue triage workflows with clear steps and best practices. +Use this skill when the user needs issue triage docs that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with issue triage. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/javascript-mastery/SKILL.md b/skills/documentation/javascript-mastery/SKILL.md deleted file mode 100644 index f5999d01..00000000 --- a/skills/documentation/javascript-mastery/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: javascript-mastery -name: JavaScript Mastery -description: Step-by-step guidance for javascript mastery. -category: Documentation ---- - -# JavaScript Mastery - -Support javascript mastery workflows with clear steps and best practices. - -## When to Use - -- You need help with javascript mastery. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/jupyter-notebook/SKILL.md b/skills/documentation/jupyter-notebook/SKILL.md index 1d401b6e..2e1cceb9 100644 --- a/skills/documentation/jupyter-notebook/SKILL.md +++ b/skills/documentation/jupyter-notebook/SKILL.md @@ -1,20 +1,44 @@ --- id: jupyter-notebook name: Jupyter Notebook -description: Step-by-step guidance for jupyter notebook. +description: Plan and maintain Jupyter notebook docs with clear information architecture, publishing workflow, and source-of-truth boundaries. category: Documentation +requires: [] +examples: + - "Set up Jupyter notebook docs with structure, publishing rules, and maintenance ownership." + - "Review Jupyter notebook docs for navigation problems, stale content risk, and weak source-of-truth boundaries." --- # Jupyter Notebook -Support jupyter notebook workflows with clear steps and best practices. +Use this skill when the user is structuring or reviewing Jupyter notebook docs and needs documentation that fits the platform without pretending to have hidden publishing or backend powers. -## When to Use +## Start By Clarifying +- What content belongs on the platform and what should remain elsewhere. +- Who owns publishing, review, and long-term maintenance. +- How readers discover content through navigation, search, or links. +- What source-of-truth rules prevent drift between platform pages and other docs. +- Which examples, screenshots, or platform-specific conventions need active upkeep. -- You need help with jupyter notebook. -- You want a clear, actionable next step. +## Workflow +1. Define the information architecture and where each document type belongs. +2. Set authorship, review, and publishing expectations before adding content at scale. +3. Write or reorganize pages around reader tasks and stable navigation paths. +4. Add freshness cues, ownership notes, and update triggers for high-change content. +5. Review the platform for searchability, duplication, and stale or conflicting pages. -## Output +## Good Output +- Recommended page structure and navigation model. +- Source-of-truth boundaries and ownership expectations. +- Publishing or review workflow guidance. +- Risks around stale content, duplicated pages, or misleading examples. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Treating the platform as the information architecture instead of designing one. +- Duplicating content in multiple places with no freshness rule. +- Publishing screenshots or examples that age quickly without maintenance ownership. +- Implying platform capabilities or automation that the user has not confirmed. + +## Boundaries +- Do not imply direct access to publishing systems unless the user provides it. +- Prefer platform-aware structure and governance over tool-magic claims. diff --git a/skills/documentation/kaizen/SKILL.md b/skills/documentation/kaizen/SKILL.md deleted file mode 100644 index 8c796fa1..00000000 --- a/skills/documentation/kaizen/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: kaizen -name: Kaizen -description: Step-by-step guidance for kaizen. -category: Documentation ---- - -# Kaizen - -Support kaizen workflows with clear steps and best practices. - -## When to Use - -- You need help with kaizen. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/libraries-release-notes/SKILL.md b/skills/documentation/libraries-release-notes/SKILL.md index d485e7c9..bf864034 100644 --- a/skills/documentation/libraries-release-notes/SKILL.md +++ b/skills/documentation/libraries-release-notes/SKILL.md @@ -1,20 +1,44 @@ --- id: libraries-release-notes name: Libraries Release Notes -description: Step-by-step guidance for libraries release notes. +description: Write library release notes with clear impact, compatibility notes, rollout context, and reader actions. category: Documentation +requires: [] +examples: + - "Draft library release notes that explains impact, migration notes, and known issues clearly." + - "Review library release notes so readers can tell whether they are affected and what to do next." --- # Libraries Release Notes -Support libraries release notes workflows with clear steps and best practices. +Use this skill when the user needs library release notes so readers understand what changed, why it matters, and what they need to do next. -## When to Use +## Start By Clarifying +- Who the release notes are for and what they care about most. +- Which changes are user-visible, operationally significant, or compatibility-sensitive. +- Whether migrations, deprecations, or rollout caveats need explicit treatment. +- What risks, known issues, or support guidance should be surfaced. +- How much implementation detail helps rather than distracts. -- You need help with libraries release notes. -- You want a clear, actionable next step. +## Workflow +1. Collect the meaningful changes and group them by reader impact, not commit chronology. +2. Highlight features, fixes, breaking changes, and operational notes separately where useful. +3. Add migration or upgrade guidance wherever readers may need to take action. +4. Call out known issues, rollout caveats, and audience-specific warnings honestly. +5. Review the notes for clarity, completeness, and whether affected readers can recognize themselves. -## Output +## Good Output +- Release summary tailored to the intended audience. +- Grouped notes by impact or change type. +- Migration, rollback, or compatibility notes. +- Known issues or rollout caveats that should not be hidden. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Copying commit messages instead of explaining reader impact. +- Burying breaking changes among minor fixes. +- Leaving users unsure whether they need to act. +- Overstating rollout completeness or stability without confirmation. + +## Boundaries +- Do not imply a change is fully rolled out unless the user confirms it. +- Prefer impact-focused communication over changelog noise. diff --git a/skills/documentation/make-plan/SKILL.md b/skills/documentation/make-plan/SKILL.md deleted file mode 100644 index 8384d739..00000000 --- a/skills/documentation/make-plan/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: make-plan -name: Make Plan -description: Step-by-step guidance for make plan. -category: Documentation ---- - -# Make Plan - -Support make plan workflows with clear steps and best practices. - -## When to Use - -- You need help with make plan. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/microsoft-code-reference/SKILL.md b/skills/documentation/microsoft-code-reference/SKILL.md deleted file mode 100644 index 74cafad1..00000000 --- a/skills/documentation/microsoft-code-reference/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: microsoft-code-reference -name: Microsoft Code Reference -description: Step-by-step guidance for microsoft code reference. -category: Documentation ---- - -# Microsoft Code Reference - -Support microsoft code reference workflows with clear steps and best practices. - -## When to Use - -- You need help with microsoft code reference. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/microsoft-docs/SKILL.md b/skills/documentation/microsoft-docs/SKILL.md deleted file mode 100644 index a40d5382..00000000 --- a/skills/documentation/microsoft-docs/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: microsoft-docs -name: Microsoft Docs -description: Step-by-step guidance for microsoft docs. -category: Documentation ---- - -# Microsoft Docs - -Support microsoft docs workflows with clear steps and best practices. - -## When to Use - -- You need help with microsoft docs. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/mintlify/SKILL.md b/skills/documentation/mintlify/SKILL.md index 860ed89c..4cfa99d8 100644 --- a/skills/documentation/mintlify/SKILL.md +++ b/skills/documentation/mintlify/SKILL.md @@ -1,20 +1,44 @@ --- id: mintlify name: Mintlify -description: Step-by-step guidance for mintlify. +description: Plan and maintain Mintlify docs workflows with clear information architecture, publishing workflow, and source-of-truth boundaries. category: Documentation +requires: [] +examples: + - "Set up Mintlify docs workflows with structure, publishing rules, and maintenance ownership." + - "Review Mintlify docs workflows for navigation problems, stale content risk, and weak source-of-truth boundaries." --- # Mintlify -Support mintlify workflows with clear steps and best practices. +Use this skill when the user is structuring or reviewing Mintlify docs workflows and needs documentation that fits the platform without pretending to have hidden publishing or backend powers. -## When to Use +## Start By Clarifying +- What content belongs on the platform and what should remain elsewhere. +- Who owns publishing, review, and long-term maintenance. +- How readers discover content through navigation, search, or links. +- What source-of-truth rules prevent drift between platform pages and other docs. +- Which examples, screenshots, or platform-specific conventions need active upkeep. -- You need help with mintlify. -- You want a clear, actionable next step. +## Workflow +1. Define the information architecture and where each document type belongs. +2. Set authorship, review, and publishing expectations before adding content at scale. +3. Write or reorganize pages around reader tasks and stable navigation paths. +4. Add freshness cues, ownership notes, and update triggers for high-change content. +5. Review the platform for searchability, duplication, and stale or conflicting pages. -## Output +## Good Output +- Recommended page structure and navigation model. +- Source-of-truth boundaries and ownership expectations. +- Publishing or review workflow guidance. +- Risks around stale content, duplicated pages, or misleading examples. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Treating the platform as the information architecture instead of designing one. +- Duplicating content in multiple places with no freshness rule. +- Publishing screenshots or examples that age quickly without maintenance ownership. +- Implying platform capabilities or automation that the user has not confirmed. + +## Boundaries +- Do not imply direct access to publishing systems unless the user provides it. +- Prefer platform-aware structure and governance over tool-magic claims. diff --git a/skills/documentation/navigator/SKILL.md b/skills/documentation/navigator/SKILL.md index 2d80f6eb..4ba244b8 100644 --- a/skills/documentation/navigator/SKILL.md +++ b/skills/documentation/navigator/SKILL.md @@ -1,20 +1,44 @@ --- id: navigator name: Navigator -description: Step-by-step guidance for navigator. +description: Structure documentation navigation strategy so context stays discoverable, bounded, and maintainable without implying hidden system state. category: Documentation +requires: [] +examples: + - "Design documentation navigation strategy so important context stays discoverable and appropriately scoped." + - "Review documentation navigation strategy for taxonomy gaps, retrieval friction, and freshness risk." --- # Navigator -Support navigator workflows with clear steps and best practices. +Use this skill when the user needs documentation navigation strategy organized so important context can be captured, found, and updated without implying hidden memory or invisible indexed state. -## When to Use +## Start By Clarifying +- What information deserves durable capture versus short-lived discussion. +- How readers should locate the right context later. +- Which taxonomy, tags, or summary conventions will keep retrieval manageable. +- What freshness signals or ownership rules prevent silent decay. +- Where the boundaries are between documented knowledge and inferred context. -- You need help with navigator. -- You want a clear, actionable next step. +## Workflow +1. Define the knowledge objects, categories, and retrieval paths readers will use. +2. Choose a structure for summaries, tags, links, and source references. +3. Document what should be captured, what should be omitted, and how updates happen. +4. Add examples of good entries, summaries, or indexing conventions. +5. Review for taxonomy sprawl, stale knowledge, and unclear source-of-truth rules. -## Output +## Good Output +- Knowledge structure or taxonomy recommendation. +- Rules for summaries, tags, references, and freshness. +- Ambiguities where context capture could become misleading or too broad. +- Maintenance guidance so the knowledge system stays usable. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting everything and creating an unsearchable memory dump. +- Using vague labels that do not help future retrieval. +- Failing to separate verified facts from interpretation or working notes. +- Implying persistent memory or indexing capabilities that are not actually present. + +## Boundaries +- Do not imply undocumented retrieval or memory systems exist. +- Prefer explicit taxonomy and source references over invisible context magic. diff --git a/skills/documentation/openai-docs/SKILL.md b/skills/documentation/openai-docs/SKILL.md index dc53c1e3..07fe2767 100644 --- a/skills/documentation/openai-docs/SKILL.md +++ b/skills/documentation/openai-docs/SKILL.md @@ -1,20 +1,44 @@ --- id: openai-docs name: OpenAI Docs -description: Step-by-step guidance for openai docs. +description: Plan and maintain OpenAI docs with clear information architecture, publishing workflow, and source-of-truth boundaries. category: Documentation +requires: [] +examples: + - "Set up OpenAI docs with structure, publishing rules, and maintenance ownership." + - "Review OpenAI docs for navigation problems, stale content risk, and weak source-of-truth boundaries." --- # OpenAI Docs -Support openai docs workflows with clear steps and best practices. +Use this skill when the user is structuring or reviewing OpenAI docs and needs documentation that fits the platform without pretending to have hidden publishing or backend powers. -## When to Use +## Start By Clarifying +- What content belongs on the platform and what should remain elsewhere. +- Who owns publishing, review, and long-term maintenance. +- How readers discover content through navigation, search, or links. +- What source-of-truth rules prevent drift between platform pages and other docs. +- Which examples, screenshots, or platform-specific conventions need active upkeep. -- You need help with openai docs. -- You want a clear, actionable next step. +## Workflow +1. Define the information architecture and where each document type belongs. +2. Set authorship, review, and publishing expectations before adding content at scale. +3. Write or reorganize pages around reader tasks and stable navigation paths. +4. Add freshness cues, ownership notes, and update triggers for high-change content. +5. Review the platform for searchability, duplication, and stale or conflicting pages. -## Output +## Good Output +- Recommended page structure and navigation model. +- Source-of-truth boundaries and ownership expectations. +- Publishing or review workflow guidance. +- Risks around stale content, duplicated pages, or misleading examples. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Treating the platform as the information architecture instead of designing one. +- Duplicating content in multiple places with no freshness rule. +- Publishing screenshots or examples that age quickly without maintenance ownership. +- Implying platform capabilities or automation that the user has not confirmed. + +## Boundaries +- Do not imply direct access to publishing systems unless the user provides it. +- Prefer platform-aware structure and governance over tool-magic claims. diff --git a/skills/documentation/openai-knowledge/SKILL.md b/skills/documentation/openai-knowledge/SKILL.md deleted file mode 100644 index 49381ccb..00000000 --- a/skills/documentation/openai-knowledge/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: openai-knowledge -name: OpenAI Knowledge -description: Step-by-step guidance for openai knowledge. -category: Documentation ---- - -# OpenAI Knowledge - -Support openai knowledge workflows with clear steps and best practices. - -## When to Use - -- You need help with openai knowledge. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/packages/SKILL.md b/skills/documentation/packages/SKILL.md index e98437cd..a85d3235 100644 --- a/skills/documentation/packages/SKILL.md +++ b/skills/documentation/packages/SKILL.md @@ -1,20 +1,44 @@ --- id: packages name: Packages -description: Step-by-step guidance for packages. +description: Create and maintain package docs with accurate contracts, examples, edge cases, and version-aware detail. category: Documentation +requires: [] +examples: + - "Create package docs with examples, constraints, and edge-case coverage." + - "Review package docs for gaps in contracts, parameters, compatibility notes, or failure cases." --- # Packages -Support packages workflows with clear steps and best practices. +Use this skill when the user needs package docs that readers can trust as a durable lookup source rather than a vague narrative summary. -## When to Use +## Start By Clarifying +- What entities, endpoints, fields, functions, or concepts are actually in scope. +- Which versions, compatibility boundaries, or deprecations matter. +- What inputs, outputs, defaults, and error cases readers most often misunderstand. +- Which examples are necessary to make the reference usable, not just complete. +- What surrounding guide material should be linked rather than duplicated. -- You need help with packages. -- You want a clear, actionable next step. +## Workflow +1. Define the reference surface and group it into durable reader-facing sections. +2. Document contracts, required fields, defaults, side effects, and failure modes explicitly. +3. Add examples that show normal use, edge cases, and compatibility caveats. +4. Call out version boundaries, deprecations, and non-obvious constraints. +5. Review for omissions that would force readers back into code or guesswork. -## Output +## Good Output +- Reference structure by resource, concept, or API surface. +- Missing contract details, examples, or compatibility notes. +- Places where defaults, limits, or failure behavior need stronger explanation. +- Cross-links needed to connect reference material to task-oriented guides. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting names without documenting behavior or constraints. +- Skipping error cases because the happy path feels sufficient. +- Hiding version-specific caveats until readers hit production issues. +- Letting the reference drift from actual source behavior. + +## Boundaries +- Do not imply undocumented behavior is guaranteed. +- Prefer precise contracts and examples over broad marketing-style wording. diff --git a/skills/documentation/parallel-debugging/SKILL.md b/skills/documentation/parallel-debugging/SKILL.md deleted file mode 100644 index 07180792..00000000 --- a/skills/documentation/parallel-debugging/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: parallel-debugging -name: Parallel Debugging -description: Step-by-step guidance for parallel debugging. -category: Documentation ---- - -# Parallel Debugging - -Support parallel debugging workflows with clear steps and best practices. - -## When to Use - -- You need help with parallel debugging. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/playwright-dev/SKILL.md b/skills/documentation/playwright-dev/SKILL.md deleted file mode 100644 index 36e35eaf..00000000 --- a/skills/documentation/playwright-dev/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: playwright-dev -name: Playwright Dev -description: Step-by-step guidance for playwright dev. -category: Documentation ---- - -# Playwright Dev - -Support playwright dev workflows with clear steps and best practices. - -## When to Use - -- You need help with playwright dev. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/pr-walkthrough/SKILL.md b/skills/documentation/pr-walkthrough/SKILL.md index f0e7cc09..27338549 100644 --- a/skills/documentation/pr-walkthrough/SKILL.md +++ b/skills/documentation/pr-walkthrough/SKILL.md @@ -1,20 +1,44 @@ --- id: pr-walkthrough name: PR Walkthrough -description: Step-by-step guidance for pr walkthrough. +description: Document PR walkthrough docs with clear responsibilities, decision points, sequencing, and follow-through expectations. category: Documentation +requires: [] +examples: + - "Document PR walkthrough docs so contributors know the flow, roles, and exit criteria." + - "Turn this loose workflow into PR walkthrough docs with checkpoints, ownership, and review gates." --- # PR Walkthrough -Support pr walkthrough workflows with clear steps and best practices. +Use this skill when the user needs PR walkthrough docs that turn an informal workflow into something reviewable, teachable, and easier to execute consistently. -## When to Use +## Start By Clarifying +- Who participates in the process and where responsibilities change hands. +- What the entry criteria, checkpoints, and exit criteria should be. +- Which decisions require sign-off, escalation, or documented rationale. +- What artifacts, links, or evidence should exist at each stage. +- How the process should stay lightweight enough to be followed in practice. -- You need help with pr walkthrough. -- You want a clear, actionable next step. +## Workflow +1. Define the objective of the process and the scenarios it is meant to cover. +2. Map the stages, decision points, owners, and required artifacts. +3. Make review gates, success criteria, and escalation rules explicit. +4. Add examples, templates, or checklists where teams commonly drift. +5. Document how the process is maintained when the system or team changes. -## Output +## Good Output +- Process outline with roles, sequence, and decision gates. +- Required artifacts, examples, or checklists. +- Open questions or edge cases that need policy rather than improvisation. +- Maintenance notes so the process stays current. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Describing the ideal path but omitting ownership and exception handling. +- Adding heavy ceremony without clear value or decision support. +- Failing to show what done looks like at each stage. +- Letting the process drift from how teams actually work. + +## Boundaries +- Do not confuse process guidance with proof that the process is already being followed. +- Prefer concrete responsibilities and exit criteria over vague workflow prose. diff --git a/skills/documentation/project-overview/SKILL.md b/skills/documentation/project-overview/SKILL.md index cce90429..60ce8717 100644 --- a/skills/documentation/project-overview/SKILL.md +++ b/skills/documentation/project-overview/SKILL.md @@ -1,20 +1,44 @@ --- id: project-overview name: Project Overview -description: Step-by-step guidance for project overview. +description: Write and improve project overview docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft project overview docs for this project so readers can act without guessing." + - "Review project overview docs for missing prerequisites, stale assumptions, and unclear steps." --- # Project Overview -Support project overview workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring project overview docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with project overview. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/python-expert/SKILL.md b/skills/documentation/python-expert/SKILL.md deleted file mode 100644 index 70668820..00000000 --- a/skills/documentation/python-expert/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: python-expert -name: Python Expert -description: Step-by-step guidance for python expert. -category: Documentation ---- - -# Python Expert - -Support python expert workflows with clear steps and best practices. - -## When to Use - -- You need help with python expert. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/reference-core/SKILL.md b/skills/documentation/reference-core/SKILL.md index efc5fdeb..06b9eeb1 100644 --- a/skills/documentation/reference-core/SKILL.md +++ b/skills/documentation/reference-core/SKILL.md @@ -1,20 +1,44 @@ --- id: reference-core name: Reference Core -description: Step-by-step guidance for reference core. +description: Create and maintain core reference docs with accurate contracts, examples, edge cases, and version-aware detail. category: Documentation +requires: [] +examples: + - "Create core reference docs with examples, constraints, and edge-case coverage." + - "Review core reference docs for gaps in contracts, parameters, compatibility notes, or failure cases." --- # Reference Core -Support reference core workflows with clear steps and best practices. +Use this skill when the user needs core reference docs that readers can trust as a durable lookup source rather than a vague narrative summary. -## When to Use +## Start By Clarifying +- What entities, endpoints, fields, functions, or concepts are actually in scope. +- Which versions, compatibility boundaries, or deprecations matter. +- What inputs, outputs, defaults, and error cases readers most often misunderstand. +- Which examples are necessary to make the reference usable, not just complete. +- What surrounding guide material should be linked rather than duplicated. -- You need help with reference core. -- You want a clear, actionable next step. +## Workflow +1. Define the reference surface and group it into durable reader-facing sections. +2. Document contracts, required fields, defaults, side effects, and failure modes explicitly. +3. Add examples that show normal use, edge cases, and compatibility caveats. +4. Call out version boundaries, deprecations, and non-obvious constraints. +5. Review for omissions that would force readers back into code or guesswork. -## Output +## Good Output +- Reference structure by resource, concept, or API surface. +- Missing contract details, examples, or compatibility notes. +- Places where defaults, limits, or failure behavior need stronger explanation. +- Cross-links needed to connect reference material to task-oriented guides. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting names without documenting behavior or constraints. +- Skipping error cases because the happy path feels sufficient. +- Hiding version-specific caveats until readers hit production issues. +- Letting the reference drift from actual source behavior. + +## Boundaries +- Do not imply undocumented behavior is guaranteed. +- Prefer precise contracts and examples over broad marketing-style wording. diff --git a/skills/documentation/reference-signal-forms/SKILL.md b/skills/documentation/reference-signal-forms/SKILL.md deleted file mode 100644 index 028b9265..00000000 --- a/skills/documentation/reference-signal-forms/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: reference-signal-forms -name: Reference Signal Forms -description: Step-by-step guidance for reference signal forms. -category: Documentation ---- - -# Reference Signal Forms - -Support reference signal forms workflows with clear steps and best practices. - -## When to Use - -- You need help with reference signal forms. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/resource-curator/SKILL.md b/skills/documentation/resource-curator/SKILL.md deleted file mode 100644 index f6bd1b6f..00000000 --- a/skills/documentation/resource-curator/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: resource-curator -name: Resource Curator -description: Step-by-step guidance for resource curator. -category: Documentation ---- - -# Resource Curator - -Support resource curator workflows with clear steps and best practices. - -## When to Use - -- You need help with resource curator. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/review-docs/SKILL.md b/skills/documentation/review-docs/SKILL.md index a15463e0..56e1d85b 100644 --- a/skills/documentation/review-docs/SKILL.md +++ b/skills/documentation/review-docs/SKILL.md @@ -1,20 +1,44 @@ --- id: review-docs name: Review Docs -description: Step-by-step guidance for docs. +description: Write and improve doc review workflows with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft doc review workflows for this project so readers can act without guessing." + - "Review doc review workflows for missing prerequisites, stale assumptions, and unclear steps." --- # Review Docs -Support docs workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring doc review workflows and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with review docs. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/scientific-slides/SKILL.md b/skills/documentation/scientific-slides/SKILL.md index d683d99f..ca95461d 100644 --- a/skills/documentation/scientific-slides/SKILL.md +++ b/skills/documentation/scientific-slides/SKILL.md @@ -1,20 +1,44 @@ --- id: scientific-slides name: Scientific Slides -description: Step-by-step guidance for scientific slides. +description: Write and improve scientific slide docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft scientific slide docs for this project so readers can act without guessing." + - "Review scientific slide docs for missing prerequisites, stale assumptions, and unclear steps." --- # Scientific Slides -Support scientific slides workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring scientific slide docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with scientific slides. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/seo-audit/SKILL.md b/skills/documentation/seo-audit/SKILL.md index c6072691..a778dad3 100644 --- a/skills/documentation/seo-audit/SKILL.md +++ b/skills/documentation/seo-audit/SKILL.md @@ -1,20 +1,44 @@ --- id: seo-audit name: SEO Audit -description: Step-by-step guidance for seo audit. +description: Write and improve SEO audit docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft SEO audit docs for this project so readers can act without guessing." + - "Review SEO audit docs for missing prerequisites, stale assumptions, and unclear steps." --- # SEO Audit -Support seo audit workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring SEO audit docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with seo audit. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/skill-builder/SKILL.md b/skills/documentation/skill-builder/SKILL.md deleted file mode 100644 index 7739007e..00000000 --- a/skills/documentation/skill-builder/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: skill-builder -name: Skill Builder -description: Step-by-step guidance for builder. -category: Documentation ---- - -# Skill Builder - -Support builder workflows with clear steps and best practices. - -## When to Use - -- You need help with skill builder. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/skill-development/SKILL.md b/skills/documentation/skill-development/SKILL.md deleted file mode 100644 index ed023834..00000000 --- a/skills/documentation/skill-development/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: skill-development -name: Skill Development -description: Step-by-step guidance for development. -category: Documentation ---- - -# Skill Development - -Support development workflows with clear steps and best practices. - -## When to Use - -- You need help with skill development. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/skill-seekers/SKILL.md b/skills/documentation/skill-seekers/SKILL.md deleted file mode 100644 index e0e4128d..00000000 --- a/skills/documentation/skill-seekers/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: skill-seekers -name: Skill Seekers -description: Step-by-step guidance for seekers. -category: Documentation ---- - -# Skill Seekers - -Support seekers workflows with clear steps and best practices. - -## When to Use - -- You need help with skill seekers. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/skill-share/SKILL.md b/skills/documentation/skill-share/SKILL.md deleted file mode 100644 index 720733cc..00000000 --- a/skills/documentation/skill-share/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: skill-share -name: Skill Share -description: Step-by-step guidance for share. -category: Documentation ---- - -# Skill Share - -Support share workflows with clear steps and best practices. - -## When to Use - -- You need help with skill share. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/slack-gif-creator/SKILL.md b/skills/documentation/slack-gif-creator/SKILL.md deleted file mode 100644 index 9b88225b..00000000 --- a/skills/documentation/slack-gif-creator/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: slack-gif-creator -name: Slack GIF Creator -description: Step-by-step guidance for slack gif creator. -category: Documentation ---- - -# Slack GIF Creator - -Support slack gif creator workflows with clear steps and best practices. - -## When to Use - -- You need help with slack gif creator. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/testing-handbook-generator/SKILL.md b/skills/documentation/testing-handbook-generator/SKILL.md index 39eb1b17..f9a208ca 100644 --- a/skills/documentation/testing-handbook-generator/SKILL.md +++ b/skills/documentation/testing-handbook-generator/SKILL.md @@ -1,20 +1,44 @@ --- id: testing-handbook-generator name: Testing Handbook Generator -description: Step-by-step guidance for testing handbook. +description: Develop testing handbooks with step-by-step guidance, examples, troubleshooting, and update ownership. category: Documentation +requires: [] +examples: + - "Create testing handbooks with step-by-step workflows, examples, and troubleshooting." + - "Audit testing handbooks for missing validation steps, stale procedures, and weak edge-case guidance." --- # Testing Handbook Generator -Support testing handbook workflows with clear steps and best practices. +Use this skill when the user is building testing handbooks and needs a guide that people can actually follow under normal work and edge conditions. -## When to Use +## Start By Clarifying +- What tasks the handbook should support from start to finish. +- Which readers are beginners versus experienced maintainers. +- What tooling, environment, or safety assumptions must be explicit. +- Which examples, troubleshooting paths, or validation steps are essential. +- How the handbook will stay aligned with reality as systems evolve. -- You need help with testing handbook generator. -- You want a clear, actionable next step. +## Workflow +1. Define the handbook scope and the task sequence readers need most. +2. Write the guide around workflows, checkpoints, and recovery paths rather than just concepts. +3. Add examples, troubleshooting cues, and validation steps for common failure modes. +4. Surface prerequisites, limits, and risky assumptions early. +5. Review for stale steps, missing edge cases, and unclear ownership. -## Output +## Good Output +- Task-oriented handbook structure. +- Examples, validation checkpoints, and troubleshooting sections worth adding. +- Risks or stale assumptions that make the current guide hard to trust. +- Update and ownership guidance for long-term maintenance. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Explaining theory while leaving readers unable to execute the task. +- Omitting troubleshooting because the happy path seems obvious. +- Leaving commands, version assumptions, or paths to decay silently. +- Packing too many unrelated workflows into one handbook. + +## Boundaries +- Do not present unchecked steps as validated procedure. +- Prefer practical workflows and failure handling over generic advice. diff --git a/skills/documentation/train-rl/SKILL.md b/skills/documentation/train-rl/SKILL.md deleted file mode 100644 index ae6a3f83..00000000 --- a/skills/documentation/train-rl/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: train-rl -name: Train RL -description: Step-by-step guidance for train rl. -category: Documentation ---- - -# Train RL - -Support train rl workflows with clear steps and best practices. - -## When to Use - -- You need help with train rl. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/tutorial-engineer/SKILL.md b/skills/documentation/tutorial-engineer/SKILL.md index 84512162..1b5c7c0b 100644 --- a/skills/documentation/tutorial-engineer/SKILL.md +++ b/skills/documentation/tutorial-engineer/SKILL.md @@ -1,20 +1,44 @@ --- id: tutorial-engineer name: Tutorial Engineer -description: Step-by-step guidance for tutorial engineer. +description: Write and improve tutorial docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft tutorial docs for this project so readers can act without guessing." + - "Review tutorial docs for missing prerequisites, stale assumptions, and unclear steps." --- # Tutorial Engineer -Support tutorial engineer workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring tutorial docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with tutorial engineer. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/update-docs/SKILL.md b/skills/documentation/update-docs/SKILL.md deleted file mode 100644 index 83c308aa..00000000 --- a/skills/documentation/update-docs/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: update-docs -name: Update Docs -description: Step-by-step guidance for update docs. -category: Documentation ---- - -# Update Docs - -Support update docs workflows with clear steps and best practices. - -## When to Use - -- You need help with update docs. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/web-design-guidelines/SKILL.md b/skills/documentation/web-design-guidelines/SKILL.md index 1e40320e..74505aca 100644 --- a/skills/documentation/web-design-guidelines/SKILL.md +++ b/skills/documentation/web-design-guidelines/SKILL.md @@ -1,20 +1,44 @@ --- id: web-design-guidelines name: Web Design Guidelines -description: Step-by-step guidance for web design guidelines. +description: Write and improve web design guideline docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft web design guideline docs for this project so readers can act without guessing." + - "Review web design guideline docs for missing prerequisites, stale assumptions, and unclear steps." --- # Web Design Guidelines -Support web design guidelines workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring web design guideline docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with web design guidelines. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/web-design-reviewer/SKILL.md b/skills/documentation/web-design-reviewer/SKILL.md index 29d4f93c..1a6b2466 100644 --- a/skills/documentation/web-design-reviewer/SKILL.md +++ b/skills/documentation/web-design-reviewer/SKILL.md @@ -1,20 +1,44 @@ --- id: web-design-reviewer name: Web Design Reviewer -description: Step-by-step guidance for web design reviewer. +description: Write and improve web design review docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft web design review docs for this project so readers can act without guessing." + - "Review web design review docs for missing prerequisites, stale assumptions, and unclear steps." --- # Web Design Reviewer -Support web design reviewer workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring web design review docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with web design reviewer. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/wiki-onboarding/SKILL.md b/skills/documentation/wiki-onboarding/SKILL.md index 582aab7d..1fa49df7 100644 --- a/skills/documentation/wiki-onboarding/SKILL.md +++ b/skills/documentation/wiki-onboarding/SKILL.md @@ -1,20 +1,44 @@ --- id: wiki-onboarding name: Wiki Onboarding -description: Step-by-step guidance for wiki onboarding. +description: Write and improve wiki onboarding docs with clear structure, audience fit, useful examples, and maintenance guidance. category: Documentation +requires: [] +examples: + - "Draft wiki onboarding docs for this project so readers can act without guessing." + - "Review wiki onboarding docs for missing prerequisites, stale assumptions, and unclear steps." --- # Wiki Onboarding -Support wiki onboarding workflows with clear steps and best practices. +Use this skill when the user is writing, reviewing, or restructuring wiki onboarding docs and needs the result to be readable, trustworthy, and genuinely useful after publication. -## When to Use +## Start By Clarifying +- Who the readers are and what they are trying to accomplish. +- What source material or product truth the document should rely on. +- Which prerequisites, assumptions, or environment details must be explicit. +- What is likely to change over time and how freshness will be maintained. +- Whether the document should teach, orient, review, or support troubleshooting. -- You need help with wiki onboarding. -- You want a clear, actionable next step. +## Workflow +1. Define the audience, the primary reader questions, and the desired outcome. +2. Gather accurate source material from code, product behavior, or subject-matter owners. +3. Organize the document around reader tasks, decisions, or mental models rather than internal org charts. +4. Add concrete examples, checklists, or comparisons where they reduce ambiguity. +5. Review for gaps, stale assumptions, and missing ownership before calling it complete. -## Output +## Good Output +- Recommended document structure and section order. +- Gaps in reader context, prerequisites, or examples. +- Suggested revisions for clarity, accuracy, and maintainability. +- Update triggers or ownership notes for future freshness. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Writing for insiders and assuming too much prior knowledge. +- Burying prerequisites or caveats after the main steps. +- Leaving examples too abstract to help real readers. +- Publishing docs with no clear owner or update trigger. + +## Boundaries +- Do not present guesses as verified facts. +- Prefer reader tasks and decision support over internal jargon or filler. diff --git a/skills/documentation/workflows-yaml-reference/SKILL.md b/skills/documentation/workflows-yaml-reference/SKILL.md index 053e3ae1..f6dedfb1 100644 --- a/skills/documentation/workflows-yaml-reference/SKILL.md +++ b/skills/documentation/workflows-yaml-reference/SKILL.md @@ -1,20 +1,44 @@ --- id: workflows-yaml-reference name: Workflows YAML Reference -description: Step-by-step guidance for workflows yaml reference. +description: Create and maintain workflow YAML reference docs with accurate contracts, examples, edge cases, and version-aware detail. category: Documentation +requires: [] +examples: + - "Create workflow YAML reference docs with examples, constraints, and edge-case coverage." + - "Review workflow YAML reference docs for gaps in contracts, parameters, compatibility notes, or failure cases." --- # Workflows YAML Reference -Support workflows yaml reference workflows with clear steps and best practices. +Use this skill when the user needs workflow YAML reference docs that readers can trust as a durable lookup source rather than a vague narrative summary. -## When to Use +## Start By Clarifying +- What entities, endpoints, fields, functions, or concepts are actually in scope. +- Which versions, compatibility boundaries, or deprecations matter. +- What inputs, outputs, defaults, and error cases readers most often misunderstand. +- Which examples are necessary to make the reference usable, not just complete. +- What surrounding guide material should be linked rather than duplicated. -- You need help with workflows yaml reference. -- You want a clear, actionable next step. +## Workflow +1. Define the reference surface and group it into durable reader-facing sections. +2. Document contracts, required fields, defaults, side effects, and failure modes explicitly. +3. Add examples that show normal use, edge cases, and compatibility caveats. +4. Call out version boundaries, deprecations, and non-obvious constraints. +5. Review for omissions that would force readers back into code or guesswork. -## Output +## Good Output +- Reference structure by resource, concept, or API surface. +- Missing contract details, examples, or compatibility notes. +- Places where defaults, limits, or failure behavior need stronger explanation. +- Cross-links needed to connect reference material to task-oriented guides. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Documenting names without documenting behavior or constraints. +- Skipping error cases because the happy path feels sufficient. +- Hiding version-specific caveats until readers hit production issues. +- Letting the reference drift from actual source behavior. + +## Boundaries +- Do not imply undocumented behavior is guaranteed. +- Prefer precise contracts and examples over broad marketing-style wording. diff --git a/skills/documentation/write-concept/SKILL.md b/skills/documentation/write-concept/SKILL.md deleted file mode 100644 index e1615c64..00000000 --- a/skills/documentation/write-concept/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: write-concept -name: Write Concept -description: Step-by-step guidance for write concept. -category: Documentation ---- - -# Write Concept - -Support write concept workflows with clear steps and best practices. - -## When to Use - -- You need help with write concept. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/write-docs/SKILL.md b/skills/documentation/write-docs/SKILL.md deleted file mode 100644 index 6c6912d0..00000000 --- a/skills/documentation/write-docs/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: write-docs -name: Write Docs -description: Step-by-step guidance for write docs. -category: Documentation ---- - -# Write Docs - -Support write docs workflows with clear steps and best practices. - -## When to Use - -- You need help with write docs. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/write-example/SKILL.md b/skills/documentation/write-example/SKILL.md deleted file mode 100644 index 95aca980..00000000 --- a/skills/documentation/write-example/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: write-example -name: Write Example -description: Step-by-step guidance for write example. -category: Documentation ---- - -# Write Example - -Support write example workflows with clear steps and best practices. - -## When to Use - -- You need help with write example. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions diff --git a/skills/documentation/write-release-notes/SKILL.md b/skills/documentation/write-release-notes/SKILL.md index 80a269a4..13f443b4 100644 --- a/skills/documentation/write-release-notes/SKILL.md +++ b/skills/documentation/write-release-notes/SKILL.md @@ -1,20 +1,44 @@ --- id: write-release-notes name: Write Release Notes -description: Step-by-step guidance for write release notes. +description: Write release notes with clear impact, compatibility notes, rollout context, and reader actions. category: Documentation +requires: [] +examples: + - "Draft release notes that explains impact, migration notes, and known issues clearly." + - "Review release notes so readers can tell whether they are affected and what to do next." --- # Write Release Notes -Support write release notes workflows with clear steps and best practices. +Use this skill when the user needs release notes so readers understand what changed, why it matters, and what they need to do next. -## When to Use +## Start By Clarifying +- Who the release notes are for and what they care about most. +- Which changes are user-visible, operationally significant, or compatibility-sensitive. +- Whether migrations, deprecations, or rollout caveats need explicit treatment. +- What risks, known issues, or support guidance should be surfaced. +- How much implementation detail helps rather than distracts. -- You need help with write release notes. -- You want a clear, actionable next step. +## Workflow +1. Collect the meaningful changes and group them by reader impact, not commit chronology. +2. Highlight features, fixes, breaking changes, and operational notes separately where useful. +3. Add migration or upgrade guidance wherever readers may need to take action. +4. Call out known issues, rollout caveats, and audience-specific warnings honestly. +5. Review the notes for clarity, completeness, and whether affected readers can recognize themselves. -## Output +## Good Output +- Release summary tailored to the intended audience. +- Grouped notes by impact or change type. +- Migration, rollback, or compatibility notes. +- Known issues or rollout caveats that should not be hidden. -- Summary of goals and plan -- Key tips and precautions +## Common Pitfalls +- Copying commit messages instead of explaining reader impact. +- Burying breaking changes among minor fixes. +- Leaving users unsure whether they need to act. +- Overstating rollout completeness or stability without confirmation. + +## Boundaries +- Do not imply a change is fully rolled out unless the user confirms it. +- Prefer impact-focused communication over changelog noise. diff --git a/skills/documentation/writing-docs/SKILL.md b/skills/documentation/writing-docs/SKILL.md deleted file mode 100644 index 87dd42df..00000000 --- a/skills/documentation/writing-docs/SKILL.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: writing-docs -name: Writing Docs -description: Step-by-step guidance for docs. -category: Documentation ---- - -# Writing Docs - -Support docs workflows with clear steps and best practices. - -## When to Use - -- You need help with writing docs. -- You want a clear, actionable next step. - -## Output - -- Summary of goals and plan -- Key tips and precautions