founder-skills

Use when designing and implementing a new software feature from scratch — triggers the Fable-plan → implement → review pipeline.

Use when declaring or checking the token budget / model tier for this session. Triggers on: "set effort", "how much budget do we have", "low on tokens", "use opus", "use sonnet", "constrained this week", or any explicit model-tier selection. Can also be called mid-session to downgrade tier when tokens run low.

Generate an implementation-ready Product Requirements Document for a feature: self-clarify the open questions (no user interview), then write a structured PRD — goals, one-session tasks with verifiable acceptance criteria, numbered functional requirements, non-goals — saved to /tasks/prd-<feature-name>.md, ready for the `tasks` skill to convert into an executable plan. Use when the user asks "create a prd", "write a prd for X", "plan this feature", "spec out X", "requirements for X", or after running `build-options` (its Phase 4 hands the winning option here).

Convert a PRD markdown file (typically `/tasks/prd-<feature>.md` from the `prd` skill) into `prd.json` — an ordered, dependency-sorted execution plan where every acceptance criterion is a boolean check an agent can pass or fail without a human. Use when the user asks "convert prd", "create tasks", "prd to json", "generate tasks from prd", or after running `/prd` at the end of the `/market-validation → /build-options → /prd → /tasks` chain.

Map and maintain the founder-skills <-> PlatAtlas integration surface: the fable-org-audit endpoint map (with its known drift against the live worker), the market-validation market-map sink (nodes.json + flows.json into workflow-atlas, shape-valid but load-untested), adoption guidance for PlatAtlas rail agent seats, and the documented-not-executed mirror plan into workflow-atlas's own plugin convention. Use when a maintainer says "how does founder-skills connect to PlatAtlas", "is the org-audit endpoint map still current", "prove the market-map sink", "load the market map into PlatAtlas", "can the rail agents use these skills", "mirror founder-skills into workflow-atlas", or "what drifted on the PlatAtlas side".

Decide WHAT to build after a market is validated: generate divergent build options, score them with an independent judge panel into a weighted decision matrix, adversarially stress-test the top, recommend one (with kill criteria), render a Tufte decision matrix, and hand the winner to the `prd` skill. Use when the user asks "what should I build", "what are my build options", "which option should we build", "decide what to build", or after running `market-validation`.

Use when you need to verify that a customer organization on your platform is healthy and getting full value — a live integration audit that probes real API signals across eight dimensions, not a code review. Triggers on: "audit this org", "is <org> healthy", "health-check the integration", "why does this org feel off", or a scheduled pre-demo / weekly org check.

Validate whether there is a real market for a product idea, end to end: scope questions → a multi-angle web-research workflow with mandatory live-URL verification → a cited evidence pack → a Tufte HTML deck + PDF + PPTX → a build/integrate brief and an emitted market-map graph. Use when the user asks "is there a market for X", "validate demand for", "prove the market for", "should I build X", "market research / competitor + willingness-to-pay evidence for X", or wants a fundable evidence pack.

Domain reference for the Anthropic primitives the founder-skills plugins orchestrate, as used in THIS repo (not a textbook): the Workflow({scriptPath,args}) opt-in pattern and its injected-globals runtime, batched AskUserQuestion with the (Recommended) option first, the Agent() model-tier routing tables (Fable 5 plans/reviews, Opus 4.8 complex, Sonnet 4.6 standard, external executor cheap), output_config.effort vs the Task Budgets beta, /loop and /schedule and Claude Managed Agents scheduling, session-context.md tier persistence, and the canonical Anthropic doc-URL list with re-verify curls. Use when a maintainer asks "what does Workflow({scriptPath}) mean here", "which model implements vs plans", "what is the model routing table", "what's the difference between /effort and output_config.effort", "what is the task budgets beta", "how do these skills schedule recurring runs", "where is the effort tier persisted", "what URLs do these skills cite", or needs to edit any SKILL.md text that mentions Agent, Workflow

How changes to founder-skills are classified, gated, and reviewed: the operator-approved spec -> checkbox plan -> commits-matching-plan-verbatim pipeline, plus the five standing rules (direct-push-to-master with a mandatory local pre-push gate, no GitHub Actions ever, public repo canonical over private claude-skills, prd/tasks rewrite licensed, operator commits / assistants never run mutating git) with the rationale and incident behind each. Use when a maintainer asks "how do I ship a change here", "do I need a spec for this", "can I just push this fix", "why is there no CI", "who commits", "can I edit the site copy", "what's the change process", or before writing any spec, plan, or commit in this repo.

The founder-skills defect chronicle: every known failure in this repo as symptom -> root cause -> evidence -> status, so no maintainer re-fights a settled battle or re-discovers a known trap. Use when a test fails, a command from a README doesn't work, an asset is missing, or you're about to touch .gitignore, add-skill.sh, prd/tasks, the Pages site, or a workflow script. Triggers on: "the tests fail", "FileNotFoundError matrix.template", "no module named pytest", "node --test can't find tests", "is this a known bug", "why is the site claiming X", "has this broken before", "add a defect to the ledger", "what's the status of defect N".

The decision-gated executable campaign that proved and hardened the flagship founder chain (market-validation → build-options → prd → tasks). Phases 0-3 executed 2026-07-02 (template rescue, proving runs, prd/tasks rewrite, site truth-up) — the skill remains the record and the playbook for regressions or a future re-run. Use when a maintainer says "run the proving run", "prove the workflow scripts", "harden the founder chain", "is the flagship chain fixed", "rewrite prd/tasks", "genericize agent-browser", "fix the site oversell", or asks what the current phase/status of the flagship campaign is.

Entry-point map of the founder-skills repo: layout, the four skill groups, the two-session history, quality tiers (golden four vs off-style), the open-defect ledger pointer, and a router table telling you which fs- sibling skill to load for which job. Load this FIRST when starting any maintenance work on founder-skills. Use when a maintainer says "orient me in founder-skills", "what is this repo", "where do I start", "which skill covers X", "map of founder-skills", "how is this repo organized", or begins any founder-skills task without a specific fs- skill already in mind.

The research agenda for founder-skills: four open problems where this repo could advance the state of the art, with why current skill catalogs fail, what asset this repo already holds, the first three concrete steps IN THIS REPO, and a falsifiable milestone for each. Priorities per operator decision 2026-07-02: measured-not-claimed token costs (primary), self-maintaining library, skills-as-product for PlatAtlas, ecosystem growth. Everything here is OPEN or CANDIDATE — nothing is claimed done. Use when a maintainer says "what's the research frontier", "what should we work on next beyond maintenance", "how do we measure token costs for real", "make the token claims honest", "can this library maintain itself", "skills as product", "how do outsiders contribute", or "what would make this repo state of the art".

Edit the founder-skills public surfaces — the Pages site (docs/index.html), the per-plugin READMEs, and the sibling catalog site — without breaking the single-file dark-editorial design system, the fixed README template, benefit-led copy rules, the mandatory attribution footer, or the no-oversell doctrine; includes the currently-open oversell defects and the measured-not-claimed standard for what may be claimed externally. Use when a maintainer says "update the site", "change docs/index.html", "add a card for the new skill", "edit a plugin README", "fix the token-cost chips", "the site oversells", "update the catalog site", "change the footer", or "what are we allowed to claim publicly".

The written house style for founder-skills SKILL.md and README.md files — the style the repo practiced but never wrote down, extracted from the golden four (market-validation, build-options, ecosystem-planning, fable-org-audit): frontmatter rules, trigger-rich descriptions, Phase/Step skeletons, the recurring closer tables, honesty and Tests sections, the README template, and a conformance checklist. Use when a founder-skills maintainer says "does this skill match the founder-skills house style", "review this founder-skills SKILL.md", "write the description/frontmatter for a new skill in this repo", "which skills can I copy from", "style-check this founder-skills plugin", or before editing any SKILL.md or plugin README in this repo. If you are NOT working inside founder-skills, load the public skill-style-guide plugin instead — it is the generic, calibrate-to-your-own-golden-set version.

Recreate the founder-skills working environment from scratch and run or extend its three test suites: the venv procedure (the host Python is PEP-668 externally managed, so the README's test commands fail verbatim), the Node glob-form-only rule for the JS suite, the Function-wrapper harness pattern for testing top-level-await Workflow scripts, how to add a test to each suite, and a symptom-to-triage table for toolchain failures. Use when a maintainer says "run the tests", "pytest says no module named pytest", "node --test can't find the module", "set up the environment", "why do the README test commands fail", "FileNotFoundError matrix.template.html", "how do I test a workflow script", or "add a test for this asset".

The founder-skills non-negotiables with their rationale: planner-never-writes-implementation-code routing, no-oversell / source-traceability (every claim traces to an official Anthropic URL verified that session), the sanitization hard gate for anything public, the attribution / non-affiliation footer, the honesty conventions (Known-limitations sections, the "syntax-checked only" admission, refused-not-silently-skipped), and the v0.2.0 fact-check methodology as this project's research method. Use when a maintainer asks "what are the rules here", "can I claim X on the site", "is this claim allowed", "sanitization check", "can I say this works", "why can't Fable write the code", "how do I cite Anthropic docs", "add a known-limitations section", or before reviewing ANY text that will ship publicly.

Run the recurring re-verification sweep that catches drift in founder-skills: hardcoded model IDs (Opus 4.8 / Sonnet 4.6 / Haiku 4.5 / Fable 5) and the multi-file bump procedure when Anthropic ships new models, beta API surfaces cited in v0.2.0 content (task budgets, Outcomes, fallbacks — last live-verified 2026-06-11), cited doc-URL liveness, installed-cache vs repo sync, sibling-site consistency, and private-repo divergence. Use when a founder-skills maintainer says "run the founder-skills freshness sweep", "is anything stale in this repo", "Anthropic shipped a new model — what do we bump here", "re-verify this repo's beta claims", "check the URLs this repo cites still resolve", "are installed users behind the repo", or on any monthly / pre-release founder-skills maintenance pass. If you are NOT working inside founder-skills, load the public skill-freshness-watch plugin instead — it is the generic version of this sweep.

The structural contract of a founder-skills plugin: directory layout, plugin.json schema and version semantics (0.1.0 vs 0.2.0), marketplace.json dual registration (local ./plugins vs git-subdir cross-list), relative-path and <skill-dir> conventions, and per-plugin .gitignore hazards including the *.html swallow that shipped build-options broken. Use when a maintainer asks "what files does a plugin need", "what goes in plugin.json", "why is my asset missing after install", "how do I register a plugin in the marketplace", "what version should this plugin be", "is my .gitignore safe", or "why did claude plugin validate pass but the skill still broke".

Ship founder-skills safely on a live-publishing master with no CI: run the executable pre-push gate (both pytest suites, node glob test, JSON parse, sanitization grep, optional URL sweep), bump plugin versions, handle installed-cache desync, and coordinate the sibling catalog site. Use when a founder-skills maintainer says "I'm about to push founder-skills", "release this founder-skills change", "publish the new plugin in this repo", "run the founder-skills pre-push gate", "bump this plugin's version", "why don't installed users see my change", or "update the site cards". If you are NOT working inside founder-skills, load the public skill-release-gate plugin instead — it is the generic version of this gate.

End-to-end workflow for adding a new skill/plugin to founder-skills: scripts/add-skill.sh anatomy step-by-step, its verified hazards (manifest-schema-only validation, the rm -rf symlink swap of ~/.claude/skills/<name>, the maybe-absent ~/claude-code-plugins cross-list, the folded-description misparse), the conformance pass against the house style, and the sanitize-and-graduate gate for publishing a private skill. Use when a maintainer asks "how do I add a new skill", "scaffold a plugin", "run add-skill.sh", "publish this private skill", "graduate a skill from claude-skills", "is this safe to make public", or "why did add-skill.sh eat my skill directory".

Run a recurring re-verification sweep that catches drift in a published Claude Code skill marketplace: hardcoded model IDs and the multi-file bump procedure when Anthropic ships new models, beta API surfaces cited in skill text, cited doc-URL liveness, installed-plugin-cache vs repo sync, sibling-site consistency, and divergence from upstream/downstream repos. Use when a marketplace maintainer says "sweep my marketplace for drift", "is my skill marketplace stale", "a new model shipped — what do we bump in my marketplace", "audit my published claims for staleness", "check my marketplace's cited URLs", "are my installed users behind my repo", or on any monthly / pre-release maintenance pass over a marketplace you publish.

Ship a Claude Code skill marketplace safely when your default branch is live-publishing: run a local pre-push gate (test suites, manifest JSON parse, sanitization grep, gitignore-swallow check, optional live-URL sweep), bump plugin versions with content, and handle installed-cache desync and catalog site coordination. Use when a marketplace maintainer says "I'm about to push my marketplace", "gate my marketplace release", "release this plugin to my marketplace", "publish the new skill", "bump a plugin version", "why don't my marketplace's installed users see the change", or "is this safe to ship".

A written house style for Claude Code skill-marketplace SKILL.md and README.md files — frontmatter rules, trigger-rich descriptions, Phase/Step body skeletons, recurring honesty and Tests sections, a six-section plugin README template, and a conformance checklist you calibrate against your own repo's golden examples. Use when a marketplace maintainer says "set up a style guide for my skill marketplace", "does this skill match my marketplace's house style", "review a SKILL.md against my golden set", "write trigger-rich frontmatter for a new skill in my marketplace", or "style-check my marketplace's plugins" — in any marketplace repo you maintain.

Use when designing a long-running agent loop, evaluation harness, or multi-session memory system with Fable 5 — covers self-correction loops, verifier sub-agents, and the memory progression pattern.

Use when you need a deep, honest audit of a repository with a prioritized improvement plan — before a refactor, before onboarding a new contributor, or before committing to a codebase.

Use when a change is architecturally significant and spans three or more repos — to thread a hard-won lesson through an entire ecosystem with a single approvable plan. Triggers on: "bake X into the whole ecosystem", "incorporate lessons across repos", "design a multi-repo program", or any cross-service plan that flows through a shared protocol or identity layer.

Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays Applies principles: data-ink ratio, chartjunk elimination, graphical integrity, lie factor, small multiples, and data density.

Use at the beginning of any new session — before any work begins — to establish effort tier, session goal, and skill routing. Triggers on: "start a session", "let's begin", "new session", "kick off", "where do we start", or whenever a fresh context needs calibration before a build, research, or planning task.