CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/ceedling-build-runner

Author and run the Ceedling build system for C unit testing - the canonical build orchestration on top of Unity (assertions) + CMock (mocks) + CException (exceptions). Covers ceedling new scaffolding, the project.yml schema (:project / :paths / :files / :defines / :flags / :tools / :test_runner / :cmock / :unity / :cexception / :gcov / :plugins), the task surface (test:all, test:{name}, test:pattern, test:path, release, clean / clobber, gcov:all, module:create, environment, dumpconfig), JUnit XML via the report_tests_* plugins, gcov integration, host vs cross-build flow, and CI wiring. CMock semantics - the generated Expect / Ignore / IgnoreArg / ReturnThruPtr / AddCallback / Stub / ExpectAndThrow family, cmock.yml :plugins, mock naming, tearDown verification, strict-vs-ignore matching - are in references/cmock.md. Use when a C project wants the ThrowTheSwitch trio bundled by one build command, or when authoring / reading CMock mocks. For the Unity assertion API see unity-test-framework-c.

74

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable skill body: executable commands and config at every step, real output samples, an anti-patterns table, and honest limitations. Detail is correctly offloaded to three real, clearly-signaled reference files. The only gaps are minor: a few sentences could be trimmed and the test-failure recovery loop is implicit rather than spelled out.

DimensionReasoningScore

Conciseness

The body is efficient: every section is commands, code, or dense tables ("gem install ceedling / ceedling new my-firmware --docs --local", the project.yml block, the CI yaml, the 8-row anti-patterns table) with almost no explanation of concepts Claude already knows. Minor trims are possible — e.g., "the same one GoogleTest produces, so the same CI pipeline plugin ... consumes both" and the Overview paragraph restating the description — which keeps it at anchor 4 rather than the fully lean anchor 5.

4 / 5

Actionability

Guidance is copy-paste ready throughout: the scaffold commands, a minimal working project.yml, "ceedling module:create[ringbuffer]" with the generated file list, "ceedling test:all / gcov:all" with exit-code semantics, real output samples ("test/test_ringbuffer.c:48:test_overflow_returns_minus_one:FAIL: Expected -1 Was 0"), and a complete executable GitHub Actions workflow. These cover the common cases end to end.

5 / 5

Workflow Clarity

The sequence is clear and ordered — Scaffolding → project.yml → module:create → Running → Parsing results → CI integration — with an explicit checkpoint ("ceedling test:all returns non-zero on any test failure; CI gates on the exit code") and debugging guidance ("dumpconfig is the only reliable verifier", "Always clobber before the CI run", plus failure-mode rows in the anti-patterns table). It falls short of anchor 5 only because there is no explicit validate→fix→retry loop for test failures in the run flow.

4 / 5

Progressive Disclosure

The body is a genuine overview spine that keeps only the canonical loop inline and clearly signals one-level-deep references for the bulk detail: "The full schema ... is in references/project-yml-schema.md", "The full task surface ... is in references/task-reference.md", and CMock semantics in references/cmock.md — all three files exist in the bundle and contain the promised content without further nesting (cmock.md's links back to SKILL.md and to external docs are backlinks, not depth). Navigation is easy with a consistent section structure and a References section.

5 / 5

Total

18

/

20

Passed

Description

96%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, concrete, well-triggered description that clearly states what the skill does, enumerates the full capability surface, and gives an explicit "Use when" clause with routing to sibling skills. The only weakness is slight overlap risk with the surrounding Unity/coverage/QEMU skill family, partially mitigated by explicit disambiguation.

DimensionReasoningScore

Specificity

The description enumerates many concrete capabilities: "Author and run the Ceedling build system for C unit testing", "ceedling new scaffolding, the project.yml schema (:project / :paths / :files / :defines / :flags ...)", the full task surface ("test:all, test:{name}, test:pattern, test:path, release, clean / clobber, gcov:all, module:create"), "JUnit XML via the report_tests_* plugins", "host vs cross-build flow, and CI wiring". Coverage is comprehensive with no generic filler.

5 / 5

Completeness

Both questions are answered explicitly: the "what" is the opening sentence plus the "Covers ..." enumeration, and the "when" is a concrete trigger clause — "Use when a C project wants the ThrowTheSwitch trio bundled by one build command, or when authoring / reading CMock mocks." It even routes adjacent needs ("For the Unity assertion API see unity-test-framework-c").

5 / 5

Trigger Term Quality

It contains the natural terms a user would say when needing this skill: "Ceedling", "Unity", "CMock", "CException", "C unit testing", "ThrowTheSwitch trio", "CMock mocks", plus artifact names like "project.yml". These are exactly the domain's synonyms and identifiers; nothing common is missing.

5 / 5

Distinctiveness Conflict Risk

The niche is clear (Ceedling as the canonical orchestration over the Unity/CMock/CException trio) and it explicitly disambiguates the closest sibling ("For the Unity assertion API see unity-test-framework-c"), but it operates in an ecosystem of several closely related skills (unity-test-framework-c, embedded-coverage-strategy-reference, qemu-system-test-runner) and mentions gcov/coverage surfaces those siblings also claim, leaving minor overlap risk. It sits noticeably above anchor 3 ("could still overlap with similar skills") because of the explicit routing, but not fully at anchor 5's "minimal conflict risk" given the breadth of topics (gcov, CI wiring, cross-build) it claims.

4 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents