Recently Added
Fresh skills just added to the collection. Be the first to try them out!
speckit.plan
by kbrdn1
Execute the implementation planning workflow using the plan template to generate design artifacts.
speckit.install
by kbrdn1
Bootstrap the SpecKit spec-driven development system into any project directory.
speckit.implement
by kbrdn1
Execute the implementation plan by processing and executing all tasks defined in tasks.md
speckit.converge
by kbrdn1
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new, traceable tasks to tasks.md so speckit.implement can complete it. Append-only — never rewrites spec/plan or existing tasks, never edits code.
speckit.constitution
by kbrdn1
Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
speckit.clarify
by kbrdn1
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
speckit.checklist
by kbrdn1
Generate a custom checklist for the current feature based on user requirements.
speckit.analyze
by kbrdn1
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
spec-git-flow-worktree
by kbrdn1
Spec-driven end-to-end GitHub workflow in an isolated git worktree — opens the issue via gh, creates a clean worktree with gwm, then runs the full Spec Kit cycle (speckit.specify → speckit.plan → speckit.tasks → speckit.implement) inside it, makes atomic Gitmoji/Conventional commits referencing the issue, pushes, and opens a PR. Issue-first numbering: the GitHub issue number drives the branch (<type>/#<issue>-<slug>) AND the spec directory (<issue>-<slug>). Triggers on "spec issue worktree PR", "speckit worktree flow", "spec-driven worktree", "specify then worktree then implement", and any request that combines speckit.specify/speckit.implement with gwm + gh issue. Use this skill (not spec-git-flow-branch) whenever the spec-driven change should live in an isolated worktree rather than the current checkout.
spec-git-flow-branch
by kbrdn1
Spec-driven end-to-end GitHub workflow on a branch in the current checkout — opens the issue via gh, creates a feature branch (<type>/#<issue>-<slug>) from the up-to-date default branch, then runs the full Spec Kit cycle (speckit.specify → speckit.plan → speckit.tasks → speckit.implement) on it, makes atomic Gitmoji/Conventional commits referencing the issue, pushes, and opens a PR. Issue-first numbering: the GitHub issue number drives the branch AND the spec directory (<issue>-<slug>). Triggers on "spec issue branch PR", "speckit branch flow", "spec-driven branch", "specify then branch then implement", and any request that combines speckit.specify/speckit.implement with a feature branch (NOT a worktree). Use this skill (not spec-git-flow-worktree) when the spec-driven change should live in the current checkout without a worktree.
material-ui-theme
by DonArtkins
"Build the MUI v6 theme from the Figma tokens: palette, typography, shape, transitions. The theme file is the single source of visual style."
auth-and-zustand
by DonArtkins
"Web auth + client-state split: JWT access token in memory (Zustand), refresh token in an httpOnly cookie, silent refresh on boot, and the Zustand=client-only-state rule."
apollo-graphql
by DonArtkins
"Apollo Client integration for Griot's GraphQL reads: single client, InMemoryCache typePolicies, colocated fragments, refetch discipline."
xunit-dotnet
by DonArtkins
"xUnit unit + integration testing for the Griot backend: WebApplicationFactory against the real SQL Server container, refresh-rotation replay, bulk-atomicity, coverage collection."
owasp-review
by DonArtkins
"OWASP Top-10 basics review for the Griot estate: injection (parameterized SQL), broken auth (refresh rotation), sensitive data (no localStorage tokens), CORS allow-list, AI principal scope."
newman-api
by DonArtkins
"Newman CLI runs of the Postman collection in CI: API contract + regression suite, JSON schema assertions, chained tokens."
k6-perf
by DonArtkins
"k6 load/performance testing for Griot: dashboard query, login, board read. Baseline (Week 6) vs regression (Week 7). p95 < 500ms target."
jest-rtl
by DonArtkins
"Jest + React Testing Library for the Griot web app: component tests for TaskCard/BoardView/modals, mocked Apollo/React Query hooks, MSW for the copilot stub."
flutter-testing
by DonArtkins
"Flutter widget + integration tests for the Griot mobile app: widget tests for key screens, integration_test for device flows, Docker-pinned runner in CI."
writing-processor-javascript
by AtomiCloud
Write or modify CyanPrint processor code in JavaScript. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (StartProcessorWithLambda), CyanFileHelper (read/write/copy/resolveAll), and VirtualFile (content/read/write). Processor lambda receives (input, fileHelper) as two parameters.
writing-processor-dotnet
by AtomiCloud
Write or modify CyanPrint processor code in C#. Use when the user asks to change file transformations, modify the entry point, handle file processing, or change output generation. Covers entry point (CyanEngine.StartProcessor), CyanFileHelper (ResolveAll/Read/Copy), and VirtualFile (Content/WriteFile). Processor function receives (ProcessorInput, CyanFileHelper) as two parameters.
testing-processor
by AtomiCloud
Test this CyanPrint processor. Use when the user asks to write processor tests, add test cases with input files, update snapshots, or debug processor test failures. Covers test.cyan.yaml format with input directories, config, validate commands, and expected output.
documenting-processor
by AtomiCloud
Document this CyanPrint processor into README.MD. Use when the user asks to document the processor, write a README, explain processor configuration, or describe file transformations. Reads cyan.yaml and entry point code to extract config schema and file handling.
writing-plugin-typescript
by AtomiCloud
Write or modify CyanPrint plugin code in TypeScript. Use when the user asks to add validation rules, change plugin behavior, modify the entry point, run commands from a plugin, or mutate files. Covers entry point (StartPluginWithLambda), native filesystem I/O (fs), and command execution (child_process). Plugins receive { directory, config } and use native OS operations.