@fro.bot/systematic 1.14.0 → 1.16.0

package/skills/create-agent-skills/workflows/create-new-skill.md

@@ -18,7 +18,7 @@
 **If user just invoked skill without context:**
 → Ask what they want to build
 
-### Using AskUserQuestion
+### Using question tool
 
 Ask 2-4 domain-specific questions based on actual gaps. Each question should:
 - Have specific options with descriptions
@@ -42,7 +42,7 @@ Options:
 
 ## Step 2: Research Trigger (If External API)
 
-**When external service detected**, ask using AskUserQuestion:
+**When external service detected**, ask using question tool:
 "This involves [service name] API. Would you like me to research current endpoints and patterns before building?"
 
 Options:
@@ -90,13 +90,13 @@ See references/recommended-structure.md for templates.
 ## Step 4: Create Directory
 
 ```bash
-mkdir -p ~/.claude/skills/{skill-name}
+mkdir -p ~/.config/opencode/skills/{skill-name}
 # If complex:
-mkdir -p ~/.claude/skills/{skill-name}/workflows
-mkdir -p ~/.claude/skills/{skill-name}/references
+mkdir -p ~/.config/opencode/skills/{skill-name}/workflows
+mkdir -p ~/.config/opencode/skills/{skill-name}/references
 # If needed:
-mkdir -p ~/.claude/skills/{skill-name}/templates  # for output structures
-mkdir -p ~/.claude/skills/{skill-name}/scripts    # for reusable code
+mkdir -p ~/.config/opencode/skills/{skill-name}/templates  # for output structures
+mkdir -p ~/.config/opencode/skills/{skill-name}/scripts    # for reusable code
 ```
 
 ## Step 5: Write SKILL.md
@@ -154,7 +154,7 @@ Check:
 ## Step 9: Create Slash Command
 
 ```bash
-cat > ~/.claude/commands/{skill-name}.md << 'EOF'
+cat > ~/.config/opencode/commands/{skill-name}.md << 'EOF'
 ---
 description: {Brief description}
 argument-hint: [{argument hint}]

package/skills/create-agent-skills/workflows/upgrade-to-router.md

@@ -10,7 +10,7 @@
 ## Step 1: Select the Skill
 
 ```bash
-ls ~/.claude/skills/
+ls ~/.config/opencode/skills/
 ```
 
 Present numbered list, ask: "Which skill should be upgraded to the router pattern?"
@@ -19,8 +19,8 @@ Present numbered list, ask: "Which skill should be upgraded to the router patter
 
 Read the skill:
 ```bash
-cat ~/.claude/skills/{skill-name}/SKILL.md
-ls ~/.claude/skills/{skill-name}/
+cat ~/.config/opencode/skills/{skill-name}/SKILL.md
+ls ~/.config/opencode/skills/{skill-name}/
 ```
 
 **Already a router?** (has workflows/ and intake question)
@@ -65,8 +65,8 @@ Ask: "Does this breakdown look right? Any adjustments?"
 ## Step 4: Create Directory Structure
 
 ```bash
-mkdir -p ~/.claude/skills/{skill-name}/workflows
-mkdir -p ~/.claude/skills/{skill-name}/references
+mkdir -p ~/.config/opencode/skills/{skill-name}/workflows
+mkdir -p ~/.config/opencode/skills/{skill-name}/references
 ```
 
 ## Step 5: Extract Workflows

package/skills/create-agent-skills/workflows/verify-skill.md

@@ -15,7 +15,7 @@ Skills contain claims about external things: APIs, CLI tools, frameworks, servic
 ## Step 1: Select the Skill
 
 ```bash
-ls ~/.claude/skills/
+ls ~/.config/opencode/skills/
 ```
 
 Present numbered list, ask: "Which skill should I verify for accuracy?"
@@ -24,9 +24,9 @@ Present numbered list, ask: "Which skill should I verify for accuracy?"
 
 Read the entire skill (SKILL.md + workflows/ + references/):
 ```bash
-cat ~/.claude/skills/{skill-name}/SKILL.md
-cat ~/.claude/skills/{skill-name}/workflows/*.md 2>/dev/null
-cat ~/.claude/skills/{skill-name}/references/*.md 2>/dev/null
+cat ~/.config/opencode/skills/{skill-name}/SKILL.md
+cat ~/.config/opencode/skills/{skill-name}/workflows/*.md 2>/dev/null
+cat ~/.config/opencode/skills/{skill-name}/references/*.md 2>/dev/null
 ```
 
 Categorize by primary dependency type:

package/skills/document-review/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: document-review
+description: This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it.
+---
+
+# Document Review
+
+Improve brainstorm or plan documents through structured review.
+
+## Step 1: Get the Document
+
+**If a document path is provided:** Read it, then proceed to Step 2.
+
+**If no document is specified:** Ask which document to review, or look for the most recent brainstorm/plan in `docs/brainstorms/` or `docs/plans/`.
+
+## Step 2: Assess
+
+Read through the document and ask:
+
+- What is unclear?
+- What is unnecessary?
+- What decision is being avoided?
+- What assumptions are unstated?
+- Where could scope accidentally expand?
+
+These questions surface issues. Don't fix yet—just note what you find.
+
+## Step 3: Evaluate
+
+Score the document against these criteria:
+
+| Criterion | What to Check |
+|-----------|---------------|
+| **Clarity** | Problem statement is clear, no vague language ("probably," "consider," "try to") |
+| **Completeness** | Required sections present, constraints stated, open questions flagged |
+| **Specificity** | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
+| **YAGNI** | No hypothetical features, simplest approach chosen |
+
+If invoked within a workflow (after `/workflows:brainstorm` or `/workflows:plan`), also check:
+- **User intent fidelity** — Document reflects what was discussed, assumptions validated
+
+## Step 4: Identify the Critical Improvement
+
+Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.
+
+## Step 5: Make Changes
+
+Present your findings, then:
+
+1. **Auto-fix** minor issues (vague language, formatting) without asking
+2. **Ask approval** before substantive changes (restructuring, removing sections, changing meaning)
+3. **Update** the document inline—no separate files, no metadata sections
+
+### Simplification Guidance
+
+Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
+
+**Simplify when:**
+- Content serves hypothetical future needs, not current ones
+- Sections repeat information already covered elsewhere
+- Detail exceeds what's needed to take the next step
+- Abstractions or structure add overhead without clarity
+
+**Don't simplify:**
+- Constraints or edge cases that affect implementation
+- Rationale that explains why alternatives were rejected
+- Open questions that need resolution
+
+## Step 6: Offer Next Action
+
+After changes are complete, ask:
+
+1. **Refine again** - Another review pass
+2. **Review complete** - Document is ready
+
+### Iteration Guidance
+
+After 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.
+
+Return control to the caller (workflow or user) after selection.
+
+## What NOT to Do
+
+- Do not rewrite the entire document
+- Do not add new sections or requirements the user didn't discuss
+- Do not over-engineer or add complexity
+- Do not create separate review files or add metadata sections
+

package/skills/file-todos/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: file-todos
 description: This skill should be used when managing the file-based todo tracking system in the todos/ directory. It provides workflows for creating todos, managing status and dependencies, conducting triage, and integrating with slash commands and code review processes.
+disable-model-invocation: true
 ---
 
 # File-Based Todo Tracking Skill
@@ -149,7 +150,7 @@ done
 ```markdown
 ### YYYY-MM-DD - Session Title
 
-**By:** Claude Code / Developer Name
+**By:** OpenCode / Developer Name
 
 **Actions:**
 - Specific changes made (include file:line references)
@@ -244,7 +245,7 @@ grep -r "payment" todos/
 - Active Record CRUD operations
 - Different from this file-based system
 
-**TodoWrite tool:**
+**todowrite tool:**
 - In-memory task tracking during agent sessions
 - Temporary tracking for single conversation
 - Not persisted to disk

package/skills/file-todos/assets/todo-template.md

@@ -129,7 +129,7 @@ Chronological record of work sessions, actions taken, and learnings.
 
 ### 2025-11-12 - Initial Discovery
 
-**By:** Claude Code
+**By:** OpenCode
 
 **Actions:**
 - Identified 12 missing test scenarios

package/skills/frontend-design/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: frontend-design
+description: This skill should be used when creating distinctive, production-grade frontend interfaces with high design quality. It applies when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
+license: Complete terms in LICENSE.txt
+---
+
+This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
+
+The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
+
+## Design Thinking
+
+Before coding, understand the context and commit to a BOLD aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
+- **Constraints**: Technical requirements (framework, performance, accessibility).
+- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
+
+**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
+
+Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
+- Production-grade and functional
+- Visually striking and memorable
+- Cohesive with a clear aesthetic point-of-view
+- Meticulously refined in every detail
+
+## Frontend Aesthetics Guidelines
+
+Focus on:
+- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
+- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
+- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
+- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
+
+NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
+
+**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
+
+Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
+

package/skills/git-worktree/SKILL.md

@@ -28,7 +28,7 @@ The script handles critical setup that raw git commands don't:
 
 ```bash
 # ✅ CORRECT - Always use the script
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-name
+bash scripts/worktree-manager.sh create feature-name
 
 # ❌ WRONG - Never do this directly
 git worktree add .worktrees/feature-name -b feature-name main
@@ -45,7 +45,7 @@ Use this skill in these scenarios:
 
 ## How to Use
 
-### In Claude Code Workflows
+### In OpenCode Workflows
 
 The skill is automatically called from `/workflows:review` and `/workflows:work` commands:
 
@@ -60,19 +60,19 @@ You can also invoke the skill directly from bash:
 
 ```bash
 # Create a new worktree (copies .env files automatically)
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
+bash scripts/worktree-manager.sh create feature-login
 
 # List all worktrees
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
+bash scripts/worktree-manager.sh list
 
 # Switch to a worktree
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
+bash scripts/worktree-manager.sh switch feature-login
 
 # Copy .env files to an existing worktree (if they weren't copied)
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh copy-env feature-login
+bash scripts/worktree-manager.sh copy-env feature-login
 
 # Clean up completed worktrees
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
+bash scripts/worktree-manager.sh cleanup
 ```
 
 ## Commands
@@ -87,7 +87,7 @@ Creates a new worktree with the given branch name.
 
 **Example:**
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
+bash scripts/worktree-manager.sh create feature-login
 ```
 
 **What happens:**
@@ -103,7 +103,7 @@ Lists all available worktrees with their branches and current status.
 
 **Example:**
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
+bash scripts/worktree-manager.sh list
 ```
 
 **Output shows:**
@@ -118,7 +118,7 @@ Switches to an existing worktree and cd's into it.
 
 **Example:**
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
+bash scripts/worktree-manager.sh switch feature-login
 ```
 
 **Optional:**
@@ -130,7 +130,7 @@ Interactively cleans up inactive worktrees with confirmation.
 
 **Example:**
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
+bash scripts/worktree-manager.sh cleanup
 ```
 
 **What happens:**
@@ -144,39 +144,39 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh clean
 ### Code Review with Worktree
 
 ```bash
-# Claude Code recognizes you're not on the PR branch
+# OpenCode recognizes you're not on the PR branch
 # Offers: "Use worktree for isolated review? (y/n)"
 
 # You respond: yes
 # Script runs (copies .env files automatically):
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create pr-123-feature-name
+bash scripts/worktree-manager.sh create pr-123-feature-name
 
 # You're now in isolated worktree for review with all env vars
 cd .worktrees/pr-123-feature-name
 
 # After review, return to main:
 cd ../..
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
+bash scripts/worktree-manager.sh cleanup
 ```
 
 ### Parallel Feature Development
 
 ```bash
 # For first feature (copies .env files):
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
+bash scripts/worktree-manager.sh create feature-login
 
 # Later, start second feature (also copies .env files):
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-notifications
+bash scripts/worktree-manager.sh create feature-notifications
 
 # List what you have:
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
+bash scripts/worktree-manager.sh list
 
 # Switch between them as needed:
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
+bash scripts/worktree-manager.sh switch feature-login
 
 # Return to main and cleanup when done:
 cd .
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
+bash scripts/worktree-manager.sh cleanup
 ```
 
 ## Key Design Principles
@@ -242,7 +242,7 @@ Switch out of the worktree first (to main repo), then cleanup:
 
 ```bash
 cd $(git rev-parse --show-toplevel)
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
+bash scripts/worktree-manager.sh cleanup
 ```
 
 ### Lost in a worktree?
@@ -250,7 +250,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh clean
 See where you are:
 
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
+bash scripts/worktree-manager.sh list
 ```
 
 ### .env files missing in worktree?
@@ -258,7 +258,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
 If a worktree was created without .env files (e.g., via raw `git worktree add`), copy them:
 
 ```bash
-bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh copy-env feature-name
+bash scripts/worktree-manager.sh copy-env feature-name
 ```
 
 Navigate back to main:
@@ -300,3 +300,4 @@ cd $(git rev-parse --show-toplevel)
 - No repository duplication
 - Shared git objects for efficiency
 - Much faster than cloning or stashing/switching
+

package/skills/git-worktree/scripts/worktree-manager.sh

@@ -91,14 +91,6 @@ create_worktree() {
   echo -e "${BLUE}Creating worktree: $branch_name${NC}"
   echo "  From: $from_branch"
   echo "  Path: $worktree_path"
-  echo ""
-  echo "Proceed? (y/n)"
-  read -r response
-
-  if [[ "$response" != "y" ]]; then
-    echo -e "${YELLOW}Cancelled${NC}"
-    return
-  fi
 
   # Update main branch
   echo -e "${BLUE}Updating $from_branch...${NC}"
@@ -134,7 +126,7 @@ list_worktrees() {
 
   local count=0
   for worktree_path in "$WORKTREE_DIR"/*; do
-    if [[ -d "$worktree_path" && -d "$worktree_path/.git" ]]; then
+    if [[ -d "$worktree_path" && -e "$worktree_path/.git" ]]; then
       count=$((count + 1))
       local worktree_name=$(basename "$worktree_path")
       local branch=$(git -C "$worktree_path" rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unknown")
@@ -231,7 +223,7 @@ cleanup_worktrees() {
   local to_remove=()
 
   for worktree_path in "$WORKTREE_DIR"/*; do
-    if [[ -d "$worktree_path" && -d "$worktree_path/.git" ]]; then
+    if [[ -d "$worktree_path" && -e "$worktree_path/.git" ]]; then
       local worktree_name=$(basename "$worktree_path")
 
       # Skip if current worktree