@heytherevibin/skillforge 0.2.1

package/skills/article-writing/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: article-writing
+description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
+---
+
+# Article Writing
+
+Write long-form content that sounds like an actual person with a point of view, not an LLM smoothing itself into paste.
+
+## When to Activate
+
+- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
+- turning notes, transcripts, or research into polished articles
+- matching an existing founder, operator, or brand voice from examples
+- tightening structure, pacing, and evidence in already-written long-form copy
+
+## Core Rules
+
+1. Lead with the concrete thing: artifact, example, output, anecdote, number, screenshot, or code.
+2. Explain after the example, not before.
+3. Keep sentences tight unless the source voice is intentionally expansive.
+4. Use proof instead of adjectives.
+5. Never invent facts, credibility, or customer evidence.
+
+## Voice Handling
+
+If the user wants a specific voice, run `brand-voice` first and reuse its `VOICE PROFILE`.
+Do not duplicate a second style-analysis pass here unless the user explicitly asks for one.
+
+If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful.
+
+## Banned Patterns
+
+Delete and rewrite any of these:
+- "In today's rapidly evolving landscape"
+- "game-changer", "cutting-edge", "revolutionary"
+- "here's why this matters" as a standalone bridge
+- fake vulnerability arcs
+- a closing question added only to juice engagement
+- biography padding that does not move the argument
+- generic AI throat-clearing that delays the point
+
+## Writing Process
+
+1. Clarify the audience and purpose.
+2. Build a hard outline with one job per section.
+3. Start sections with proof, artifact, conflict, or example.
+4. Expand only where the next sentence earns space.
+5. Cut anything that sounds templated, overexplained, or self-congratulatory.
+
+## Structure Guidance
+
+### Technical Guides
+
+- open with what the reader gets
+- use code, commands, screenshots, or concrete output in major sections
+- end with actionable takeaways, not a soft recap
+
+### Essays / Opinion
+
+- start with tension, contradiction, or a specific observation
+- keep one argument thread per section
+- make opinions answer to evidence
+
+### Newsletters
+
+- keep the first screen doing real work
+- do not front-load diary filler
+- use section labels only when they improve scanability
+
+## Quality Gate
+
+Before delivering:
+- factual claims are backed by provided sources
+- generic AI transitions are gone
+- the voice matches the supplied examples or the agreed `VOICE PROFILE`
+- every section adds something new
+- formatting matches the intended medium

package/skills/automation-audit-ops/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: automation-audit-ops
+description: Evidence-first automation inventory and overlap audit workflow for the toolset. Use when the user wants to know which jobs, hooks, connectors, MCP servers, or wrappers are live, broken, redundant, or missing before fixing anything.
+origin: the toolset
+---
+
+# Automation Audit Ops
+
+Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors are actually doing useful work right now.
+
+This is an audit-first operator skill. The job is to produce an evidence-backed inventory and a keep / merge / cut / fix-next recommendation set before rewriting anything.
+
+## Skill Stack
+
+Pull these the toolset-native skills into the workflow when relevant:
+
+- `workspace-surface-audit` for connector, MCP, hook, and app inventory
+- `knowledge-ops` when the audit needs to reconcile live repo truth with durable context
+- `github-ops` when the answer depends on CI, scheduled workflows, issues, or PR automation
+- `research-ops` when local inventory must be compared against current platform support or public docs
+- `verification-loop` for proving post-fix state instead of relying on assumed recovery
+
+## When to Use
+
+- user asks "what automations do I have", "what is live", "what is broken", or "what overlaps"
+- the task spans cron jobs, GitHub Actions, local hooks, MCP servers, connectors, wrappers, or app integrations
+- the user wants to know what was ported from another agent system and what still needs to be rebuilt inside the toolset
+- the workspace has accumulated multiple ways to do the same thing and the user wants one canonical lane
+
+## Guardrails
+
+- start read-only unless the user explicitly asked for fixes
+- separate:
+  - configured
+  - authenticated
+  - recently verified
+  - stale or broken
+  - missing entirely
+- do not claim a tool is live just because a skill or config references it
+- do not merge or delete overlapping surfaces until the evidence table exists
+
+## Workflow
+
+### 1. Inventory the real surface
+
+Read the current live surface before theorizing:
+
+- repo hooks and local hook scripts
+- GitHub Actions and scheduled workflows
+- MCP configs and enabled servers
+- connector- or app-backed integrations
+- wrapper scripts and repo-specific automation entrypoints
+
+Group them by surface:
+
+- local runtime
+- repo CI / automation
+- connected external systems
+- messaging / notifications
+- billing / customer operations
+- research / monitoring
+
+### 2. Classify each item by live state
+
+For every surfaced automation, mark:
+
+- configured
+- authenticated
+- recently verified
+- stale or broken
+- missing
+
+Then classify the problem type:
+
+- active breakage
+- auth outage
+- stale status
+- overlap or redundancy
+- missing capability
+
+### 3. Trace the proof path
+
+Back every important claim with a concrete source:
+
+- file path
+- workflow run
+- hook log
+- config entry
+- recent command output
+- exact failure signature
+
+If the current state is ambiguous, say so directly instead of pretending the audit is complete.
+
+### 4. End with keep / merge / cut / fix-next
+
+For each overlapping or suspect surface, return one call:
+
+- keep
+- merge
+- cut
+- fix next
+
+The value is in collapsing noisy automation into one canonical the toolset lane, not in preserving every historical path.
+
+## Output Format
+
+```text
+CURRENT SURFACE
+- automation
+- source
+- live state
+- proof
+
+FINDINGS
+- active breakage
+- overlap
+- stale status
+- missing capability
+
+RECOMMENDATION
+- keep
+- merge
+- cut
+- fix next
+
+NEXT the toolset MOVE
+- exact skill / hook / workflow / app lane to strengthen
+```
+
+## Pitfalls
+
+- do not answer from memory when the live inventory can be read
+- do not treat "present in config" as "working"
+- do not fix lower-value redundancy before naming the broken high-signal path
+- do not widen the task into a repo rewrite if the user asked for inventory first
+
+## Verification
+
+- important claims cite a live proof path
+- each surfaced automation is labeled with a clear live-state category
+- the final recommendation distinguishes keep / merge / cut / fix-next

package/skills/autonomous-agent-harness/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: autonomous-agent-harness
+description: Transform Claude Code into a fully autonomous agent system with persistent memory, scheduled operations, computer use, and task queuing. Replaces standalone agent frameworks (Hermes, AutoGPT) by leveraging Claude Code's native crons, dispatch, MCP tools, and memory. Use when the user wants continuous autonomous operation, scheduled tasks, or a self-directing agent loop.
+origin: the toolset
+---
+
+# Autonomous Agent Harness
+
+Turn Claude Code into a persistent, self-directing agent system using only native features and MCP servers.
+
+## Consent and Safety Boundaries
+
+Autonomous operation must be explicitly requested and scoped by the user. Do not create schedules, dispatch remote agents, write persistent memory, use computer control, post externally, modify third-party resources, or act on private communications unless the user has approved that capability and the target workspace for the current setup.
+
+Prefer dry-run plans and local queue files before enabling recurring or event-driven actions. Keep credentials, private workspace exports, personal datasets, and account-specific automations out of reusable the toolset artifacts.
+
+## When to Activate
+
+- User wants an agent that runs continuously or on a schedule
+- Setting up automated workflows that trigger periodically
+- Building a personal AI assistant that remembers context across sessions
+- User says "run this every day", "check on this regularly", "keep monitoring"
+- Wants to replicate functionality from Hermes, AutoGPT, or similar autonomous agent frameworks
+- Needs computer use combined with scheduled execution
+
+## Architecture
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│                    Claude Code Runtime                        │
+│                                                              │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────────┐ │
+│  │  Crons   │  │ Dispatch │  │ Memory   │  │ Computer    │ │
+│  │ Schedule │  │ Remote   │  │ Store    │  │ Use         │ │
+│  │ Tasks    │  │ Agents   │  │          │  │             │ │
+│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └──────┬──────┘ │
+│       │              │             │                │        │
+│       ▼              ▼             ▼                ▼        │
+│  ┌──────────────────────────────────────────────────────┐    │
+│  │              the toolset Skill + Agent Layer                  │    │
+│  │                                                      │    │
+│  │  skills/     agents/     commands/     hooks/        │    │
+│  └──────────────────────────────────────────────────────┘    │
+│       │              │             │                │        │
+│       ▼              ▼             ▼                ▼        │
+│  ┌──────────────────────────────────────────────────────┐    │
+│  │              MCP Server Layer                        │    │
+│  │                                                      │    │
+│  │  memory    github    exa    supabase    browser-use  │    │
+│  └──────────────────────────────────────────────────────┘    │
+└──────────────────────────────────────────────────────────────┘
+```
+
+## Core Components
+
+### 1. Persistent Memory
+
+Use Claude Code's built-in memory system enhanced with MCP memory server for structured data.
+
+**Built-in memory** (`~/.claude/projects/*/memory/`):
+- User preferences, feedback, project context
+- Stored as markdown files with frontmatter
+- Automatically loaded at session start
+
+**MCP memory server** (structured knowledge graph):
+- Entities, relations, observations
+- Queryable graph structure
+- Cross-session persistence
+
+**Memory patterns:**
+
+```
+# Short-term: current session context
+Use TodoWrite for in-session task tracking
+
+# Medium-term: project memory files
+Write to ~/.claude/projects/*/memory/ for cross-session recall
+
+# Long-term: MCP knowledge graph
+Use mcp__memory__create_entities for permanent structured data
+Use mcp__memory__create_relations for relationship mapping
+Use mcp__memory__add_observations for new facts about known entities
+```
+
+### 2. Scheduled Operations (Crons)
+
+Use Claude Code's scheduled tasks to create recurring agent operations.
+
+**Setting up a cron:**
+
+```
+# Via MCP tool
+mcp__scheduled-tasks__create_scheduled_task({
+  name: "daily-pr-review",
+  schedule: "0 9 * * 1-5",  # 9 AM weekdays
+  project_dir: "/path/to/repo"
+})
+
+# Via claude -p (programmatic mode)
+echo "Review open PRs and summarize" | claude -p --project /path/to/repo
+```
+
+**Useful cron patterns:**
+
+| Pattern | Schedule | Use Case |
+|---------|----------|----------|
+| Daily standup | `0 9 * * 1-5` | Review PRs, issues, deploy status |
+| Weekly review | `0 10 * * 1` | Code quality metrics, test coverage |
+| Hourly monitor | `0 * * * *` | Production health, error rate checks |
+| Nightly build | `0 2 * * *` | Run full test suite, security scan |
+| Pre-meeting | `*/30 * * * *` | Prepare context for upcoming meetings |
+
+### 3. Dispatch / Remote Agents
+
+Trigger Claude Code agents remotely for event-driven workflows.
+
+**Dispatch patterns:**
+
+```bash
+# Trigger from CI/CD
+curl -X POST "https://api.anthropic.com/dispatch" \
+  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
+  -d '{"prompt": "Build failed on main. Diagnose and fix.", "project": "/repo"}'
+
+# Trigger from webhook
+# GitHub webhook → dispatch → Claude agent → fix → PR
+
+# Trigger from another agent
+claude -p "Analyze the output of the security scan and create issues for findings"
+```
+
+### 4. Computer Use
+
+Leverage Claude's computer-use MCP for physical world interaction.
+
+**Capabilities:**
+- Browser automation (navigate, click, fill forms, screenshot)
+- Desktop control (open apps, type, mouse control)
+- File system operations beyond CLI
+
+**Use cases within the harness:**
+- Automated testing of web UIs
+- Form filling and data entry
+- Screenshot-based monitoring
+- Multi-app workflows
+
+### 5. Task Queue
+
+Manage a persistent queue of tasks that survive session boundaries.
+
+**Implementation:**
+
+```
+# Task persistence via memory
+Write task queue to ~/.claude/projects/*/memory/task-queue.md
+
+# Task format
+---
+name: task-queue
+type: project
+description: Persistent task queue for autonomous operation
+---
+
+## Active Tasks
+- [ ] PR #123: Review and approve if CI green
+- [ ] Monitor deploy: check /health every 30 min for 2 hours
+- [ ] Research: Find 5 leads in AI tooling space
+
+## Completed
+- [x] Daily standup: reviewed 3 PRs, 2 issues
+```
+
+## Replacing Hermes
+
+| Hermes Component | the toolset Equivalent | How |
+|------------------|---------------|-----|
+| Gateway/Router | Claude Code dispatch + crons | Scheduled tasks trigger agent sessions |
+| Memory System | Claude memory + MCP memory server | Built-in persistence + knowledge graph |
+| Tool Registry | MCP servers | Dynamically loaded tool providers |
+| Orchestration | the toolset skills + agents | Skill definitions direct agent behavior |
+| Computer Use | computer-use MCP | Native browser and desktop control |
+| Context Manager | Session management + memory | the toolset 2.0 session lifecycle |
+| Task Queue | Memory-persisted task list | TodoWrite + memory files |
+
+## Setup Guide
+
+### Step 1: Configure MCP Servers
+
+Ensure these are in `~/.claude.json`:
+
+```json
+{
+  "mcpServers": {
+    "memory": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/memory-mcp-server"]
+    },
+    "scheduled-tasks": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/scheduled-tasks-mcp-server"]
+    },
+    "computer-use": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/computer-use-mcp-server"]
+    }
+  }
+}
+```
+
+### Step 2: Create Base Crons
+
+```bash
+# Daily morning briefing
+claude -p "Create a scheduled task: every weekday at 9am, review my GitHub notifications, open PRs, and calendar. Write a morning briefing to memory."
+
+# Continuous learning
+claude -p "Create a scheduled task: every Sunday at 8pm, extract patterns from this week's sessions and update the learned skills."
+```
+
+### Step 3: Initialize Memory Graph
+
+```bash
+# Bootstrap your identity and context
+claude -p "Create memory entities for: me (user profile), my projects, my key contacts. Add observations about current priorities."
+```
+
+### Step 4: Enable Computer Use (Optional)
+
+Grant computer-use MCP the necessary permissions for browser and desktop control.
+
+## Example Workflows
+
+### Autonomous PR Reviewer
+```
+Cron: every 30 min during work hours
+1. Check for new PRs on watched repos
+2. For each new PR:
+   - Pull branch locally
+   - Run tests
+   - Review changes with code-reviewer agent
+   - Post review comments via GitHub MCP
+3. Update memory with review status
+```
+
+### Personal Research Agent
+```
+Cron: daily at 6 AM
+1. Check saved search queries in memory
+2. Run Exa searches for each query
+3. Summarize new findings
+4. Compare against yesterday's results
+5. Write digest to memory
+6. Flag high-priority items for morning review
+```
+
+### Meeting Prep Agent
+```
+Trigger: 30 min before each calendar event
+1. Read calendar event details
+2. Search memory for context on attendees
+3. Pull recent email/Slack threads with attendees
+4. Prepare talking points and agenda suggestions
+5. Write prep doc to memory
+```
+
+## Constraints
+
+- Cron tasks run in isolated sessions — they don't share context with interactive sessions unless through memory.
+- Computer use requires explicit permission grants. Don't assume access.
+- Remote dispatch may have rate limits. Design crons with appropriate intervals.
+- Memory files should be kept concise. Archive old data rather than letting files grow unbounded.
+- Always verify that scheduled tasks completed successfully. Add error handling to cron prompts.