feat(block-kit): add poll, wizard modal, and empty state templates to common patterns#85
feat(block-kit): add poll, wizard modal, and empty state templates to common patterns#85Roach wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 1a8514d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Hey @Roach 👋🏻 Good to hear from you, friend! Thanks the PR. At first, I was hesitant to accept more scope to our skills without some supporting use-cases, but I think you're hitting on important gaps in this PR. Thanks for signing the CLA - I've started the GitHub Action checks. 🔒 @WilliamBergamin and I will take your skill changes for a test drive and make sure that they're working well. |
WilliamBergamin
left a comment
There was a problem hiding this comment.
@Roach thanks for your interest in this project 🚀 💯
Seem like there are still some kinks in our CI pipeline for forks 😅
I ran the evals locally and they passed 🟢
I used the following prompts to test out the changes and got expected behavior 🟢
Use the block-kit skill to build a poll message where teammates vote with buttons and see a live tally. It should ask which day works best for our team lunch, with options Tuesday, Wednesday, and Thursday.
Use the block-kit skill to create a multi-step setup form with a step indicator, this will be the first step of onboarding a new customer account.
Use the block-kit skill to design a first-run home tab that points a brand-new user to their first action, before they have any data yet.
|
@mwbrooks once you've taken this for a test drive and made sure its working well we will need to bypass the the merge rules because |
Summary
Adds three ready-made templates to the block-kit skill's
references/common-patterns.md, filling gaps in the existing pattern library (which covers approvals, forms, alerts, dashboards, confirmations, tables, and settings):sectionblocks with button accessories and a text-rendered tally, with a note that the app re-renders viachat.updateas votes arrive.contextblock, "Next" as the submit label, and customization notes on chaining steps (response_action: "update"/views.update) and carrying state inprivate_metadata.One per surface, each structurally distinct from the existing templates. The Step 2 example list in
SKILL.mdis extended with matching entries so the skill can route requests to the new templates, and a changeset is included.The templates stick to block types and composition objects already demonstrated in the file (
header,section,divider,actions,context,input,button,static_select,plain_text_input), plus asectionbuttonaccessoryand the modalprivate_metadatafield. No new/exotic block types are introduced, but a maintainer spot-check of the two new templates against docs.slack.dev would be welcome — I did not run them throughblocks.validateagainst the live API from this environment.Preview
New sections appended to
skills/block-kit/references/common-patterns.md, following the existing format:## Name [M/V/H]heading, one-line description, JSON scaffold,**Customization points:**line.Testing
These are reference templates consumed by the skill's Fast Path / Step 3, not executable code, so testing focused on structure and consistency:
rumdl check .passes with the repo's config (no issues in 14 files).make test-unitpasses (12/12).make test-evalwas not run locally (requiresGEMINI_API_KEY/SLACK_MCP_TOKEN).blocks.validate(no live Slack API access from this environment) — the file's own preamble already directs users to re-validate customized payloads before shipping.Notes
minorsince this adds new skill content rather than fixing existing content; happy to downgrade topatchif that matches your versioning intent for reference-only changes.Requirements
make testand the tests pass (unit suite; the eval suite needs API keys I don't have locally — see Testing above).