最近新增
刚加入收藏的新技能，抢先试用。
speckit.plan
kbrdn1
Execute the implementation planning workflow using the plan template to generate design artifacts.
speckit.install
kbrdn1
Bootstrap the SpecKit spec-driven development system into any project directory.
speckit.implement
kbrdn1
Execute the implementation plan by processing and executing all tasks defined in tasks.md
speckit.converge
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
kbrdn1
Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
speckit.clarify
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
kbrdn1
Generate a custom checklist for the current feature based on user requirements.
speckit.analyze
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
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
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
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
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
DonArtkins
"Apollo Client integration for Griot's GraphQL reads: single client, InMemoryCache typePolicies, colocated fragments, refetch discipline."
xunit-dotnet
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
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
DonArtkins
"Newman CLI runs of the Postman collection in CI: API contract + regression suite, JSON schema assertions, chained tokens."
k6-perf
DonArtkins
"k6 load/performance testing for Griot: dashboard query, login, board read. Baseline (Week 6) vs regression (Week 7). p95 < 500ms target."
jest-rtl
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
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
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
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
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
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
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.