shmakk 1.1.0 → 1.2.0

package/skills/docs-bear-notes.md

@@ -0,0 +1,108 @@
+---
+name: bear-notes
+description: Create, search, and manage Bear notes via grizzly CLI.
+homepage: https://bear.app
+metadata:
+  {
+    "openclaw":
+      {
+        "emoji": "🐻",
+        "os": ["darwin"],
+        "requires": { "bins": ["grizzly"] },
+        "install":
+          [
+            {
+              "id": "go",
+              "kind": "go",
+              "module": "github.com/tylerwince/grizzly/cmd/grizzly@latest",
+              "bins": ["grizzly"],
+              "label": "Install grizzly (go)",
+            },
+          ],
+      },
+  }
+category: docs
+---
+
+# Bear Notes
+
+Use `grizzly` to create, read, and manage notes in Bear on macOS.
+
+Requirements
+
+- Bear app installed and running
+- For some operations (add-text, tags, open-note --selected), a Bear app token (stored in `~/.config/grizzly/token`)
+
+## Getting a Bear Token
+
+For operations that require a token (add-text, tags, open-note --selected), you need an authentication token:
+
+1. Open Bear → Help → API Token → Copy Token
+2. Save it: `echo "YOUR_TOKEN" > ~/.config/grizzly/token`
+
+## Common Commands
+
+Create a note
+
+```bash
+echo "Note content here" | grizzly create --title "My Note" --tag work
+grizzly create --title "Quick Note" --tag inbox < /dev/null
+```
+
+Open/read a note by ID
+
+```bash
+grizzly open-note --id "NOTE_ID" --enable-callback --json
+```
+
+Append text to a note
+
+```bash
+echo "Additional content" | grizzly add-text --id "NOTE_ID" --mode append --token-file ~/.config/grizzly/token
+```
+
+List all tags
+
+```bash
+grizzly tags --enable-callback --json --token-file ~/.config/grizzly/token
+```
+
+Search notes (via open-tag)
+
+```bash
+grizzly open-tag --name "work" --enable-callback --json
+```
+
+## Options
+
+Common flags:
+
+- `--dry-run` — Preview the URL without executing
+- `--print-url` — Show the x-callback-url
+- `--enable-callback` — Wait for Bear's response (needed for reading data)
+- `--json` — Output as JSON (when using callbacks)
+- `--token-file PATH` — Path to Bear API token file
+
+## Configuration
+
+Grizzly reads config from (in priority order):
+
+1. CLI flags
+2. Environment variables (`GRIZZLY_TOKEN_FILE`, `GRIZZLY_CALLBACK_URL`, `GRIZZLY_TIMEOUT`)
+3. `.grizzly.toml` in current directory
+4. `~/.config/grizzly/config.toml`
+
+Example `~/.config/grizzly/config.toml`:
+
+```toml
+token_file = "~/.config/grizzly/token"
+callback_url = "http://127.0.0.1:42123/success"
+timeout = "5s"
+```
+
+## Notes
+
+- Bear must be running for commands to work
+- Note IDs are Bear's internal identifiers (visible in note info or via callbacks)
+- Use `--enable-callback` when you need to read data back from Bear
+- Some operations require a valid token (add-text, tags, open-note --selected)

package/skills/docs-create-llms.md

@@ -0,0 +1,211 @@
+---
+name: create-llms
+description: 'Create an llms.txt file from scratch based on repository structure following the llms.txt specification at https://llmstxt.org/'
+category: docs
+---
+
+# Create LLMs.txt File from Repository Structure
+
+Create a new `llms.txt` file from scratch in the root of the repository following the official llms.txt specification at https://llmstxt.org/. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications.
+
+## Primary Directive
+
+Create a comprehensive `llms.txt` file that serves as an entry point for LLMs to understand and navigate the repository effectively. The file must comply with the llms.txt specification and be optimized for LLM consumption while remaining human-readable.
+
+## Analysis and Planning Phase
+
+Before creating the `llms.txt` file, you must complete a thorough analysis:
+
+### Step 1: Review llms.txt Specification
+
+- Review the official specification at https://llmstxt.org/ to ensure full compliance
+- Understand the required format structure and guidelines
+- Note the specific markdown structure requirements
+
+### Step 2: Repository Structure Analysis
+
+- Examine the complete repository structure using appropriate tools
+- Identify the primary purpose and scope of the repository
+- Catalog all important directories and their purposes
+- List key files that would be valuable for LLM understanding
+
+### Step 3: Content Discovery
+
+- Identify README files and their locations
+- Find documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
+- Locate specification files and their purposes
+- Discover configuration files and their relevance
+- Find example files and code samples
+- Identify any existing documentation structure
+
+### Step 4: Create Implementation Plan
+
+Based on your analysis, create a structured plan that includes:
+
+- Repository purpose and scope summary
+- Priority-ordered list of essential files for LLM understanding
+- Secondary files that provide additional context
+- Organizational structure for the llms.txt file
+
+## Implementation Requirements
+
+### Format Compliance
+
+The `llms.txt` file must follow this exact structure per the specification:
+
+1. **H1 Header**: Single line with repository/project name (required)
+2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended)
+3. **Additional Details**: Zero or more markdown sections without headings for context
+4. **File List Sections**: Zero or more H2 sections containing markdown lists of links
+
+### Content Requirements
+
+#### Required Elements
+
+- **Project Name**: Clear, descriptive title as H1
+- **Summary**: Concise blockquote explaining the repository's purpose
+- **Key Files**: Essential files organized by category (H2 sections)
+
+#### File Link Format
+
+Each file link must follow: `[descriptive-name](relative-url): optional description`
+
+#### Section Organization
+
+Organize files into logical H2 sections such as:
+
+- **Documentation**: Core documentation files
+- **Specifications**: Technical specifications and requirements
+- **Examples**: Sample code and usage examples
+- **Configuration**: Setup and configuration files
+- **Optional**: Secondary files (special meaning - can be skipped for shorter context)
+
+### Content Guidelines
+
+#### Language and Style
+
+- Use concise, clear, unambiguous language
+- Avoid jargon without explanation
+- Write for both human and LLM readers
+- Be specific and informative in descriptions
+
+#### File Selection Criteria
+
+Include files that:
+- Explain the repository's purpose and scope
+- Provide essential technical documentation
+- Show usage examples and patterns
+- Define interfaces and specifications
+- Contain configuration and setup instructions
+
+Exclude files that:
+- Are purely implementation details
+- Contain redundant information
+- Are build artifacts or generated content
+- Are not relevant to understanding the project
+
+## Execution Steps
+
+### Step 1: Repository Analysis
+
+1. Examine the repository structure completely
+2. Read the main README.md to understand the project
+3. Identify all documentation directories and files
+4. Catalog specification files and their purposes
+5. Find example files and configuration files
+
+### Step 2: Content Planning
+
+1. Determine the primary purpose statement
+2. Write a concise summary for the blockquote
+3. Group identified files into logical categories
+4. Prioritize files by importance for LLM understanding
+5. Create descriptions for each file link
+
+### Step 3: File Creation
+
+1. Create the `llms.txt` file in the repository root
+2. Follow the exact format specification
+3. Include all required sections
+4. Use proper markdown formatting
+5. Ensure all links are valid relative paths
+
+### Step 4: Validation
+1. Verify compliance with https://llmstxt.org/ specification
+2. Check that all links are valid and accessible
+3. Ensure the file serves as an effective LLM navigation tool
+4. Confirm the file is both human and machine readable
+
+## Quality Assurance
+
+### Format Validation
+
+- ✅ H1 header with project name
+- ✅ Blockquote summary (if included)
+- ✅ H2 sections for file lists
+- ✅ Proper markdown link format
+- ✅ No broken or invalid links
+- ✅ Consistent formatting throughout
+
+### Content Validation
+
+- ✅ Clear, unambiguous language
+- ✅ Comprehensive coverage of essential files
+- ✅ Logical organization of content
+- ✅ Appropriate file descriptions
+- ✅ Serves as effective LLM navigation tool
+
+### Specification Compliance
+
+- ✅ Follows https://llmstxt.org/ format exactly
+- ✅ Uses required markdown structure
+- ✅ Implements optional sections appropriately
+- ✅ File located at repository root (`/llms.txt`)
+
+## Example Structure Template
+
+```txt
+# [Repository Name]
+
+> [Concise description of the repository's purpose and scope]
+
+[Optional additional context paragraphs without headings]
+
+## Documentation
+
+- [Main README](README.md): Primary project documentation and getting started guide
+- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
+- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
+
+## Specifications
+
+- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
+- [API Specification](spec/api-spec.md): Interface definitions and data contracts
+
+## Examples
+
+- [Basic Example](examples/basic-usage.md): Simple usage demonstration
+- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
+
+## Configuration
+
+- [Setup Guide](docs/setup.md): Installation and configuration instructions
+- [Deployment Guide](docs/deployment.md): Production deployment guidelines
+
+## Optional
+
+- [Architecture Documentation](docs/architecture.md): Detailed system architecture
+- [Design Decisions](docs/decisions.md): Historical design decision records
+```
+
+## Success Criteria
+
+The created `llms.txt` file should:
+1. Enable LLMs to quickly understand the repository's purpose
+2. Provide clear navigation to essential documentation
+3. Follow the official llms.txt specification exactly
+4. Be comprehensive yet concise
+5. Serve both human and machine readers effectively
+6. Include all critical files for project understanding
+7. Use clear, unambiguous language throughout
+8. Organize content logically for easy consumption

package/skills/docs-doc-gen.md

@@ -0,0 +1,20 @@
+---
+name: doc-gen
+description: Generate and maintain documentation with drift detection
+argument-hint: "[--target PATH]"
+allowed-tools: Bash(npx *) mcp__claude-flow__hooks_worker-dispatch mcp__claude-flow__memory_store CronCreate Read Write
+category: docs
+---
+Generate docs via MCP worker dispatch:
+`mcp__claude-flow__hooks_worker-dispatch({ trigger: "document" })`
+
+For continuous doc maintenance via CronCreate:
+`CronCreate({ schedule: "0 */2 * * *", prompt: "Run document worker" })`
+
+Detect drift by comparing current code against existing docs and flagging inconsistencies.
+
+Scoped generation:
+- API docs: `npx @claude-flow/cli@latest hooks worker dispatch --trigger document --scope api`
+- Full project: `npx @claude-flow/cli@latest hooks worker dispatch --trigger document --scope full`
+
+Store the approach: `mcp__claude-flow__memory_store({ key: "doc-pattern", value: "APPROACH", namespace: "patterns" })`

package/skills/docs-documentation-writer.md

@@ -0,0 +1,46 @@
+---
+name: documentation-writer
+description: 'Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.'
+category: docs
+---
+
+# Diátaxis Documentation Expert
+
+You are an expert technical writer specializing in creating high-quality software documentation.
+Your work is strictly guided by the principles and structure of the Diátaxis Framework (https://diataxis.fr/).
+
+## GUIDING PRINCIPLES
+
+1. **Clarity:** Write in simple, clear, and unambiguous language.
+2. **Accuracy:** Ensure all information, especially code snippets and technical details, is correct and up-to-date.
+3. **User-Centricity:** Always prioritize the user's goal. Every document must help a specific user achieve a specific task.
+4. **Consistency:** Maintain a consistent tone, terminology, and style across all documentation.
+
+## YOUR TASK: The Four Document Types
+
+You will create documentation across the four Diátaxis quadrants. You must understand the distinct purpose of each:
+
+- **Tutorials:** Learning-oriented, practical steps to guide a newcomer to a successful outcome. A lesson.
+- **How-to Guides:** Problem-oriented, steps to solve a specific problem. A recipe.
+- **Reference:** Information-oriented, technical descriptions of machinery. A dictionary.
+- **Explanation:** Understanding-oriented, clarifying a particular topic. A discussion.
+
+## WORKFLOW
+
+You will follow this process for every documentation request:
+
+1. **Acknowledge & Clarify:** Acknowledge my request and ask clarifying questions to fill any gaps in the information I provide. You MUST determine the following before proceeding:
+    - **Document Type:** (Tutorial, How-to, Reference, or Explanation)
+    - **Target Audience:** (e.g., novice developers, experienced sysadmins, non-technical users)
+    - **User's Goal:** What does the user want to achieve by reading this document?
+    - **Scope:** What specific topics should be included and, importantly, excluded?
+
+2. **Propose a Structure:** Based on the clarified information, propose a detailed outline (e.g., a table of contents with brief descriptions) for the document. Await my approval before writing the full content.
+
+3. **Generate Content:** Once I approve the outline, write the full documentation in well-formatted Markdown. Adhere to all guiding principles.
+
+## CONTEXTUAL AWARENESS
+
+- When I provide other markdown files, use them as context to understand the project's existing tone, style, and terminology.
+- DO NOT copy content from them unless I explicitly ask you to.
+- You may not consult external websites or other sources unless I provide a link and instruct you to do so.

package/skills/docs-llm-config.md

@@ -0,0 +1,33 @@
+---
+name: llm-config
+description: Configure RuVLLM local inference with model selection, MicroLoRA fine-tuning, and SONA adaptation
+argument-hint: "[--model MODEL] [--adapter microlora|sona]"
+allowed-tools: mcp__claude-flow__ruvllm_generate_config mcp__claude-flow__ruvllm_status mcp__claude-flow__ruvllm_microlora_create mcp__claude-flow__ruvllm_microlora_adapt mcp__claude-flow__ruvllm_sona_create mcp__claude-flow__ruvllm_sona_adapt Bash
+category: docs
+---
+
+# LLM Configuration
+
+Configure RuVLLM for local inference and fine-tuning.
+
+## When to use
+
+When you need to configure local LLM inference, create MicroLoRA adapters for task-specific fine-tuning, or set up SONA for real-time adaptation.
+
+## Steps
+
+1. **Check status** — call `mcp__claude-flow__ruvllm_status` to see current model and adapter state
+2. **Generate config** — call `mcp__claude-flow__ruvllm_generate_config` with model parameters
+3. **Create MicroLoRA** — call `mcp__claude-flow__ruvllm_microlora_create` for task-specific adapters
+4. **Adapt MicroLoRA** — call `mcp__claude-flow__ruvllm_microlora_adapt` with training data
+5. **Create SONA** — call `mcp__claude-flow__ruvllm_sona_create` for real-time neural adaptation
+6. **Adapt SONA** — call `mcp__claude-flow__ruvllm_sona_adapt` with feedback signals
+
+## MicroLoRA vs SONA
+
+| Feature | MicroLoRA | SONA |
+|---------|-----------|------|
+| Speed | Minutes to train | <0.05ms adaptation |
+| Scope | Task-specific fine-tuning | Real-time micro-adjustments |
+| Persistence | Saved as adapter weights | Session-scoped |
+| Use case | Specialized domain tasks | Continuous feedback loops |

package/skills/docs-mkdocs-translations.md

@@ -0,0 +1,109 @@
+---
+name: mkdocs-translations
+description: 'Generate a language translation for a mkdocs documentation stack.'
+category: docs
+---
+
+# MkDocs AI Translator
+
+## Role
+You are a professional technical writer and translator.
+
+## Required Input  
+**Before proceeding, ask the user to specify the target translation language and locale code.**  
+Examples:
+- Spanish (`es`)
+- French (`fr`)
+- Brazilian Portuguese (`pt-BR`)
+- Korean (`ko`)
+
+Use this value consistently in folder names, translated content paths, and MkDocs configuration updates. Once confirmed, proceed with the instructions below.
+
+---
+
+## Objective  
+Translate all documentation from the `docs/docs/en` and `docs/docs/includes/en` folders into the specified target language. Preserve the original folder structure and all Markdown formatting.
+
+---
+
+## File Listing and Translation Order
+
+The following is the task list you must complete. Check each item off as it is done and report that to the user.
+
+- [ ] Begin by listing all files and subdirectories under `docs/docs/en`.
+- [ ] Then list all files and subdirectories under `docs/docs/includes/en`.
+- [ ] Translate **every file** in the list **one by one** in the order shown. Do not skip, reorder, or stop after a fixed number of files.
+- [ ] After each translation, **check whether there are remaining files** that have not yet been translated. If there are, **continue automatically** with the next file.
+- [ ] Do **not** prompt for confirmation, approval, or next steps—**proceed automatically** until all files are translated.
+- [ ] Once completed, confirm that the number of translated files matches the number of source files listed. If any files remain unprocessed, resume from where you left off.
+
+---
+
+## Folder Structure and Output
+
+Before starting to create **any** new files, create a new git branch using the terminal command `git checkout -b docs-translation-<language>`.
+
+- Create a new folder under `docs/docs/` named using the ISO 639-1 or locale code provided by the user.  
+  Examples:  
+  - `es` for Spanish  
+  - `fr` for French  
+  - `pt-BR` for Brazilian Portuguese
+- Mirror the exact folder and file structure from the original `en` directories.
+- For each translated file:
+  - Preserve all Markdown formatting, including headings, code blocks, metadata, and links.
+  - Maintain the original filename.
+  - Do **not** wrap the translated content in Markdown code blocks.
+  - Append this line at the end of the file:  
+    *Translated using GitHub Copilot and GPT-4o.*
+  - Save the translated file into the corresponding target language folder.
+
+---
+
+## Include Path Updates
+
+- Update include references in files to reflect the new locale.  
+  Example:  
+    `includes/en/introduction-event.md` → `includes/es/introduction-event.md`  
+  Replace `es` with the actual locale code provided by the user.
+
+---
+
+## MkDocs Configuration Update
+
+- [ ] Modify the `mkdocs.yml` configuration:
+  - [ ] Add a new `locale` entry under the `i18n` plugin using the target language code.
+  - [ ] Provide appropriate translations for:
+    - [ ] `nav_translations`
+    - [ ] `admonition_translations`
+
+---
+
+## Translation Rules
+
+- Use accurate, clear, and technically appropriate translations.
+- Always use computer industry-standard terminology.  
+  Example: prefer "Stack Tecnológica" over "Pila Tecnológica".
+
+**Do not:**
+- Comment on, suggest changes for, or attempt to fix any formatting or Markdown linting issues.  
+  This includes, but is not limited to:
+  - Missing blank lines around headings or lists
+  - Trailing punctuation in headings
+  - Missing alt text for images
+  - Improper heading levels
+  - Line length or spacing issues
+- Do not say things like:  
+  _"There are some linting issues, such as…"_
+  _"Would you like me to fix…"_
+- Never prompt the user about any linting or formatting issues.
+- Do not wait for confirmation before continuing.
+- Do not wrap the translated content or file in Markdown code blocks.
+
+---
+
+## Translating Includes (`docs/docs/includes/en`)
+
+- Create a new folder under `docs/docs/includes/` using the target language code provided by the user.
+- Translate each file using the same rules as above.
+- Maintain the same file and folder structure in the translated output.
+- Save each translated file in the appropriate target language folder.

package/skills/docs-obsidian-vault-maintainer.md

@@ -0,0 +1,14 @@
+---
+name: obsidian-vault-maintainer
+description: Maintain an Obsidian-friendly memory wiki vault with wikilinks, frontmatter, and official Obsidian CLI awareness.
+category: docs
+---
+
+Use this skill when the memory-wiki vault render mode is `obsidian` or the user wants the wiki to play nicely with Obsidian.
+
+- Start from `openclaw wiki status` to confirm the vault mode and whether the official Obsidian CLI is available.
+- Use `openclaw wiki obsidian status` before shelling out, then prefer the dedicated helpers like `openclaw wiki obsidian search`, `openclaw wiki obsidian open`, `openclaw wiki obsidian command`, and `openclaw wiki obsidian daily`.
+- Prefer `[[Wikilinks]]`, stable filenames, and frontmatter that works with Obsidian dashboards and Dataview-style queries.
+- Keep generated sections deterministic so Obsidian users can safely add handwritten notes around them.
+- If the official Obsidian CLI is enabled, probe it before depending on it. Do not assume the app is installed, running, or configured.
+- Avoid destructive renames unless you also have a link-repair plan.

package/skills/docs-obsidian.md

@@ -0,0 +1,82 @@
+---
+name: obsidian
+description: Work with Obsidian vaults (plain Markdown notes) and automate via obsidian-cli.
+homepage: https://help.obsidian.md
+metadata:
+  {
+    "openclaw":
+      {
+        "emoji": "💎",
+        "requires": { "bins": ["obsidian-cli"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "yakitrak/yakitrak/obsidian-cli",
+              "bins": ["obsidian-cli"],
+              "label": "Install obsidian-cli (brew)",
+            },
+          ],
+      },
+  }
+category: docs
+---
+
+# Obsidian
+
+Obsidian vault = a normal folder on disk.
+
+Vault structure (typical)
+
+- Notes: `*.md` (plain text Markdown; edit with any editor)
+- Config: `.obsidian/` (workspace + plugin settings; usually don’t touch from scripts)
+- Canvases: `*.canvas` (JSON)
+- Attachments: whatever folder you chose in Obsidian settings (images/PDFs/etc.)
+
+## Find the active vault(s)
+
+Obsidian desktop tracks vaults here (source of truth):
+
+- `~/Library/Application Support/obsidian/obsidian.json`
+
+`obsidian-cli` resolves vaults from that file; vault name is typically the **folder name** (path suffix).
+
+Fast “what vault is active / where are the notes?”
+
+- If you’ve already set a default: `obsidian-cli print-default --path-only`
+- Otherwise, read `~/Library/Application Support/obsidian/obsidian.json` and use the vault entry with `"open": true`.
+
+Notes
+
+- Multiple vaults common (iCloud vs `~/Documents`, work/personal, etc.). Don’t guess; read config.
+- Avoid writing hardcoded vault paths into scripts; prefer reading the config or using `print-default`.
+
+## obsidian-cli quick start
+
+Pick a default vault (once):
+
+- `obsidian-cli set-default "<vault-folder-name>"`
+- `obsidian-cli print-default` / `obsidian-cli print-default --path-only`
+
+Search
+
+- `obsidian-cli search "query"` (note names)
+- `obsidian-cli search-content "query"` (inside notes; shows snippets + lines)
+
+Create
+
+- `obsidian-cli create "Folder/New note" --content "..." --open`
+- Requires Obsidian URI handler (`obsidian://…`) working (Obsidian installed).
+- Avoid creating notes under “hidden” dot-folders (e.g. `.something/...`) via URI; Obsidian may refuse.
+
+Move/rename (safe refactor)
+
+- `obsidian-cli move "old/path/note" "new/path/note"`
+- Updates `[[wikilinks]]` and common Markdown links across the vault (this is the main win vs `mv`).
+
+Delete
+
+- `obsidian-cli delete "path/note"`
+
+Prefer direct edits when appropriate: open the `.md` file and change it; Obsidian will pick it up.