@rfxlamia/skillkit 1.1.0 → 1.2.0

package/skills/skills/thread-pro/voice-injection.md

@@ -0,0 +1,130 @@
+# Voice Injection: Making AI Sound Human
+
+Techniques to transform robotic text into relatable content.
+
+**Contents:**
+- [The Voice Spectrum](#the-voice-spectrum)
+- [Technique 1: Specificity Injection](#technique-1-specificity-injection)
+- [Technique 2: Emotional Honesty](#technique-2-emotional-honesty)
+- [Technique 3: Sentence Rhythm](#technique-3-sentence-rhythm-burstiness)
+- [Technique 4: Casual Connectors](#technique-4-casual-connectors)
+- [Technique 5: Direct Address](#technique-5-direct-address)
+- [Technique 6: Imperfect Grammar](#technique-6-imperfect-grammar)
+- [Technique 7: The Friend Test](#technique-7-the-friend-test)
+
+## The Voice Spectrum
+
+```
+ROBOTIC ←────────────────────────→ HUMAN
+
+Corporate    Professional    Casual    Raw
+LinkedIn     Newsletter      Twitter   DMs
+```
+
+For viral threads, aim for **Casual to Raw**.
+
+## Technique 1: Specificity Injection
+
+Replace vague with vivid.
+
+| Vague (AI) | Specific (Human) |
+|------------|------------------|
+| "a tech company" | "Stripe, 3rd floor, desk by the fire exit" |
+| "recently" | "last Tuesday at 2am" |
+| "a lot of money" | "$47,832 (I still have the receipt)" |
+| "many people" | "347 people (I counted)" |
+| "for a while" | "for 3 years, 2 months, and 4 days" |
+
+## Technique 2: Emotional Honesty
+
+Say what you actually felt.
+
+| Sanitized (AI) | Honest (Human) |
+|----------------|----------------|
+| "It was challenging" | "I cried in my car. Twice." |
+| "I was nervous" | "My hands were shaking so bad I spilled coffee on my laptop" |
+| "I felt proud" | "I screamed so loud my neighbor called the cops" |
+| "I was uncertain" | "I had no fucking clue what I was doing" |
+
+**Note:** Swearing is optional but adds authenticity when appropriate for your audience.
+
+## Technique 3: Sentence Rhythm (Burstiness)
+
+AI writes uniform sentences. Humans don't.
+
+**AI Pattern:**
+> "I started my business in 2019. I faced many challenges along the way. I learned valuable lessons from each experience. Today I run a successful company."
+
+**Human Pattern:**
+> "Started the business in 2019. Chaos. Absolute chaos. But I learned more in those first 6 months than in 4 years of college. Now? We're doing $2M ARR. Wild."
+
+Mix:
+- One-word sentences
+- Fragments
+- Long, flowing thoughts
+- Questions?
+- Exclamations!
+
+## Technique 4: Casual Connectors
+
+Replace formal transitions with conversational ones.
+
+| Formal (AI) | Casual (Human) |
+|-------------|----------------|
+| "However" | "But here's the thing—" |
+| "Therefore" | "So" |
+| "Additionally" | "Oh, and" |
+| "In conclusion" | "Bottom line?" |
+| "For example" | "Like this:" |
+| "It should be noted" | "Real talk:" |
+
+## Technique 5: Direct Address
+
+Talk TO the reader, not AT them.
+
+| Distant (AI) | Direct (Human) |
+|--------------|----------------|
+| "One might consider" | "You need to try this" |
+| "Users can benefit from" | "This will save you hours" |
+| "It is advisable to" | "Do this. Seriously." |
+| "Readers should note" | "Here's what most people miss:" |
+
+## Technique 6: Imperfect Grammar
+
+Perfect grammar = AI flag. Real people:
+
+- Start sentences with "And" or "But"
+- Use fragments. Often.
+- End with prepositions (who cares)
+- Skip articles sometimes ("Started company in 2019")
+- Use run-on sentences when excited about something because honestly who stops to punctuate when they're on a roll
+
+## Technique 7: The "Friend Test"
+
+Before posting, ask:
+> "Would I text this to a friend?"
+
+If no → too formal
+If yes → ship it
+
+## Voice Quick Reference
+
+| Element | AI Default | Human Override |
+|---------|------------|----------------|
+| Numbers | Round ($50K) | Precise ($47.3K) |
+| Examples | Generic | Named/specific |
+| Emotions | Sanitized | Raw |
+| Sentences | Uniform | Varied |
+| Grammar | Perfect | Intentionally flawed |
+| Transitions | Formal | Casual |
+| Perspective | Third person | Second person (you) |
+
+## The 30-Second Voice Check
+
+Read your thread aloud. Check for:
+
+1. **Sounds like a textbook?** → Add personality
+2. **All same sentence length?** → Mix it up
+3. **No specific details?** → Add names/numbers
+4. **No emotion?** → What did you FEEL?
+5. **Would feel weird texting this?** → Too formal

package/skills/skills/tinkering/SKILL.md

@@ -0,0 +1,251 @@
+---
+name: tinkering
+description: >
+  Safe experimentation framework for AI agents. Creates isolated sandbox
+  environments for trying new features, testing approaches, and exploring
+  solutions without polluting the main codebase.
+
+  USE WHEN: Agent needs to try something uncertain, explore multiple approaches,
+  test a new library, prototype a feature, or run a technical spike before
+  committing to implementation.
+
+  PRIMARY TRIGGERS:
+  "experiment with" = Setup sandbox + run experiment
+  "try this approach" = Quick experiment in sandbox
+  "spike" / "POC" / "prototype" = Time-boxed technical investigation
+  "tinker" / "tinkering mode" = Enter experimentation workflow
+  "explore options" = Multi-approach comparison in sandbox
+
+  NOT FOR: Debugging (use debugger), testing (use test runner),
+  or committed feature work (use git branches).
+
+  DIFFERENTIATOR: Unlike git branches (for committed direction), tinkering is
+  for "I don't know if this will work" exploration. Try 5 things in sandbox
+  before committing to a branch. Faster feedback, zero codebase pollution.
+category: experimentation
+---
+
+# Tinkering
+
+## Overview
+
+Structured experimentation framework. When uncertain about an approach, don't
+hack at production code - create an isolated sandbox, try freely, then graduate
+successful experiments or discard failed ones cleanly.
+
+**Core principle:** The output of tinkering is **knowledge**, not production code.
+A successful experiment teaches you how to solve the problem. The actual
+implementation happens after, informed by what you learned.
+
+## When to Use
+
+| Situation | Tinkering? | Why |
+|-----------|-----------|-----|
+| "Will this library work for our use case?" | Yes | Unknown outcome, need to explore |
+| "Which of these 3 approaches is fastest?" | Yes | Comparing multiple options |
+| "How do I integrate this API?" | Yes | Technical spike, learning-focused |
+| "Add a login button to the header" | No | Clear requirement, use git branch |
+| "Fix the null pointer on line 42" | No | Debugging, not experimenting |
+| "Refactor auth module to use JWT" | Maybe | If approach uncertain, spike first |
+
+---
+
+## Workflow
+
+### Phase 1: Setup Sandbox
+
+Create isolated experiment environment:
+
+```bash
+# 1. Create experiment directory
+mkdir -p _experiments/{experiment-name}
+
+# 2. Add to .gitignore (if not already present)
+grep -qxF '_experiments/' .gitignore 2>/dev/null || echo '_experiments/' >> .gitignore
+
+# 3. Create manifest (first time only)
+# See MANIFEST.md template below
+```
+
+**MANIFEST.md template** (create at `_experiments/MANIFEST.md`):
+```markdown
+# Experiment Log
+
+## Active
+
+### {experiment-name}
+- **Date**: YYYY-MM-DD
+- **Hypothesis**: What we're trying to learn
+- **Status**: active
+- **Result**: (pending)
+
+## Completed
+<!-- Move finished experiments here -->
+```
+
+**Rules:**
+- NEVER modify production files during tinkering
+- ALL experiment code goes inside `_experiments/{name}/`
+- Copy source files into sandbox if you need to modify them
+
+---
+
+### Phase 2: Hypothesize
+
+Before writing any code, state clearly:
+
+```
+Question : What specific question are we answering?
+Success  : How will we know it works?
+Time box : Maximum time to spend (default: 30 min)
+Scope    : Which files/areas are involved?
+```
+
+Write this in `_experiments/{name}/HYPOTHESIS.md` or as a top comment.
+
+**Example:**
+```
+Question : Can we replace moment.js with date-fns and reduce bundle size?
+Success  : Bundle decreases >20%, all date formatting still works
+Time box : 20 minutes
+Scope    : src/utils/date.ts, package.json
+```
+
+---
+
+### Phase 3: Experiment
+
+Build freely in the sandbox.
+
+**Modifying existing code:**
+```bash
+# Copy the file(s) you need to change
+cp src/utils/date.ts _experiments/date-fns-migration/date.ts
+# Edit the copy freely - zero risk to production
+```
+
+**New feature exploration:**
+```bash
+# Create new files directly in sandbox
+touch _experiments/websocket-poc/server.ts
+touch _experiments/websocket-poc/client.ts
+```
+
+**Library evaluation:**
+```bash
+# Minimal test script in sandbox
+touch _experiments/redis-eval/test_redis.py
+# Use isolated dependencies (venv, local node_modules)
+```
+
+**Multi-approach comparison:**
+```
+_experiments/caching-spike/
+  approach-a-redis/
+  approach-b-memory/
+  approach-c-sqlite/
+  COMPARISON.md       # Side-by-side evaluation
+```
+
+**Rules during experimentation:**
+- Stay in sandbox - never touch production files
+- Quick and dirty is fine - this is throwaway code
+- Document learnings as you go
+- Stop at time box, even if incomplete - partial answers are still answers
+
+---
+
+### Phase 4: Evaluate
+
+Assess results against the hypothesis.
+
+**Checklist:**
+- Did the experiment answer the original question?
+- Does it meet the success criteria from Phase 2?
+- Any unexpected side effects or constraints discovered?
+- Is the approach feasible for production implementation?
+- What's the estimated effort to implement properly?
+
+**Update MANIFEST.md:**
+```markdown
+- **Result**: SUCCESS - date-fns reduced bundle by 34%, all tests pass
+- **Status**: graduated
+- **Notes**: Need to handle timezone edge case in formatRelative()
+```
+
+**Decision:**
+- Positive result -> Phase 5, Path A (Graduate)
+- Negative result -> Phase 5, Path B (Discard)
+- Inconclusive -> Extend time box OR try different approach
+
+---
+
+### Phase 5: Graduate or Discard
+
+#### Path A: Graduate (success)
+
+**Load reference:** `references/graduation-checklist.md`
+
+Quick summary:
+1. Do NOT copy-paste experiment code directly into production
+2. Re-implement properly using what you learned
+3. Write proper tests for the production implementation
+4. Apply code standards (experiment was quick & dirty, production shouldn't be)
+5. Reference experiment in commit message for context
+
+#### Path B: Discard (failed)
+
+Failed experiments are valuable - they tell you what NOT to do.
+
+1. Update MANIFEST.md with failure reason and learnings
+2. Delete experiment files: `rm -rf _experiments/{name}/`
+3. Or keep briefly if learnings are worth referencing
+
+---
+
+### Phase 6: Cleanup
+
+```bash
+# Remove completed experiment
+rm -rf _experiments/{experiment-name}/
+
+# Update MANIFEST.md - move entry to "Completed" section
+```
+
+**MANIFEST.md after cleanup:**
+```markdown
+## Completed
+
+### date-fns-migration (2025-01-15)
+- GRADUATED - Implemented in commit abc123
+- Learnings: date-fns 3x smaller, timezone handling needs explicit config
+
+### graphql-evaluation (2025-01-10)
+- DISCARDED - Too much overhead for our simple REST API
+- Learnings: REST + OpenAPI better fit for <20 endpoints
+```
+
+---
+
+## Quick Reference
+
+```
+Setup      ->  mkdir _experiments/{name}, add to .gitignore
+Hypothesize ->  Question + success criteria + time box
+Experiment  ->  Build in sandbox (never touch production)
+Evaluate    ->  Check against success criteria
+Graduate    ->  Re-implement properly in production
+Cleanup     ->  Remove files, update manifest
+```
+
+## Edge Cases
+
+**Needs database changes:** Use separate test DB or schema prefix. Document in hypothesis.
+
+**Needs running server:** Run from sandbox, use different port to avoid conflicts.
+
+**Multiple concurrent experiments:** Each gets own subdirectory. MANIFEST tracks all.
+
+**Experiment grows into real feature:** Graduate it. Don't let experiments become shadow production code.
+
+**Team member needs to see experiment:** Push to feature branch (temporarily track `_experiments/`) or share via patch.

package/skills/skills/tinkering/references/graduation-checklist.md

@@ -0,0 +1,100 @@
+# Graduation Checklist
+
+How to safely move a successful experiment into production code.
+
+## Pre-Graduation
+
+Before touching production code, confirm:
+
+- [ ] Experiment clearly answered the hypothesis question
+- [ ] Success criteria from HYPOTHESIS.md are met
+- [ ] You understand WHY the experiment worked (not just that it did)
+- [ ] Edge cases discovered during experimentation are documented
+
+## Graduation Steps
+
+### 1. Plan the Integration
+
+Don't just copy-paste. The experiment was quick and dirty - production needs to be clean.
+
+```
+Map out:
+- Which production files need changes?
+- What's the minimal changeset to achieve the result?
+- Are there dependencies to add/update?
+- Do existing tests need updating?
+```
+
+### 2. Implement Incrementally
+
+Apply changes to production code in small, reviewable steps:
+
+```
+Bad:  Copy entire _experiments/websocket-poc/ into src/
+Good: Implement websocket module in src/ informed by experiment learnings
+```
+
+**Key differences from experiment code:**
+- Proper error handling (experiment probably skipped this)
+- Type safety and validation (experiment used `any` everywhere)
+- Code style compliance (experiment ignored linting)
+- Edge case handling (experiment only covered happy path)
+- Documentation (experiment had none or minimal)
+
+### 3. Write Tests
+
+The experiment proved the concept works. Now prove it with proper tests:
+
+- Unit tests for new functions/modules
+- Integration tests for changed interactions
+- Edge case tests for issues discovered during experimentation
+- Regression tests if modifying existing behavior
+
+### 4. Validate
+
+```bash
+# Run full test suite
+npm test  # or pytest, cargo test, etc.
+
+# Run linter
+npm run lint
+
+# Build check
+npm run build
+
+# Manual smoke test of the feature
+```
+
+### 5. Commit with Context
+
+Reference the experiment in your commit for traceability:
+
+```
+feat: replace moment.js with date-fns for 34% bundle reduction
+
+Spike in _experiments/date-fns-migration/ confirmed date-fns handles
+all our formatting cases with 3x smaller footprint. Timezone edge case
+in formatRelative() resolved by explicit timezone config.
+```
+
+### 6. Clean Up Experiment
+
+After the production implementation is merged:
+
+```bash
+# Remove experiment directory
+rm -rf _experiments/{experiment-name}/
+
+# Update MANIFEST.md
+# Move entry to "Completed" with reference to commit/PR
+```
+
+## Common Graduation Mistakes
+
+| Mistake | Why It's Bad | Do This Instead |
+|---------|-------------|-----------------|
+| Copy-paste experiment code | Brings technical debt into production | Re-implement with proper standards |
+| Skip tests because "it worked in experiment" | Experiment tested manually, production needs automated tests | Write proper test suite |
+| Graduate partial experiment | Incomplete features cause confusion | Finish the experiment or graduate only the complete parts |
+| Forget to clean up sandbox | Stale experiments accumulate, mislead future developers | Delete after graduation |
+| No commit reference to experiment | Context lost, future devs don't know why decision was made | Reference experiment in commit message |

package/skills/skills/validate-plan/.skillkit-mode

@@ -0,0 +1 @@
+fast