skills/wsf-thread/SKILL.md
Manage persistent context threads for cross-session work
npx skillsauth add sampx/agent-tools wsf-threadInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Parse $ARGUMENTS to determine mode:
<mode_list> If no arguments or $ARGUMENTS is empty:
List all threads:
ls .planning/threads/*.md 2>/dev/null
For each thread, read the first few lines to show title and status:
## Active Threads
| Thread | Status | Last Updated |
|--------|--------|-------------|
| fix-deploy-key-auth | OPEN | 2026-03-15 |
| pasta-tcp-timeout | RESOLVED | 2026-03-12 |
| perf-investigation | IN PROGRESS | 2026-03-17 |
If no threads exist, show:
No threads found. Create one with: /wsf-thread <description>
</mode_list>
<mode_resume> If $ARGUMENTS matches an existing thread name (file exists):
Resume the thread — load its context into the current session:
cat ".planning/threads/${THREAD_NAME}.md"
Display the thread content and ask what the user wants to work on next.
Update the thread's status to IN PROGRESS if it was OPEN.
</mode_resume>
<mode_create> If $ARGUMENTS is a new description (no matching thread file):
Create a new thread:
Generate slug from description:
SLUG=$(node "/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf/bin/wsf-tools.cjs" generate-slug "$ARGUMENTS" --raw)
Create the threads directory if needed:
mkdir -p .planning/threads
Write the thread file:
cat > ".planning/threads/${SLUG}.md" << 'EOF'
# Thread: {description}
## Status: OPEN
## Goal
{description}
## Context
*Created from conversation on {today's date}.*
## References
- *(add links, file paths, or issue numbers)*
## Next Steps
- *(what the next session should do first)*
EOF
If there's relevant context in the current conversation (code snippets, error messages, investigation results), extract and add it to the Context section.
Commit:
node "/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf/bin/wsf-tools.cjs" commit "docs: create thread — ${ARGUMENTS}" --files ".planning/threads/${SLUG}.md"
Report:
## 🧵 Thread Created
Thread: {slug}
File: .planning/threads/{slug}.md
Resume anytime with: /wsf-thread {slug}
</mode_create>
</process> <notes> - Threads are NOT phase-scoped — they exist independently of the roadmap - Lighter weight than /wsf-pause-work — no phase state, no plan context - The value is in Context and Next Steps — a cold-start session can pick up immediately - Threads can be promoted to phases or backlog items when they mature: /wsf-add-phase or /wsf-add-backlog with context from the thread - Thread files live in .planning/threads/ — no collision with phases or other WSF structures </notes>tools
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
development
Workspace-level Git worktree management — create, list, remove, and prune isolated development environments. Use this skill whenever the user needs to create a worktree, set up an isolated workspace, work on multiple features in parallel, list existing worktrees, check what worktrees exist, remove or delete a worktree, clean up stale worktrees, or manage git working trees in any way. Triggers include "create worktree", "new worktree", "list worktrees", "show worktrees", "remove worktree", "delete worktree", "clean up worktree", "prune worktree", "isolated environment", "parallel development", "worktree for <project>", or any request involving git worktree operations.
development
Issue/Plan-driven development workflow. Tasks must be backed by a GitHub Issue or Plan. Trigger: issue references like #14, creating issues, creating plans, implementing plans, executing plans, checking plans, verifying plans, Plan lifecycle transitions (approve/complete/verify/archive), decomposing PRDs into Issues. Skip: spec-driven workflows, research/discussion/explanation only, small ad-hoc changes that don't need an Issue or Plan.
testing
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.