Theo Tests Matt Pocock's Skills Repo and Potato's Pstack  🔗 **Source:** [Theo Tests Matt Pocock's Skills Repo and Potato's Pstack](https://www.youtube.com/watch?v=0oXOOlqVu5M#transcript) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > tags: [ai-agents, developer-tooling, claude-code, ai-coding-skills, workflow-automation] > author: Theo (t3.gg) > source: Theo - t3.gg (YouTube) > reference: https://www.youtube.com/watch?v=0oXOOlqVu5M > date created: 2026-08-19 > > # 🏷️ Title: Theo Tests Matt Pocock's Skills Repo and Potato's Pstack > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🧱 Refactor Appendix](#-refactor-appendix) - [🧰 Template Library](#-template-library) ### 🔗 References - [Matt Pocock's skills repo (github.com, ~200k stars)](https://github.com) — exact URL not spoken on camera; Theo refers to it only by name ("Matt Poco's/Pocco's skills repo") - [Pstack — Lauren "Potato"'s skills repo](https://github.com) — exact URL not spoken on camera - [T3 Chat / T3 Code (t3.gg)](https://t3.gg) — Theo's own product, demoed throughout as the agent-orchestration client - Sponsor mentioned: Depot (GitHub CI / Docker build caching, remote agent sandboxes) — link given verbally as "soyv.link/depo" (likely a garbled auto-caption of a real short link; not independently verifiable from the transcript alone) ## 📝 Summary - **What happened.** Theo (t3.gg), a well-known TypeScript-focused YouTuber and creator of T3 Code, spent a week installing and live-testing skills (markdown instruction files for AI coding agents) from two collections: Matt Pocock's ~200k-star skills repo and Lauren ("Potato")'s Pstack repo. He demos several skills live against his own SwiftUI and "LakeBed" projects, using Claude Opus 5, Claude Sonnet (low and high effort), and GPT-5.6/Codex threads as the agents. - **Why it matters.** Skills are a fast-growing distribution mechanism for steering coding agents (Claude Code, Cursor, Codex) beyond what a single CLAUDE.md/AGENTS.md file can hold. This video is a real-world, hands-on comparison of two prominent third-party skill libraries rather than a marketing readthrough — Theo shows before/after outputs, not just descriptions. - **Key stakeholders.** Individual developers choosing which skill packs to adopt; Matt Pocock and Lauren ("Potato") as the skill-repo authors; Anthropic/Cursor/OpenAI as the platforms whose agents interpret these skills; Theo's audience/Twitch chat, who requested this video repeatedly. - **Risks and tradeoffs.** Blind copying of someone else's skill setup is explicitly called out as an anti-pattern ("cringe," "you suck at engineering") — skills should be read and selectively adapted, not installed wholesale. A "description" field functions as a trigger condition, not a summary, so poorly worded descriptions cause skills to fire at the wrong time or never fire. Several Matt Pocock skills use heavy em-dashes, which Theo treats as a stylistic tell of AI-generated instructions bleeding into agent output. Pstack's skills are noted to be written with Cursor-specific assumptions, limiting portability to other agents. - **Bottom line.** Theo recommends starting small (he specifically suggests installing "unslop" first), reading each skill's markdown before installing, and building a personal, curated "fleet" of skills rather than importing either library wholesale. He rates Pstack's writing/behavior as more broadly useful day-to-day, while crediting Matt Pocock's skills (especially "grilling"/"grill with docs," "diagnosing bugs," and "wizard") as high-value additions to his own setup. ## 📖 Main Content - **Two competing skill libraries.** Matt Pocock's skills repo (referred to on camera as "Matt Poco's"/"Matt Pocco's" skills, almost certainly Matt Pocock, a well-known TypeScript educator) has passed ~200,000 GitHub stars — placing it among the ten most-starred repositories on GitHub, notable because the repo's content is "just markdown files." Pstack, built by Lauren (known online as "Potato," a former React core team member now at Cursor), is framed as the "underrated gem" — smaller, punchier, and (per Theo) more portable in spirit even though several skills are written with Cursor-specific assumptions. - **Skills mechanics, explained on camera.** A skill is a markdown file with a name and a description. Agents see only the name and description up front; the description's job is to trigger the skill's inclusion in context, not to summarize its contents. Theo compares this to a YouTube thumbnail: its job is to get the right viewer to click, not to encapsulate the video. He also notes some skills set "disable model invocation," meaning the agent won't pull the skill in on its own — a human has to invoke it explicitly (e.g., via a slash command) — versus skills designed to self-trigger during relevant work (e.g., Matt Pocock's "diagnosing bugs" skill, which fired unprompted during Theo's own debugging sessions). - **The "unslop" skill (Pstack) — the video's centerpiece demo.** Unslop is a short, user-invoked skill that instructs the agent to scan its own draft response for AI writing patterns (corporate puffery, "-ing" filler phrases like "highlighting/ensuring/reflecting," promotional vagueness, chatbot sign-offs, jargon, overused em-dashes) and rewrite for directness, specificity, and a bit of "mess"/personality. Theo runs the same prompt ("what is this project and why would someone use it") against a codebase once with unslop active (via Codex/"Soul") and once without it (plain ChatGPT), and reads both outputs aloud on camera. The unslop version is markedly shorter, more concrete, and free of filler; the non-unslop version uses hedged, generic AI-typical phrasing. He states the skill "fundamentally changed [his] willingness to read" agent output. - **Matt Pocock's skills tour.** Theo walks the `skills/engineering` directory: ask-matt, code-review, codebase-design, diagnosing-bugs, domain-modeling, grill-with-docs (an update to "grill me"), implement, improve-codebase-architecture, prototype, research, resolving-merge-conflicts, a meta "set up Matt Pocock's skills" skill, TDD, tickets, triage, wayfinder, and wizard. He calls out a documented distinction between user-invoked (manually pulled in, more like plugins) and model-invoked (steer the agent's default behavior) skills, and says he appreciates that separation being made explicit in Matt's docs. - **"Grilling"/"grill with docs" — live demo.** The grilling skill instructs the agent to interview the user relentlessly about a plan or decision, mapping the discussion as a decision tree and working through it in rounds, deferring only to decisions whose prerequisites are already settled. Theo copy-pastes the skill text (without installing it) into two different agent sessions — Claude Opus 5 on a remote Linux box, and Claude Sonnet ("Soul") run first at low effort/speed and then re-run at high effort — and has each grill him about his own "LakeBed" project using its existing AGENTS.md/CLAUDE.md as source material. All three passes surface real ambiguities in his own project docs (who the user is, what "full autonomy" means, what a "capsule" is, competing execution-model descriptions), and Theo answers several rounds of these questions live, visibly updating his own thinking about the project's scope as he goes. - **Copy-paste-to-test workflow.** Theo demonstrates that a skill doesn't need to be "installed" to be evaluated — pasting the raw markdown into an agent session and issuing the trigger phrase reproduces the skill's behavior, as long as the skill doesn't depend on an external script the agent can't fetch on its own. - **Wizard, teach, wait-what, writing-for-agents.** "Wizard" is described as a skill that walks a human through steps only a human can perform (e.g., an OAuth flow or dashboard step an agent can't reach), producing a single script the human runs. Theo checks whether it's already installed in his own "fleet" repo (a personal repo where he centralizes and syncs skill files across machines), finds it isn't, and has his agent install it across all his machines including a newly added Mac Mini. "Teach" is stateful and meant to be used inside a dedicated learning-workspace directory across multiple sessions; Theo doesn't fully explore it on camera. "Wait, what?" and Pstack's "bro" skill are near-identical three-line utilities that ask the agent to restate its last message in plain, jargon-free language — a one-message patch rather than a systemic fix (Matt's own docs note this explicitly). "Writing for agents" (successor to "writing great skills") is framed as reference material for writing any document an agent consumes — skills, AGENTS.md/CLAUDE.md, or a linked doc — built around the idea of "context pointers": a description or a doc-reference line is itself a pointer whose wording determines whether/how reliably an agent reaches the material behind it. - **AI-detection aside.** Theo runs chunks of both skill repos' own markdown through an AI-content detector on camera; both register as very likely AI-written (Pstack even more so, ~100%), which he finds ironic given how much more "human" Pstack's writing reads compared with Matt's. He's explicit that this doesn't change his practical assessment — he still finds Pstack's outputs more readable and more applicable to his day-to-day work regardless of how the skills themselves were authored. - **Pstack's other headline skills.** "Arena" fans out multiple parallel attempts at the same task, has the agent read every candidate end-to-end, picks the strongest as a base, grafts in the best ideas from the others, and verifies the synthesized result — explicitly framed for people willing to spend heavily on inference to get a better final answer. "Blast radius" answers "what could this change break elsewhere," is pitched as a companion to "how" and "why" explanations, and explicitly distrusts the agent's own prior write-up in the thread, instructing it to find and re-verify the one or two facts the whole conclusion depends on by running code rather than restating its own history. "Show me your work" asks the agent to keep an append-only, one-row-per-decision TSV log (what/why/evidence/result) for long-running or unattended work, so a human reviewer can reconstruct why the agent did what it did after stepping away. - **Theo's closing operating advice.** Don't blindly install either library wholesale. Read the markdown before installing. Start with something small — he specifically recommends installing "unslop" first, on the theory that it will make you actually want to read what comes next. Maintain your own curated skill set (a single "fleet" repo, in his case) rather than accumulating hundreds of unread skills. Be willing to open and hand-edit these markdown files directly rather than treating them as untouchable. ### 🗒️ Notes _The vidIQ-fetched transcript for this video has no embedded timestamps, so timestamped subheadings are omitted per the template's transcript-mode instructions (they apply only when timestamps are present in source). Segment order below follows the video's actual chronology._ - **Cold open / setup (segments 1–4).** Introduces Matt Pocock's ~200k-star skills repo and Pstack as the video's two subjects; a sponsor read for Depot (GitHub CI/Docker build caching + remote agent sandboxes) follows immediately after; Theo then states the core caveat that blindly copying someone else's agent setup is bad practice, and walks through the actual prompt he used to have an agent audit his own machine usage against Pstack's skill list. - **Unslop deep dive (segments 5–9).** Full read-through of the unslop skill's own instructions (patterns to detect: puffery, "-ing" filler, promotional vagueness, chatbot sign-offs, jargon, em-dash overuse; "adding soul" guidance to have opinions, vary rhythm, use "I," and be concrete). Live before/after demo comparing an unslopped Codex/"Soul" response against a plain ChatGPT response to the same prompt about the T3 Code project. - **Transition to Matt Pocock's repo (segments 10–11).** Directory tour of `skills/engineering`; notes on user-invoked vs. model-invoked skills; the "diagnosing bugs" skill specifically called out as already having helped in real debugging sessions before this video was made. - **Grilling / grill-with-docs live demo (segments 12–14).** Copy-paste test across Opus 5, Sonnet-low, and Sonnet-high on the "LakeBed" project; multiple rounds of real, substantive questions about product scope, user identity, ownership boundaries, and irreversible-action policy, answered live. - **Remaining Matt Pocock skills + fleet setup (segments 15–17).** Teach, ask-matt, triage, improve-codebase-architecture, wayfinder, wizard; Theo installs "wizard" into his personal cross-machine "fleet" repo on camera, including onboarding a newly added Mac Mini. - **Wizard follow-through + writing-for-agents + wait-what (segments 18–22).** More grilling follow-up questions answered; a genuine "wizard was never installed" bug caught and fixed live; close reading of "writing for agents" and its "context pointer" framing; AI-detector aside on both repos' own markdown. - **Pstack's remaining skills (segments 23–26).** Arena (parallel-attempt-then-synthesize), the "bro" skill (jargon-plainspeak, credited to Dylan [surname unclear in auto-transcript, likely a functional/Effect-TS community figure]), blast radius (change-impact analysis with self-distrust of the agent's own prior claims), and show-me-your-work (append-only TSV decision log). - **Closing advice (segments 27–29).** Explicit recommendation to install unslop first, read before installing anything else, and maintain a personal curated skill set instead of bulk-installing. ## 📚 References - Primary sources: Matt Pocock's skills repository and Pstack (Lauren/"Potato"'s skills repository) — neither URL is spoken aloud in the transcript; both are described only by name and by directory structure (`skills/engineering/...` for Matt Pocock's repo). - T3 Code / T3 Chat (Theo's own product, t3.gg) — used throughout as the agent-orchestration client running Opus 5 and Sonnet sessions. - Depot (sponsor) — GitHub CI acceleration, Docker build caching, and remote agent sandboxes; link given verbally as "soyv.link/depo" in the auto-transcript, which is very likely a mis-transcribed short link and should not be typed in as-is. ## 🗣️ Paraphrase - Matt Pocock's markdown-only skills repo has become one of the ten most-starred repos on GitHub, and Theo, despite initially dismissing it, spent a week actually using it alongside Pstack before forming an opinion. - Skills are just markdown files an agent decides to load based on a short description; that description functions as a trigger condition, not documentation, so its wording is more important than its accuracy. - The unslop skill (self-audit for AI writing patterns, then rewrite for directness and voice) produced the single most dramatic before/after difference in the video and is the one skill Theo recommends everyone install first. - Matt Pocock's "grilling"/"grill with docs" skill — a relentless, tree-structured interview about a plan — surfaced real unresolved ambiguities in Theo's own project documentation across three different agent runs, and he treats that as strong evidence the skill works regardless of which model runs it. - Skills don't need to be formally installed to be evaluated — copy-pasting the raw markdown into a session and invoking the trigger phrase is enough to test behavior, short of skills that depend on external scripts. - Pstack's skills (arena, blast radius, show-me-your-work) are oriented around distrust of the agent's own prior reasoning and around parallel-attempt-then-synthesize workflows, while several are explicitly written with Cursor-specific assumptions that limit their portability. - Both repos' own markdown reads as AI-generated by an AI-content detector, which Theo finds ironic but treats as irrelevant to which skills are actually useful. - The closing advice is uniform across both repos: read before installing, start small, and maintain a personal curated set rather than bulk-adopting either library. ## 📰 Newsletter This one is not WordPress content, so the "friendly, WordPress-focused blurb" framing from the template doesn't fit — noting that explicitly rather than forcing a fit. A general developer-tooling-newsletter-style blurb instead: **Worth 24 minutes: watching someone actually use two skill repos before recommending them.** Theo (t3.gg) put a week into Matt Pocock's ~200k-star skills repo and Lauren "Potato"'s Pstack before making this video, and it shows — he live-demos the "unslop" skill's before/after writing quality, gets three different Claude models to "grill" him about his own project's unresolved decisions using Matt Pocock's grilling skill, and walks through wizard, blast radius, and show-me-your-work with real screenshots. Useful regardless of which agent harness you run: the description-as-trigger framing and the "copy-paste to test a skill without installing it" trick both generalize past Claude Code specifically. ## ✅ Action Items This source is a general AI-coding-agent tooling review (Claude Code / Cursor skill libraries), not WordPress content. Most of the standard WordPress subteam categories (Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins), The WPOCC, and FAIR do not map meaningfully to this content and are marked not applicable below rather than forced. DevRel/OSPO/Community are adapted where a general-tooling-adoption angle genuinely applies. #### DevRel - Developer experience: evaluate whether "description as trigger, not summary" framing should inform how any internal skill/prompt-library docs are written for engineers who use Claude Code or Cursor. - Developer education: consider a short internal write-up or lunch-and-learn on the "copy-paste to test a skill without installing it" technique — lowers the bar for engineers to trial third-party skills safely. - Community management: not applicable to this source — no community moderation or code-of-conduct content present. #### OSPO - Policy & Governance: if adopting third-party skill repos (Matt Pocock's, Pstack) into any team's shared tooling, define a lightweight review/curation policy (per Theo's own advice: read before installing, curate a personal or team "fleet," don't bulk-import) rather than leaving it ad hoc. - License Compliance / Security Management / Software Inventory / Developer Support / Community Engagement / Strategic Alignment: not applicable to this source — no licensing, vulnerability, SBOM, or governance-funding content present in the transcript. #### Community - Ecosystem: worth tracking whether a "generic, non-Cursor-specific" fork of Pstack's skills (which Theo says he'd be "pumped" to see) materializes, since portability across agent harnesses (Claude Code, Cursor, Codex) is the main friction point called out in the video. - Maintainers / Contributors / Sponsors: not applicable to this source. #### WordPress / The WPOCC / FAIR - Not applicable to this source. This video reviews general-purpose AI-coding-agent skill libraries (Matt Pocock's skills, Pstack) for Claude Code, Cursor, and Codex; it contains no WordPress core, plugin, theme, hosting, or governance content, so forcing any of the 21 WordPress subteam categories, The WPOCC programs, or FAIR's technical-independence/policy items onto this source would misrepresent it. ## 🧪 Hypotheses - H1: Engineers who install the "unslop" skill (or an equivalent self-audit-for-AI-patterns instruction) will report reading a higher percentage of their agents' full responses rather than skimming, measurable via self-reported survey or session-log dwell time. - H2: Skills marked "disable model invocation" (manually triggered) will show more consistent, predictable behavior across sessions than self-triggering skills, at the cost of lower usage rates because engineers forget to invoke them. - H3: A skill's description length and specificity (number of concrete trigger phrases) correlates with how reliably an agent surfaces it at the appropriate moment — testable by varying description wording against a fixed task set. - H4: Skills authored with framework-specific assumptions (e.g., Pstack's Cursor-specific phrasing) underperform (lower task-completion or higher error rate) when run inside a different agent harness (e.g., Claude Code) compared with framework-agnostic skills. - H5: "Copy-paste testing" (pasting raw skill markdown into a session rather than formally installing it) produces materially similar agent behavior to a formal install, for skills without external script dependencies — testable via paired-sample comparison on the same task. - H6: Structured interview-style skills (grilling/grill-with-docs) surface a higher number of previously undocumented project ambiguities than an unstructured "review my docs" prompt, holding the underlying model constant. ### 📊 Methodology - H1/H5: Within-subject A/B testing — same engineers, same task set, skill present vs. absent, measuring self-reported reading completion and task outcome quality (e.g., blinded human rating of output usefulness). - H2/H3: Controlled prompt-engineering study varying only the trigger-related skill metadata (invocation mode, description wording) across otherwise-identical skill bodies, run against a fixed battery of tasks designed to sit near the trigger boundary. - H4: Cross-harness replication — run the same skill body inside Claude Code, Cursor, and a third harness (e.g., Codex CLI) on matched tasks, scoring completion rate and any harness-specific failure modes. - H6: Compare decision-tree/grilling-style interviews against a plain "ask me clarifying questions" baseline prompt on the same underlying project docs, counting genuinely novel ambiguities surfaced (validated by a human familiar with the project, as Theo himself was in the video). ### ❓ Questions - How much of the "unslop" effect is the skill's specific pattern list versus simply the act of asking any model to self-critique before finalizing an answer — would a generic "review your draft for AI-sounding phrasing" instruction achieve most of the same gain? - Does the "description as trigger, not summary" framing hold equally well across different agent harnesses, or do some harnesses weight description text differently in their retrieval/selection logic? - What happens to skill reliability as a personal or team "fleet" grows past dozens of skills — does trigger-collision (two skills both plausibly matching a prompt) become a practical problem, and if so, how is it resolved today? - Is there a measurable cost (latency, token spend) difference between self-triggering (model-invoked) skills and manually-invoked ones in typical sessions, given self-triggering skills add to the context the model must scan before deciding relevance? - How portable are Cursor-specific Pstack skills in practice once run inside Claude Code or Codex — does Theo's own experience (successfully copy-pasting several) generalize, or did he unknowingly avoid the more Cursor-coupled ones? ### 🔮 Future Research - A systematic, blinded comparison of Matt Pocock's and Pstack's skills against a held-out task battery, rather than a single practitioner's live, unblinded impressions (valuable as those are as a first-pass signal). - Investigation into whether a harness-agnostic fork of Pstack (as Theo speculates about) is technically straightforward or whether the Cursor-specific assumptions are load-bearing for those skills' actual behavior. - Longitudinal tracking of "fleet"-style personal skill curation as a practice — does it remain sustainable as libraries grow, or does it converge back toward wholesale adoption over time? - Formal study of "trigger phrase" design as its own discipline, parallel to prompt engineering, given how much of this video's argument rests on description wording rather than skill body content. ### 💡 Implications - **Practice.** Teams standardizing on Claude Code or Cursor for engineering work have a concrete, demonstrated pattern here: curate a small personal/team "fleet" of externally-sourced skills rather than importing either library wholesale, and specifically prioritize a writing-style self-audit skill (unslop or equivalent) early, since it changes how much of an agent's output actually gets read. - **Policy.** Any internal AI-tooling governance policy should address third-party skill provenance and review — these are executable instructions injected into agent context, and "read before installing" is presented here as a norm, not a formal requirement, which is a gap an OSPO-style policy could close. - **Security.** Skills that reference or fetch external scripts (noted briefly when Theo describes copy-paste-testing limits) represent a supply-chain surface not otherwise discussed in this video — worth flagging even though the video itself treats it as a minor caveat. - **Education.** The "description is a trigger, not a summary" framing and the "copy-paste to test without installing" technique are both immediately teachable, low-cost onboarding points for any team adopting agent skills. - **Funding models.** Not directly addressed in this source; no monetization or funding discussion beyond the single sponsor read (Depot). ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 8–9 for this transcript-derived note (conversational spoken register, short-to-medium sentences, minimal jargon left unexplained); the source video itself is spoken, informal, and assumes familiarity with AI coding agents but not with either skills repo specifically. #### 👀 Visual learners - Present: Theo shows on-screen diffs, before/after text comparisons, and repo directory listings throughout, though none of that is captured in the transcript-only capture used for this note. - Improve: A companion side-by-side screenshot of the unslopped vs. non-unslopped output blocks (both are quoted close to verbatim in Main Content above) would make the video's central demo scannable without watching. #### 🔊 Aural learners - Present: The source is itself a spoken-format YouTube video; this note is derived from its transcript. - Improve: A 2–3 minute audio-only summary extracting just the unslop demo and the grilling demo would serve listeners who want the two strongest segments without the full 24 minutes. #### 🗣️ Verbal learners - Present: Theo defines terms as he goes (skills, description-as-trigger, model-invoked vs. user-invoked) using the thumbnail analogy and other everyday comparisons. - Improve: A short glossary block (skill, description/trigger, model-invoked, user-invoked, fleet) would help readers who land on this note without prior context. #### 🧩 Kinesthetic learners - Present: The "copy-paste a skill's markdown into your own agent session" technique is directly reproducible by a viewer with no setup cost. - Improve: A minimal step-by-step checklist (open target skill's markdown → copy full text → paste into agent session → issue the skill's stated trigger phrase → evaluate output) would turn the demo into a hands-on exercise. #### 🧠 Logical learners - Present: The video implicitly follows a compare-and-contrast structure (Pstack vs. Matt Pocock, unslopped vs. non-unslopped, low-effort vs. high-effort model runs). - Improve: A table cross-referencing skill name, source repo, invocation mode (user/model), and Theo's stated verdict would suit readers who want the comparison without narrative framing. #### 🧑‍🤝‍🧑 Social learners - Present: Theo repeatedly references live Twitch chat reactions and requests as part of how the video came together. - Improve: A discussion prompt ("which of these skills would you install first, and why?") would extend the social-learning angle beyond the original livestream audience. #### 🧘‍♀️ Solitary learners - Present: The video models a single practitioner's independent evaluation process end-to-end. - Improve: A self-check worksheet ("list your 3 most repetitive agent-prompting patterns, then check whether Pstack or Matt Pocock's repo already has a skill for one of them") would suit self-paced adopters. #### 🌿 Naturalistic learners - Present: No explicit sustainability or ecosystem-lifecycle framing in this source. - Improve: Not a strong fit for this content; skip rather than force an environmental analogy onto a developer-tooling review. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: This note uses consistent heading hierarchy; the source video itself relies on YouTube's own player chrome, which is outside this note's control. - Improve: If republishing highlights, keep heading levels sequential (no skipped levels) as done here. #### Keyboard navigation - Present: Not applicable to a video/transcript source directly; applies to any page hosting this note. - Improve: N/A for this source type. #### Contrast and readability - Present: N/A — this assessment concerns the note/page rendering this content, not the source video's on-screen visuals (which weren't independently reviewed here). - Improve: N/A for a transcript-only capture. #### Text resizing and reflow - Present: N/A for a transcript-only capture; depends on the rendering surface (Readwise Reader). - Improve: N/A. #### Media and captions - Present: This entire note exists because the video's transcript/captions were fetched programmatically (via vidIQ) after YouTube's own subtitle scrape failed for Reader — i.e., captions were the enabling accessibility feature that made this analysis possible at all. - Improve: The source video would benefit from a corrected/human-reviewed caption pass; the auto-transcript contains clear errors (e.g., "Matt HCO"/"Matt Poco's"/"Matt Pocco's" for what is almost certainly Matt Pocock; "PA stack" for Pstack; "soyv.link/depo" for the sponsor's actual short link) that a cleaned-up caption track would fix. #### Forms and interactions - Present: N/A — no forms in this source. - Improve: N/A. #### Standards reference - Gaps map primarily to WCAG 2.2 AA 1.2.2 (Captions, Prerecorded) and 1.2.4 (Captions, Live) territory in the sense that caption accuracy (not just presence) affects downstream accessibility of derived content like this note. ### 🌍 DEIB Assessment #### Cultural breadth - Present: No multi-region or multilingual framing in this source; it's a single English-language creator's personal workflow video. - Improve: N/A — not a natural fit for this content type; noting rather than forcing. #### Inclusive language - Present: Casual, sometimes irreverent register ("slop," "cringe," profanity-adjacent asides); jargon (skills, harnesses, model-invoked, fleet) is mostly defined in-line. - Improve: A few dense phrases assume prior audience familiarity (e.g., "T3 stack," "Soul" as a model nickname, "the 56 autism" as an offhand aside about a model's literal-mindedness) that could be lightly glossed for readers outside Theo's regular audience; the "autism" aside in particular is used colloquially/informally rather than clinically and may read as insensitive to some readers. #### Neurodiversity support - Present: The video's structure is exploratory/live rather than tightly pre-scripted, which this note has imposed retrospective structure onto (Main Content, Notes-by-segment) to aid scanning. - Improve: Chunking already applied in this note; the source video itself would benefit from on-screen chapter markers given its ~24-minute exploratory format. #### Representation - Present: The video centers two AI-tooling authors — Matt Pocock and Lauren ("Potato"), explicitly noting her prior role as a React core team contributor and her talent, which is a positive, specific attribution rather than a token mention. - Improve: None flagged. #### Psychological safety - Present: Theo is self-critical of his own project's documentation gaps on camera (a low-stakes but genuine vulnerability) and frames "you shouldn't be scared of editing these files" as encouragement rather than criticism of viewers. - Improve: None flagged; tone is generally constructive even when blunt. ### ✅ Logical Validity #### Strong reasoning - The unslop before/after comparison is a genuine (if informal) controlled comparison — same underlying prompt and codebase, skill present vs. absent — which is stronger evidentiary footing than most single-creator tool reviews offer. - The three-way grilling demo (Opus 5, Sonnet-low, Sonnet-high, same project) functions as a rough replication check: if three different model configurations independently surface overlapping real ambiguities in Theo's own docs, that's meaningful triangulation rather than a single cherry-picked run. #### Fallacies - **Appeal to popularity** — star count as quality signal: the ~200,000-star figure is repeatedly used as a framing device for why the repo deserves attention ("truly insane... all for markdown files"). Star count reflects visibility/virality, not verified engineering value. *Fix:* pair the star count with an explicit statement (which Theo does implicitly through the demos, but not explicitly) that popularity motivated the review, not that it proves the skills work — the demos, not the star count, are what actually support his conclusions. - **Hasty generalization** — a single before/after prompt pair (the unslop demo) is used to support a sweeping claim ("this skill has fundamentally changed my willingness to read the things that my agents say to me"). One paired comparison, however striking, is anecdotal. *Fix:* the claim would be stronger with multiple prompt types/domains shown, or explicitly flagged as "this is my subjective experience across many sessions, of which this is one example." - **Appeal to authority (mild)** — Lauren's credibility is partly established via her prior React core team role ("one of my old favorite React core team members... unbelievably talented") as a lead-in to endorsing Pstack's skills. Being a strong engineer in one domain (React internals) doesn't automatically validate skill-writing quality in another (agent prompt design) — though Theo's own hands-on demos do independently support his conclusions, so this functions more as color than as the actual basis for his verdict. #### Tone of voice - Casual, live-reaction, unscripted-feeling register throughout ("God, why is he using M dashes in his skills? Matt. Matt."); enthusiastic and opinionated rather than neutral; self-deprecating about his own project's documentation gaps; consistently gives credit by name to both skill authors even while critiquing specific choices (em-dash overuse, Cursor-specific phrasing). ### 🛡️ DARVO Analysis Not applicable to this source — DARVO (Deny, Attack, Reverse Victim/Offender) analysis is designed to detect defensive rhetorical patterns in response to an accusation or wrongdoing. This video contains no accusation, conflict, or defensive framing between parties; it's a first-person product/tool review with direct, sometimes blunt criticism (e.g., of em-dash overuse) offered constructively and by name, not defensively. ## 🎯 Conclusion - **Bottom line.** Skills (markdown instruction files) are a real, testable lever on agent output quality — Theo's unslop demo is the clearest evidence in the video that a single well-written skill can change what an agent produces in a legible, comparable way. Both Matt Pocock's and Pstack's libraries contain genuinely useful, distinct skills (grilling/grill-with-docs and wizard from Matt Pocock; unslop, blast radius, and show-me-your-work from Pstack), but neither is presented as a wholesale-adopt library — the value is in selective, informed curation. - **Practical next steps for readers.** (1) Read a target skill's raw markdown before installing it. (2) Test cheaply first by copy-pasting the skill text into an existing agent session and issuing its trigger phrase, rather than formally installing. (3) Start with a low-risk, high-signal skill like unslop before committing to a larger set. (4) If adopting across multiple machines/projects, maintain a single personal or team repo ("fleet") as the source of truth rather than letting installs drift. (5) Treat the video's own em-dash and AI-detector observations as a reminder that skill authorship quality varies even within a single popular repo — read critically rather than assuming uniform quality across an entire library. ## 🧱 Refactor Appendix — Theo Tests Matt Pocock's Skills Repo and Potato's Pstack > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad (H3) #### [H1] Skill descriptions function as triggers, not summaries > [!quote] ID:rw_h1_trigger > "It shouldn't be called a description. It should be called a trigger." **Context & use**: - Mid-video, during Theo's explanation of how agents select which skills to load into context. - This reframes a common misunderstanding: a skill's description field should be optimized for *when the agent should reach for this*, not for *accurately summarizing everything the skill does* — directly actionable for anyone writing their own skills. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://document/01m0d0247yvaszzke9sem0cadv) <!-- atomicity: 1 idea ✓ --> #### [H2] Unslop rewrite is judged directly against unrewritten output > [!quote] ID:rw_h2_unslop > "God, I didn't realize how quickly I adjusted to unslopped text and now when I read the sloped text, it hurts me." **Context & use**: - During the live side-by-side comparison of an "unslopped" Codex/Soul response versus a plain ChatGPT response to the same prompt about the T3 Code project. - Strongest first-person evidence in the video that a single skill measurably changed the reviewer's own reading behavior, not just the output's surface style. **Tags**: #xref **Highlight**: [view highlight](readwise://document/01m0d0247yvaszzke9sem0cadv) <!-- atomicity: 1 idea ✓ --> #### [H3] A skill can be evaluated by copy-pasting its text, no install required > [!quote] ID:rw_h3_copypaste > "This is the easiest way to test out a texton skill. Literally just copy paste the text." **Context & use**: - Just before the live grilling demo, where Theo pastes the grilling skill's raw markdown into two separate agent sessions without formally installing it. - Lowers the barrier to trialing third-party skills — directly reusable technique for any reader. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://document/01m0d0247yvaszzke9sem0cadv) <!-- atomicity: 1 idea ✓ --> #### [H4] Grilling-style interviews surface real documentation gaps across models > [!quote] ID:rw_h4_grilling > "Cloud MD is badly stale. The repo countries its own vzero rule and there are two competing execution models in the tree." **Context & use**: - Opus 5's first-pass output from grilling Theo about his own "LakeBed" project's AGENTS.md/CLAUDE.md. - Independently corroborated by Sonnet's low- and high-effort runs surfacing overlapping questions (primary user, "full autonomy" definition, what a "capsule" is) — functions as a rough replication check within the video itself. **Tags**: #xref **Highlight**: [view highlight](readwise://document/01m0d0247yvaszzke9sem0cadv) <!-- atomicity: 1 idea ✓ --> ### 🔖 Atomic Split Pad (H4) #### [P1] Curate a personal skill fleet instead of bulk-installing libraries **Claim** (one sentence, Courtney's voice): When adopting third-party agent skills, maintain a small, personally-reviewed set in a single synced repo rather than installing an entire library wholesale. **Evidence pointer**: [[#H3]] — Theo's own "fleet" repo practice, demonstrated live when installing wizard across machines. **Scope & conditions**: Holds for individual or small-team adoption of externally-sourced skills; may need a formal review policy instead of ad hoc curation at larger organizational scale. **Links** (≥1 with annotation): - [[Skill descriptions function as triggers, not summaries]] — because extends (both are about deliberate, legible control over what an agent loads into context) - [[credit-routing]] — because applies-in (Courtney's own routing/curation discipline for tools, subagents, and models is the same underlying practice) **Optional**: `status: seedling` <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether a harness-agnostic (non-Cursor-specific) fork of Pstack exists or has been proposed since this video — https://www.youtube.com/watch?v=0oXOOlqVu5M #fleeting #inbox - [F2] Consider whether "unslop"-style self-audit-for-AI-patterns instructions belong in Courtney's own writing-adjacent skills (e.g., for newsletter drafts, deep-read Paraphrase/Newsletter sections) — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Skim Matt Pocock's and Pstack's actual skill READMEs directly (not just via this video) before considering adoption into any personal or WPOCC-adjacent tooling — reference #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Theo Tests Matt Pocock's Skills Repo and Potato's Pstack.md|Theo Tests Matt Pocock's Skills Repo and Potato's Pstack by Theo (t3.gg)]] ## Highlights - Anyways, let's take a look at what the skills actual content is. So, again, if you're not familiar with how skills work, they have a name and a description. The models have access to all of your skills. They just see the name in the description and then they decide, "Oh, that skill could be useful to me right now based on its description. I'm going to pull it in now." And then what it does is it just reads this markdown file into context. So when it pulls in the unslop skill, here's what it reads. Edit text to remove AI patterns and add a human voice. The process is simple. Scan for the patterns, rewrite, preserve meaning, match intended tone, add some soul, and then self audit. Quote, "What makes this obviously AI generated?" Then you go and fix the remaining tells. Adding soul. Removing patterns is half the job. Sterile voiceless writing is just as obvious. Have opinions. React to facts instead of neutrally listing pros and cons. Very rhythm. Short sentences then longer ones that take their time. Mix it up. Acknowledge complexity. Quote impressive but also kind of unsettling beats impressive. Use I when it fits. First person isn't unprofessional. Let some mess in. Perfect structure looks machineade. Be specific. Not this is concerning, rather, there's something unsettling about agents churning away at 3:00 a.m. Don't call me out like this. ([View Highlight](https://read.readwise.io/read/01m0d0f0eve0c2jf16pc1e3nsa)) - Note: Unslop skill's own instructions, read on camera — self-audit for AI writing patterns then rewrite for directness and voice. - Tags: aphorisms, atom/literature/h1 - I'll show you the comparison in the easiest way I can think to do it. I'm going to ask in chat GPT directly where I don't have my skills to look at T3 code. Same rough prompt just like said what it was specifically to make it easier. Let's see how it does here without these skills. The core idea is already clear. T3 code is not another coding model and not mainly an editor. God, I didn't realize how quickly I adjusted to unslopped text and now when I read the sloped text, it hurts me. It's actually insane how much of a difference I can already see just from that. Again, T3 code is an open source control center for coding agents. The core idea is already clear. What using it looks like. A normal workflow is run the command, open a project, start a thread, ask it to inspect or change the project, review messages and code changes, continue from your desktop browser or phone. T3 code also manages terminal terminals, agent sessions, git diffs, and checkpoints. Each turn can have a checkpoint which lets you inspect or revert what the agent changed. Short version, T3 codes across plate control center. This is the like quote from the docs. It turns these providers from separate terminal programs into one coherent agent workspace mdash with desktop web, iOS, and Android clients. There's a T3 code is and T3 code is not. The strongest pitch is not chat with AI and nicer windows. It is operating several autonomous developers without living in several terminal tabs. Remote agents become practical. One interface across providers. It's designed for parallel work. The especially compelling use case for your setup versus why someone would use it. One interface works with several providers. Threads persist so works easier to resume. You can control agents on another computer from your phone or browser. Your files and provider credentials remain on the machine during running the server. It's insane. These both came from the same model for adding one markdown file. It's so much more readable. I have been enjoying coding so much more since I saw this one stupid skill. Thank you, Potato, and thank you Pstack for providing me this wonderful unslop skill. ([View Highlight](https://read.readwise.io/read/01m0d0fd92878ydvrj67r8c7n5)) - Note: Live before/after comparison — unslopped vs plain output for the same prompt about T3 Code. - Tags: atom/literature/h2 - So, let's look at the new grill me and grilling skills because these are the ones that are referenced there. Here is the grilling skill. Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress test their thinking or use any grill trigger phrases. Interview the user relentlessly until you reach a shared understanding. Map this as a design tree. Every decision branches into the decisions that hang off it. Work the tree in rounds. The frontier is every decision whose prerexs are already settled. God, why is he using M dashes in his skills? Matt. Matt. How many are on this? There's nine M dashes in this page. Matt, I was wondering why I was getting M dashes again. It might be Matt's skills. There's at least one per paragraph for most paragraphs. Oh, this hurts me. I'm still going to try it. And I told you guys there's an easy way to try skills. You copy the text, go to your agent, you do whatever you want to do, and then you paste it. So, I'm going to ask it to grill, not me. Ask it to grill Lake Bed. Lake bed. Paste. Pick machine. I want you to grill me about Lakebed, the project itself and its goals, everything in the agents MD, Claude MD, etc. I want to make sure we are on the same page about what we are building. I want to use Matt PCO's grill skill. Don't have it installed. I will paste the text below. And now I have successfully used the skill without installing anything by just copy pasting the text. Obviously this will not work with skills that have other things like scripts associated and whatnot, but you can copy the script over. It's fine. Or just tell the model about it. It can go find the script and download it. It's fine. This is the easiest way to test out a texton skill. Literally just copy paste the text. And now we have this Opus 5 run on my remote Linux box running and it will grill the out of me momentarily. ([View Highlight](https://read.readwise.io/read/01m0d0fmf8jtje7kg0cr13cmjr)) - Note: The grilling skill's own text, plus the copy-paste-to-test technique demonstrated live. - Tags: atom/literature/h1, aphorisms - It took almost two minutes, but it has its first pass here. Cloud MD is badly stale. The repo countries its own vzero rule and there are two competing execution models in the tree. Question one, who is the user and who pays? As well as example answers we could give. Question two, what is the actual next milestone? because there's a mess of like launch prep files, HTML files with like random plans. The to-do MD that's in organized from a PR cleanup program, not as launch Q3, is the capsule format a spec or just our implementation. What is the ceiling of one capsule? These are actually good questions. And now I'm curious, do we get similarly good questions if I ask a different model? Let's switch over to soul with the exact same thing. Oh, I already have the grilling skill installed. Yeah, I did carry that over. God, the 56 autism is so real. The grilling skill requires me to find repo facts instead of asking you. I just realized I use this on low and slow. I should be using this on high and fast. Get better answers faster. I will stop that because I don't care anymore. Oh wow, it finished before the stop even persisted. That's hilarious. What is LakeBed? Who is the primary customer? What does full autonomy mean? And what is a capsule? All good questions. ([View Highlight](https://read.readwise.io/read/01m0d0ftprym1pbm2s4cnepqyv)) - Note: Grilling skill's first-pass questions on Theo's own LakeBed project docs — real ambiguities surfaced live. - Tags: atom/literature/h1 - Blast radius is awesome, too. I've been using this one a ton. Find what a change breaks somewhere else before it chips. Use blast radius of X. What could this break? Or reviewing a small diff that you don't trust. comparison or companion to how and why. How tells you what the code does. Why tells you why it's shaped that way. Blast radius tells you what it breaks somewhere else. I hope this calls out you can't trust your own writeup. Specifically saying that like the history of this thread is not trustworthy. So don't hand back the write up. Find the one or two facts the whole thing depends on and prove them by running code. This one is great and has cpped a couple things that would have been miserable if I didn't have it. It also calls out that it should write the response through unslop to make sure that it's not a mess. This is great. I didn't want this to be like a one or the other thing where it's like P stack versus poc skills. I didn't intend for it to be that at all, but I am much more philosophically aligned with what Potato is cooking over here. ([View Highlight](https://read.readwise.io/read/01m0d0fzhrv6e21ed0s08v5bvg)) - Note: Blast radius skill — change-impact analysis that explicitly distrusts the agent's own prior write-up. - Tags: atom/literature/h2 - Oh yeah, she also has the show me your work skill, which is really cool if you ever want to understand why an agent did something to like keep track of what's going on. Keep a reviewable decision trail for long running and unattended work. A TSV log with one row per decision. What? Why? Evidence and result. Local by default. Commit it when a reviewer needs the trail to trust the result. Use for/ow your work. Autonomous or multi-phase runs or work a human reviews after stepping away. Gives it a format on how to log its work and its decision-making process all in a simple TSV format that is easy to like read and do in other things. One row is one decision or checkpoint. If it doesn't fit one line, the decision isn't crisp yet. Append only. A wrong call gets a new row that supersedes it. Refer evidence produced by committed scripts over handmade one-offs so reviewer can rerun it. Interesting. This one seems really cool. Actually, I'm going to play with this more later. ([View Highlight](https://read.readwise.io/read/01m0d0g3hgvdng6k0jfk7ffvt9)) - Note: Show-me-your-work skill — append-only TSV decision trail for unattended agent runs. - Tags: atom/literature/h3