feat: add skills and workspace files
- Add complete skill set including feishu, github, ci-gen, etc. - Add workspace documentation (AGENTS.md, SOUL.md, etc.) - Add memory system and project context
This commit is contained in:
OpenClaw Agent
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"version": 1,
|
||||
"registry": "https://clawhub.ai",
|
||||
"slug": "clawlist",
|
||||
"installedVersion": "0.0.1",
|
||||
"installedAt": 1770309239752
|
||||
}
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: clawlist
|
||||
description: "MUST use for any multi-step project, long-running task, or infinite monitoring workflow. Plan, execute, track, and verify tasks with checkpoint validation. For projects, automation, and ongoing operations."
|
||||
---
|
||||
|
||||
# Clawlist - Task Mastery
|
||||
|
||||
A systematic workflow for planning, executing, and tracking any task — from one-off projects to infinite monitoring loops.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
**ALWAYS use clawlist when:**
|
||||
- Starting any new project or initiative
|
||||
- Setting up long-running monitoring
|
||||
- Breaking down complex goals
|
||||
- You need to track progress across sessions
|
||||
- Managing infinite tasks (research, monitoring, engagement)
|
||||
|
||||
## Long-Running & Infinite Task Examples
|
||||
|
||||
### Example: Moltbook Engagement (Infinite)
|
||||
- **Type:** Infinite loop
|
||||
- **Schedule:** Every 30 minutes
|
||||
- **Goal:** Engage with community, build presence
|
||||
- **Checkpoints:** Check feed, check DMs, create content
|
||||
|
||||
### Example: GitHub Monitoring (Long-Running)
|
||||
- **Type:** Continuous
|
||||
- **Schedule:** Every 4 hours
|
||||
- **Goal:** Monitor repos, triage issues, implement
|
||||
- **Checkpoints:** Inbox zero, PR review, implementation
|
||||
|
||||
## The Clawlist Workflow
|
||||
|
||||
Uses standalone skills in sequence:
|
||||
|
||||
1. **brainstorming** → Clarify intent, explore approaches
|
||||
2. **write-plan** → Create detailed plan with checkpoints
|
||||
3. **doing-tasks** → Execute with skill discipline
|
||||
4. **verify-task** → Confirm completion
|
||||
|
||||
For parallel work, insert **dispatch-multiple-agents** between write-plan and doing-tasks.
|
||||
|
||||
## Ongoing Tasks File
|
||||
|
||||
**Location:** `memory/tasks/ongoing-tasks.md`
|
||||
|
||||
Tracks all long-running and infinite tasks. Updated by heartbeat to:
|
||||
- Check task health
|
||||
- Detect blockers
|
||||
- Execute due tasks
|
||||
- Summarize status
|
||||
|
||||
## Task Types
|
||||
|
||||
| Type | Duration | Tracking | Example |
|
||||
|------|----------|----------|---------|
|
||||
| **One-off** | Minutes-hours | Context only | Fix a bug |
|
||||
| **Project** | Days-weeks | Context + completion doc | Build feature |
|
||||
| **Long-running** | Ongoing | `ongoing-tasks.md` | GitHub monitoring |
|
||||
| **Infinite** | Forever | `ongoing-tasks.md` | Moltbook engagement |
|
||||
|
||||
## Integration with Heartbeat
|
||||
|
||||
Heartbeat reads `ongoing-tasks.md` every check to:
|
||||
- Execute due infinite tasks
|
||||
- Detect and report blockers
|
||||
- Update health status (🟢🟡🔴)
|
||||
- Ping user if intervention needed
|
||||
|
||||
## Quick Reference
|
||||
|
||||
```
|
||||
New Task
|
||||
↓
|
||||
brainstorming → write-plan → doing-tasks → verify-task
|
||||
↓
|
||||
dispatch-multiple-agents (if parallel)
|
||||
↓
|
||||
update ongoing-tasks.md (if long-running)
|
||||
```
|
||||
|
||||
## Sub-Skills
|
||||
|
||||
- **brainstorming** - Phase 1: Clarify
|
||||
- **write-plan** - Phase 2: Plan
|
||||
- **doing-tasks** - Phase 3: Execute
|
||||
- **dispatch-multiple-agents** - Parallel execution
|
||||
- **verify-task** - Phase 4: Verify
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"ownerId": "kn7fmmgtxega8e1rmvf65w1cxh808cgb",
|
||||
"slug": "clawlist",
|
||||
"version": "0.0.1",
|
||||
"publishedAt": 1769828137423
|
||||
}
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
name: brainstorming
|
||||
description: "MUST use before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
|
||||
---
|
||||
|
||||
# Brainstorming Ideas Into Designs
|
||||
|
||||
## Overview
|
||||
|
||||
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
|
||||
|
||||
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
|
||||
|
||||
## The Process
|
||||
|
||||
**Understanding the idea:**
|
||||
- Check out the current project state first (files, docs, recent commits)
|
||||
- Ask questions one at a time to refine the idea
|
||||
- Prefer multiple choice questions when possible, but open-ended is fine too
|
||||
- Only one question per message - if a topic needs more exploration, break it into multiple questions
|
||||
- Focus on understanding: purpose, constraints, success criteria
|
||||
|
||||
**Exploring approaches:**
|
||||
- Propose 2-3 different approaches with trade-offs
|
||||
- Present options conversationally with your recommendation and reasoning
|
||||
- Lead with your recommended option and explain why
|
||||
|
||||
**Presenting the design:**
|
||||
- Once you believe you understand what you're building, present the design
|
||||
- Break it into sections of 200-300 words
|
||||
- Ask after each section whether it looks right so far
|
||||
- Cover: architecture, components, data flow, error handling, testing
|
||||
- Be ready to go back and clarify if something doesn't make sense
|
||||
|
||||
## After Brainstorming
|
||||
|
||||
Once design is validated, proceed to **write-plan** skill to create the implementation plan.
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **One question at a time** - Don't overwhelm with multiple questions
|
||||
- **Multiple choice preferred** - Easier to answer than open-ended when possible
|
||||
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
|
||||
- **Explore alternatives** - Always propose 2-3 approaches before settling
|
||||
- **Incremental validation** - Present design in sections, validate each
|
||||
- **Be flexible** - Go back and clarify when something doesn't make sense
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: dispatch-multiple-agents
|
||||
description: "Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Dispatch subagents to work concurrently."
|
||||
---
|
||||
|
||||
# Dispatch Multiple Agents
|
||||
|
||||
When you have multiple independent tasks, don't do them sequentially. Dispatch agents to work in parallel.
|
||||
|
||||
## When to Use
|
||||
|
||||
**Use when:**
|
||||
- 3+ independent tasks need attention
|
||||
- Tasks don't share state or resources
|
||||
- No dependencies between tasks
|
||||
- Speed matters
|
||||
|
||||
**Don't use when:**
|
||||
- Tasks are related (fixing one might fix others)
|
||||
- Tasks share files/resources (would conflict)
|
||||
- You need full system context for all tasks
|
||||
- Tasks must happen in specific order
|
||||
|
||||
## The Pattern
|
||||
|
||||
### 1. Identify Independent Domains
|
||||
|
||||
Group work by what's needed:
|
||||
- Task A: Research competitor A
|
||||
- Task B: Research competitor B
|
||||
- Task C: Research competitor C
|
||||
|
||||
Each is independent.
|
||||
|
||||
### 2. Create Focused Tasks
|
||||
|
||||
Each subagent gets:
|
||||
- **Specific scope:** One clear task
|
||||
- **All context needed:** Don't make them hunt
|
||||
- **Clear output:** What should they return?
|
||||
- **Constraints:** What NOT to touch
|
||||
|
||||
### 3. Dispatch in Parallel
|
||||
|
||||
Using sessions_spawn for concurrent execution.
|
||||
|
||||
### 4. Review and Integrate
|
||||
|
||||
When agents return:
|
||||
- Read each result
|
||||
- Verify no conflicts
|
||||
- Integrate findings
|
||||
- Report summary
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
Use dispatch-multiple-agents WITHIN the workflow:
|
||||
|
||||
```
|
||||
brainstorming → write-plan → dispatch-multiple-agents → verify-task
|
||||
↓
|
||||
doing-tasks (per subagent)
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
**Problem:** Research 5 competitors
|
||||
|
||||
**Dispatch:**
|
||||
- Agent 1 → Competitor A
|
||||
- Agent 2 → Competitor B
|
||||
- Agent 3 → Competitor C
|
||||
- Agent 4 → Competitor D
|
||||
- Agent 5 → Competitor E
|
||||
|
||||
**Result:** Full analysis in minutes, not hours.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: doing-tasks
|
||||
description: "Use when executing any task. Work through plans systematically, tracking progress, handling blockers, and coordinating with other skills. The central execution skill."
|
||||
---
|
||||
|
||||
# Doing Tasks - Execution Core
|
||||
|
||||
## The Rule
|
||||
|
||||
**If a task exists, you MUST use the appropriate skill before acting.**
|
||||
|
||||
```
|
||||
User message received
|
||||
↓
|
||||
Might any skill apply? → YES (even 1% chance) → Invoke skill
|
||||
↓ ↓
|
||||
NO ← definitely not Announce: "Using [skill]"
|
||||
↓ ↓
|
||||
Respond Follow skill exactly
|
||||
```
|
||||
|
||||
## Skill Priority
|
||||
|
||||
When multiple skills could apply:
|
||||
|
||||
1. **Process skills first** (brainstorming, debugging) - determine HOW
|
||||
2. **Planning skills second** (write-plan) - create roadmap
|
||||
3. **Execution skills third** (doing-tasks, dispatch-multiple-agents) - do the work
|
||||
4. **Verification skills last** (verify-task) - confirm completion
|
||||
|
||||
## The Workflow
|
||||
|
||||
### Standard Project Flow:
|
||||
|
||||
```
|
||||
brainstorming → write-plan → doing-tasks → verify-task
|
||||
↑ ↓
|
||||
└────── refinement ←───────────┘
|
||||
```
|
||||
|
||||
### With Parallel Execution:
|
||||
|
||||
```
|
||||
brainstorming → write-plan → dispatch-multiple-agents → verify-task
|
||||
↓
|
||||
doing-tasks (per subagent)
|
||||
```
|
||||
|
||||
## Red Flags - STOP and Check Skills
|
||||
|
||||
| Thought | Reality |
|
||||
|---------|---------|
|
||||
| "This is just a simple question" | Questions are tasks. Check for skills. |
|
||||
| "I need more context first" | Skill check comes BEFORE clarifying. |
|
||||
| "Let me explore first" | Skills tell you HOW to explore. |
|
||||
| "I can check files quickly" | Check for skills first. |
|
||||
| "I remember this skill" | Skills evolve. Read current version. |
|
||||
| "This doesn't need a formal skill" | If a skill exists, use it. |
|
||||
| "I'll just do this one thing first" | Check BEFORE doing anything. |
|
||||
|
||||
## Execution Discipline
|
||||
|
||||
### Do:
|
||||
- Check for skills BEFORE any action
|
||||
- Follow the plan exactly
|
||||
- Mark tasks complete as you finish
|
||||
- Report blockers immediately
|
||||
- Ask for clarification when unclear
|
||||
|
||||
### Don't:
|
||||
- Skip skills because "it's simple"
|
||||
- Add unplanned scope without approval
|
||||
- Work silently for long periods
|
||||
- Guess when unclear
|
||||
- Let blockers sit unreported
|
||||
|
||||
## Integration with Clawlist
|
||||
|
||||
For long-running or infinite tasks:
|
||||
|
||||
```
|
||||
doing-tasks → update ongoing-tasks.md → schedule next run
|
||||
```
|
||||
|
||||
The doing-tasks skill executes, then updates the task tracking file for heartbeat monitoring.
|
||||
|
||||
## Sub-Skills Reference
|
||||
|
||||
- **brainstorming** - Before any creative work
|
||||
- **write-plan** - After design, before execution
|
||||
- **dispatch-multiple-agents** - For parallel independent tasks
|
||||
- **verify-task** - After completion
|
||||
|
||||
## Example
|
||||
|
||||
**User:** "Build me a todo app"
|
||||
|
||||
**Correct flow:**
|
||||
1. "Using brainstorming skill to clarify requirements"
|
||||
2. Brainstorm: Ask questions, explore approaches
|
||||
3. "Using write-plan skill to create implementation plan"
|
||||
4. Write-plan: Create checkpoints and tasks
|
||||
5. "Using doing-tasks skill to execute"
|
||||
6. Execute: Work through plan
|
||||
7. "Using verify-task skill to confirm completion"
|
||||
8. Verify: Check against plan, get user approval
|
||||
|
||||
**Incorrect:**
|
||||
- Jumping straight to coding without brainstorming
|
||||
- Starting work without a plan
|
||||
- Skipping verification
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
name: verify-task
|
||||
description: "MUST use after completing any multi-step task or project. Verifies completion against the original plan, checks quality criteria, and documents outcomes."
|
||||
---
|
||||
|
||||
# Verify Task
|
||||
|
||||
## Overview
|
||||
|
||||
Confirm successful completion and document outcomes against the original plan.
|
||||
|
||||
## When to Verify
|
||||
|
||||
- All tasks from plan are marked complete
|
||||
- User asks "is it done?" or "did it work?"
|
||||
- Before declaring a project finished
|
||||
- After each checkpoint in long-running tasks
|
||||
|
||||
## Verification Process
|
||||
|
||||
### Step 1: Load Original Plan
|
||||
|
||||
Read the plan that was created by write-plan skill.
|
||||
|
||||
### Step 2: Verify Each Checkpoint
|
||||
|
||||
Go through each checkpoint and confirm:
|
||||
- [ ] All tasks marked complete
|
||||
- [ ] Verification criteria met
|
||||
- [ ] Quality standards achieved
|
||||
|
||||
### Step 3: Final Quality Checks
|
||||
|
||||
**General quality criteria:**
|
||||
- [ ] Output matches original goal
|
||||
- [ ] No obvious errors or issues
|
||||
- [ ] Documentation updated (if applicable)
|
||||
- [ ] User can use/access the result
|
||||
|
||||
### Step 4: User Confirmation
|
||||
|
||||
```
|
||||
"Verification complete. Final checks:
|
||||
|
||||
✓ All tasks from plan completed (X/Y)
|
||||
✓ Quality criteria met
|
||||
✓ [Specific checks]
|
||||
|
||||
[Preview/demonstrate result]
|
||||
|
||||
Does this meet your expectations? Any adjustments needed?"
|
||||
```
|
||||
|
||||
### Step 5: Document Completion
|
||||
|
||||
Save completion report to: `memory/plans/YYYY-MM-DD-<project>-complete.md`
|
||||
|
||||
Template:
|
||||
```markdown
|
||||
# [Project] - Completion Report
|
||||
|
||||
**Date Completed:** YYYY-MM-DD
|
||||
**Original Goal:** [from plan]
|
||||
**Final Result:** [brief description]
|
||||
|
||||
## Completion Summary
|
||||
|
||||
| Metric | Planned | Actual |
|
||||
|--------|---------|--------|
|
||||
| Checkpoints | X | X |
|
||||
| Tasks | Y | Y |
|
||||
| Time | Z min | W min |
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [x] All tasks complete
|
||||
- [x] Quality criteria met
|
||||
- [x] User approved
|
||||
|
||||
## What Was Delivered
|
||||
|
||||
[Description of final output]
|
||||
|
||||
## Blockers Encountered
|
||||
|
||||
1. [Blocker] → [Resolution]
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
- [What worked well]
|
||||
- [What to do differently next time]
|
||||
```
|
||||
|
||||
## Handling Issues
|
||||
|
||||
### If verification fails:
|
||||
|
||||
**Minor issues:** Quick fixes, proceed
|
||||
**Major issues:** Return to doing-tasks or re-plan
|
||||
|
||||
## Principles
|
||||
|
||||
- **Objectivity** - Verify against the plan, not assumptions
|
||||
- **Thoroughness** - Check all criteria
|
||||
- **Honesty** - Report issues, don't hide problems
|
||||
- **User-centric** - Final approval comes from user satisfaction
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: write-plan
|
||||
description: "MUST use after brainstorming and before executing. Creates detailed implementation plans with checkpoints, verification criteria, and execution options."
|
||||
---
|
||||
|
||||
# Write Plan
|
||||
|
||||
## Overview
|
||||
|
||||
Transform validated designs into detailed, actionable implementation plans with checkpoints.
|
||||
|
||||
Every plan includes:
|
||||
- Bite-sized tasks (2-5 minutes each)
|
||||
- Checkpoints with verification criteria
|
||||
- Estimated time for each section
|
||||
- Execution options at the end
|
||||
|
||||
## Plan Structure
|
||||
|
||||
```markdown
|
||||
# [Project Name] - Implementation Plan
|
||||
|
||||
**Goal:** One sentence describing success
|
||||
**Approach:** Brief summary of the chosen approach
|
||||
**Estimated Total Time:** X minutes
|
||||
|
||||
## Checkpoint 1: [Milestone Name]
|
||||
- [ ] Task 1: [Description] (~X min)
|
||||
- **Action:** [Specific action]
|
||||
- **Verify:** [How to confirm done]
|
||||
- [ ] Task 2: [Description] (~X min)
|
||||
...
|
||||
|
||||
## Checkpoint 2: [Milestone Name]
|
||||
...
|
||||
|
||||
## Verification Criteria
|
||||
- [ ] All checkpoints complete
|
||||
- [ ] Quality standards met
|
||||
- [ ] User approval obtained
|
||||
```
|
||||
|
||||
## Task Granularity
|
||||
|
||||
- **Small:** 2-5 minutes of work
|
||||
- **Specific:** Clear what "done" means
|
||||
- **Verifiable:** Can confirm completion
|
||||
- **Independent:** Doesn't block on other tasks in same checkpoint
|
||||
|
||||
## Execution Handoff
|
||||
|
||||
After saving the plan, offer execution choice:
|
||||
|
||||
**"Plan complete and saved to `memory/plans/<filename>.md`. Two execution options:**
|
||||
|
||||
**1. Single-Agent (this session)** - I execute tasks sequentially, review at each checkpoint
|
||||
|
||||
**2. Dispatch Multiple Agents (parallel)** - Spawn subagents for independent tasks
|
||||
|
||||
**Which approach?"**
|
||||
|
||||
**If Single-Agent chosen:**
|
||||
- Stay in this session
|
||||
- Execute tasks sequentially
|
||||
- Report progress at each checkpoint
|
||||
|
||||
**If Dispatch Multiple Agents chosen:**
|
||||
- Use dispatch-multiple-agents skill
|
||||
- Spawn subagents for parallel work
|
||||
- Integrate results
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
- After **brainstorming** → Use write-plan
|
||||
- Before **doing-tasks** → Plan must exist
|
||||
- With **dispatch-multiple-agents** → For parallel execution
|
||||
Reference in New Issue
Block a user