timbogp-marketplace

Adjust the difficulty level of a learning sub-project's curriculum — simplify a too-advanced curriculum into a gentler on-ramp, or deepen a too-introductory one into something with real teeth. Use whenever the user signals the curriculum's level doesn't match their starting point — phrases like "this paper is too hard, can we build up to it?", "simplify the curriculum", "make it easier", "go more advanced", "I want a more rigorous version", "this is too basic, push deeper", "I need an intro version of this", or "create a simpler/harder curriculum from this material". The skill is allowed to pull in external materials and training knowledge to fill the gap between the source's natural level and the target level, but every external addition is explicitly labeled — the user always knows what came from their own source materials and what came from elsewhere.

Scaffold a new learning sub-project under the agentic-study-environment harness — create the directory, generate per-project AGENTS.md, CLAUDE.md, and PROGRESS.md from templates, and register the new project in the .studyenv/PROGRESS.md cross-project tracker. Use this skill whenever the user wants to start studying a new topic, paper, book, language, or domain with the tutor harness — phrases like "bootstrap a new project to learn X", "start a new sub-project for Y", "set up a learning project on Z", or "create a sub-project to study W" should all trigger this skill. Do not use for general project scaffolding outside the agentic-study-environment harness.

Explain the agentic-study-environment plugin — what it does, the lifecycle skills it ships, the domain overlays, the session types, and the key conventions — or a specific one of those if the user names it. Use this skill whenever the user asks for help with the study harness itself rather than asking to study something: phrases like "help with agentic-study-environment", "what can the study harness do", "how does this plugin work", "list the study skills", "how do I use set-curriculum", "what domains are there", "explain session types", or the /study-help command. With no topic, give the full overview; with a named skill, overlay, session type, or convention, explain just that. Do NOT use this to bootstrap, set a curriculum, or run a session — those are the lifecycle skills.

Begin a bracketed onboarding session over an existing artifact you didn't author — a codebase, a document corpus, a body of papers — inside a agentic-study-environment sub-project. The agent surveys the artifact, walks it part by part with comprehension checks, then has the user reproduce a recent change from its history. Use whenever the user signals they want to get up to speed on something someone else made — phrases like "onboard me on this codebase", "walk me through this repo", "help me get up to speed on X", "I just joined this project", "drop me into this codebase", or "get familiar with this corpus" should trigger this skill. `onboarding` is the fourth core session type; unlike `theory`/`practice`/`role-play` it has its own dedicated entry point rather than being proposed inside `start-session`. A session ends with the `stop-session` skill.

Build or update the teaching curriculum for a learning sub-project from its source materials. Use whenever the user wants to plan, structure, or refresh the learning path for a sub-project — phrases like "set curriculum for X", "update the curriculum", "plan the teaching path", "build a curriculum from these materials", or general intent to organize source material into an ordered teaching plan. This skill reads the sub-project's source materials and writes ai-agent-materials/curriculum.md. It does not start a session and does not update PROGRESS.md.

Begin a bracketed learning session inside a agentic-study-environment sub-project — pick a topic, propose theory vs. practice (or an overlay-specific type such as simulation or defense), and conduct it per the sub-project's domain overlay. Use whenever the user signals they want to actively study, work an exercise, role-play a clinical case, rehearse a research defense, or review theory inside a sub-project — phrases like "start session", "let's work on X", "begin a practice session", "ok let's study Y", or "I want to do an exercise on Z" should trigger this skill. A session is the harness's unit of work and ends with the stop-session skill.

End the current learning session — update the sub-project's PROGRESS.md (topics + journal), mirror status changes into the .studyenv/PROGRESS.md cross-project tracker (unless the sub-project is Tracking: local-only), and produce a concise summary of what was covered. Use whenever the user signals the session is over — phrases like "stop session", "let's wrap up", "end session", "we're done for today", or any out-of-character role-play debrief signal ("debrief", or a flavor-specific "end simulation" / "end defense" / "end review"). Do not invoke this skill proactively at the end of a long conversation unless the user signals it.

This skill should be used when the user wants to run or practice a customer-development interview — "play a customer so I can practice", "let's do a problem interview", "role-play a solution interview", "run an MVP / usability interview", "interview me as a target customer", "help me prep customer interviews", or "I need to talk to customers, coach me". It role-plays a realistic target customer (Problem, Solution, or MVP flavor), holds the right script, stays in character through the conversation, then breaks character to debrief on interview technique and learning. It can also just prep scripts and questions without role-play. Writes artifacts to .lean/interviews/. This is the core "get out of the building" practice of Running Lean.

This skill should be used when the user asks for help with the lean-coach plugin — what it does, which skills, commands, agent, or roles it ships, or how to use a specific one. Triggers on the /lean-help command and on phrases like "help with lean-coach", "what can lean-coach do", "list the lean commands", "how do I use customer-interview", "what roles can the coach play", "explain the lean canvas skill". With no specific topic, give the full overview; with a named skill, command, agent, role, or concept, explain just that one. Do not use for actually doing lean work (building a canvas, running an interview) — that's the individual skills.

This skill should be used when the user wants to rehearse or stress-test a fundraising pitch — "play an investor", "let's practice my pitch", "be a skeptical VC and grill me", "pitch practice", "what would an investor ask?", "is my traction story convincing?", or prepping for an angel/seed meeting. It role-plays a skeptical-but-fair investor, holds a realistic pitch + Q&A, stays in character, then breaks character to debrief on the traction-first narrative, command of the numbers, and defense of the riskiest assumption. It can also just prep a pitch or critique a deck without role-play. Writes to .lean/pitch/.

This skill should be used when the user wants to capture, build, or refine their business model on a one-page Lean Canvas — "help me make a lean canvas", "let's document my business model", "fill in the canvas for my idea", "update my lean canvas", "what's my UVP / unfair advantage / revenue model?", or brainstorming model variants (different customer segments, pricing, channels). It writes and versions .lean/canvas.md, working block by block, and flags each entry as an untested assumption. Use it for the "Document your Plan A" step of Running Lean. For ranking which assumptions to test first, use prioritize-risks instead.

This skill should be used when the user wants to be guided through building a business the Lean way (Ash Maurya's Running Lean) or asks where they are and what to do next — "coach me through my startup", "help me develop my business idea", "what should I work on next?", "where am I in the lean process?", "is this the right thing to be testing?", "I have an idea, where do I start?". It is the navigator: it onboards the venture into a .lean/ workspace, figures out the current stage and the riskiest untested assumption, and routes to the right role or skill. Use it as the default entry point when no more specific lean activity (canvas, interview, experiment, pitch) is named.

This skill should be used when the user wants the agent to adopt or switch into a specific Lean role/persona — "be my devil's advocate", "switch to business-partner mode", "play a skeptical co-founder", "review my model as a mentor", "give me brutal feedback on my plan", "let's brainstorm this together", "poke holes in my canvas", or "what roles can you play?". It is the front door for the plugin's role-play personas (Business partner, Devil's advocate, Mentor — plus Customer and Investor, which have their own dedicated skills). It explains the cast and runs the shared role-play protocol for the chosen role. For a structured customer interview use customer-interview; for pitch practice use investor-pitch.

This skill should be used when the user wants to set up measurement or judge whether they've built something people want — "how do I measure product/market fit?", "set up my metrics / conversion funnel / cohorts", "am I at product/market fit?", "run the Sean Ellis test", "what should my key metric be?", "track retention/activation", "which engine of growth?", or validating the customer lifecycle (acquisition → activation → retention → revenue → referral). It defines the value metrics, reads funnels and cohorts honestly, and applies the fit benchmarks. Writes to .lean/metrics/. Use for the "verify quantitatively" stage. For designing a single experiment, use run-experiment.

This skill should be used when the user wants to figure out which part of their business model to test first — "what's the riskiest part of my plan?", "where should I start?", "prioritize my assumptions", "which of these business models should I pursue?", "how do I de-risk this?", or "rank my lean canvases". It identifies the assumptions on the Lean Canvas, classifies them as product/customer/market risk, ranks them, and picks the riskiest-first starting point, writing .lean/risks.md. Use it after a canvas exists and before running experiments or interviews. For documenting the model itself, use lean-canvas; for testing an assumption, use customer-interview or run-experiment.

This skill should be used when the user wants to design or log an experiment to test a business-model assumption — "design an experiment to test X", "how do I validate this assumption?", "turn this into a falsifiable hypothesis", "what's the smallest test for this?", "set up a landing-page / concierge / smoke test", or "log the results of my experiment". It frames the assumption as a falsifiable hypothesis, picks a single key metric and the smallest build, and records the Build-Measure-Learn cycle to .lean/experiments/. Use it for the "systematically test your plan" step. For interviews specifically, use customer-interview; for judging product/market fit, use measure-fit.

This skill should be used when the user asks for help with the ux-design plugin — what it does, which skills, commands, agent, or bundled tools it ships, or how to use a specific one. Triggers on the /ux-help command and on phrases like "help with ux-design", "what can ux-design do", "list the ux-design commands", "how do I use ux-audit", "explain design-tokens". With no specific topic, give the full overview of everything the plugin offers; with a named skill, command, agent, or tool, explain just that one in depth. Do not use for actually running an audit or scaffolding work — that's the individual capability skills.

This skill should be used when evaluating a design, page, or component against accessibility standards and producing a severity-scored report. Trigger phrases include "audit accessibility", "check a11y", "is this accessible", "WCAG audit", "check color contrast", and "accessibility review before handoff". Use it to assess WCAG 2.2 Level AA conformance from code, a screenshot, a description, or a live URL, and to grade findings by severity with concrete remediations.

This skill should be used when the user wants to build or fix accessible UI components or set up accessibility tooling — triggers like "make this modal accessible", "build an accessible dropdown", "add ARIA to this", "accessible tabs/combobox/tooltip/accordion", "set up a11y linting", or "fix keyboard navigation". It scaffolds WAI-ARIA APG component patterns adapted to the detected framework and wires up automated a11y linting.

This skill should be used when a user wants to scaffold or refactor a design token system — e.g. "set up design tokens", "create a design system foundation", "extract these hardcoded colors into tokens", "add a type scale", "theming setup", or "dark mode tokens". It produces a single source of truth for color, type, spacing, radius, shadow, motion, and z-index, emitted in the format the detected stack expects.

This skill should be used when the user wants clear visual feedback for async actions and state changes — triggers like "add loading and error states", "show a success message", "add a toast/notification", "inline form validation", "optimistic UI", "empty state for this list", "this button gives no feedback", or "add a skeleton loader". It implements loading/empty/error/success states, toasts, micro-interactions, and their accessibility announcements, adapted to the detected stack.

This skill should be used when the user wants to bootstrap or set up a UX baseline in a project — e.g. "bootstrap UX best practices", "set up our UX foundations", "scaffold a design system starting point", "establish UX standards for this repo", or runs /ux-bootstrap. It detects the project's stack and lays down design tokens, accessible base primitives, a11y linting, lightweight metrics, and a UX-CHECKLIST. It is the orchestrator that other implement skills (design-tokens, accessible-components, interaction-feedback) build on.

This skill should be used when quantifying user experience — instrumenting performance, defining analytics events, or scoring usability. Trigger phrases include "measure UX", "Core Web Vitals", "set up web vitals", "track LCP/INP/CLS", "Lighthouse score", "design analytics events", "SUS score", "usability metrics", and "how do I quantify UX". Use it to pick the right metrics, instrument them, and interpret the numbers.

This skill should be used when someone wants to get familiar with an existing project's UX/design choices and patterns — e.g. "walk me through how this app does UX", "onboard me onto the design system", "explain this project's UI patterns", "I'm new to this codebase, show me the design layer", or runs /ux-onboarding. It builds a working mental model by surveying the design layer, teaching it part by part (explaining, sending the user to read the real code, and checking comprehension with questions), then having the user reimplement a small recent UX change picked from history. Familiarization — not scaffolding (ux-foundations) or scoring (ux-audit).

This skill should be used when the user wants a structured usability review of an interface and asks to "audit this UX", "run a usability review", "do a heuristic evaluation", "review this flow/screen", "what's wrong with this UI", or "is this usable". It produces a scored, severity-ranked usability report from screenshots, a live URL, a description, or source code.

This skill should be used when the user wants to write or review interface microcopy and says things like "write copy for", "what should this button say", "review this error message", "empty state copy", "onboarding text", "confirmation dialog wording", "rename this CTA", or "microcopy". It writes clear, user-centered UX copy and critiques existing copy with before/after rewrites.