shawnclybor
- 37 skills
- 0 followers
- 7 hours ago last updated
- ▌ Ooda · shawnclyborRuns John Boyd's OODA decision cycle as a working protocol on a task the user has explicitly asked to work that way. Requires an Orientation Block — the current model of the situation, what changed since the last cycle, and what evidence would falsify it — before any decision is committed, then returns to Observe after acting. Reasons through a structured-thinking tool, one pass per phase. Invoke only on explicit request — "run OODA", "OODA this", "/ooda", "use the OODA loop", "give this a method" — or when the user opens a long multi-stage piece of work and asks for a method to run it. This skill does not select itself; if it was not asked for, it does not run. For a failure that already happened use five-whys. For pre-deploy robustness review use chaos-engineer.
- ▌ Verify · shawnclyborRun the deterministic verification gate against a PRD's success criteria. Every criterion must map to a check that returns a green/red signal. Use after ralph-implement completes and before the quality-review evaluation stage. Triggers — "verify against the PRD", "run the verification", "check success criteria", "did we hit all the gates", "verify [feature]". Hand-waving green checks is the most common way to ship the wrong thing.
- ▌ Five Whys · shawnclyborRoot-cause analysis protocol for when something breaks or fails unexpectedly. Use when a tool call fails twice, an integration returns unexpected results, a workflow produces wrong output, or any situation where retrying blindly would waste time. Also use when the user says "why did that break", "what went wrong", "debug this", or "figure out why X isn't working." Use proactively — if you catch yourself about to retry the same failing call a third time, stop and invoke this skill instead. Do NOT use for routine errors with obvious fixes (typos, missing params, wrong file path). Use when the failure is surprising or the cause is unclear.
- ▌ Build Prd · shawnclyborCapture what you're building BEFORE writing it. Question-driven discovery that locks the target, success criteria, anchor case (one concrete example with expected outcome), and out-of-scope BEFORE any code, plan, or scaffolding. Output is `.claude/PRPs/{slug}/prd.md`. Use when starting a new skill, plugin, scorer, integration, deliverable template, or any artifact where "done" needs a verifiable definition. Triggers — "PRD for X", "spec out X", "let's plan a new skill/plugin", "build pipeline for X", "what are we actually building", or before any non-trivial build where you've caught yourself about to write code without a target. Pairs with build-probe (next), build-validate, build-plan, build-execute, build-evaluate.
- ▌ Five Whys 2 · shawnclyborRoot-cause analysis protocol for when something breaks unexpectedly. Use when a tool call fails twice, a service returns unexpected results, a workflow produces wrong output, or any situation where retrying blindly would waste time. Triggered by "why did that break", "what went wrong", "debug this", or the Two Strikes Rule. Use proactively — if you catch yourself about to retry the same failing call a third time, stop and invoke this instead. Do NOT use for routine errors with obvious fixes (typos, missing params, wrong file path).
- ▌ Task Plan · shawnclyborDecompose a PRD into a sequenced checkbox task list. Each task is small enough to complete in one focused pass and tied to one or more PRD success criteria. Use after the PRD is accepted and before implementation begins. Triggers — "plan from the PRD", "break this into tasks", "task list for [feature]", "decompose [PRD]", "give me a plan".
- ▌ Build Plan · shawnclyborDecompose a build PRD into an implementation plan. Names mandatory reading with file paths and line ranges, identifies the mirror target to copy structure from, lists step-by-step tasks, and specifies the acceptance test that build-evaluate will run. Plan only — no implementation code is written. Output is `.claude/PRPs/{slug}/plan.md`. Use after build-validate, before build-estimate. Triggers — "plan the build", "decompose the PRD", "implementation plan for X", "/build plan", or any time a PRD exists but no plan does.
- ▌ Prd Writer · shawnclyborWrite a PRD (product requirements doc) for a new feature or non-trivial change. Output is a markdown file with problem statement, binary success criteria, in/out of scope, dependencies, and risks. Use at the start of any work that warrants a quality gate before implementation. Triggers — "write a PRD", "draft a PRD for X", "start with a PRD", "PRD for [feature]", "spec out [feature]". The success criteria written here become the verification gates downstream — they must be binary (yes/no answerable), not vibes.
- ▌ Ralph Loop · shawnclyborRun a Ralph Loop — Stop-hook-driven autonomous iteration on a single prompt. Same prompt re-fed each iteration via a Stop hook that blocks session exit. Claude emits an exact completion-promise string to signal done. Use for well-defined tasks with automatic verification that can run autonomously (overnight, walk-away). Triggers — "ralph this", "ralph loop on X", "autonomous loop on X", "let it iterate until done", "run until completion-promise". Monolithic — one task per loop.
- ▌ Build Probe · shawnclybor bundleTurn a PRD's asserted facts into EMITTED facts. Writes one executable probe per measured claim in the PRD — each prints a single value — plus a lockfile pinning every source the PRD cites. PASS = every probe runs and prints exactly what the PRD says, and no cited source has moved. Runs after build-prd and before build-validate, and re-runs in seconds at every later stage as the drift detector. Use when a PRD asserts a number, a count, a filename, a line reference, or an "every X / none of X" claim. Triggers — "probe the PRD", "prove the anchors", "are the numbers still true", "recheck the sources", "/build probe".
- ▌ Build Polish · shawnclybor bundleThe final stage of a whole build, and the stage that owns done. Once the build's planned versions and increments are finished, build-polish runs the real thing rapidly until it matches its goldens, then marks the deliverable complete; build-evaluate is not run again. Phase 0 is a preflight gate: it writes the definition of done (the release standard, a named golden set with numeric floors, two independent witnesses, the end-user journey) and nothing runs until the owner confirms it. Then up to three rounds: one serialized run of the core function into a frozen snapshot; comparison against the goldens; parallel read-only subagents that check it and walk the user journey; an evidence-gated sequential-thinking checklist deciding whether each anomaly is really a problem; the smallest fix, under a KISS/YAGNI veto and code review. The end check stays small: real results, plus single mutation rows or sets whose output drives a fix. Triggers - polish the build, final polish, get it to done, is it done, /build polish.
- ▌ Build Execute · shawnclyborBounded execution loop for a validated build plan. Hard caps on iterations, edits, and (where applicable) spend prevent runaway loops. Each iteration runs a CONDITIONAL adversarial review (only when the change touches a contract, a pinned constant, a refusal limb, or an unmutated path), applies the edit, measures via parallel fixture runs, and auto-invokes five-whys on stagnation or regression. Calls writing-quality on prose edits. Stops on success, on cap hit, on stagnation, or on regression. Use after Stage 3 is dispositioned (PASS, SKIPPED or WAIVED - recorded either way), before build-evaluate. Triggers — "execute the build", "build it", "iterate the X", "implement the plan". Refuses to start if the probes mismatch, the plan-soundness gate fails, the Stage 3 disposition is unrecorded, or profile preconditions are unmet.
- ▌ Build Estimate · shawnclybor bundleProject a build's remaining effort onto the calendar from MEASURED rates, not guesses. Reads a calibration ledger of past builds (tasks landed per hour under a named process profile), scales by task kind and status, walks the calendar past weekends and holidays, and returns low/mid/high finish dates with a fit verdict against a target date. Two modes — `project` (before or during a build) and `calibrate` (after a build, append the actuals so the next estimate is better). Use when a plan needs its "Estimated effort" section, when someone asks "will this fit by <date>", when the calendar needs reassessing mid-build, or when a build finishes and its actuals should be recorded. Triggers — "estimate the build", "how long will this take", "will we make the date", "reassess the calendar", "record the actuals", "calibrate the estimate".
- ▌ Build Evaluate · shawnclyborVerify a completed build against the PRD's anchor case and success criteria. Runs the acceptance test and anchor-case check (serial across drivers sharing a write root), fans out 2-3 read-only cold-read agents (fresh-eyes, anti-scope-creep, drift-vs-mirror). On FAIL, auto-invokes five-whys for root-cause. On PASS with novel patterns, invokes insight-promotion to codify learnings. Read-only against the built artifact, idempotent — safe to re-run. Use after build-execute reports success. Triggers — "evaluate the build", "did it work", "verify the build", "acceptance test", "is it actually done". Outputs `.claude/PRPs/{slug}/evaluate.md` with a binary verdict.
- ▌ Build Validate · shawnclyborReview a build's PREMISES — the three-to-five things that must be true about the world for the design to be right — once, after build-probe and before build-plan. Not a plan review. Not a per-round gate. Spawns 2-3 reviewers against the premise page and the probe run's UNPROVABLE list, and asks one question: is the frame right. Use when a build's frame is new or contested — a new module whose oracle is not obvious, a schema change that alters what a field MEANS, or a reversal like "we check their sheet" becoming "we produce it". Triggers — "validate the premises", "is the frame right", "check my assumptions before I plan", "/build validate". Do NOT use on a plan, on a repair round, or on a running system.
- ▌ Quality Review · shawnclyborStructured 3-agent quality review using parallel simplifier, adversarial-reviewer, and chaos-engineer agents. Use when evaluating plans, designs, PRDs, architecture decisions, or any proposal before implementation. Three non-overlapping lenses — KISS/YAGNI, evidence/reasoning, robustness/edge cases.
- ▌ Session Output · shawnclybor bundleGenerate a session output — a report of what a working session actually did — in one of two modes. Default mode emits a polished self-contained HTML dashboard (light and dark, validated palette) for a technical decision-maker, a client, or your own record. Plain-language mode, invoked as "/session-output simplify" or by asking for plain English, no jargon, or a readable recap, emits prose instead — what was asked for, what the session did, where things stand now, what is still open, and the recommended next step, in complete sentences that name every subject and referent. Use when the user says "session output", "session report", "summarize this session", "recap what you did", "simplify the output", "explain that in plain English", or "no jargon". Both modes report MEASURED outcomes only, never invented, list the skills and tools used, and run the file-hygiene gate over every file the session touched.
- ▌ Why Diagnostic · shawnclyborA framing diagnostic for "why did this happen?" moments during agent and tool work. Use when the user says "why did this fail", "why did the agent do that", "why is this output wrong", "why isn't this working", or otherwise asks for an explanation of agent/tool behavior. Reads like an incident report — frame the question, surface the assumptions doing silent work, walk the reasoning back, name where the chain honestly ends, point at what to test first.
- ▌ Writing Quality · shawnclyborAudit and rewrite content to remove AI writing patterns ("AI-isms") from deliverables, emails, and any written output. Use whenever generating client-facing or publish-grade content, drafting external emails longer than 3 sentences, writing proposals or reports, or when the user says "clean up the writing", "remove AI-isms", "make this sound less like AI", "audit the writing", "check for AI patterns", or "writing quality check". Also invoke automatically before any deliverable formatting step. If you just wrote or curated content that will go to a client or the public, run this skill on it before finalizing. Adapted from conorbronsdon/avoid-ai-writing v3.3.0 (MIT license).
- ▌ Ralph Implement · shawnclyborImplement a task list with the ralph-loop pattern — run, score, fix, re-run. Generic code-implementation loop (separate from skill-validator which targets skills). Use when executing a plan from task-plan. Triggers — "implement the plan", "ralph the implementation", "work the task list", "iterate on [feature]", "run the implementation loop". Two-strike rule on retries; escalates to `debugger` and `five-whys` on repeated failure rather than masking with a third blind retry.
- ▌ Skill Validator · shawnclyborRalph-loop skill validator. Iteratively runs a target skill against representative inputs in a target repo, scores output against pass criteria, applies fixes, and re-runs until pass or budget exhausted. Use when you need to validate that a skill works as advertised on a real codebase rather than just reviewing the SKILL.md by eye. Triggers — "validate this skill against [repo]", "ralph loop on [skill]", "does this skill work on [target repo]", "run the skill-validator". Read-only against the target repo by default.
- ▌ Writing Quality 2 · shawnclyborAudit and rewrite content to remove AI writing patterns ("AI-isms") from deliverables, emails, and any written output. Use this skill whenever generating deliverable content (Phase 1 curation in any client deliverable skill), drafting client emails longer than 3 sentences, writing proposals or SOWs, creating reports, or when the user says "clean up the writing", "remove AI-isms", "make this sound less like AI", "audit the writing", "check for AI patterns", or "writing quality check". Also invoke automatically before any deliverable formatting step — do not skip. If you just wrote or curated content that will go to a client, run this skill on it before finalizing. Adapted from conorbronsdon/avoid-ai-writing v3.3.0 (MIT license).
- ▌ Graduate Project · shawnclyborGraduate a life-crm project into its own ~/gits dev repo and wire the OKF spine between them. Use when a life-crm project needs its own dev or build space (the move to Claude Code), or the user says graduate this project, spin up a repo for it, give it its own repo, or move it to gits. Scaffolds the repo from clybor-claude-tooling (build) or the ClaudeOS or OKF template (knowledge), writes the spine pointers anchored on the Notion Project ID, flips the life-crm folder to role crm, and registers plus backlinks. Done when check-spine.py and validate-okf.py pass.
- ▌ Meeting Workflow · shawnclyborTransform meeting transcripts (pasted text, .vtt/.srt/.txt uploads, or your meeting tool's export) into structured records — a summary note with decisions and open questions, plus tracked tasks for every action item. Use whenever the user pastes or uploads a meeting transcript, says "log this meeting", "process this transcript", "here are my meeting notes", "what happened in this call", "meeting summary", or "turn this into notes". Handles extraction and structuring, then writes to the record system your project uses.
- ▌ Notion Governance · shawnclyborGovernance for reading and writing the Clybor life-CRM Notion workspace from a build repo. Use whenever a request touches Notion — logging a decision, creating or closing a task, reading project or client state, filing a note or KB entry, or invoking any notion-search / notion-fetch / notion-create-pages / notion-update-page tool. Carries the six databases and the overlay that supplies their IDs, the record-type-to-database mapping that says which one a decision, lesson, event, or commitment belongs in, the per-database title conventions, the relation-replace trap that silently destroys multi-value relations, retrieval routing (enumerate vs locate vs comprehend), the trailing-space property names that fail silently when guessed, and the rule that "what is active" is a filtered query and never a semantic search. Triggers — "log this in Notion", "create a task", "update the project", "what's active", "file this", "check Notion", or any request implying a CRM record should change. Cheap to consult; expensive to
- ▌ Project Bootstrap · shawnclyborGuided install of reusable Claude tooling from the clybor-claude-tooling catalog into a new project. Reads catalog.json, asks up to 4 project-profile questions, proposes a matching install set with rationales, copies assets into .claude/, adds a router row in CLAUDE.md for each one so it is actually reachable, fills the catalog-declared adaptation tokens in one batch-confirm round, and writes a TOOLING.md manifest recording what was installed. Use when the user says "bootstrap this project", "set up claude tooling for this project", "install tooling from the catalog", "what tooling from my catalog fits this project", or "init this repo from clybor-claude-tooling". Works for both Claude Code and Cowork projects.
- ▌ Insight Promotion · shawnclyborPromote a crystallized insight or one-off realization into always-on governance — a CLAUDE.md hard rule, a .claude/rules/*.md section, or a skill SKILL.md addition. Use when the user says "promote this to governance", "add this as a rule", "make this always-on", "codify this", "add to the router", or "this needs to be a rule not a note". Also trigger proactively right after insight-crystallizer when the insight meets promotion criteria (pattern recurred twice or more, describes a governance gap, prevents a known failure mode). Crystallizer captures knowledge; promotion makes knowledge enforceable.
- ▌ Notion Governance 2 · shawnclyborGovernance for the Clybor life-CRM Notion workspace from a build repo. Use whenever a request touches Notion — logging a decision, creating or closing a task, reading project or client state, filing a note or KB entry, or invoking any notion-search / notion-fetch / notion-create-pages / notion-update-page tool. Carries the six databases and their ID overlay, the record-type-to-database mapping (decision, lesson, event, commitment), per-database title conventions, the relation-replace trap that silently destroys multi-value relations, retrieval routing (enumerate vs locate vs comprehend), trailing-space property names that fail silently when guessed, and "what is active" as a filtered query, never a semantic search. Triggers — "log this in Notion", "create a task", "update the project", "what's active", "file this", "check Notion", or any request implying a CRM record should change. Cheap to consult; expensive to replace a relation you meant to append to.
- ▌ Search Governance · shawnclyborGovernance layer for all web search operations in the life-crm workflow. Enforces the mandatory use of Brave Search (`brave_web_search` via MCP) and blocks the built-in `WebSearch` tool. Use this skill whenever you are about to perform a web search, look something up online, search for documentation, find current information, or any request that involves querying the web — even if the user just says "look up", "search for", "find out", "google", or "what is the latest on." Also use when you instinctively reach for WebSearch or WebFetch — this skill redirects you to the correct tool. If in doubt about whether a web lookup is involved, use this skill — it's cheap to consult and expensive to use the wrong search tool.
- ▌ Adversarial Review · shawnclybor bundleCoordinated three-lens adversarial review of any target — a PRD, a build plan, a validation report, code, or a freeform proposal. Spawns chaos-engineer, simplifier and adversarial-reviewer in parallel against non-overlapping questions, grades every finding against a rubric fixed BEFORE the agents run, defers the machine-decidable classes to a mechanical checker, and tracks the review process's own drift across runs so it cannot ratchet indefinitely. Use when a proposal, plan or document needs adversarial scrutiny before it is committed to. Triggers — "adversarial review", "review this plan", "tear this apart", "what's wrong with this", "review before I commit", "/adversarial-review". Do NOT use for a routine code diff (use code-review) or a build plan's pre-execution gate (use build-validate, which this complements rather than replaces).
- ▌ Promote To Tooling · shawnclyborReview a tooling change made in a working repo (new skill, script, rule, hook, template, or workflow fix) and promote the universal parts into the clybor-claude-tooling master template. Use when the user says "promote to tooling", "add this to the master tooling", "update clybor-claude-tooling", "parlay this into the template", "should this go in the template repo", or right after building or adapting tooling in any project repo. Runs a universality test, diffs against the master counterpart, generalizes project-specific bits, applies the edit, wires references, and flags downstream repos that need a re-sync.
- ▌ Yellow Sheet Corpus · shawnclyborRun the Yellow Sheet chain end to end against ANY matter, from the original PDFs, and read the result honestly. Use whenever someone asks what has been tested end to end, whether a matter produces a usable sheet, how to onboard a NEW matter, or asks to re-run after a code change. Carries the intake mechanism that makes a new matter a JSON file rather than a code change, the one command, the measurement that actually says whether a sheet is usable, the STRUCTURAL vs UNREAD refusal split, and the traps that have produced wrong answers to this question before. Triggers — "what cases have we tested end to end", "run the corpus", "does it work on real matters", "add a new matter", "onboard this packet", "re-run after this change", "which matters produce a sheet".
- ▌ Adversarial Re Read · shawnclyborFirst-pass extraction systematically misses 15–25% of extractable content because LLMs satisfice; this skill is the gate that catches those misses before they ship to a client-facing deliverable. It's a mandatory second-pass adversarial re-read of source material against the synthesis or extraction it produced. Use whenever a workflow extracts content, consumes transcripts, reviews attachments, or fetches documents and that extraction feeds a downstream deliverable. User says: "second pass," "re-read the source," "verify extraction," "what did I miss in the source," "did I capture everything," "diff my extract against the original."
- ▌ Insight Crystallizer · shawnclyborCapture valuable insights, analyses, and decisions from a chat session and file them as persistent markdown so they survive past the current context. Use when a conversation produces something worth keeping — a comparison, a decision with rationale, a research synthesis, a non-obvious debugging finding, a framework. Triggers — "file this", "save this insight", "this is worth keeping", "remember this analysis", "crystallize this", "don't lose this". Also trigger proactively after deep analytical work whose result would help future sessions. Prevents the "forgotten session" problem where valuable thinking evaporates when the chat ends.
- ▌ Governance Skill Template · shawnclyborTemplate for writing a domain-governance skill — the pattern of encoding a domain's tool-selection rules, defaults, known bugs, and pre-write checks as an on-demand skill instead of always-on context. Use when the user says "create a governance skill for {{DOMAIN}}", "codify the rules for [tool/domain]", "we keep making the same mistake with [tool]", or after the same operational failure recurs twice in one domain. Copy this template, replace every token, delete sections that don't apply.
- ▌ Excel Connector Governance · shawnclyborGoverns driving Excel Online (Business) through a Microsoft Copilot Studio agent against SharePoint-hosted .xlsx. Triggers — "Copilot Studio", "Excel Online (Business)", "add a row", "update a row", "delete a row", "connector 502 / BadGateway", "Office Script", "pin the File input", "spreadsheet agent", "SharePoint xlsx agent". Loudest bug — the File pin stores an opaque 34-character drive-item ID and shows no filename anywhere in the UI, so a tool pinned to the wrong workbook fails identically every time, and against a healthy workbook would silently write to the wrong client's file. Resolve every File pin back to a filename before trusting a write. Cheap to consult; expensive to write a row into the wrong client's workbook, or to record a working connector as a permanent limitation.
- ▌ Plugin Builder · shawnclyborBuild, package, and ship a Cowork plugin (`.plugin`) from one or more skills. Covers plugin structure and packaging (zip from inside the plugin dir so `.claude-plugin/plugin.json` sits at the archive root), the mandatory version bump on every rebuild, backing up the prior bundle, the 1024-char SKILL.md description cap, presenting via sandbox paths, marketplace registration, and how PreToolUse hooks behave in Cowork — they fire and hard-block on Bash and Write on both local and cloud, but fail open when the hook script crashes, so the real gate stays in the skill's own script, never only in a hook. Use when creating a new plugin, adding a skill to one, rebuilding or repackaging, wiring a plugin hook, registering in the marketplace, or presenting a `.plugin` for install. Triggers — "build a plugin", "package this as a plugin", "add a hook to the plugin", "rebuild the plugin", "bump the plugin version", "ship a plugin".