Add community skills, agents, system prompts from 22+ sources

Community Skills (32):
- jat: jat-start, jat-verify, jat-complete
- pi-mono: codex-cli, codex-5.3-prompting, interactive-shell
- picoclaw: github, weather, tmux, summarize, skill-creator
- dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.)
- dexter: dcf valuation skill

Agents (23):
- pi-mono subagents: scout, planner, reviewer, worker
- toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.)

System Prompts (91):
- Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.)
- OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools)
- Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli)
- xAI: 5 Grok prompts
- Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.)

Hooks (9):
- JAT hooks for session management, signal tracking, activity logging

Prompts (6):
- pi-mono templates for PR review, issue analysis, changelog audit

Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell,
craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus,
zed, clawdbot, OS-Copilot, and more

skills/community/dyad/fix-issue/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: dyad:fix-issue
+description: Create a plan to fix a GitHub issue, then implement it locally.
+---
+
+# Fix Issue
+
+Create a plan to fix a GitHub issue, then implement it locally.
+
+## Arguments
+
+- `$ARGUMENTS`: GitHub issue number or URL.
+
+## Instructions
+
+1. **Fetch the GitHub issue:**
+
+   First, extract the issue number from `$ARGUMENTS`:
+   - If `$ARGUMENTS` is a number (e.g., `123`), use it directly
+   - If `$ARGUMENTS` is a URL (e.g., `https://github.com/owner/repo/issues/123`), extract the issue number from the path
+
+   Then fetch the issue:
+
+   ```
+   gh issue view <issue-number> --json title,body,comments,labels,assignees
+   ```
+
+2. **Sanitize the issue content:**
+
+   Run the issue body through the sanitization script to remove HTML comments, invisible characters, and other artifacts:
+
+   ```
+   printf '%s' "$ISSUE_BODY" | python3 .claude/skills/fix-issue/scripts/sanitize_issue_markdown.py
+   ```
+
+   This removes:
+   - HTML comments (`<!-- ... -->`)
+   - Zero-width and invisible Unicode characters
+   - Excessive blank lines
+   - HTML details/summary tags (keeping content)
+
+3. **Analyze the issue:**
+   - Understand what the issue is asking for
+   - Identify the type of work (bug fix, feature, refactor, etc.)
+   - Note any specific requirements or constraints mentioned
+
+4. **Explore the codebase:**
+   - Search for relevant files and code related to the issue
+   - Understand the current implementation
+   - Identify what needs to change
+   - Look at existing tests to understand testing patterns used in the project
+
+5. **Determine testing approach:**
+
+   Consider what kind of testing is appropriate for this change:
+   - **E2E test**: For user-facing features or complete user flows. Prefer this when the change involves UI interactions or would require mocking many dependencies to unit test.
+   - **Unit test**: For pure business logic, utility functions, or isolated components.
+   - **No new tests**: Only for trivial changes (typos, config tweaks, etc.)
+
+   Note: Per project guidelines, avoid writing many E2E tests for one feature. Prefer one or two E2E tests with broad coverage. If unsure, ask the user for guidance on testing approach.
+
+   **IMPORTANT for E2E tests:** You MUST run `npm run build` before running E2E tests. E2E tests run against the built application binary. If you make any changes to application code (anything outside of `e2e-tests/`), you MUST re-run `npm run build` before running E2E tests, otherwise you'll be testing the old version.
+
+6. **Create a detailed plan:**
+
+   Write a plan that includes:
+   - **Summary**: Brief description of the issue and proposed solution
+   - **Files to modify**: List of files that will need changes
+   - **Implementation steps**: Ordered list of specific changes to make
+   - **Testing approach**: What tests to add (E2E, unit, or none) and why
+   - **Potential risks**: Any concerns or edge cases to consider
+
+7. **Execute the plan:**
+
+   If the plan is straightforward with no ambiguities or open questions:
+   - Proceed directly to implementation without asking for approval
+   - Implement the plan step by step
+   - Run `/dyad:pr-push` when complete
+
+   If the plan has significant complexity, multiple valid approaches, or requires user input:
+   - Present the plan to the user and use `ExitPlanMode` to request approval
+   - After approval, implement the plan step by step
+   - Run `/dyad:pr-push` when complete