All authors

Claude Skills by Kemdirimakujuobi
github.com/Kemdirimakujuobi13 skills0 installs17 views
- Announcing A FeatureRun this BEFORE pushing any branch or opening any PR in an app that has an in-app "what's new" modal — invoked as a step of `pre-push-review` right after `updating-the-changelog`, or directly when the user says "announce this", "add a feature modal", "show users what's new", or ships a new page or workflow people would otherwise miss. It decides whether the change earns a modal (rarely), writes the entry and graphic in the same PR, prunes old entries, and records the decision in the PR body. ...Votes: 0GitHub stars: 9
- Authoring A PrdRun this to turn a feature idea or brief into a house-style PRD BEFORE any branch is opened — whenever the user says "write a PRD", "help me write a PRD", "create a PRD for", "draft the requirements for", "spec this feature", "document this feature", "turn this brief into a PRD", or "publish this to the tracker". Also offer it proactively when the user describes a feature that needs documenting before build. It produces the PRD in the repo's PRD folder, seeds an epic plus one issue per user s...Votes: 0GitHub stars: 9
- Building ComponentsThe workflow for building, rebuilding, or restyling any design-system component (Button, Dialog, Select, Table, Tabs, Tooltip, and so on). Trigger whenever the user says "let's do the dialog", "restyle X", "bring in / pull in a component", "build the select", "rebuild this atom", or starts work on an item from the component inventory, even if they don't name the workflow. The base is the FULL headless primitive (Radix, React Aria, Base UI: every part, all the bundled a11y); your semantic toke...Votes: 0GitHub stars: 9
- Design TokensThe workflow for adding or changing any design token: colours, radii, spacing, type, shadows, opacity. Trigger when the user wants to add a token, change a token value, says "the component needs a token that doesn't exist yet", updates the palette or scales, asks to regenerate tokens, reviews a token PR, or has changed Figma variables and needs them in code. Also trigger from `building-components` whenever a Figma binding points at a token that hasn't been generated. The design tool is the si...Votes: 0GitHub stars: 9
- Docs Sync ReviewRun this BEFORE pushing any branch that changes what a user can see or do in the product — as a step of `pre-push-review`, or directly when the user says "does this need docs?", "update the help section", "check the docs", or ships a feature, a new metric, a new widget, a renamed field or a changed calculation. It maps the diff to the affected docs page, names what the page now gets wrong, and drafts the fix in the same PR. Docs are the product's self-serve answer; a page that describes last ...Votes: 0GitHub stars: 9
- Figma BuildImplement a Figma design to a measured 1:1 match by round-tripping — build from the extracted tokens, render it, screenshot it, diff it against Figma numerically, fix every discrepancy, repeat until the delta is zero across every state and both themes. Use when building, implementing, porting, or restyling any UI from Figma. One pixel off is a failed build. Requires figma-import to have captured the design first; never build from a screenshot alone.Votes: 0GitHub stars: 9
- Figma ImportPull a Figma node in the order that decides whether the build can be correct — the full node first with no clarifying questions, then locate the exact piece, then every spacing token, then colour, then type/radii/shadows/states, and the screenshot LAST. Use the moment a figma.com link is shared or someone says "implement this Figma", "here's the figma", "build this from Figma". The screenshot is what you verify against, never what you build from. Hands the extraction record to figma-build.Votes: 0GitHub stars: 9
- Landing A Design System ChangeRun this AFTER a design-system PR merges, whenever the user says "it's merged", "I merged it", "did it land?", "make sure it reaches the app", or you have just watched a PR touching published components, tokens or icons go green and merge. A merge is NOT delivery: the change must be declared (changeset), published to the registry, bumped in the consuming app, and verified in the installed build. Every one of those hops can fail silently, and a green check proves only that a request was sent. ...Votes: 0GitHub stars: 9
- Mobile Responsive ReviewRun this BEFORE pushing any branch that changes UI in a Tailwind app — as a step of `pre-push-review`, or directly when the user says "is this responsive?", "check mobile", "does this work on a phone?", or ships a new page, panel, dialog, table, toolbar or layout. It scans the diff's added markup for the patterns that break at phone width (360–430px), checks the fixes leave desktop (>= 768px) unchanged, and drafts the `max-md:` fixes in the same PR. People open your product on phones; a page ...Votes: 0GitHub stars: 9
- Pre Push ReviewRun this BEFORE every `git push` or opening a PR — whenever the user says "push this", "open a PR", "ready to ship", "let's get this reviewed", or you are about to push a branch. It self-reviews the diff against docs/standards/STANDARDS.md, runs the local gates including unit and integration tests, and makes the PR body carry its evidence and its explicit opt-outs (tests, changelog, docs, mobile). Reviewer findings are knowable before you push; every one caught here is a review round you don'...Votes: 0GitHub stars: 9
- Starting A ChangeRun this BEFORE creating a branch or starting any new unit of work that will become a PR — whenever the user says "let's start X", "new branch", "let's build the Y page", "let's do the Z component", "fix this bug", or otherwise kicks off a change. It names the branch `<area>/<slug>` at creation time, branches off a fresh base (never another feature branch), and surfaces the latest RETRO.md lessons so known traps are designed out before the first commit. Skip it and the branch name gets reject...Votes: 0GitHub stars: 9
- Testing A ChangeRun this while building any change that adds or alters behaviour, and again as a step of `pre-push-review` — whenever the user says "add tests", "is this tested?", "write a test for this", "run the tests", "run the integration tests", "e2e", "why is CI red on test", or fixes a bug, adds a calculation, a data mapping, a flow, or a rule you want to stay true. It picks the right layer (unit, integration, component accessibility), writes tests whose expected values come from an independent source...Votes: 0GitHub stars: 9
- Updating The ChangelogRun this BEFORE pushing any branch or opening any PR in a product with a customer-facing changelog — invoked as a step of `pre-push-review`, or directly whenever the user says "update the changelog", "add this to the changelog", "what's new", or ships a feature, integration, metric, setting or customer-visible fix. It decides whether the change earns a changelog entry, writes the entry in the same PR, and records the decision in the PR body. The changelog is only true if every PR updates it; ...Votes: 0GitHub stars: 9