johns-harness 2026.9.24 → 2026.9.25

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 2026.9.25
+
+- Family 72: eleven generic skills from the author's workspace ship as bundled skills (`code-ops`, `web-research`, `plan-archival`, `todos`, `dashboard`, `arch-viz`, `content-story`, `cold-outreach`, `gcp-logs`, `activity-logging`, `outlook`), converted to fully generic wording first: no owner names, paths, repos, accounts, or products. They load by description match like every other bundled skill (none is always-on), workspace copies override them, and `enabled: false` and `allowBundled` still apply. `RULES.md` lists all of them.
+- The Family 71 packed-artifact gate now also proves all eleven bundled generic skills are inside every tarball, and verifier checks 72.1 through 72.5 enforce presence, frontmatter, the generic wording contract, and no em dashes.
+- Roll back with `npm i -g johns-harness@2026.9.24`.
+
 ## 2026.9.24
 
 - Family 71: native-first Jiti plugin loading (Family 68) is now standard on `latest`. The `extended` dist-tag moves to this same version, so both lines converge at 2026.9.24. Node loads already-built JavaScript plugin code natively first and keeps Babel only for TypeScript plugin entries; `JITI_TRY_NATIVE` is no longer needed and is harmless if set.

package/README.md

@@ -85,8 +85,8 @@ node johnness.mjs --help
 ### Verify
 
 ```bash
-npm test                        # 909 tests against the installed dependency tree
-bash scripts/verify-patches.sh  # 443 checks across every patch family
+npm test                        # 914 tests against the installed dependency tree
+bash scripts/verify-patches.sh  # 458 checks across every patch family
 ```
 
 ## Launch a swarm with one command
@@ -132,7 +132,7 @@ Coding agents today run as isolated processes. Two agents on the same repository
 - **Memory built for production.** Tiered recall that traces from consolidated reflections down to the verbatim record, surviving compaction and shared across the swarm. Installed and enabled by default.
 - **Production authority per commit.** Promotion is granted to an exact SHA, never to a branch name, so one worker's authorization never covers another worker's commits.
 - **An append-only action log.** Agents record every consequential action to `ACTION_LOG.md` and read it before acting.
-- **A fixed runtime surface.** The core does not grow on a schedule. New mechanisms enter only to solve a demonstrated production failure, one narrow, tested, reversible patch at a time: 71 patch families, each with a regression test and a rollback path.
+- **A fixed runtime surface.** The core does not grow on a schedule. New mechanisms enter only to solve a demonstrated production failure, one narrow, tested, reversible patch at a time: 72 patch families, each with a regression test and a rollback path.
 - **Reliability with a definition.** Bounded retries, explicit failure states, exact-once continuation, context-pressure recovery, durable delivery, and supervised gateway recovery.
 - **Coding first, phone optional.** Direct the work at a high level from a chat channel while agents plan, implement, test, coordinate, and stage releases unattended.
 - **Local voice.** Optional native Whisper transcription of inbound audio, entirely on your machine. Off by default. [Setup](docs/NATIVE-WHISPER-MUSE.md).
@@ -199,7 +199,7 @@ The log is a [`RULES.md`](RULES.md) workspace convention enforced through the ac
 
 ## Patch families
 
-The runtime carries 71 patch families plus the 65.1 safe-update amendment. Each is a production fix applied at the source with a regression test, a durable patch marker, and a rollback path. A verifier runs 443 checks against the package tree and installed dependencies, and 909 tests run against the installed dependency tree.
+The runtime carries 72 patch families plus the 65.1 safe-update amendment. Each is a production fix applied at the source with a regression test, a durable patch marker, and a rollback path. A verifier runs 458 checks against the package tree and installed dependencies, and 914 tests run against the installed dependency tree.
 
 Every family follows the same six steps: reproduce the failure, trace the exact runtime path, make the smallest source-level change that restores the invariant, add a regression test and a patch marker, run the verifier, and retain rollback artifacts. The full index: [`docs/PATCHES.md`](docs/PATCHES.md).
 
@@ -213,11 +213,12 @@ Every family follows the same six steps: reproduce the failure, trace the exact
 | `--dev` | Dev profile under `~/.johnness-dev` with its own gateway port and shifted derived ports |
 | Rules | [`RULES.md`](RULES.md) ships 19 operating-policy sections injected on every call. Fill in the placeholders; keep long procedures in skills. |
 | Orchestrator skill | Bundled and loaded implicitly on every install. Decide whether to pass the user's words through or expand them, then keep the briefing brief. Override with a workspace `skills/orchestrator/SKILL.md`. |
+| Bundled generic skills | Eleven generic skills ship in `skills/` and load by description match: `code-ops`, `web-research`, `plan-archival`, `todos`, `dashboard`, `arch-viz`, `content-story`, `cold-outreach`, `gcp-logs`, `activity-logging`, `outlook`. Workspace copies override; `enabled: false` and `allowBundled` still apply. |
 
 ## Documentation
 
 - [`docs/index.md`](docs/index.md): runtime docs, from gateway and channels to plugins, nodes, and CLI reference.
-- [`docs/PATCHES.md`](docs/PATCHES.md): the 71 patch families, one record each.
+- [`docs/PATCHES.md`](docs/PATCHES.md): the 72 patch families, one record each.
 - [`docs/NATIVE-WHISPER-MUSE.md`](docs/NATIVE-WHISPER-MUSE.md): local Whisper transcription setup.
 - [`RULES.md`](RULES.md): the default operating rules, including Rule Zero on production authorization.
 

package/docs/PATCHES.md

@@ -17,7 +17,7 @@ they predate ~2026-06-06).
 
 ## Index
 
-Family 01 is retired. Families 02 through 41, 43 through 67, 69 and 70, including the 65.1 amendment, are live on `main`; Family 68 ships on the `extended` release line. Family 42 is omitted; native Codex OAuth ownership is Family 58.
+Family 01 is retired. Families 02 through 41, 43 through 72, including the 65.1 amendment, are live on `main`; the `latest` and `extended` release lines converged at 2026.9.24. Family 42 is omitted; native Codex OAuth ownership is Family 58.
 
 1. **01, announce queue TTL, retired:** Removed the five-minute age filter that could discard delayed sub-agent completion announcements. [Details](#01--announce-ttl-retired-2026-07-30)
 2. **02, failover rotation:** Returns model selection to the highest-priority profile after its cooldown ends. [Details](#02--failover-rotation-undocumented)
@@ -95,6 +95,10 @@ Family 01 is retired. Families 02 through 41, 43 through 67, 69 and 70, includin
 
 70. **70, bundled orchestrator skill:** The delegation and briefing protocol ships as an always-eligible bundled skill; every install loads it implicitly and a workspace copy still overrides it. [Details](#family-70-bundled-orchestrator-skill)
 
+71. **71, native-first Jiti standard on latest:** The Family 68 native-first loader option ships on every artifact, the `latest` and `extended` lines converge, and a packed-artifact gate proves the tarball carries it. [Details](#family-71-native-first-jiti-standard-on-latest)
+
+72. **72, bundled generic skills:** Eleven workspace skills (code operations, research, todos, dashboard, planning, content, outreach, logs, and more) ship as generic bundled skills that load by description match, with no owner names or personal paths. [Details](#family-72-bundled-generic-skills)
+
 ---
 
 ## 01 - announce-ttl (RETIRED 2026-07-30)
@@ -2618,3 +2622,39 @@ Family 67 hash checks continue to compare the Family-67 surface with the Family
 **Tests:** `tests/native-jiti-standard.test.mjs` proves the gate passes a complete tarball, fails a tarball packed without Family 68 (the 2026.9.22 and 2026.9.23 shape), fails when one copy lacks the option or is absent, fails on a version mismatch, exits non-zero from the CLI, and that the real `npm pack` output of this tree carries the marker in all ten copies. Verifier checks 71.1 through 71.3 cover the shipped gate, the packed or installed artifact, and the absence of a separate extended pin in `package.json`.
 
 Roll back with `npm i -g johns-harness@2026.9.23` (no native-first Jiti) or `npm i -g johns-harness@2026.9.21-extended.1` (Family 68 without Families 69 and 70).
+
+## Family 72: bundled generic skills
+
+**Release:** `johns-harness@2026.9.25`. Published as `latest` and the `extended` dist-tag moves to it (the two lines converged at 2026.9.24).
+
+Eleven skills from the author's personal workspace ship as bundled skills in `skills/<name>/SKILL.md`, made fully generic first: no owner names, no personal paths, repos, accounts, or products. Every one loads by description match like the other bundled skills (none is `always`-on, unlike the Family 70 orchestrator), a workspace or managed copy overrides it, `skills.entries.<name>.enabled: false` turns it off, and an `allowBundled` allowlist that omits it is respected.
+
+Shipped skills: `code-ops` (learnings protocol, config tracing, publishing safety), `web-research` (never give up deep research method), `plan-archival` (move finished plans to plans/archive and memory/completed-plans), `todos` (workspace memory/todos protocol), `dashboard` (command center updated after every action), `arch-viz` (sub-agent generated architecture visualization), `content-story` (Story, Concept, Drop framework), `cold-outreach` (Four Pillars cold DM framework), `gcp-logs` (Cloud Run log debugging via gcloud, placeholder service names), `activity-logging` (log outcomes, not tasks, plus the ACTION_LOG), `outlook` (outlook tool quick reference).
+
+Decision table:
+
+| Skill | Decision | Reason |
+|---|---|---|
+| code-ops | ship, converted | generic protocol, anecdote generalized |
+| web-research | ship, converted | generic method, em dashes stripped |
+| plan-archival | ship, converted | personal paths replaced with workspace-relative |
+| todos | ship, converted | owner name and paths replaced |
+| dashboard | ship, converted | names, projects and paths scrubbed |
+| arch-viz | ship, converted | personal paths and projects scrubbed |
+| content-story | ship, converted | frontmatter added, em dashes stripped |
+| cold-outreach | ship, converted | frontmatter added, product names scrubbed |
+| gcp-logs | ship, converted | baked-in service names replaced with placeholders |
+| activity-logging | ship, converted | log names and paths made workspace-relative |
+| outlook | ship, converted | account domain scrubbed |
+| hq-ops | drop | personal repo and GitHub links |
+| brain-backup | drop | personal restic bucket and paths |
+| provider-stats | drop | personal auth profiles |
+| anthropic-sub-proxy | drop | specific deployed proxy setup |
+| reddit-posting | drop | product marketing workflow |
+| comms-identity, email-format, dri-reimbursement, johns-amex-login, insyte, willow, x-original-post, memoryrouter-listings, memoryrouter-seo | drop | owner-only skills |
+| hyperframes, hyperframes-cli, hyperframes-media, website-to-hyperframes, impeccable | exclude | third-party vendored skills |
+| orchestrator | already shipped | Family 70 |
+
+Verifier checks 72.1 through 72.5 cover presence with frontmatter, the generic wording contract (no owner, product or personal names and no `always` flag), no em dashes, the RULES.md skill table, and the packed artifact (the Family 71 gate now also proves all eleven skills are inside the tarball). `tests/bundled-skills.test.mjs` proves every skills chunk loads all eleven from an empty workspace, a workspace copy overrides, `enabled: false` disables, and the `allowBundled` allowlist still wins. `RULES.md` section 5 lists every bundled skill.
+
+Roll back with `npm i -g johns-harness@2026.9.24`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "johns-harness",
-  "version": "2026.9.24",
+  "version": "2026.9.25",
   "description": "John's Harness: a production agent harness that runs autonomous coding agents as one cooperative swarm.",
   "keywords": [
     "ai-agents",

package/scripts/check-packed-artifact.mjs

@@ -10,6 +10,10 @@
 // carries exactly one Family 68 marker and exactly one `tryNative: true`, the tarball version
 // matches the tree version, and no copy is missing.
 //
+// Family 72: the bundled generic skills are also part of the artifact contract. Every one of
+// the Family 72 skills must be present in the tarball with a `name` and a `description` in its
+// frontmatter. The same inspection runs on installed trees.
+//
 // Usage:
 //   node scripts/check-packed-artifact.mjs [package root]        pack the tree, then inspect
 //   node scripts/check-packed-artifact.mjs --tarball <file.tgz>  inspect a tarball (for example
@@ -40,6 +44,36 @@ export const LOADERS10 = [
 
 const count = (text, needle) => text.split(needle).length - 1;
 
+// Family 72: the generic skills shipped as bundled skills. Each must be inside the artifact
+// with valid frontmatter (a `name:` and a `description:` line).
+export const F72_SKILLS = [
+  "activity-logging",
+  "arch-viz",
+  "code-ops",
+  "cold-outreach",
+  "content-story",
+  "dashboard",
+  "gcp-logs",
+  "outlook",
+  "plan-archival",
+  "todos",
+  "web-research",
+];
+
+/** Family 72: verify every bundled generic skill is present with frontmatter. Returns the count. */
+export function inspectSkills72(pkgDir) {
+  const problems = [];
+  for (const name of F72_SKILLS) {
+    const file = path.join(pkgDir, "skills", name, "SKILL.md");
+    if (!fs.existsSync(file)) { problems.push(`${name}: skills/${name}/SKILL.md missing from artifact`); continue; }
+    const text = fs.readFileSync(file, "utf8");
+    if (!/^name: [a-z0-9-]+$/m.test(text)) problems.push(`${name}: frontmatter has no name line`);
+    if (!/^description: .+$/m.test(text)) problems.push(`${name}: frontmatter has no description line`);
+  }
+  if (problems.length) throw new Error(`Family 72: packed artifact is missing bundled generic skills:\n  ${problems.join("\n  ")}`);
+  return F72_SKILLS.length;
+}
+
 /** Inspect an extracted package directory (the `package/` folder of a tarball). Throws on any gap. */
 export function inspectExtracted71(pkgDir, { expectVersion } = {}) {
   const manifestPath = path.join(pkgDir, "package.json");
@@ -62,7 +96,8 @@ export function inspectExtracted71(pkgDir, { expectVersion } = {}) {
     if (m === 1 && o === 1) markers += 1;
   }
   if (problems.length) throw new Error(`Family 71: packed artifact lacks native-first Jiti:\n  ${problems.join("\n  ")}`);
-  return { version: manifest.version, loaders: LOADERS10.length, markers };
+  const skills = inspectSkills72(pkgDir);
+  return { version: manifest.version, loaders: LOADERS10.length, markers, skills };
 }
 
 /** Extract a tarball into a temp dir and inspect it. */
@@ -105,7 +140,7 @@ if (process.argv[1] && path.resolve(process.argv[1]) === fileURLToPath(import.me
       const root = path.resolve(positional[0] || path.join(path.dirname(fileURLToPath(import.meta.url)), ".."));
       result = packAndInspect71(root);
     }
-    console.log(`Family 71: ${result.markers}/${result.loaders} loader copies carry native-first Jiti in ${path.basename(result.tarball)} (version ${result.version})`);
+    console.log(`Family 71: ${result.markers}/${result.loaders} loader copies carry native-first Jiti in ${path.basename(result.tarball)} (version ${result.version}); Family 72: ${result.skills} bundled generic skills present`);
   } catch (error) {
     console.error(error.message);
     process.exit(1);

package/skills/activity-logging/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: activity-logging
+description: Activity and action logging to the workspace. Load when logging work outcomes or recording actions to ACTION_LOG.md.
+---
+
+# Activity & Action Logging
+
+## Activity Logging: Log Outcomes, Not Tasks
+
+### What to Log
+- Features built or meaningfully improved
+- Process/rule changes with real impact
+- Decisions that matter
+- Problems encountered and how they were resolved (if interesting)
+
+### What NOT to Log
+- Fixing your own mistakes (type errors, build failures, typos)
+- Minor tweaks or implementation details
+- Each tiny step of a larger task: consolidate into one entry
+- Routine maintenance
+
+### How to Decide
+Ask: *"Would the user care about this in a weekly review?"*
+- If it's an **outcome** that delivered value, log it
+- If it's **busywork** or cleanup, skip it
+- If multiple items are related, **consolidate** into one entry
+
+### Format
+- **Bold the specific outcome**: then explain what/how/why
+- Entry should make sense in 3 months without extra context
+- Ask: *"What can the user or I do now that we couldn't before?"*
+- Bad: "Improved chart system"
+- Good: "Pie charts now show percentages on slices: added data labels, mobile scroll, theme colors"
+
+### Process
+1. Update today's log: `memory/logs/YYYY-MM-DD.md`
+2. Mirror on the dashboard if one exists
+3. Push to git:
+```bash
+cd <workspace>
+git add -A && git commit -m "Update log" && git push
+```
+
+---
+
+## Action Log (Real-Time Action Tracking)
+
+**Log every action as it happens.**
+
+### Location
+`ACTION_LOG.md` in the workspace root
+
+### What to Log
+Every action you take: simple one-liner titles:
+- Spawned sub-agent for X
+- Generated image for Y
+- Fixed Z in repo
+- Created skill for W
+- Sent message to user about V
+
+### Format
+```markdown
+## YYYY-MM-DD
+
+- Action 1
+- Action 2
+- Action 3
+```
+
+### Rules
+1. **Log immediately**: after completing any action, add a one-liner
+2. **Keep it simple**: title-level, not detailed
+3. **New date section**: start each day with a new `## YYYY-MM-DD` header
+4. **Don't overthink**: if you did something, log it
+
+### Daily Recap (Scheduled Job)
+A daily scheduled job can create `memory/YYYY-MM-DD.md` from:
+1. **Conversation history**: the full journey of what was discussed, decided, built
+2. **Action Log**: the action entries
+
+Format:
+```markdown
+# YYYY-MM-DD: [Creative title capturing the day's vibe]
+
+## The Story
+[2-4 paragraph narrative, journal entry style, captures the day's energy]
+
+## Key Accomplishments
+- Major wins and shipped items
+- Decisions made
+
+## Actions Log
+[Actions from ACTION_LOG.md]
+```
+
+This captures the journey over time: both the story AND the specifics.

package/skills/arch-viz/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: arch-viz
+description: Generate a detailed visual architecture image for any codebase. Spawns a sub-agent that analyzes the code, understands the flow, and creates a cyberpunk-style visualization showing data moving through the system.
+metadata: { "johnness": { "emoji": "🎨" } }
+---
+
+# Architecture Visualizer
+
+Spawns a sub-agent to analyze a codebase and generate a detailed visual architecture image.
+
+## When to Use
+
+- User says "visualize this codebase"
+- User wants an architecture diagram that's creative/visual (not mermaid)
+- User asks for a "picture of how this works"
+- User wants to see "the flow" or "how data moves"
+
+## How It Works
+
+1. You spawn a sub-agent with the task below
+2. Sub-agent analyzes the codebase (entry points, folder structure, docs)
+3. Sub-agent identifies components and data flows
+4. Sub-agent crafts a detailed image prompt
+5. Sub-agent generates the image with an image-generation tool available in the environment
+6. Sub-agent reports back with the image path
+
+## Spawn Template
+
+```
+sessions_spawn(
+  task: "Analyze the codebase and create a detailed visual architecture image.
+
+    Working directory: [PATH]
+
+    Steps:
+    1. Read the codebase - entry points, folder structure, README, any architecture docs
+    2. Identify the core components:
+       - User-facing interfaces (mobile app, web, CLI, API consumers)
+       - Backend services/APIs (frameworks, routes, controllers)
+       - Databases and storage (what data, how structured)
+       - External services (AI providers, payments, auth, third-party APIs)
+       - Key data flows (what goes in, transforms, comes out)
+
+    3. Create a DETAILED image generation prompt following this style:
+       - Isometric 3D, dark background, neon cyberpunk aesthetic
+       - Show data MOVING through the system (binary streams, glowing packets, light pulses)
+       - Each component has INTERNAL DETAIL visible (like a cross-section of a living machine)
+       - Stage the flow left-to-right: Input → Processing → Output
+       - Visual elements to include:
+         * Binary 1s and 0s streaming between components
+         * API calls as light pulses traveling along pathways
+         * Database with visible rows/tables scrolling
+         * Storage with file thumbnails flowing in/out
+         * AI as neural network with synapses firing
+         * Auth as locks/keys/tokens
+         * Payments as cards/coins/tiers
+       - NO TEXT LABELS - everything visually self-explanatory
+       - Color palette: deep purples, electric blues, hot pinks, cyan accents
+       - Style keywords: 'hyper-detailed cyberpunk tech visualization'
+
+    4. Generate the image with an image-generation tool or skill available in your
+       environment, saving it as '[project-name]-architecture.png' at 2K resolution.
+
+    5. Report the image path so it can be sent to the user.
+
+    Be thorough in your analysis. The more you understand the codebase, the better the visualization.",
+  label: "arch-viz-[project-name]",
+  runTimeoutSeconds: 600
+)
+```
+
+## Example Usage
+
+User: "Visualize the <project> codebase"
+
+→ Spawn with the path of the codebase.
+
+User: "Make an architecture image for <project>"
+
+→ Spawn with the path of the codebase.
+
+## Output
+
+The sub-agent will generate an image and report the path. Send it to the user with:
+
+```
+message(action: "send", media: "[image_path]", message: "Here's your architecture visualization")
+```
+
+## Tips
+
+- For larger codebases, the analysis takes longer but produces better results
+- The sub-agent may ask clarifying questions if the codebase structure is unclear
+- Images are saved to the workspace by default

package/skills/code-ops/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: code-ops
+description: "Code operations: learnings protocol, config tracing, publishing safety. Load BEFORE editing the agent runtime or any codebase, starting a coding project, or publishing anything."
+---
+
+# Code Operations: Learnings, Config Tracing, Publishing
+
+## Learnings Protocol: Read First, Write After
+
+**Before starting ANY coding project, read `.learnings/` if it exists. After completing work, write learnings.**
+
+### Before Starting
+1. **Check** if `.learnings/` folder exists in the project root
+2. **If it exists**, read ALL files in `.learnings/` before writing any code
+3. **Internalize** the lessons. They are hard-won insights from past mistakes
+
+### After Completing
+When you discover something important or finish a project:
+1. **Create** `.learnings/` folder if it doesn't exist
+2. **Write** a learnings file: `.learnings/YYYY-MM-DD-brief-topic.md`
+3. **Include:**
+   - What went wrong / what we learned
+   - Root cause
+   - The fix
+   - How to prevent it next time
+
+### Format
+```markdown
+# [Topic]: Learnings from YYYY-MM-DD
+
+## What Happened
+[Brief description of the issue/discovery]
+
+## Root Cause
+[Why it happened]
+
+## The Fix
+[How we solved it]
+
+## Prevention
+[How to avoid this next time]
+```
+
+### Why
+- Don't repeat the same mistakes
+- Institutional memory lives in the codebase
+- Future you (or other agents) will thank you
+- Learnings compound over time
+
+**Read learnings FIRST. Write learnings AFTER. Always.**
+
+---
+
+## Code Edits: Trace the Full Path
+
+**When editing the agent runtime or any codebase, TRIPLE CHECK the config flow before committing.**
+
+### The Rule
+Before ANY code change that touches config, types, or exports:
+1. **Trace the variable**: follow it through EVERY file it touches
+2. **Check validation schemas**: does the schema need updating?
+3. **Check type exports**: are all functions still exported that should be?
+4. **Check config validation**: will the config loader accept this?
+5. **Build and test**: the build must pass
+6. **Test runtime**: start the gateway and verify it doesn't crash
+
+### What This Prevents
+- Orphaned exports (function removed but re-export left behind)
+- Missing schema fields (config exists but validation rejects it)
+- Type mismatches (compiles but runtime fails)
+- Partial implementations (added feature but forgot plumbing)
+
+### The Checklist (Run Before Every Commit)
+```
+□ Traced all new/changed variables through full code path
+□ Updated schema if adding config fields
+□ Removed orphaned exports if deleting functions
+□ Build passes
+□ Gateway starts without crash
+□ Feature actually works (manual test)
+```
+
+### Why This Matters
+One real incident: a search integration was added without updating the validation schema, and an orphaned export was left behind. Result: the gateway crashed and the agent had to be revived. This is unacceptable. Code changes to your own infrastructure require extra care.
+
+### Anti-Patterns (NEVER do these)
+❌ Add config field but forget the schema
+❌ Remove function but leave the export
+❌ Commit without building
+❌ Trust that "it should work" without testing
+❌ Rush the commit to ship faster
+
+**Every code edit: trace, validate, build, test. No shortcuts.**
+
+---
+
+## Publishing Rules
+
+**Before publishing ANYTHING, verify secrets are excluded.**
+
+### The Rule
+Before publishing to any registry, repo, or public location:
+1. **Check ignore files**: confirm `.env`, secrets, and dev files are excluded
+2. **Preview what's included**: dry-run or list files before publishing
+3. **Look for red flags**: `.env`, config files with keys, anything sensitive
+
+### Pre-Publish Checklist
+```
+□ Ignore files properly configured (.gitignore, .npmignore, .dockerignore, etc.)
+□ Previewed/verified file list before publishing
+□ No secrets in any included files
+□ Version bumped appropriately
+```
+
+### If Secrets Are Published
+1. **Immediately** publish a clean version
+2. **Deprecate/remove** the compromised version
+3. **Rotate** any exposed credentials
+4. **Notify** affected parties if applicable
+
+**Every publish: verify what's included. No exceptions.**

package/skills/cold-outreach/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: cold-outreach
+description: Write cold DMs that get responses using the Four Pillars framework. Use when drafting outreach messages, direct messages, or connection requests for the user.
+---
+
+# Cold Outreach / DM Skill
+
+Write cold DMs that get responses. Uses the Four Pillars framework.
+
+## Required Reading
+
+Before ANY outreach, read the full playbook if one exists:
+- `memory/outreach-playbook.md` in the workspace
+
+## The Four Pillars
+
+Every message must hit all 4:
+
+1. **PERSONAL**: their thesis/worldview (what they REALLY believe)
+2. **RELEVANT**: their current mission (what they're building NOW)
+3. **TIMELY**: recent content (what's top of mind TODAY)
+4. **POWERFUL**: peer energy (you're a collaborator, not a fan)
+
+## The DM Flow
+
+| Step | What to Say | Goal |
+|------|-------------|------|
+| 1. Opener | React to THEIR thing + ask question | Start conversation |
+| 2. Listen | Let them share their pain | Understand their words |
+| 3. "Same" | "yeah same, I built something" | Create curiosity |
+| 4. Wait | They ask "what is it?" | Make them pull |
+| 5. Share | Now give them the product | Favor, not pitch |
+
+## Opener Formula
+
+```
+"[reaction to specific content]. [establish same problem]. [ask what they did about it]"
+```
+
+**Example:**
+> "yo that piece on agents forgetting everything hit hard. been banging my head on the same problem. curious what you ended up doing about it"
+
+## Anti-Patterns (NEVER)
+
+- ❌ Product name in opener
+- ❌ Install commands
+- ❌ "Your audience would love..."
+- ❌ Flattery ("love your content!")
+- ❌ Fan energy ("would you check out...")
+- ❌ Offering before they ask
+
+## Good vs Bad
+
+**Bad (ad energy):**
+> "Hey [name] - been watching your agent coverage. I built [our product], a plugin that gives agents persistent memory. One-liner install. Think your audience would love it."
+
+**Good (peer energy):**
+> "yo that piece on agents forgetting everything hit hard. been banging my head on the same problem. curious what you ended up doing about it"
+
+## Research Requirements
+
+Before writing ANY outreach:
+1. Watch 2-3 recent videos: find their THESIS
+2. Read social presence: what identity are they building?
+3. Find ONE specific thing to react to
+4. Know what they'll likely respond (from research)
+5. Plan your step 3 response
+
+## Output Format
+
+For each creator, produce:
+
+```markdown
+## [Creator Name]
+
+### Research
+- **Thesis:** [what they really believe]
+- **Current mission:** [what they're building now]
+- **Recent content:** [specific thing to reference]
+- **Their solution:** [what they're currently doing about the problem]
+
+### Opener
+> [the DM]
+
+### Expected Response
+> [what they'll likely say]
+
+### Step 3 Response
+> [our "same, I built something" response]
+
+### Step 5 Share
+> [product share if they ask]
+```
+
+## Key Insight
+
+**Make them ask. Never offer first.**
+
+The goal is to create curiosity so strong that THEY pull the product out of you. Then sharing feels like a favor, not a pitch.