메뉴
Use this skill when asked to write tests, specs, or test coverage for a command, query, or slice in a Cratis-based project. Produces BDD-style integration specs using xUnit and Cratis.Specifications.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Step-by-step guidance for building a React page in a Cratis Arc application — listing data with DataPage, toolbar actions with CommandDialog, row selection, detail panels, observable queries, and MVVM. Use whenever building or modifying a React page that lists or displays data, adding a table or grid, wiring up Add/Edit/Delete actions, using DataPage, DataTableForQuery, CommandDialog, or any @cratis/components. Also trigger when connecting a React component to a proxy-generated query or observable query.
Use this skill when asked to add a Chronicle reactor (automation or translation) to a Cratis-based project. Reactors observe events and produce side effects.
Diátaxis Documentation Expert for Cratis projects. Writes high-quality DocFX documentation guided by the Diátaxis framework — classifying every page as a Tutorial, How-to Guide, Reference, or Explanation.
Use this skill when changing, fixing, or improving Cratis documentation whose source file is under `Documentation/**` in a product or contributing repo. The content is split across repos (each product owns its docs in its own `Documentation/` folder; the `Documentation` repo aggregates them), so this skill finds the real source file, edits it, syncs, and verifies. Trigger whenever someone asks to edit/update/fix/reword a docs page, fix a broken link, correct a code example, update a guide or tutorial or reference page, or says a docs page is wrong/outdated — for Chronicle, Arc, Components, CLI, Fundamentals, or the contributing docs.
Use this skill to visually QA rendered docs site pages after changes to source files under `Documentation/**` — screenshot pages headless in light AND dark, evaluate how they look against the aspire.dev bar, check diagrams/tables/code blocks render, and diagnose layout-shift ("flicker"/"twitch"/"pop") bugs. Trigger when someone asks to screenshot the docs, check how a docs page looks, review the docs visually, verify a diagram or table renders, compare the docs to aspire.dev, or investigate a flicker/jump/layout-shift on the docs site.
Use this skill when creating a NEW Cratis documentation page under `Documentation/**` in a product or contributing repo — a new tutorial chapter, how-to/guide, explanation/concept page, reference page, or scenario/recipe. Handles where the file goes (which product repo), wiring it into the sidebar nav (toc.yml + Diátaxis bucket), and verifying it renders. Trigger when someone asks to add/create/write a new docs page, document a new feature, add a guide/tutorial/recipe/concept to the docs, or add a new section to a product's documentation.
| name | write-specs |
| description | Use this skill when asked to write tests, specs, or test coverage for a command, query, or slice in a Cratis-based project. Produces BDD-style integration specs using xUnit and Cratis.Specifications. |
Write comprehensive BDD integration specs for a vertical slice command or query.
Specs live in the same slice folder as the .cs file:
Features/<Feature>/<Slice>/
├── <Slice>.cs
└── when_<verb_phrase>/
├── and_<happy_scenario>.cs
└── and_<failure_scenario>.cs
Write one spec class for each of:
and_ class per [Required], [MaxLength], etc. ruleand_ class per DCB condition in Handle() that inspects a read modeland_ class per IConstraint// Copyright (c) Cratis. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using Cratis.Arc.Commands;
using context = <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>.and_<scenario>.context;
namespace <NamespaceRoot>.<Feature>.<Slice>.when_<behavior>;
[Collection(ChronicleCollection.Name)]
public class and_<scenario>(context context) : Given<context>(context)
{
public class context(ChronicleOutOfProcessFixture fixture) : given.an_http_client(fixture)
{
public CommandResult<object>? Result;
async Task Because()
{
Result = await Client.ExecuteCommand<<Command>>(
"/api/<feature>/<action>",
new <Command>(...));
}
}
[Fact] void should_<expected_result>() => Context.Result.IsSuccess.ShouldBeTrue();
}
For scenarios that require pre-existing state, add an async Task Establish() before Because():
async Task Establish() =>
await EventStore.EventLog.Append(SomeId.New(), new SomeEvent(...));
when_<verb_phrase> — e.g. when_registering, when_removing_a_projectand_<condition>.cs — e.g. and_name_is_unique.cs, and_name_already_exists.csshould_<expected_result> — e.g. should_append_the_registered_eventUse Cratis.Specifications helpers — never raw Assert.*:
Context.Result.IsSuccess.ShouldBeTrue()Context.Result.IsSuccess.ShouldBeFalse()Context.ShouldHaveTailSequenceNumber(EventSequenceNumber.First) — checks the event log tailRun dotnet test. Fix all failures before completing.
For full worked examples of each spec type (happy path, validation, business rule, constraint), see references/EXAMPLES.md.