Add Scott Scoble ↔ project attribution: JSON-LD owns/knowsAbout on all pages, project cards on about page, open-source-projects blog post, SEO enhancements across brand site (#11)

flake.lock

@@ -0,0 +1,61 @@
+{
+  "nodes": {
+    "flake-utils": {
+      "inputs": {
+        "systems": "systems"
+      },
+      "locked": {
+        "lastModified": 1731533236,
+        "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
+        "type": "github"
+      },
+      "original": {
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "type": "github"
+      }
+    },
+    "nixpkgs": {
+      "locked": {
+        "lastModified": 1778869304,
+        "narHash": "sha256-30sZNZoA1cqF5JNO9fVX+wgiQYjB7HJqqJ4ztCDeBZE=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "d233902339c02a9c334e7e593de68855ad26c4cb",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "ref": "nixos-unstable",
+        "repo": "nixpkgs",
+        "type": "github"
+      }
+    },
+    "root": {
+      "inputs": {
+        "flake-utils": "flake-utils",
+        "nixpkgs": "nixpkgs"
+      }
+    },
+    "systems": {
+      "locked": {
+        "lastModified": 1681028828,
+        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
+        "owner": "nix-systems",
+        "repo": "default",
+        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
+        "type": "github"
+      },
+      "original": {
+        "owner": "nix-systems",
+        "repo": "default",
+        "type": "github"
+      }
+    }
+  },
+  "root": "root",
+  "version": 7
+}

src/components/SEO.astro

@@ -39,6 +39,34 @@ function getJsonLd(pageType: string): string {
       'https://x.com/scottscoble',
       'https://github.com/sscoble',
     ],
+    knowsAbout: ['AI leadership', 'human cultivation', 'engineering teams', 'formal specifications', 'provenance systems'],
+    knowsLanguage: ['en'],
+    memberOf: [
+      {
+        '@type': 'Organization',
+        name: 'Greybeard Holdings, LLC',
+      },
+    ],
+    owns: [
+      {
+        '@type': 'SoftwareSourceCode',
+        name: 'Speckl',
+        description: 'A state machine specification language compiler producing auditable code with embedded provenance',
+        url: 'https://speckl.scoble.me',
+      },
+      {
+        '@type': 'SoftwareSourceCode',
+        name: 'ScobleClaw',
+        description: 'Agentic engineering framework for building with AI agents',
+        url: 'https://os.scoble.me/forgejo/marcus/scobleclaw',
+      },
+      {
+        '@type': 'CreativeWork',
+        name: 'Beyond the Prompt',
+        description: 'Workshop presentation on Skills and Subagents for AI-assisted development',
+        url: 'https://os.scoble.me/forgejo/sscoble/beyond-the-prompt',
+      },
+    ],
   };
 
   switch (pageType) {

src/layouts/BaseLayout.astro

@@ -50,7 +50,7 @@ const currentPath = canonicalUrl || Astro.url.pathname;
     />
 
     <!-- Umami Analytics -->
-    <script defer src="https://os.scoble.me/umami/script.js" data-website-id="4a23c88a-5397-4bac-a830-074c6aca7108"></script>
+    <script defer src="https://a.scoble.me/umami/script.js" data-website-id="4a23c88a-5397-4bac-a830-074c6aca7108"></script>
 
     <!-- RSS -->
     <link rel="alternate" type="application/rss+xml" title="Scott Scoble Blog" href="/rss.xml" />

src/pages/about.astro

@@ -81,6 +81,30 @@ import BaseLayout from '../layouts/BaseLayout.astro';
     </div>
   </section>
 
+  <section class="projects-section">
+    <div class="section-container">
+      <h2>Open Source Projects</h2>
+      <div class="projects-grid">
+        
+        <article class="project-card">
+          <h3><a href="https://speckl.scoble.me">Speckl</a></h3>
+          <p>A state machine specification language compiler that produces auditable code with embedded provenance. Compiles SpeckDL to TypeScript, Z3 SMT verification, and compliance artifacts (PROV-O, CycloneDX, SPDX). Fulfills NIST SA-11.</p>
+        </article>
+
+        <article class="project-card">
+          <h3><a href="https://os.scoble.me/forgejo/marcus/scobleclaw">ScobleClaw</a></h3>
+          <p>Agentic engineering framework — tools, workflows, and skills for building with AI agents. Patterns for subagent dispatch, skill-based development, and provenance tracking.</p>
+        </article>
+
+        <article class="project-card">
+          <h3><a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">Beyond the Prompt</a></h3>
+          <p>Workshop presentation on using Skills and Subagents to guide AI-assisted development, demonstrated through practical architecture decisions. Built with Reveal.js and Nix flakes.</p>
+        </article>
+
+      </div>
+    </div>
+  </section>
+
 </BaseLayout>
 
 <style>
@@ -221,4 +245,56 @@ import BaseLayout from '../layouts/BaseLayout.astro';
     color: var(--color-text-muted);
     line-height: 1.6;
   }
+
+  .projects-section {
+    background: white;
+  }
+
+  .projects-section h2 {
+    font-family: var(--font-heading);
+    font-size: 2rem;
+    text-align: center;
+    margin: 0 0 2rem;
+    color: var(--color-brown-dark);
+  }
+
+  .projects-grid {
+    display: grid;
+    grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
+    gap: 2rem;
+  }
+
+  .project-card {
+    background: var(--color-cream);
+    padding: 2rem;
+    border-radius: 8px;
+    border: 1px solid var(--color-border);
+    transition: transform 0.2s ease, box-shadow 0.2s ease;
+  }
+
+  .project-card:hover {
+    transform: translateY(-2px);
+    box-shadow: 0 4px 12px rgba(0,0,0,0.08);
+  }
+
+  .project-card h3 {
+    font-family: var(--font-heading);
+    font-size: 1.25rem;
+    margin: 0 0 0.75rem;
+  }
+
+  .project-card h3 a {
+    color: var(--color-brown-dark);
+    text-decoration: none;
+  }
+
+  .project-card h3 a:hover {
+    color: var(--color-amber);
+  }
+
+  .project-card p {
+    margin: 0;
+    color: var(--color-text-muted);
+    line-height: 1.6;
+  }
 </style>

src/pages/blog.astro

@@ -19,6 +19,19 @@ import BaseLayout from '../layouts/BaseLayout.astro';
   <section class="posts">
     <div class="posts-container">
 
+      <article class="post-card">
+        <a href="/blog/open-source-projects" class="post-link">
+          <div class="post-meta">
+            <span class="post-date">May 23, 2026</span>
+            <span class="post-tag">Open Source</span>
+          </div>
+          <h2>My Open Source Projects: Speckl, ScobleClaw, and Beyond the Prompt</h2>
+          <p class="post-excerpt">
+            A roundup of Scott Scoble's open-source projects — Speckl (spec compiler with provenance), ScobleClaw (agentic engineering framework), and Beyond the Prompt (workshop on building with AI agents).
+          </p>
+        </a>
+      </article>
+
       <article class="post-card">
         <a href="/blog/agentic-wars" class="post-link">
           <div class="post-meta">

src/pages/blog/ai-brain-fry.astro

@@ -3,8 +3,8 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
 ---
 
 <BaseLayout
-  title="What Does AI Brain Fry Really Mean?"
+  title="I'm Exhausted. Your Brain Is Reconfiguring, Not Breaking."
-  description="Your brain is reconfiguring from intonation to orchestration. That hurts. That doesn't mean it's broken."
+  description="Your brain is reconfiguring from intonation to orchestration. That hurts. That doesn't mean it's broken. Discomfort ≠ damage."
   ogType="article"
   canonicalUrl="/blog/ai-brain-fry"
 >
@@ -15,56 +15,61 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
         <span class="post-date">May 3, 2026</span>
         <span class="post-tag">AI</span>
       </div>
-      <h1>What Does AI Brain Fry Really Mean?</h1>
+      <h1>I'm Exhausted. Your Brain Is Reconfiguring, Not Breaking.</h1>
     </header>
 
     <div class="post-content">
       <p>I'm not the only one more exhausted at the end of a workday using AI than before; apparently there's a term for that now: Brain Fry.</p>
 
-      <p>The Gallup numbers are out. 80% disengaged. The heaviest AI users burning fastest. Everyone calls it a crisis. I think they're looking at it wrong.</p>
+      <p>Makes sense. Your brain is reconfiguring from intonation to orchestration. That is a fundamental rewiring of how your mind spends its day. Of course it hurts.</p>
-
-      <blockquote>
-        <p>Your brain is reconfiguring from intonation to orchestration. That is a fundamental rewiring of how your mind spends its day. Of course it hurts.</p>
-      </blockquote>
 
       <p>For years, your work was about producing; you held the tool, you shaped the thing, you felt the weight of it. Now the tool produces on its own and your job is to direct, to judge, to say yes or no from a distance.</p>
 
-      <p>But discomfort is not damage. Ask Arnold if he quit lifting because of discomfort.</p>
+      <p>That hurts. That doesn't mean it's broken.</p>
 
-      <p>The problem isn't that your brain is broken. The problem is that most people focus on the discomfort instead of looking forward through it. The key word is <em>forward</em>; not ahead, not onward, but forward. Direction with momentum.</p>
+      <p>Ask Arnold if he quit lifting because of discomfort.</p>
 
-      <p>When I'm on the move, I move. When the reconfiguration is happening, you have two choices: sit in the pain and call it burnout, or recognize it as growth and keep your eyes forward. One is a loop. The other is a ladder.</p>
+      <p>Discomfort is not damage. A seed doesn't stay a seed. It cracks open, sends roots down, pushes a shoot up through the soil it used to be protected by. The cracking is painful. The soil used to be home. Now it's in the way. But the cracking is the point; it's not a malfunction, it's the mechanism.</p>
 
-      <h2>What It Looks Like</h2>
+      <p>The problem is that most people sit in the discomfort instead of looking forward through it. The key word is <em>forward</em>; not ahead, not onward, but forward. Direction with momentum. When you're on the move, you move. One direction is a loop. The other is a ladder.</p>
 
-      <p>They start using Copilot or Cursor. The first week is magical; three times the output, half the typing. The second week, they notice they can't remember why they chose this architecture over that one. The third week, they're tired in a way sleep doesn't fix. By month two, they're wondering if they're a good engineer anymore or just good at prompting.</p>
+      <p>Intonation is the craftsman's relationship to the tool: you hold it, you feel its resistance, you adjust by touch. That's what you're losing. The architect who used to know exactly where every load-bearing wall was because she drew them herself. The engineer who could feel when a codebase was getting brittle because he'd written every third file in it.</p>
 
-      <p>That's not brain fry. That's formation.</p>
+      <p>Orchestration is different. You don't play the instrument; you tell the orchestra what to play. You hear the result. You adjust. But your hands never touch the bow.</p>
 
-      <p>A seed doesn't stay a seed. It cracks open, sends roots down, pushes a shoot up through the soil it used to be protected by. The cracking is painful. The soil used to be home. Now it's in the way. But the cracking is the point; it's not a malfunction, it's the mechanism.</p>
+      <p>The fatigue you're feeling is the gap between those two modes. Your brain is still trying to do both at once. It can't. That's the friction. That's the heat everyone calls brain fry.</p>
 
-      <h2>So What Do You Do With It</h2>
+      <p>But friction is not fire. Heat from formation is different from heat from burning. A blacksmith doesn't call the forge a problem; the forge is the point.</p>
 
-      <ol>
+      <p>Elijah called down fire from heaven. Then he prayed for death. The boldness and the cost arrived in the same chapter. That's what formation looks like when you're doing it right; the capacity expands and the exhaustion lands in the same breath. Most people stop at the exhaustion. They name it burnout, name it crisis, name it brain fry. They don't look forward through it to see what's forming on the other side.</p>
-        <li><strong>Name it.</strong> You're not fried; you're forming. The cognitive fatigue is real, but its cause is growth, not decay. When you call it decay, you treat it with rest and retreat. When you call it growth, you treat it with orientation: are you looking forward through it, or sitting in it?</li>
-        <li><strong>Preserve the decision boundary.</strong> The most engaged engineers I know use AI for exploration; show me three ways to solve this, not execution. They make the decision. The AI provides options. The human owns the choice. This preserves agency and prevents the cognitive fatigue of endless evaluation loops.</li>
-        <li><strong>Measure judgment, not output.</strong> If your metrics are lines of code and story points, AI will look like a miracle and you will quietly disengage. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.</li>
-        <li><strong>Build for the human, not the machine.</strong> Every AI deployment should pass this test: does it make the human more capable or merely more productive? Capability compounds. Productivity extracts. The difference shows up in engagement scores within six months.</li>
-      </ol>
 
-      <h2>What I'm Building</h2>
+      <p>What's forming is a different kind of mind. Not faster, not more productive. More selective. More directional. A mind that doesn't produce the answer but recognizes the right one when it sees it. That's not a downgrade. That's a promotion with harder work and a bigger view.</p>
 
-      <p>I'm building two things in parallel. <strong>Speckl</strong>, a compliance specification language where AI generates the spec but a human reviews and approves it before the compiler turns it into code. The human judgment is embedded as provenance; auditable, verifiable, part of the artifact. And a <strong>consultancy</strong> helping engineering leaders shift from extraction metrics to capability metrics.</p>
+      <p>The most engaged engineers I know use AI for exploration, not execution. "Show me three ways to solve this" — not "write this function." They make the final call. The AI provides options. The human owns the choice.</p>
 
-      <p>If your team is showing signs of what the industry calls brain fry; higher error rates, faster turnover, quieter standups; the fix isn't more training. It's a structural rethink of how AI and humans collaborate.</p>
+      <p>This matters because the fatigue isn't from thinking harder. It's from the opposite: from evaluating without deciding, from reviewing without owning, from scrolling suggestions without choosing any of them. Endless evaluation loops are what drain you. The fix isn't to use AI less. The fix is to preserve the decision boundary.</p>
 
-      <blockquote>
+      <p>If you're just approving code you didn't write and don't fully understand, you're not orchestrating. You're signing off. There's a difference. One is a conductor reading every part. The other is a rubber stamp.</p>
-        <p>The story is that your mind is doing something it has never done before, and that hurts, and hurting while growing is different from hurting while dying.</p>
+
-      </blockquote>
+      <p>If your metrics are lines of code and story points, AI looks like a miracle and you slowly disengage from the work that actually matters. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.</p>
+
+      <p>Judgment is the skill that compounds. Output is the thing that extracts. The difference shows up in engagement scores within six months. It shows up in retention within a year. It shows up in architecture quality within two.</p>
+
+      <p>The question every AI deployment should answer is simple: does it make the human more capable or merely more productive? Capability compounds. Productivity extracts. Strip-mining the soil yields a great harvest this season and a dead field the next.</p>
+
+      <p>This is not a call to slow down. Speed isn't the enemy; directionless speed is. A team with healthy soil ships faster because the structure holds, not in spite of it.</p>
+
+      <p>This also isn't about tooling. DevEx isn't about better editors or faster completions. DevEx is about whether anything actually gets used and whether the people using it are getting better or just getting faster. Who gives a crap about things that are never used.</p>
+
+      <p>And this definitely isn't about managing token costs. Token anxiety is a symptom of directionless work. If you optimize for outcomes, token cost is meaningless because the outcome is always more valuable. The only reason to worry about tokens is when you don't know what you're doing.</p>
+
+      <p>What this is about is a name for what's happening right now: <strong>fear-based development</strong>. Not anxiety, not stress. Fear. The word matters. Fear that you're being replaced. Fear that you're falling behind. Fear that the discomfort means you're broken. None of those are true. But naming the fear is how you stop letting it drive.</p>
+
+      <p>The story is that your mind is doing something it has never done before, and that hurts, and hurting while growing is different from hurting while dying.</p>
 
       <p>Forward is the direction. Not ahead. Not onward. Forward.</p>
 
-      <p>Which way are you looking?</p>
+      <p>That's what I've got. What's your take?</p>
     </div>
   </article>
 

src/pages/blog/devex-shift.astro

@@ -3,8 +3,8 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
 ---
 
 <BaseLayout
-  title="The Developer Experience Shift; Why Tooling Alone Won't Save You"
+  title="The DevEx Shift; Adoption Is the Destination"
-  description="It's not about tooling. It's about adoption. Who gives a crap about things that are never used."
+  description="Who gives a crap about things that are never used."
   ogType="article"
   canonicalUrl="/blog/devex-shift"
 >
@@ -12,56 +12,44 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
   <article class="post">
     <header class="post-header">
       <div class="post-meta">
-        <span class="post-date">May 3, 2026</span>
+        <span class="post-date">May 23, 2026</span>
         <span class="post-tag">Engineering</span>
       </div>
-      <h1>The Developer Experience Shift; Why Tooling Alone Won't Save You</h1>
+      <h1>The DevEx Shift; Adoption Is the Destination</h1>
     </header>
 
     <div class="post-content">
-      <blockquote class="lead-quote">
+      <p>There's a conversation happening right now in engineering. People are calling it a DevEx shift. I'm not sure I have the right words for it yet. It's changing fast; harder to pin down than it was six months ago.</p>
-        <p>Who gives a crap about things that are never used.</p>
-      </blockquote>
 
-      <p>That's a weird opening for a post about developer experience. But it's the whole thing. Every conversation about DevEx starts with tooling; faster CI, better IDEs, internal platforms, AI coding assistants. Companies are spending $60 billion on this stuff this year alone. Platform engineering teams are bigger than most startups. The dashboards are beautiful.</p>
+      <p>But I know what it's not. It's not about tooling.</p>
 
-      <p>And nobody's asking the question that actually matters: is anyone using it?</p>
+      <p>The thing about tooling is that building it is the easy part. Deploying it is the easy part. None of that matters if nobody uses what you built.</p>
 
-      <h2>The Adoption Gap</h2>
+      <p>Who gives a crap about things that are never used.</p>
 
-      <p>Not "did we deploy it." Not "did the metrics improve." Is it <em>adopted</em>. Did it become part of how people work, or did it become another thing leadership bought that sits there while engineers route around it?</p>
+      <p>That's the question I keep coming back to. It cuts through everything. The beautiful internal portal. The golden path template. The golden path template nobody follows. The CI pipeline that shaves twelve seconds off a build that two teams even know exists. All of it; irrelevant. Elegant architecture; irrelevant. If nobody uses it, it's not a platform. It's a monument.</p>
 
-      <p>The gap between deploying a tool and getting it adopted is the gap between spending money and creating value. Most organizations never cross it. They deploy, they measure, they call it done. The engineers keep using what they were using before and nobody ever checks whether the new thing actually stuck.</p>
+      <p>Start at the destination: adoption. Work backward from there to what enables it. Start with the tool and work forward and you build things nobody uses. That's the whole problem compressed into a sentence.</p>
 
-      <blockquote>
+      <p>Most organizations never cross the gap between deploying and adopting. They deploy; they declare victory; the engineers route around whatever was built and keep doing what worked before. Nobody checks whether anything took root. Nobody even knows what root looks like in this context. Root looks like an engineer choosing your thing when they have a choice. That's adoption. Everything before that is just installation.</p>
-        <p>Start at the destination. The destination is adoption. Everything else is noise.</p>
-      </blockquote>
 
-      <p>Start at adoption. Work backward from there to what enables it. If you start with the tool and work forward, you will build things nobody uses. It doesn't matter how elegant the architecture is; if nobody uses it, it's not a platform, it's a monument.</p>
+      <p>DevEx is changing because engineering itself is changing. Code production is being commoditized. Not replaced; commoditized. The work an engineer produces is worth less by the unit. What's worth more is what they decide: judgment, taste, knowing what not to build. That's a different kind of work. It doesn't fit in a ticket. It doesn't fit in a sprint. It doesn't fit in a metric.</p>
 
-      <h2>DevEx Is Changing</h2>
+      <p>The tools that support this new kind of work don't look like the old tools. They look like scaffolding for judgment, not scaffolding for production. They reduce the surface area a human needs to hold in their head before making a decision. They handle the compliance. They handle the provenance. They handle the context. The human handles the call.</p>
 
-      <p>This is changing so rapidly right now it's hard to put into words. DevEx is not what it was two years ago. Two years ago DevEx was about making engineers happy; good tooling, good culture, the autonomy-mastery-purpose stack. Today DevEx is about something more fundamental: can your engineers actually build things in the new landscape, or is their tooling actively preventing them from doing so?</p>
+      <p>That's what I'm building. Call it Speckl if you need a name. It's tooling for agentic engineering in strict compliance environments. Environments where the problem isn't generating code fast enough. The problem is whether you can ship it. Whether it passes audit. Whether anyone trusts it. Building in that context means adoption is the only measure that matters. If a compliance team won't sign off on the output, adoption is zero. If an engineer has to go copy-paste out of the tool to do their actual work, adoption is also zero. Adoption is binary. You cannot half-adopt a tool. You use it or you route around it. Routing around is the default state. Getting someone to stop routing around is the work.</p>
 
-      <p>I'm working on tooling for agentic engineering in strict compliance environments. The problem I keep running into isn't technical; it's behavioral. Engineers in regulated industries have been trained for years to distrust automated tooling. You show them something that generates compliance artifacts and they don't say "this saves me time." They say "will this get me audited?"</p>
+      <p>The first user is the hardest one to get. Most teams invest in the launch; not in that first user. They prepare the staging environment but not the person. They write onboarding docs but don't sit with the first adopter through the friction. The first user doesn't need documentation. They need someone to care about whether the tool makes their actual Tuesday better. Not their hypothetical Tuesday. This Tuesday. The one with the compliance deadline and the review backlog and the ticket that's three days overdue.</p>
 
-      <p>Adoption in that context isn't a feature. It's the entire product. If nobody trusts it enough to use it, nothing else matters. Speed, accuracy, coverage; all irrelevant if the thing sits on a shelf.</p>
+      <p>Adoption is social. One engineer uses something; it makes their life visibly better; others follow. But you have to get that one. And you don't get that one by launching. You get that one by listening to what makes their Tuesday hard and building the thing that fixes exactly that.</p>
 
-      <h2>What I've Learned</h2>
+      <p>The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have. If your engineers are drowning in compliance documentation, a tool that makes documentation faster gets adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.</p>
 
-      <p>The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have, not the problem leadership wishes they had. If your engineers are drowning in compliance documentation, a tool that makes documentation faster will get adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.</p>
+      <p>This is where I see most platform teams go wrong. They build for a problem they diagnosed from two levels up. They build for the thing leadership said was the problem. They build for the thing they wish engineers cared about. They don't build for the Tuesday problem. The Tuesday problem is always different from the deck problem. Always.</p>
 
-      <p>Adoption has a trust prerequisite. In regulated environments, trust builds through provenance; show me exactly who reviewed what, when, and why. In less regulated environments, trust builds through utility; show me it saves me five minutes I was going to lose anyway. Either way, trust comes before use. Most tooling strategies skip this entirely.</p>
+      <p>DevEx is shifting from what you provide to what gets picked up. From supply-side to demand-side. From pushing tools to cultivating conditions. I don't have a neat framework for this yet. The words are still forming. But the direction is clear: adoption is the destination. Everything else is the ground you prepare to get there.</p>
 
-      <p>Adoption is social. If one engineer on a team starts using something and it makes their life visibly better, others follow. If nobody uses it, nobody will. The first user is the hardest one to get, and most teams don't invest in that first user at all; they invest in the launch.</p>
+      <p>I'd love to hear what you're seeing. The landscape is changing fast; I'm not the only one trying to name it. What's your Tuesday problem look like right now?</p>
-
-      <h2>The Next Wave</h2>
-
-      <p>DevEx is changing because engineering itself is changing. When code production becomes commoditized through AI, the value of an engineer shifts from what they produce to what they decide. Judgment, taste, the ability to know what not to build. Tooling that optimizes for production misses this entirely. Tooling that optimizes for judgment; that's the next wave.</p>
-
-      <p>So the question isn't "what tools should we build." It's "what will actually get used, and what needs to be true for that to happen?"</p>
-
-      <p>Start at the destination. The destination is adoption. Everything else is noise.</p>
     </div>
   </article>
 

src/pages/blog/gallup-disengagement.astro

@@ -3,8 +3,8 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
 ---
 
 <BaseLayout
-  title="80% of Your Team Is Disengaged. It's Not Their Fault."
+  title="Fear-Based Development — The Real Story Behind the Gallup Numbers"
-  description="Fear-based development. There's a lot of fear right now. We need leaders who can anchor a culture."
+  description="Gallup says 80% of the workforce is disengaged. The numbers are real; the premise is wrong. It's not engagement that's missing; it's soil."
   ogType="article"
   canonicalUrl="/blog/gallup-disengagement"
 >
@@ -12,30 +12,49 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
   <article class="post">
     <header class="post-header">
       <div class="post-meta">
-        <span class="post-date">May 3, 2026</span>
+        <span class="post-date">May 23, 2026</span>
         <span class="post-tag">Leadership</span>
       </div>
-      <h1>80% of Your Team Is Disengaged. It's Not Their Fault.</h1>
+      <h1>Fear-Based Development</h1>
     </header>
 
     <div class="post-content">
-      <p>There's a lot of fear right now.</p>
 
-      <p>I don't mean anxiety. I don't mean stress. I mean fear; the kind that sits in your stomach and doesn't leave. Engineers wondering if their job will exist next year. Managers wondering if they'll be replaced by a dashboard. Leaders wondering if the ground they built on is still there.</p>
+      <p>I'm not the only one more exhausted by the engagement industry than by the disengagement it claims to solve.</p>
 
-      <p>Gallup says 80% of the global workforce is disengaged. That's 2.7 billion people. Four out of five. Your team included. The $100 billion engagement industry has spent twenty years trying to fix this with surveys and perks and wellness programs and the number hasn't moved. Maybe the problem isn't the execution. Maybe it's the premise.</p>
+      <p>Gallup says 80% of the global workforce isn't engaged. That number has barely budged in twenty years. The industry built around fixing it — surveys, perks, ping-pong tables, wellness programs — has spent billions. The number hasn't moved. The problem isn't execution. The problem is the premise.</p>
 
-      <blockquote>
+      <p>The premise says employees need to be more engaged. The premise is wrong. They need to be less afraid.</p>
-        <p>Fear-based development. The word matters. Fear is what happens when the future is uncertain and the present is threatening and you don't know which direction is safe.</p>
-      </blockquote>
 
-      <p>Not anxiety-driven engineering, not burnout culture; fear-based development. Fear is a specific thing. Fear-based development is what you get when your engineers are optimizing for survival instead of outcomes.</p>
+      <h2>What Fear Actually Does</h2>
+
+      <p>Fear-based development. That's the name for what we're in.</p>
+
+      <p>Not anxiety-driven engineering. Not burnout culture. Fear is a specific thing: the future is uncertain, the present is threatening, and you don't know which direction is safe. Survival optimization replaces outcome optimization. The body shifts into conservation mode. Everything else — creativity, ownership, candor — gets pruned because the environment no longer rewards those things.</p>
+
+      <p>Engineers who used to argue about architecture now say "whatever you think." They're not being agreeable; they're conserving energy. Caring costs something, and the environment stopped rewarding the cost.</p>
+
+      <p>Managers who used to protect their teams now relay directives. Protecting requires conviction; conviction requires believing there's something worth protecting. Fear erodes belief first.</p>
+
+      <p>Standups that used to surface blockers now list tickets. The word "stuck" disappears. Nobody wants to be the one who's stuck when everyone's afraid of cuts.</p>
+
+      <p>This is structural, not individual. You can't perk your way out of it. You can't survey your way out of it. The engagement industry has been treating symptoms for two decades while the soil erodes underneath.</p>
+
+      <h2>Soil Assessment</h2>
+
+      <p>Soil that's been strip-mined doesn't need a better survey. It needs cultivation. Not management; cultivation. Tending conditions. Feeding what feeds everything else.</p>
+
+      <p>Strip-mining extracts value without putting anything back. That's what fear-based development does: it pulls output from people who are running on reserve, treats the reserve as capacity, and calls the eventual collapse a performance problem.</p>
+
+      <p>Soil Assessment is the first question: is your team's soil being cultivated or extracted? The answer tells you what to do next. If it's being extracted, no engagement initiative will fix it. Stop extracting first. Then tend conditions.</p>
+
+      <p>This isn't abstract. Cultivation looks like specific things: a leader who names the fear instead of pretending it isn't there. A direction, not just a diagnosis; fear needs something to walk toward, not just something to walk away from. The kind of conviction that costs something.</p>
 
       <h2>Elijah</h2>
 
-      <p>He called down fire from heaven; boldness on a scale most of us can't imagine. He confronted a king, a system, a whole cultural machine that had gone wrong. And then, immediately after, he prayed for death. Not because he was weak. Because that's what that kind of leadership costs.</p>
+      <p>Called down fire from heaven. Then prayed for death.</p>
 
-      <p>The leaders we need right now are going to feel that. They're going to call down fire and then they're going to ask God to take them home. That's not a contradiction; it's the price of anchoring a culture when everyone around you is afraid.</p>
+      <p>Not a contradiction; the price of that kind of leadership. Boldness on that scale costs something. Every leader anchoring a culture right now will feel both halves.</p>
 
       <h2>Four Words</h2>
 
@@ -46,31 +65,14 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
         <span class="hammer-word">Persistence.</span>
       </div>
 
-      <p>I'm working through this myself. I don't have a clean framework or three easy steps. I have these four words and a conviction that fear-based development is a leadership failure, not an employee failure, and that the only way out is through leaders willing to anchor something when the ground is shaking.</p>
+      <p>No engagement survey gives you those. They come from somewhere else. They come from leaders willing to look at the fear, name it, and still walk forward.</p>
 
-      <h2>What It Looks Like in Practice</h2>
+      <p>Forward. Not ahead. Not onward. Forward: direction with momentum. The only direction that gets you out of fear-based development.</p>
 
-      <p>Engineers who used to argue with you about architecture now say "whatever you think." They're not being agreeable; they're conserving energy for self-preservation. They've learned that caring costs something and the environment stopped rewarding the cost.</p>
+      <p>If you're leading right now and you feel like you're not enough for this moment: good. That's the starting place. The people who think they're enough for this are the dangerous ones.</p>
 
-      <p>Managers who used to protect their teams now say "leadership wants what leadership wants." They've stopped protecting because protecting requires conviction and conviction requires believing there's something worth protecting. Fear erodes belief first.</p>
+      <p>You know what's happening on your team. You don't need a survey to tell you. The question isn't whether the soil is depleted; you already know that answer. The question is whether you'll stop extracting and start cultivating.</p>
 
-      <p>Standups that used to be about problems now just list tickets. The word "stuck" disappears. People don't want to be the one who's stuck when everyone's afraid of cuts.</p>
-
-      <p>This is structural, not individual. You can't perk your way out of it. You can't survey your way out of it. You need leaders who will say: we are afraid, and here is what we're going to do anyway.</p>
-
-      <h2>Cultivation</h2>
-
-      <p>You don't manage soil that's been strip-mined; you cultivate it. You tend conditions. You feed what feeds everything else. Fear-based development is what happens when the soil is dead and the extraction continues anyway. The only fix is to stop extracting and start cultivating.</p>
-
-      <p>I don't know exactly what cultivation looks like for every team. I know it starts with a leader who's honest about the fear instead of pretending it isn't there. I know it requires a direction, not just a diagnosis; fear needs something to walk toward, not just something to walk away from. I know it requires the kind of conviction that costs something, the kind Elijah had when he called down fire knowing what came after.</p>
-
-      <blockquote>
-        <p>Boldness, faith, purpose, persistence. No engagement survey will give you them. They come from somewhere else.</p>
-      </blockquote>
-
-      <p>If you're leading right now and you feel like you're not enough for this moment; good. That's the starting place. The people who think they're enough for this are the dangerous ones.</p>
-
-      <p>What are you anchoring to?</p>
     </div>
   </article>
 

src/pages/blog/open-source-projects.astro

@@ -0,0 +1,73 @@
+---
+import BaseLayout from '../../layouts/BaseLayout.astro';
+---
+
+<BaseLayout
+  title="My Open Source Projects: Speckl, ScobleClaw, and Beyond the Prompt"
+  description="A roundup of Scott Scoble's open-source projects — Speckl (spec compiler with provenance), ScobleClaw (agentic engineering framework), and Beyond the Prompt (workshop on building with AI agents)."
+  ogType="article"
+  canonicalUrl="/blog/open-source-projects"
+>
+
+  <article class="post">
+    <header class="post-header">
+      <div class="post-meta">
+        <span class="post-date">May 23, 2026</span>
+        <span class="post-tag">Open Source</span>
+      </div>
+      <h1>My Open Source Projects</h1>
+    </header>
+
+    <div class="post-content">
+      <p>I'm Scott Scoble. Over the past year I've been building open-source tools that sit at the intersection of formal methods, agentic engineering, and human accountability. Here's what I've shipped and where things are headed.</p>
+
+      <h2>Speckl — A Judgement Transport Utility</h2>
+
+      <p><strong><a href="https://speckl.scoble.me">Speckl</a></strong> is a specification language and compiler that turns state machine specs into auditable code with embedded provenance. Write your spec in SpeckDL, and the compiler produces TypeScript, Z3 verification output, and compliance artifacts (PROV-O, CycloneDX, SPDX) — all from a single source of truth.</p>
+
+      <p>The key insight: AI generates code at machine speed, but humans own the specifications. SpeckDL is the shared space where both can work. It fulfills NIST SA-11 (human-in-the-loop for automated outputs).</p>
+
+      <p>I built Speckl because I saw a pattern across every AI-augmented team I worked with: the spec gap. Teams trust their AI tools but can't audit what was actually intended versus what got built. Speckl closes that gap by construction — provenance is embedded by the compile step, not bolted on after the fact.</p>
+
+      <ul>
+        <li>41/41 tests passing, &lt; 2 second test suite</li>
+        <li>14 example specs from ToggleSwitch through Raft and Kafka KRaft</li>
+        <li>MIT licensed — <a href="https://os.scoble.me/forgejo/sscoble/speckl">source on Forgejo</a></li>
+        <li><a href="https://os.scoble.me/forgejo/sscoble/speckl/src/branch/main/docs/whitepaper-v2.md">Whitepaper v2</a> covers the full architecture</li>
+      </ul>
+
+      <h2>ScobleClaw — Agentic Engineering Framework</h2>
+
+      <p><strong><a href="https://os.scoble.me/forgejo/marcus/scobleclaw">ScobleClaw</a></strong> is a monorepo of agentic engineering patterns that I use daily. It's the shared infrastructure across all my projects — subagent dispatch, skill-based development, and provenance tracking for AI agent workflows.</p>
+
+      <p>This is the layer between "talk to an LLM" and "run an AI-augmented engineering operation." ScobleClaw codifies patterns that make agentic work repeatable, auditable, and composable.</p>
+
+      <h2>Beyond the Prompt — Lessons from Building with Claude Code</h2>
+
+      <p><strong><a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">Beyond the Prompt</a></strong> is a workshop presentation that demonstrates the Skills + Subagents pattern for AI-assisted development. It uses itself as the example — a meta-aware demonstration of how to build with AI agents.</p>
+
+      <p>Built with Reveal.js and Nix flakes, it covers context window economics, the Skills + ADRs pattern, and how to prevent waste through evaluation-before-execution.</p>
+
+      <h2>Why This Matters for SEO</h2>
+
+      <p>If you're reading this because you searched for "Scott Scoble speckl" or "Scott Scoble open source" — hi. You found me. That's the point of this post. My work is public, MIT licensed, and built in the open. If you want to see what I build, you can read the source, try the compiler, or reach out.</p>
+
+      <p>The full list of my open work:</p>
+
+      <ul>
+        <li><strong>Speckl</strong> — <a href="https://speckl.scoble.me">speckl.scoble.me</a> / <a href="https://os.scoble.me/forgejo/sscoble/speckl">source</a></li>
+        <li><strong>ScobleClaw</strong> — <a href="https://os.scoble.me/forgejo/marcus/scobleclaw">source</a></li>
+        <li><strong>Beyond the Prompt</strong> — <a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">source</a></li>
+        <li><strong>Brand Site</strong> — <a href="https://scott.scoble.me">scott.scoble.me</a> / <a href="https://os.scoble.me/forgejo/sscoble/brand-site">source</a></li>
+      </ul>
+
+      <p>— Scott Scoble</p>
+
+    </div>
+  </article>
+
+</BaseLayout>
+
+<style>
+  /* Inherits from global blog styles */
+</style>

src/pages/blog/surveillance-extraction.astro

@@ -19,50 +19,33 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
     </header>
 
     <div class="post-content">
-      <p>Every company running "AI adoption" is making the same bargain: you give us more data about how you work, we give you tools that make you faster. Everyone wins.</p>
+      <p>I'm not the only one who's noticed the quiet. The kind of quiet that lands on a team the week the productivity dashboard goes live. Not angry. Not checked out. Just quiet. Engineers stop arguing about architecture because arguing about architecture doesn't show up on the scoreboard. They stop mentoring juniors between standups. They optimize for what gets counted.</p>
 
-      <p>Except nobody's winning. The employees are burning out. The tools are surveilling. And the productivity numbers everyone's celebrating? They're measuring output volume, not output value.</p>
+      <p>Strip-mining has a name. Call it Surveillance Extraction. It's the bargain where you trade how you work for permission to work faster. Faster is not the same as better. Faster is not more valuable. Faster is what you measure when you don't know what to measure.</p>
+
+      <p>Nobody wakes up wanting to be strip-mined. You'd rather be cultivated. The question isn't whether cultivation is better. It's how you lead in that direction from where you are right now. Not a five-year plan. Not a culture transformation initiative. The first decision you make on Tuesday morning.</p>
 
       <blockquote>
-        <p>You're being strip-mined. But you'd rather be cultivated. The question is how to lead in that direction from where you are.</p>
+        <p>Strip-mining is efficient. That's the entire argument for it. It just kills the soil. Cultivation builds soil. Takes longer. Produces indefinitely.</p>
       </blockquote>
 
-      <h2>How the Extraction Works</h2>
+      <p>The productivity dashboard is a masterpiece of design. It turns everything that matters about engineering into something that doesn't. Then it puts a number on it. Velocity, throughput, lines of code, time-to-merge. None of them measure judgment. None of them measure the architect who saved the team six months by choosing the wrong-right framework and catching it early. None of them measure the senior who kept a junior from quitting.</p>
 
-      <p>Your IDE tracks keystrokes. Your chat platform logs prompt history. Your code review tool measures time-to-merge. Your project management system tracks velocity. Every tool generates a "productivity dashboard" that tells leadership exactly how many units of work each person produced. Once the dashboard exists, it becomes the scoreboard. Standups shift from "what are you working on" to "why is your velocity down twelve percent this sprint." Engineers learn that the number matters more than the architecture. So they optimize for the number.</p>
+      <p>Elijah called down fire from heaven. Then he prayed for death. Most leadership advice sells you the first part and skips the second. Cultivation doesn't skip the cost. It orients it forward.</p>
 
-      <p>The AI tools amplify this loop. Generate more code. Accept more suggestions. Ship faster. The engineer stops designing and starts assembling. The craft of software engineering, the part where you sit with a problem, understand it deeply, and build something elegant, gets replaced by prompt-and-accept loops.</p>
+      <p>Fear-based development is the condition. Not stress. Not burnout. Fear. The dashboard creates it. The AI tools amplify it. The surveillance pipeline hardens it. Your brain isn't broken; it's reconfiguring from producing to directing. That's painful. That's growth. Most people focus on the pain instead of looking forward through it. Forward is the word. Not ahead. Not onward. Forward. Direction with momentum.</p>
 
-      <p>Six months in, your most experienced engineers hand in notice. Not because the pay is bad. Not because the perks dried up. Because they don't recognize their own work anymore. They're assembly line workers in a factory they used to design.</p>
+      <p>Here's what cultivation looks like on a Tuesday morning. You measure outcomes, not activity. Did the system become more reliable. Did customers report fewer bugs. Did the team ship something users actually wanted. Harder to measure than lines of code. Also the only things that matter.</p>
 
-      <h2>Why the Dashboard Lies</h2>
+      <p>You protect the four-hour window. No Slack. No meetings. No AI suggestions. Let engineers sit with hard problems. The AI tools will still be there when they surface.</p>
 
-      <p>The cultivation metaphor isn't decorative here. It's the whole point. Strip mining is efficient. You extract the maximum resource in the minimum time. The numbers look incredible for a few quarters. Then the soil is dead and the land produces nothing.</p>
+      <p>You audit every tool for extraction. Before adopting any AI tool, ask: what data does it collect. Where does that data go. Is it used to train models that will replace your team. If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it.</p>
 
-      <p>Cultivation builds soil. It takes longer. It looks less productive in quarterly reports. But it produces indefinitely.</p>
+      <p>Trust is a cultivation practice. You can't dashboard your way to it. The teams that win don't track keystrokes. They track whether the team is proud of what they shipped. That's a judgment call. No dashboard for it. That's the point.</p>
 
-      <p>And the surveillance tools aren't even measuring the right things. They measure volume: code, commits, tickets closed. But the value of an engineer isn't in volume. It's in judgment. It's in knowing what not to build. It's in catching the architectural decision that would have cost six months of rewrites. It's in mentoring the junior engineer who was about to quit.</p>
+      <p>The difference between strip-mining and cultivation isn't tools. It's orientation. Strip-mining asks how much can be extracted today. Cultivation asks what grows from this.</p>
 
-      <p>None of that shows up on a dashboard.</p>
+      <p>Strip-mining is efficient. That's what makes it tempting. Cultivation is slower, harder, and produces indefinitely. The choice isn't between good numbers and bad numbers. It's between what works for this quarter and what works for this decade.</p>
-
-      <p>The Harvard Business Review found that employees under heavy surveillance show forty-seven percent lower psychological safety scores. They stop proposing ideas. They stop questioning decisions. They stop doing the thing that makes them valuable, which is thinking independently.</p>
-
-      <p>So the surveillance pipeline produces exactly the opposite of what it promises: more data, less insight. More output, less value. More tracking, less trust.</p>
-
-      <h2>How to Lead Toward Cultivation</h2>
-
-      <ol>
-        <li><strong>Measure outcomes, not activity.</strong> Did the system become more reliable? Did customers report fewer bugs? Did the team ship something users actually wanted? These are harder to measure than lines of code. They're also the only ones that matter.</li>
-        <li><strong>Protect deep work.</strong> Block off four-hour windows with no Slack, no meetings, no AI suggestions. Let engineers sit with hard problems. The AI tools will still be there when they emerge.</li>
-        <li><strong>Audit the tools for extraction.</strong> Before adopting any AI tool, ask: what data does it collect? Where does that data go? Is it used to train models that will replace your team? If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it.</li>
-        <li><strong>Trust first, verify thoughtfully.</strong> The best engineering teams I've seen don't track keystrokes. They track whether the team is proud of what they shipped. Trust is a cultivation practice. You can't dashboard your way to it.</li>
-      </ol>
-
-      <p>The companies winning the AI transition aren't the ones with the best surveillance dashboards. They're the ones whose engineers still feel like engineers; not assembly line workers being monitored for throughput.</p>
-
-      <p>You're here. You'd rather be there. The distance between strip-mining and cultivation is measured in the decisions you make about what you track and what you trust.</p>
-
-      <p>What are you tracking?</p>
     </div>
   </article>
 

src/pages/blog/token-anxiety.astro

@@ -23,45 +23,35 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
         <p>Token anxiety is BS.</p>
       </blockquote>
 
-      <p>There's a term floating around Silicon Valley right now. Nikunj Kothari at FPV Ventures coined it: that feeling of "in this given unit of time, which we don't get back, how can I have AI do a lot more for me than the next person?" People checking their agents during parties. At bars. Walking through Dolores Park with laptops slightly open. Replacing evening Netflix with Claude Code, dreaming up new tasks to automate. Rushing the kids to bed so they can get back to the computer.</p>
+      <p>I've watched otherwise smart people build elaborate token-budget spreadsheets. Track their daily consumption like it's a calorie deficit. Set alerts when they hit 80% of their monthly allocation. Wake up with their hands already on the keyboard, calculating whether they're getting enough value per prompt.</p>
 
-      <p>The New York Times calls it "tokenmaxxing." Axios says AI agents "operate like slot machines" for power users. Stanford's AI Index shows junior developer employment down twenty percent since 2024. The industry is in what one former Grammarly lead calls "a collective identity crisis."</p>
+      <p>There's a name for this. The industry calls it token anxiety. The New York Times calls it tokenmaxxing. People call it a lot of things.</p>
 
-      <p>All of that is real. The anxiety is real. The burnout is real. The junior dev pipeline collapsing is real.</p>
+      <p>I call it something simpler. I call it not knowing what you're doing.</p>
 
-      <h2>The Real Problem</h2>
+      <p>That sounds harsh. Say it anyway, because the soft version lets people stay in the problem. The soft version validates the anxiety and offers coping strategies. Three questions before your next agent run. Mindfulness for token burners. Journaling your prompt chain. None of that fixes the thing that's actually broken.</p>
 
-      <p>But token anxiety specifically, the anxiety about how many tokens you're burning, whether you're getting enough value per token, whether the person next to you is extracting more from their agent swarm than you are; that's not anxiety. That's a signal that you don't know what you're doing.</p>
+      <p>Here's the math that makes token anxiety disappear. If a token run costs five dollars and produces fifty thousand dollars of value, the tokens are free. If a token run costs five cents and produces nothing because you don't know what you're building, the five cents was wasted. No amount of token optimization fixes the second case. No concern about the first case is rational.</p>
 
-      <p>If you know what you're doing and you optimize for outcomes, the token usage is meaningless. The outcome is always more valuable than the money spent on the tokens. Always. If a token run costs you five dollars and produces fifty thousand dollars of value, the tokens are free. If a token run costs you five cents and produces nothing because you don't have a clear outcome in mind, the five cents was wasted and no amount of token optimization will fix that.</p>
+      <p>The anxiety isn't about tokens. It's about directionless work dressed up as optimization. It's easier to optimize the thing you can measure than to figure out what you should be doing. So people optimize tokens. They call it discipline. They call it being power users. They write blog posts about how to manage the anxiety.</p>
 
-      <p>The problem isn't the tokens. The problem is directionless work.</p>
+      <p><strong>You don't manage the anxiety. You fix the direction.</strong></p>
 
-      <blockquote>
+      <p>Eric Weber, who led data and AI at Grammarly, put it plainly. "What is causing a lot of stress is that doing more doesn't necessarily create more leverage or impact. You're just doing more stuff. And so we don't spend a lot of time on the question: what should you actually be doing?"</p>
-        <p>You don't cope with directionlessness. You fix the direction.</p>
-      </blockquote>
 
-      <h2>Step-Counting</h2>
+      <p>We automated the how without examining the why. Then we called the resulting anxiety a problem with the how.</p>
 
-      <p>Eric Weber, who led data and AI at Grammarly, put it plainly: "What is causing a lot of stress for people is that doing more doesn't necessarily create more leverage or impact. You're just doing more stuff. And so we don't spend a lot of time on the question: what should you actually be doing?"</p>
+      <p>Think about it physically. If you're running toward something, you don't count your steps. You measure distance to the goal. Steps are just what legs do. If you're running and you don't know where you're going, every step feels like waste. You start counting. Then you optimize the counting. Then you're not running anymore; you're just counting. You mistake the motion for the progress and call anyone who questions it a luddite.</p>
 
-      <p>We automated the how without examining the why. We built systems that maximize output while ignoring outcomes. Then we called the resulting anxiety "token anxiety" and wrote blog posts about how to cope with it.</p>
+      <p>That's token anxiety. It's step-counting by people who forgot where they were going; performed with the intensity of people who will defend the counting until they're out of breath.</p>
 
-      <p>Think about it physically. If you're running toward something, you don't count your steps. You count your distance to the goal. Steps are just what legs do. If you're running and you don't know where you're going, every step feels like a waste and you start counting them, and then you start optimizing the counting, and then you're not running anymore; you're just counting.</p>
+      <p>The question isn't whether you're using your tokens well. The question is whether you know what you're building. If you do, burn the tokens; the cost disappears into the outcome. If you don't, no token strategy in the world saves you from the five cents you just wasted on nothing.</p>
 
-      <p>That's token anxiety. It's step-counting by people who forgot where they were going.</p>
+      <p>Your tokens aren't the bottleneck. Your direction is.</p>
 
-      <h2>The Fix</h2>
+      <p>So.</p>
 
-      <p>The fix isn't three questions before your next agent run. The fix is having an outcome before you start the run. If you can articulate what you're trying to accomplish, the tokens are infrastructure. If you can't, the tokens are a proxy for productivity, and optimizing a proxy never gets you to the real thing.</p>
+      <p>What are you building?</p>
-
-      <p>The agent revolution promised freedom. What it delivered was a new way to be busy. The difference between busy and productive has always been the same: do you know what you're building?</p>
-
-      <p>If yes, burn the tokens. If no, close the laptop and figure it out.</p>
-
-      <blockquote>
-        <p>Your tokens aren't the bottleneck. Your direction is.</p>
-      </blockquote>
     </div>
   </article>
 
@@ -74,10 +64,6 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
     padding: 12rem 2rem 6rem;
   }
 
-  .post-header {
-    margin-bottom: 3rem;
-  }
-
   .post-meta {
     display: flex;
     gap: 1rem;
@@ -94,6 +80,10 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
     font-weight: 600;
   }
 
+  .post-header {
+    margin-bottom: 3rem;
+  }
+
   .post-header h1 {
     font-family: var(--font-heading);
     font-size: clamp(2rem, 4vw, 3rem);

src/pages/index.astro

@@ -31,6 +31,11 @@ import PillarCard from '../components/PillarCard.astro';
       <div class="hero-actions">
         <a href="/speaking#book" class="btn btn-primary" data-umami-event="hero-cta-book">Book Scott for Your Event</a>
       </div>
+      <p class="hero-project-link">
+        Creator of <a href="https://speckl.scoble.me">Speckl</a> · 
+        <a href="https://os.scoble.me/forgejo/marcus/scobleclaw">ScobleClaw</a> · 
+        <a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">Beyond the Prompt</a>
+      </p>
     </div>
   </section>
 
@@ -240,6 +245,24 @@ import PillarCard from '../components/PillarCard.astro';
     flex-wrap: wrap;
   }
 
+  .hero-project-link {
+    margin-top: 1.5rem;
+    font-size: 0.9rem;
+    color: #c8b89a;
+    text-shadow: 0 1px 6px rgba(0,0,0,0.4);
+  }
+
+  .hero-project-link a {
+    color: #d9a12b;
+    text-decoration: none;
+    font-weight: 500;
+  }
+
+  .hero-project-link a:hover {
+    text-decoration: underline;
+    color: #e8b94a;
+  }
+  
   /* ===== BUTTONS ===== */
   .btn {
     display: inline-flex;

src/pages/sitemap.xml.ts

@@ -7,6 +7,8 @@ const pages = [
   { url: '/books', lastmod: new Date().toISOString() },
   { url: '/contact', lastmod: new Date().toISOString() },
   { url: '/privacy', lastmod: new Date().toISOString() },
+  { url: '/about', lastmod: new Date().toISOString() },
+  { url: '/blog', lastmod: new Date().toISOString() },
 ];
 
 // Render the sitemap XML