clawpowers 1.0.0

package/skills/prospecting/SKILL.md

@@ -0,0 +1,313 @@
+---
+name: prospecting
+description: Lead generation workflow — define ICP, find companies, enrich contacts, and prepare outreach. Activate when you need to build a qualified prospect list.
+version: 1.0.0
+requires:
+  tools: [bash, curl]
+  runtime: true
+metrics:
+  tracks: [prospects_found, qualification_rate, enrichment_rate, outreach_response_rate]
+  improves: [icp_precision, search_query_effectiveness, enrichment_source_selection]
+---
+
+# Prospecting
+
+## When to Use
+
+Apply this skill when:
+
+- Building a list of potential customers for a product or service
+- Researching companies before a sales call or outreach
+- Finding decision-makers at target companies
+- Validating that a market segment is large enough to pursue
+- Preparing personalized outreach at scale
+
+**Skip when:**
+- You already have qualified prospects — move to outreach preparation
+- The ICP (Ideal Customer Profile) isn't defined — define it first
+- You need > 500 prospects (use dedicated sales intelligence platforms)
+
+**Relationship to market-intelligence:**
+```
+market-intelligence: understand the market (TAM, trends, positioning)
+prospecting: find specific companies and contacts within the market
+```
+
+## Core Methodology
+
+### Phase 1: ICP Definition
+
+Every prospecting campaign starts with a precise Ideal Customer Profile. Vague ICPs produce low-quality lists.
+
+**ICP template:**
+
+```markdown
+## Ideal Customer Profile
+
+### Company Attributes
+- **Industry:** [specific vertical(s) — e.g., "fintech SaaS" not "software"]
+- **Company size:** [employees: 50-500, or ARR: $5M-$50M]
+- **Stage:** [Series A/B/C, bootstrapped, public — funding is proxy for budget authority]
+- **Tech stack:** [if relevant — e.g., uses Python, AWS, GitHub Actions]
+- **Geography:** [US/EU/APAC — where procurement decisions are made]
+- **Signals:** [hiring patterns, job postings, tech adoption signals]
+
+### Contact Attributes  
+- **Title:** [VP Engineering, Director of DevOps, CTO — who FEELS the pain]
+- **Department:** [Engineering, Product, Security]
+- **Seniority:** [IC, Manager, Director, VP, C-Suite — who has BUDGET]
+- **Pain signal:** [recent role change, company event, content they've published]
+
+### Negative ICP (Disqualifiers)
+- **Company:** [too small, regulated industry if compliance blocks you, bootstrapped with no budget]
+- **Contact:** [non-technical roles, no budget authority, different pain set]
+
+### Qualification Criteria (rank in this order)
+1. [Must-have criterion — no exceptions]
+2. [Must-have criterion — no exceptions]
+3. [Strong signal — weight heavily]
+4. [Good signal — weight moderately]
+```
+
+### Phase 2: Company Discovery
+
+**Search Strategies:**
+
+**GitHub-based discovery (for developer tools):**
+```bash
+# Find companies using a specific technology
+curl -s "https://api.github.com/search/repositories?q=TECHNOLOGY+in:readme&sort=stars&per_page=30" | \
+  python3 -c "
+import json, sys
+data = json.load(sys.stdin)
+for item in data['items']:
+    if item['owner']['type'] == 'Organization':
+        print(f\"{item['owner']['login']}: {item['full_name']} ({item['stargazers_count']} stars)\")
+"
+```
+
+**LinkedIn company search:**
+
+Build search queries using Boolean operators:
+```
+"(VP Engineering OR Director Engineering OR CTO) AND (Python OR TypeScript) AND (Series B OR Series C)"
+Location: United States
+Industry: Computer Software
+Company size: 51-500 employees
+```
+
+**Exa/Perplexity for intent signals:**
+```bash
+# Find companies recently discussing a pain point you solve
+curl -X POST "https://api.exa.ai/search" \
+  -H "x-api-key: $EXA_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "query": "engineering team struggling with test coverage deployment velocity",
+    "type": "neural",
+    "numResults": 10,
+    "includeDomains": ["linkedin.com", "dev.to", "medium.com"],
+    "startPublishedDate": "2026-01-01"
+  }'
+```
+
+**Apollo.io for direct prospecting:**
+```bash
+# Search for people matching ICP
+curl -X POST "https://api.apollo.io/v1/mixed_people/search" \
+  -H "Content-Type: application/json" \
+  -H "x-api-key: $APOLLO_API_KEY" \
+  -d '{
+    "person_titles": ["VP Engineering", "Director of Engineering", "CTO"],
+    "organization_num_employees_ranges": ["51,500"],
+    "page": 1,
+    "per_page": 25
+  }'
+```
+
+### Phase 3: Qualification
+
+For each company found, score against your ICP:
+
+```markdown
+## Company: [Name]
+
+**URL:** [company.com]
+**Size:** [employees]
+**Stage:** [funding round]
+**Tech signals:** [GitHub org, job postings for relevant tech]
+
+### ICP Score
+| Criterion | Met? | Evidence |
+|-----------|------|---------|
+| [Must-have 1] | ✅/❌ | [source] |
+| [Must-have 2] | ✅/❌ | [source] |
+| [Signal 1] | ✅/❌/? | [source] |
+| [Signal 2] | ✅/❌/? | [source] |
+
+**Status:** Qualified / Disqualified / Research needed
+**Reason for disqualification:** [if applicable]
+```
+
+**Qualification protocol:**
+- Must-have criterion fail → immediate disqualification, no enrichment
+- 2+ strong signals + no disqualifiers → high-priority prospect
+- Unclear signals → brief additional research, then decide
+
+### Phase 4: Contact Enrichment
+
+For qualified companies, find the right contacts:
+
+**LinkedIn-based enrichment:**
+
+Use LinkedIn's company page to find decision-makers:
+```
+company.com/about/leadership → C-suite
+LinkedIn search: [Company Name] + [Target Title]
+```
+
+**Hunter.io for email discovery:**
+```bash
+# Find email pattern for a domain
+curl -s "https://api.hunter.io/v2/domain-search?domain=company.com&api_key=$HUNTER_API_KEY" | \
+  python3 -c "
+import json, sys
+data = json.load(sys.stdin)
+print(f'Email pattern: {data[\"data\"][\"pattern\"]}')
+for email in data['data']['emails'][:5]:
+    print(f'{email[\"value\"]}: {email[\"first_name\"]} {email[\"last_name\"]} ({email[\"position\"]})')
+"
+
+# Verify a specific email
+curl -s "https://api.hunter.io/v2/email-verifier?email=john@company.com&api_key=$HUNTER_API_KEY"
+```
+
+**Enriched contact record:**
+```markdown
+## Contact: [First Last]
+
+**Company:** [Company Name]
+**Title:** [Exact current title]
+**Email:** [email@company.com] (confidence: High/Medium)
+**LinkedIn:** [URL]
+**GitHub:** [username if found]
+
+### Personalization hooks
+- **Recent activity:** [blog post, conference talk, job change, company announcement]
+- **Shared connections:** [mutual contacts]
+- **Pain signals:** [job posting for their team, content they've published]
+- **Tech interest:** [repos they've starred, tools they've written about]
+
+### Outreach priority
+[High / Medium / Low] — [reason]
+```
+
+### Phase 5: Outreach Preparation
+
+Prepare personalized outreach for high-priority contacts:
+
+**Outreach template principles:**
+- Short: 3-4 sentences max (first touch)
+- Specific: One concrete observation about their situation
+- Relevant: Clear connection between their pain and your solution
+- Easy: Lowest-friction next step ("5-minute call" not "let's do a demo")
+
+**Template structure:**
+```
+[Personalized opener — specific observation about them or their company]
+[What you do — one sentence, focused on the problem you solve]
+[Why relevant to them — connect their signal to your solution]
+[Low-friction CTA — open-ended question or easy next step]
+```
+
+**Example (developer tools):**
+```
+Hi [Name],
+
+Saw [Company] is hiring 3 senior engineers right now — congrats on the growth. 
+We built ClawPowers to help engineering teams like yours ship faster by giving 
+AI coding agents persistent memory and self-improvement — instead of re-explaining 
+context every session.
+
+Would it be worth 10 minutes to see if it fits your current workflow?
+```
+
+**What to avoid:**
+- "I hope this finds you well"
+- "I came across your profile"
+- Feature lists in the first touch
+- Asking for 30-60 minute meetings
+- CC'ing multiple people without introduction
+
+### Phase 6: CRM Output
+
+Export qualified, enriched prospects to your CRM:
+
+```bash
+# Build CSV for CRM import
+cat > prospects.csv << 'EOF'
+company,first_name,last_name,title,email,linkedin,priority,notes
+Acme Corp,Jane,Smith,VP Engineering,jane@acme.com,linkedin.com/in/jsmith,High,"Hiring 3 engineers; OSS contributor"
+EOF
+
+# Or output JSON for API import
+python3 -c "
+import json
+prospects = [
+    {
+        'company': 'Acme Corp',
+        'contact': {'first': 'Jane', 'last': 'Smith', 'title': 'VP Engineering'},
+        'email': 'jane@acme.com',
+        'priority': 'high',
+        'personalization': 'Hiring 3 engineers; active OSS contributor'
+    }
+]
+print(json.dumps(prospects, indent=2))
+"
+```
+
+## ClawPowers Enhancement
+
+When `~/.clawpowers/` runtime is initialized:
+
+**Prospect Database:**
+
+All prospects, enrichment, and outreach outcomes are stored:
+```bash
+bash runtime/persistence/store.sh set "prospect:acme-jane-smith:status" "outreach_sent"
+bash runtime/persistence/store.sh set "prospect:acme-jane-smith:email_sent_at" "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+bash runtime/persistence/store.sh set "prospect:acme-jane-smith:response" "interested"
+bash runtime/persistence/store.sh set "prospect:acme-jane-smith:response_at" "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+```
+
+**ICP Refinement:**
+
+Response rates feed back into ICP scoring:
+```bash
+bash runtime/feedback/analyze.sh --skill prospecting
+# Output:
+# ICP criterion effectiveness:
+# - "hiring 3+ engineers" signal → 34% response rate (high signal)
+# - "Series B" signal → 12% response rate (weak signal)
+# - "Python OR TypeScript in job postings" → 28% response rate (medium signal)
+# Recommendation: weight hiring signal 3x vs. funding stage
+```
+
+```bash
+bash runtime/metrics/collector.sh record \
+  --skill prospecting \
+  --outcome success \
+  --notes "devtools-campaign: 25 companies qualified, 18 contacts enriched, 18 outreach prepared"
+```
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Correct Approach |
+|-------------|-------------|-----------------|
+| Spray-and-pray outreach | Low response rate, damages brand | Qualify before enriching, enrich before outreach |
+| Contacting every person at a company | Creates noise, damages company relationship | One contact per company (initial touch) |
+| Generic outreach without personalization | Reads as spam | Specific, researched opener per contact |
+| Not disqualifying early | Wasted enrichment and outreach effort | Score ICP criteria before enrichment |
+| Storing prospects without follow-up system | Prospects go cold | CRM entry with follow-up date at enrichment time |
+| Asking for a demo in first touch | Friction too high for cold contact | Low-friction first step (quick call, question) |
+| Not tracking response rates per ICP signal | Can't improve ICP over time | Log which signals correlated with responses |

package/skills/receiving-code-review/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: receiving-code-review
+description: Process code review feedback constructively and systematically. Activate when you receive review comments on a PR.
+version: 1.0.0
+requires:
+  tools: [git, bash]
+  runtime: false
+metrics:
+  tracks: [feedback_items_addressed, response_time, clarification_requests, approved_on_cycle]
+  improves: [feedback_categorization, response_quality, pattern_detection]
+---
+
+# Receiving Code Review
+
+## When to Use
+
+Apply this skill when:
+
+- You've received review comments on a PR
+- You need to process reviewer feedback before responding
+- You want to make sure you're addressing feedback effectively, not just defensively
+
+**The mindset:** Reviewers are helping you ship better code. Feedback is information, not judgment. The goal is to understand it, not to defend against it.
+
+## Core Methodology
+
+### Step 1: Read Everything Before Responding to Anything
+
+Before replying to any comment:
+
+1. Read all comments start to finish
+2. Identify the reviewer's primary concerns (often one theme across many comments)
+3. Distinguish between required changes and suggestions
+
+**Don't respond in real-time as notifications arrive.** You'll respond to symptoms without seeing the root concern, leading to back-and-forth rather than resolution.
+
+### Step 2: Categorize Feedback
+
+For each comment, assign a category:
+
+| Category | Definition | Action |
+|----------|-----------|--------|
+| **Bug** | Reviewer found a real bug | Fix unconditionally |
+| **Security** | Security concern identified | Fix unconditionally, escalate if in scope |
+| **Clarity** | Code is correct but hard to understand | Rename / add comment / restructure |
+| **Suggestion** | Optional improvement, not blocking | Evaluate on merit; implement or decline with reason |
+| **Style** | Formatting, naming conventions | Align with team standard; if no standard, discuss |
+| **Question** | Reviewer wants to understand, not change | Explain in response; add inline comment if confusion likely for others |
+| **Out of scope** | Valid concern, but not for this PR | Acknowledge, create tracking issue, respond with issue number |
+| **Nitpick** | Low-impact preference | Implement if quick; decline with "minor — deferred" if not |
+
+**Never suppress a Bug or Security comment by arguing it's not a bug.** If you disagree, explain your reasoning and request explicit sign-off from the reviewer. Don't merge until that sign-off is given.
+
+### Step 3: Create a Response Plan
+
+Before touching code, plan your responses:
+
+```markdown
+## Review Response Plan
+
+**PR:** feature/auth-service
+**Reviewer:** Alice
+**Total comments:** 12
+
+### Required (must fix before merge)
+1. Line 61 — Token expiry check order: [AGREED — will move expiry check before signature validation]
+2. Line 88 — Error message leaks algorithm name: [AGREED — will generalize to "Invalid token"]
+
+### Will Fix (optional but clearly right)
+3. Line 44 — Rename `u` to `user_id`: [AGREED — will rename throughout]
+4. Line 102 — Missing test for empty audience claim: [AGREED — will add test]
+
+### Will Discuss (need alignment)
+5. Line 78 — Algorithm enforcement via allowlist vs. blocklist: [DISAGREE — will explain RS256-only policy in response]
+
+### Out of Scope (create issues)
+6. Line 30 — Refresh token support: [Valid — creating issue #263, not in this PR's scope]
+
+### Questions (need to understand before acting)
+7. Line 55 — "Is this safe?" — need clarification: what specifically concerns you?
+```
+
+### Step 4: Implement Changes
+
+Work through required and agreed changes:
+
+1. Create a new commit for the review changes (don't squash yet — reviewer needs to see what changed)
+2. Address each comment with a corresponding code change
+3. For each change, reply to the comment in GitHub explaining what you did
+
+**Commit message format:**
+```
+review: address auth service review feedback from Alice
+
+- Move token expiry check before signature validation (line 61)
+- Generalize error message to avoid algorithm disclosure (line 88)
+- Rename u → user_id for clarity throughout auth.py
+- Add test for empty audience claim
+```
+
+### Step 5: Respond to Every Comment
+
+Every comment deserves a response, even if the response is "acknowledged" or "disagree — see explanation":
+
+**For implemented changes:**
+```
+Fixed in commit a3f9b2c. Moved expiry check to line 47, now before signature 
+validation as you suggested. Tests updated to reflect new check order.
+```
+
+**For agreed suggestions:**
+```
+Good catch — added test for empty audience claim in test_auth.py:147.
+```
+
+**For disagreements:**
+```
+I understand the concern. The reason I chose an allowlist (RS256 only) rather than 
+a blocklist (exclude HS256) is that new algorithms get added periodically — an 
+allowlist stays secure as the JWT spec evolves, a blocklist can be bypassed by 
+a newly-added algorithm we haven't blocked yet. Happy to add a comment to the 
+code explaining this if it's not obvious.
+```
+
+**For out-of-scope items:**
+```
+Valid point — this is outside this PR's scope but worth addressing. 
+Created issue #263 for refresh token support. Added it to the next sprint backlog.
+```
+
+**Tone rules:**
+- Never sarcastic or defensive
+- Explain your reasoning when disagreeing
+- Thank reviewers for catches that were genuine bugs or security issues
+- Don't over-apologize — brief acknowledgment is sufficient
+
+### Step 6: Request Re-review
+
+After addressing all feedback:
+
+```bash
+# Push changes
+git push origin feature/auth-service
+
+# In GitHub: mark all addressed conversations as "Resolved"
+# (only resolve conversations you've addressed — let reviewer resolve their own)
+# Re-request review from reviewer
+```
+
+Notify the reviewer:
+```
+Hi Alice — addressed all your feedback. Main changes:
+1. Moved expiry check before signature validation
+2. Generalized error message
+3. Added 3 new tests for edge cases you identified
+
+Disagreed on one point (algorithm allowlist) and explained reasoning in the thread — 
+would appreciate your thoughts. PR is ready for re-review.
+```
+
+### Step 7: Iterate Until Approved
+
+Repeat Steps 4-6 until all required changes are addressed and reviewer approves.
+
+**If review is dragging:**
+- If reviewer hasn't responded in 2 business days after re-request: follow up in Slack/Teams
+- If a comment thread is becoming a lengthy debate: move it to a real conversation, then update the PR based on the conclusion
+
+## ClawPowers Enhancement
+
+When `~/.clawpowers/` runtime is initialized:
+
+**Feedback Pattern Database:**
+
+Every piece of review feedback gets stored (with PR and reviewer context):
+
+```bash
+bash runtime/persistence/store.sh set "feedback:pattern:token-expiry-order" "expiry check must precede signature check"
+bash runtime/persistence/store.sh set "feedback:pattern:error-message-leakage" "error messages must not disclose algorithm or implementation details"
+```
+
+Before writing code in the future:
+```bash
+bash runtime/persistence/store.sh list "feedback:pattern:*"
+# → Shows common feedback patterns → prevents them from being submitted in the first place
+```
+
+**Common Issues Tracking:**
+
+After 20+ PR cycles:
+```bash
+bash runtime/feedback/analyze.sh --skill receiving-code-review
+# Output:
+# Most common feedback category: Bug (38%) — improving test coverage recommended
+# Most common feedback type: Security (22%) — consider security review checklist in verification step
+# Average review cycles: 2.1 — target: 1.5
+# Longest threads: algorithm selection, error handling, naming conventions
+```
+
+**Response Quality Metrics:**
+
+```bash
+bash runtime/metrics/collector.sh record \
+  --skill receiving-code-review \
+  --outcome success \
+  --notes "auth-service: 12 comments, 10 fixed, 1 declined (explained), 1 deferred (#263), approved on cycle 2"
+```
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Correct Approach |
+|-------------|-------------|-----------------|
+| Responding to comments as they arrive | Miss the theme, respond to symptoms | Read all comments first, then respond |
+| Defensive responses | Damages reviewer relationship, slows iteration | Assume good faith, explain reasoning when disagreeing |
+| Ignoring comments | Reviewer marks "changes requested" forever | Respond to every comment |
+| Resolving reviewer's conversations yourself | Reviewer loses track of what was addressed | Only resolve your own acknowledged items |
+| "Fixed" with no explanation | Reviewer can't verify without re-reading diff | Explain what you changed and where |
+| Silently closing out-of-scope items | Valid concerns get lost | Create issues for deferred items, reference in response |
+| Merging without re-request | Reviewer never sees the updated code | Always re-request after addressing feedback |
+
+## Integration with Other Skills
+
+- Preceded by `requesting-code-review`
+- Use `systematic-debugging` if review feedback reveals a deeper architectural issue
+- Use `writing-plans` if review feedback requires substantial new work