npm - opencode-skills-collection - Versions diffs - 4.0.52 → 4.0.54 - Mend

opencode-skills-collection 4.0.52 → 4.0.54

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1176) hide show

package/bundled-skills/bug-hunt-swarm/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: bug-hunt-swarm
-description: Parallel read-only multi-agent root-cause investigation for bugs, regressions, crashes, flaky behavior, or unexplained failures. Use when the user asks to investigate a bug, find the root cause, trace a regression, understand why something broke, or wants a ranked diagnosis with the...
+description: "Parallel read-only multi-agent root-cause investigation for bugs, regressions, crashes, flaky behavior, or unexplained failures."
 risk: safe
 source: https://github.com/Dimillian/Skills/tree/main/bug-hunt-swarm
 source_repo: Dimillian/Skills
@@ -182,6 +182,12 @@ When helpful, group actions into:
 Do not implement fixes as part of this skill. The output is a read-only diagnosis with a prioritized path forward.
+## Example
+**User request:**
+> Investigate this failure with @bug-hunt-swarm, prove the root cause, implement the smallest safe fix, and verify it.
 ## Limitations
 - Use this skill only when the task clearly matches its upstream source and local project context.

package/bundled-skills/build/SKILL.md CHANGED Viewed

@@ -3,6 +3,7 @@ name: build
 description: build
 risk: critical
 source: community
+date_added: "2026-09-04"
 ---
 ---
@@ -16,638 +17,15 @@ metadata:
 Feature development pipeline - research, plan, track, and implement major features.
+## Detailed Guide
+Read [the detailed guide](references/detailed-guide.md) before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.
 ## When to Use
 - You need a structured workflow for building a major feature across research, planning, implementation, and tracking.
 - The task involves moving a feature through named phases such as `research`, `implementation`, `progress`, or `phase`.
 - You want one command to coordinate status, next steps, and phased delivery for a feature effort.
-## Instructions
-This command manages a 4-phase feature development workflow for building major features. Parse `$ARGUMENTS` to determine which subcommand to run.
-**Arguments provided:** $ARGUMENTS
-### Argument Parsing
-Parse the first word of $ARGUMENTS to determine the subcommand:
-- `research [name]` → Run the Research phase
-- `implementation [name]` → Run the Implementation phase
-- `progress [name]` → Run the Progress phase
-- `phase [n] [name]` → Run Phase n of the implementation
-- `status [name]` → Show current status and suggest next step
-- (empty or unrecognized) → Show usage help
-If the feature name is not provided in arguments, you MUST use AskUserQuestion to prompt for it.
----
-## Subcommand: Help (empty args)
-If no arguments provided, display this help:
-```
-/build - Feature Development Pipeline
-Subcommands:
-  /build research [name]        Deep research on a feature idea
-  /build implementation [name]  Create phased implementation plan
-  /build progress [name]        Set up progress tracking
-  /build phase [n] [name]       Execute implementation phase n
-  /build status [name]          Show status and next steps
-Example workflow:
-  /build research chat-interface
-  /build implementation chat-interface
-  /build progress chat-interface
-  /build phase 1 chat-interface
-```
-Then use AskUserQuestion to ask what they'd like to do:
-- question: "What would you like to do?"
-- header: "Action"
-- multiSelect: false
-- options:
-  - label: "Start new feature research"
-    description: "Begin deep research on a new feature idea"
-  - label: "Continue existing feature"
-    description: "Work on a feature already in progress"
-  - label: "Check status"
-    description: "See what step to do next for a feature"
----
-## Subcommand: research
-### Step 1: Get Feature Name
-If feature name not in arguments, use AskUserQuestion:
-- question: "What's a short identifier for this feature? (lowercase, hyphens ok - e.g., 'chat-interface', 'user-auth', 'data-export'). Use 'Other' to type it."
-- header: "Feature name"
-- multiSelect: false
-- options:
-  - label: "I'll type the name"
-    description: "Enter a short, kebab-case identifier for the feature"
-### Step 2: Check for Existing Research
-Check if `docs/{name}/RESEARCH.md` already exists.
-If it exists, use AskUserQuestion:
-- question: "A RESEARCH.md already exists for this feature. What would you like to do?"
-- header: "Existing doc"
-- multiSelect: false
-- options:
-  - label: "Overwrite"
-    description: "Replace existing research with fresh exploration"
-  - label: "Append"
-    description: "Add new research below existing content"
-  - label: "Skip"
-    description: "Keep existing research, suggest next step"
-If "Skip" selected, suggest running `/build implementation {name}` and exit.
-### Step 3: Gather Feature Context
-Use AskUserQuestion to understand the feature:
-- question: "Describe the feature you want to build. What problem does it solve? What should it do? (Use 'Other' to describe)"
-- header: "Description"
-- multiSelect: false
-- options:
-  - label: "I'll describe it"
-    description: "Provide a detailed description of the feature"
-### Step 4: Research Scope
-Use AskUserQuestion:
-- question: "What aspects should the research focus on?"
-- header: "Focus areas"
-- multiSelect: true
-- options:
-  - label: "Technical implementation"
-    description: "APIs, libraries, architecture patterns"
-  - label: "UI/UX design"
-    description: "Interface design, user flows, interactions"
-  - label: "Data requirements"
-    description: "What data to store, schemas, privacy"
-  - label: "Platform capabilities"
-    description: "OS APIs, system integrations, permissions"
-### Step 5: Conduct Deep Research
-Now conduct DEEP research on the feature:
-1. **Codebase exploration**: Understand existing patterns, similar features, relevant code
-2. **Web search**: Research best practices, similar implementations, relevant APIs
-3. **Technical deep-dive**: Explore specific technologies, libraries, frameworks
-4. **Use AskUserQuestion FREQUENTLY**: Validate assumptions, clarify requirements, get input on decisions
-Research should cover:
-- Problem definition and user needs
-- Technical approaches and trade-offs
-- Required data models and storage
-- UI/UX considerations
-- Integration points with existing code
-- Potential challenges and risks
-- Recommended approach with rationale
-### Step 6: Write Research Document
-Create the directory if needed: `docs/{name}/`
-Write findings to `docs/{name}/RESEARCH.md` with this structure:
-```markdown
-# {Feature Name} Research
-## Overview
-[Brief description of the feature and its purpose]
-## Problem Statement
-[What problem this solves, why it matters]
-## User Stories / Use Cases
-[Concrete examples of how users will use this]
-## Technical Research
-### Approach Options
-[Different ways to implement this, with pros/cons]
-### Recommended Approach
-[The approach you recommend and why]
-### Required Technologies
-[APIs, libraries, frameworks needed]
-### Data Requirements
-[What data needs to be stored/tracked]
-## UI/UX Considerations
-[Interface design thoughts, user flows]
-## Integration Points
-[How this connects to existing code/features]
-## Risks and Challenges
-[Potential issues and mitigation strategies]
-## Open Questions
-[Things that still need to be decided]
-## References
-[Links to relevant documentation, examples, articles]
-```
-### Step 7: Next Step
-After writing the research doc, inform the user:
-"Research complete! Document saved to `docs/{name}/RESEARCH.md`
-**Next step:** Run `/build implementation {name}` to create a phased implementation plan."
----
-## Subcommand: implementation
-### Step 1: Get Feature Name
-If feature name not in arguments, use AskUserQuestion to prompt for it (same as research phase).
-### Step 2: Verify Research Exists
-Check if `docs/{name}/RESEARCH.md` exists.
-If it does NOT exist:
-- Inform user: "No research document found at `docs/{name}/RESEARCH.md`"
-- Suggest: "Run `/build research {name}` first to create the research document."
-- Exit
-### Step 3: Check for Existing Implementation Doc
-Check if `docs/{name}/IMPLEMENTATION.md` already exists.
-If it exists, use AskUserQuestion:
-- question: "An IMPLEMENTATION.md already exists. What would you like to do?"
-- header: "Existing doc"
-- multiSelect: false
-- options:
-  - label: "Overwrite"
-    description: "Create a fresh implementation plan"
-  - label: "Append"
-    description: "Add new phases below existing content"
-  - label: "Skip"
-    description: "Keep existing plan, suggest next step"
-If "Skip" selected, suggest running `/build progress {name}` and exit.
-### Step 4: Read Research Document
-Read `docs/{name}/RESEARCH.md` to understand:
-- The recommended approach
-- Technical requirements
-- Data models needed
-- UI/UX design
-- Integration points
-### Step 5: Design Implementation Phases
-Break the research into practical implementation phases. Each phase should:
-- Be independently valuable (deliver something usable)
-- Be small enough to complete in a focused session
-- Build on previous phases
-- Have clear success criteria
-Use AskUserQuestion to validate phase breakdown:
-- question: "How granular should the implementation phases be?"
-- header: "Phase size"
-- multiSelect: false
-- options:
-  - label: "Small phases (1-2 hours)"
-    description: "Many focused phases, easier to track progress"
-  - label: "Medium phases (half day)"
-    description: "Balanced approach, moderate number of phases"
-  - label: "Large phases (full day)"
-    description: "Fewer phases, each delivering significant functionality"
-### Step 6: Conduct Phase Research
-For each phase you're planning, do targeted research:
-- Web search for implementation specifics
-- Review relevant code in the codebase
-- Identify dependencies between phases
-Use AskUserQuestion for any uncertainties about phase ordering or scope.
-### Step 7: Write Implementation Document
-Write to `docs/{name}/IMPLEMENTATION.md` with this structure:
-```markdown
-# {Feature Name} Implementation Plan
-## Overview
-[Brief recap of what we're building and the approach from research]
-## Prerequisites
-[What needs to be in place before starting]
-## Phase Summary
-[Quick overview of all phases]
----
-## Phase 1: [Phase Title]
-### Objective
-[What this phase accomplishes]
-### Rationale
-[Why this phase comes first, what it enables]
-### Tasks
-- [ ] Task 1
-- [ ] Task 2
-- [ ] Task 3
-### Success Criteria
-[How to verify this phase is complete]
-### Files Likely Affected
-[List of files that will probably need changes]
----
-## Phase 2: [Phase Title]
-[Same structure as Phase 1]
----
-[Continue for all phases]
----
-## Post-Implementation
-- [ ] Documentation updates
-- [ ] Testing strategy
-- [ ] Performance validation
-## Notes
-[Any additional context or decisions made during planning]
-```
-### Step 8: Next Step
-After writing the implementation doc, inform the user:
-"Implementation plan complete! Document saved to `docs/{name}/IMPLEMENTATION.md`
-**Next step:** Run `/build progress {name}` to set up progress tracking."
----
-## Subcommand: progress
-### Step 1: Get Feature Name
-If feature name not in arguments, use AskUserQuestion to prompt for it.
-### Step 2: Verify Implementation Doc Exists
-Check if `docs/{name}/IMPLEMENTATION.md` exists.
-If it does NOT exist:
-- Inform user: "No implementation document found at `docs/{name}/IMPLEMENTATION.md`"
-- Suggest: "Run `/build implementation {name}` first."
-- Exit
-### Step 3: Check for Existing Progress Doc
-Check if `docs/{name}/PROGRESS.md` already exists.
-If it exists, use AskUserQuestion:
-- question: "A PROGRESS.md already exists. What would you like to do?"
-- header: "Existing doc"
-- multiSelect: false
-- options:
-  - label: "Overwrite"
-    description: "Start fresh progress tracking"
-  - label: "Keep existing"
-    description: "Keep current progress, suggest next step"
-If "Keep existing" selected, read the progress doc and suggest the next incomplete phase.
-### Step 4: Read Implementation Document
-Read `docs/{name}/IMPLEMENTATION.md` to extract:
-- All phase titles
-- Tasks within each phase
-- Success criteria
-### Step 5: Create Progress Document
-Write to `docs/{name}/PROGRESS.md` with this structure:
-```markdown
-# {Feature Name} Progress
-## Status: Phase 1 - Not Started
-## Quick Reference
-- Research: `docs/{name}/RESEARCH.md`
-- Implementation: `docs/{name}/IMPLEMENTATION.md`
----
-## Phase Progress
-### Phase 1: [Title from Implementation]
-**Status:** Not Started
-#### Tasks Completed
-- (none yet)
-#### Decisions Made
-- (none yet)
-#### Blockers
-- (none)
----
-### Phase 2: [Title]
-**Status:** Not Started
-[Same structure]
----
-[Continue for all phases]
----
-## Session Log
-### [Date will be added as work happens]
-- Work completed
-- Decisions made
-- Notes for next session
----
-## Files Changed
-(Will be updated as implementation progresses)
-## Architectural Decisions
-(Major technical decisions and rationale)
-## Lessons Learned
-(What worked, what didn't, what to do differently)
-```
-### Step 6: Next Step
-After creating progress doc:
-"Progress tracking set up! Document saved to `docs/{name}/PROGRESS.md`
-**Next step:** Run `/build phase 1 {name}` to begin implementation."
----
-## Subcommand: phase
-### Step 1: Parse Arguments
-Parse arguments to extract:
-- Phase number (if provided)
-- Feature name (if provided)
-If neither provided, prompt for both using AskUserQuestion.
-### Step 2: Get Feature Name
-If feature name not determined, use AskUserQuestion to prompt for it.
-### Step 3: Verify All Docs Exist
-Check that all three docs exist:
-- `docs/{name}/RESEARCH.md`
-- `docs/{name}/IMPLEMENTATION.md`
-- `docs/{name}/PROGRESS.md`
-If any missing, inform user which doc is missing and suggest the appropriate `/build` command to create it.
-### Step 4: Get Phase Number
-If phase number not in arguments:
-Read `docs/{name}/IMPLEMENTATION.md` to extract available phases.
-Use AskUserQuestion to let user select:
-- question: "Which phase would you like to work on?"
-- header: "Phase"
-- multiSelect: false
-- options: [dynamically generated from phases found in IMPLEMENTATION.md, marking completed ones]
-### Step 5: Read All Context
-Read all three documents to fully understand:
-- The research and rationale (RESEARCH.md)
-- The specific phase tasks and success criteria (IMPLEMENTATION.md)
-- Current progress and decisions made (PROGRESS.md)
-### Step 6: Deep Research on Phase
-Before starting implementation:
-1. **Web search** for specific implementation details relevant to this phase
-2. **Codebase exploration** for relevant existing code
-3. **Use AskUserQuestion** to clarify any ambiguities about the phase requirements
-### Step 7: Execute Phase Work
-Begin implementing the phase:
-1. Work through each task in the phase
-2. Use AskUserQuestion frequently for implementation decisions
-3. Follow the "Always Works" philosophy - test as you go
-4. Document decisions in PROGRESS.md as you make them
-### Step 8: Update Progress Document
-As you work, update `docs/{name}/PROGRESS.md`:
-- Mark tasks as completed
-- Record decisions made and why
-- Note any blockers encountered
-- List files changed
-- Add architectural decisions
-- Update the session log with today's work
-Update the phase status:
-- "In Progress" when starting
-- "Completed" when all tasks done and success criteria met
-### Step 9: Next Step
-After completing the phase:
-1. Read PROGRESS.md to determine next incomplete phase
-2. Inform user of completion and suggest next action:
-"Phase {n} complete! Progress updated in `docs/{name}/PROGRESS.md`
-**Next step:** Run `/build phase {n+1} {name}` to continue with [next phase title]."
-Or if all phases complete:
-"All phases complete! The {feature name} feature implementation is done.
-Consider:
-- Running tests to verify everything works
-- Updating documentation
-- Creating a PR for review"
----
-## Subcommand: status
-### Step 1: Get Feature Name
-If feature name not in arguments, use AskUserQuestion to prompt for it.
-### Step 2: Check Which Docs Exist
-Check for existence of:
-- `docs/{name}/RESEARCH.md`
-- `docs/{name}/IMPLEMENTATION.md`
-- `docs/{name}/PROGRESS.md`
-### Step 3: Determine Status and Next Step
-Based on which docs exist:
-**No docs exist:**
-"No documents found for feature '{name}'.
-**Next step:** Run `/build research {name}` to start."
-**Only RESEARCH.md exists:**
-"Research complete for '{name}'.
-**Next step:** Run `/build implementation {name}` to create implementation plan."
-**RESEARCH.md and IMPLEMENTATION.md exist:**
-"Research and implementation plan complete for '{name}'.
-**Next step:** Run `/build progress {name}` to set up progress tracking."
-**All three exist:**
-Read PROGRESS.md to find current phase status.
-"Feature '{name}' is in progress.
-**Current status:** [Phase X - status]
-**Next step:** Run `/build phase {next incomplete phase} {name}` to continue."
-If all phases complete:
-"Feature '{name}' implementation is complete!"
----
-## Important Guidelines
-### Use AskUserQuestion Liberally
-Throughout all phases, use AskUserQuestion whenever:
-- There's ambiguity in requirements
-- Multiple approaches are possible
-- You need to validate an assumption
-- A decision will significantly impact the implementation
-- You're unsure about scope or priority
-### Deep Research Expectations
-"Deep research" means:
-- Multiple web searches on different aspects
-- Thorough codebase exploration
-- Reading relevant documentation
-- Considering multiple approaches
-- Understanding trade-offs
-Don't rush through research - it's the foundation for good implementation.
-### Progress Tracking
-Keep PROGRESS.md updated in real-time during phase work:
-- Don't wait until the end to update
-- Record decisions as they're made
-- Note blockers immediately
-- This creates valuable context for future sessions
-### Scope Management
-A key purpose of this workflow is preventing scope creep:
-- Each phase should have clear boundaries
-- If new requirements emerge, note them for future phases
-- Don't expand the current phase's scope mid-implementation
-- Use AskUserQuestion to validate if something is in/out of scope
-### Always Works Philosophy
-When implementing phases:
-- Test changes as you make them
-- Don't assume code works - verify it
-- If something doesn't work, fix it before moving on
-- The goal is working software, not just written code
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.