Implement a feature from a product/tech spec, URL, GitHub issue, or by auto-selecting the next papercut enhancement. Reads the spec, implements the feature following Streamlit patterns, and creates a merge-ready PR. Use when given a spec folder path, document URL, or issue link to implement, or when asked to implement…
Runs frontend unit tests with coverage, analyzes coverage reports, and implements meaningful tests to increase coverage by 0.2%. Use when you want to systematically improve frontend test coverage with high-value test cases.
Runs Python unit tests with coverage, analyzes coverage reports, and implements meaningful tests to increase coverage by 0.2%. Use when you want to systematically improve Python test coverage with high-value test cases.
Evaluates a PR's title and description for readability — do they clearly and concisely convey what changed and why to a reviewer? Produces findings with concrete proposed rewrites; the caller decides whether to apply them or present them as feedback. Use when finalizing a PR or reviewing PR metadata. For code…
Evaluates comments, docstrings, and naming in code for readability by a developer new to the codebase — is the documentation clear and concise, and is non-obvious logic documented? Produces findings with concrete proposed rewrites (or additions where documentation is missing); the caller decides whether to apply them…
Uploads agent-generated artifacts (specs, plans, learnings) to the streamlit.wiki for sharing via PR comments. Use when you have agent artifacts to share with reviewers.
Explains Streamlit's internal architecture including backend runtime, frontend rendering, and WebSocket communication. Use when debugging cross-layer issues, understanding how features work end-to-end, planning architectural changes, or onboarding to the codebase. Covers ForwardMsg/BackMsg protocol, script rerun…
Writes product and tech specs for new Streamlit features. Use when designing new API commands, widgets, or significant changes that need team review before implementation.
We use playwright with pytest to e2e test Streamlit library. E2E tests verify the complete Streamlit system (frontend, backend, communication, state, visual appearance) from a user's perspective (black-box). They complement Python/JS unit tests, which are faster and focus on internal logic, input/output validation…
Skills under lib/streamlit/.agents/skills/ ship with the library and load from the user's installed Streamlit, so keep them current as features evolve. developing-with-streamlit uses SKILL.md for routing and references/ for topic files. Follow these conventions when adding or editing guidance.
Streamlit is an open-source (Apache 2.0) Python library for creating interactive web applications and dashboards with focus on data apps and internal tools.
We use the unit tests to cover internal behavior that can work without the web / backend counterpart. We aim for 95%+ unit test coverage of our Python code in lib/streamlit.
Changes to these high-fan-out internals can affect every message, delta, element, or rerun. Keep work in them minimal, and benchmark changes with representative stress-test apps.