implementing-feature

작성자: streamlit

제품/기술 명세서, URL 또는 GitHub 이슈의 기능을 구현합니다. 명세서를 읽고 Streamlit 패턴에 따라 기능을 구현하며, 다음을 생성합니다…

npx skills add https://github.com/streamlit/streamlit --skill implementing-feature

Implementing feature

Implement a feature from a specification document, from reading the spec through to a merge-ready PR.

Usage examples

Use by pointing to a spec folder:

/implementing-feature specs/2025-12-12-menu-button

Or with a URL to a raw document:

/implementing-feature https://raw.githubusercontent.com/streamlit/streamlit/refs/heads/develop/specs/2025-12-12-menu-button/product-spec.md

Or with a GitHub issue (feature request as spec):

/implementing-feature https://github.com/streamlit/streamlit/issues/12345

When to use

  • You have a spec folder, URL, or GitHub issue to implement
  • You want end-to-end implementation: spec → code → tests → PR
  • You want a guided workflow that ensures all implementation steps are followed

Workflow

Copy this checklist and track your progress:

Progress:
- [ ] Phase 1: Read and understand the spec
- [ ] Phase 2: Research and plan
- [ ] Phase 3: Implement and test
- [ ] Phase 4: Verify against spec
- [ ] Phase 5: Finalize for merge

Phase 1: Read and understand the spec

  • If given a folder path (e.g., specs/YYYY-MM-DD-feature-name):
    • Read all files in the folder (specs, images, code samples)
  • If given a URL to a raw document:
    • Fetch the spec content directly from the URL
  • If given a GitHub issue URL:
    • Use the gh client to read the issue and all comments
    • Treat the issue description and discussion as the feature specification

Phase 2: Research and plan

Run this phase in a foreground subagent. The subagent should:

  • Search for similar existing features to follow patterns
  • Use the /understanding-streamlit-architecture skill to understand relevant internals
  • Always write an implementation plan to work-tmp/<feature-name>-implementation-plan.md, where <feature-name> is derived from the branch name (e.g., git branch --show-current | sed 's|.*/||') or, if on a detached HEAD, the spec folder basename

The implementation plan must include:

  • Summary of the feature requirements (from spec)
  • Relevant existing patterns found in codebase
  • List of files to create or modify (backend, frontend, proto, tests)
  • Implementation steps in order
  • Key decisions and trade-offs
  • Test strategy (unit tests, E2E tests)

Wait for the subagent to complete and verify the implementation plan exists before proceeding.

Phase 3: Implement and test

Run this phase in a foreground subagent. Provide all relevant context needed to implement the feature, including the full spec content, the implementation plan from Phase 2, and any key API signatures or patterns identified during research.

The subagent should:

  • Implement the feature based on the spec and plan. Read wiki/new-feature-guide.md for tips.
  • Do additional research if anything is unclear or missing from the provided context
  • Run make protobuf after any protobuf changes
  • Add unit tests (Python in lib/tests/, frontend co-located) and E2E tests in e2e_playwright/
  • Use the /debugging-streamlit skill to test and debug backend, frontend, and UI
  • Return a summary of key implementation decisions and any spec divergences

Phase 4: Verify against spec

  • Re-read the spec to verify all requirements are met; document any necessary divergences in work-tmp/
  • Run the /qa-testing-feature subagent to perform comprehensive QA testing of the implementation. Provide:
    • A brief description of the feature being tested
    • Paths to relevant documents (spec, implementation plan, API files with docstrings)
  • Review the QA report and address any issues found before proceeding

Phase 5: Finalize for merge

  • Run /finalizing-pr skill to execute quality checks, create the PR, and make it merge-ready
  • Follow all steps until the PR is merge-ready

Important notes

  • Be fully autonomous - Do NOT stop or pause to ask for confirmation. You are tasked to go from spec to merge-ready PR without human intervention. Note any open questions or ambiguities in the PR description rather than blocking on them.
  • Use foreground subagents - Phases 2 and 3 run as foreground (blocking) subagents to preserve main context while delegating intensive research and implementation work.
  • Follow Streamlit patterns - Check existing similar features for conventions
  • Reference the spec in PR - Include spec link in PR description
  • Test thoroughly - Use /debugging-streamlit before finalizing

streamlit의 다른 스킬

developing-with-streamlit
streamlit
**[필수]** 모든 Streamlit 작업(Streamlit 애플리케이션 생성, 편집, 디버깅, 미화, 스타일링, 테마 적용, 최적화)에 사용하세요. 또한 필요합니다…
official
addressing-pr-review-comments
streamlit
현재 브랜치의 streamlit/streamlit 저장소에 있는 PR의 모든 유효한 리뷰 코멘트를 처리합니다. 인라인 리뷰 코멘트와 일반 PR(이슈) 코멘트를 모두 포함합니다.
official
checking-changes
streamlit
커밋 전에 포맷, 린트, 타입, 단위 테스트 검사를 실행하여 모든 코드 변경 사항을 검증합니다. 백엔드(Python) 또는 프론트엔드(TypeScript) 작업 후에 사용하세요…
official
discovering-make-commands
streamlit
Streamlit 개발에 사용 가능한 make 명령어를 나열합니다. 빌드, 테스트, 린트 또는 포맷 작업에 사용하세요.
official
finalizing-pr
streamlit
병합을 위해 브랜치 변경 사항을 최종 확정하며, 코드 단순화, 검사 실행, 변경 사항 검토, 필요 시 PR 생성을 수행합니다. 변경 사항을 병합할 준비가 되었을 때 사용하세요.
official
fixing-flaky-e2e-tests
streamlit
불안정한 Playwright e2e 테스트를 진단하고 수정합니다. 테스트가 간헐적으로 실패하거나, 시간 초과 오류가 발생하거나, 스냅샷 불일치가 있거나, 브라우저별 특성을 보일 때 사용하세요.
official
fixing-streamlit-ci
streamlit
현재 브랜치/PR에서 실패한 GitHub Actions CI 작업을 분석하고 수정합니다. CI 검사가 실패하거나, PR 검사에서 오류가 표시되거나, 진단이 필요할 때 사용하세요…
official
generating-changelog
streamlit
두 개의 git 태그 사이에 있는 docs.streamlit.io용 정리된 웹사이트 릴리스 노트를 생성합니다. 새로운 Streamlit 릴리스를 준비하거나 변경 사항을 검토할 때 사용합니다.
official