CtrlK
BlogDocsLog inGet started
Tessl Logo

teamcity

TeamCity integration. Manage data, records, and automate workflows. Use when the user wants to interact with TeamCity data.

57

Quality

66%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/teamcity/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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.

The content is highly actionable with executable commands and a clear, checkpointed connection workflow. Its main gaps are a padded opening explanation of what TeamCity is and a monolithic single-file structure with no external references to split out detail.

Suggestions

Cut the opening "TeamCity is a build management and continuous integration server..." paragraph; Claude already knows what TeamCity is, so lead directly with the integration workflow.

Add an explicit validation step after running actions (e.g. check the response `output`/`error` fields and retry or surface errors), to close the feedback loop around the run/proxy commands.

Move the large request-flag table and verbose `clientAction` field reference into a separate reference file (e.g. REFERENCE.md) and link to it one level deep, to reduce the monolithic inline bulk.

DimensionReasoningScore

Conciseness

The body is mostly efficient command-driven guidance, but it opens by explaining what TeamCity is ("a build management and continuous integration server from JetBrains... automate the build, test, and deployment processes") which Claude already knows, and repeats the action-list command in three places, so it could be tightened.

3 / 5

Actionability

It provides copy-paste-ready commands throughout (install, login, connection ensure, --wait polling, action run, request proxy) plus a complete flag table, covering the common cases with real executable syntax.

5 / 5

Workflow Clarity

There is a clear install -> authenticate -> connect -> poll-for-ready -> discover -> run sequence with explicit state checkpoints (READY / CLIENT_ACTION_REQUIRED / CONFIGURATION_ERROR) and a poll-after-action feedback step; it stops short of a 5 only because there is no explicit verify-output / error-feedback loop around running actions.

4 / 5

Progressive Disclosure

There are no bundle files and the skill is a single ~155-line document with section headers but no one-level-deep references; it has structure but keeps everything inline (flag tables, prose) that could be split out, so it does not reach a 4.

3 / 5

Total

15

/

20

Passed

Description

62%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.

The description has an explicit what-and-when structure and a clear, distinct domain anchor in TeamCity. Its weakness is generic action language ("manage data, records") and a thin set of trigger terms, which limit specificity and trigger-term quality.

Suggestions

Replace generic actions with concrete TeamCity verbs, e.g. "Trigger and monitor builds, view build status, manage projects and build configurations".

Expand trigger terms to include natural phrases users say, such as "builds", "CI", "build server", "trigger a build", or "build status".

Sharpen the when-clause with concrete triggers, e.g. "Use when the user wants to trigger or monitor TeamCity builds, check build status, or manage build configurations."

DimensionReasoningScore

Specificity

It names the domain (TeamCity) and a couple of actions ("Manage data, records, and automate workflows"), but the actions are generic rather than concrete (builds, triggers, polling) so it does not reach the several-specific-actions bar of a 4.

3 / 5

Completeness

Both what ("Manage data, records, and automate workflows") and an explicit when ("Use when the user wants to interact with TeamCity data.") are present; the when clause is explicit but generic rather than concrete trigger phrases, so it falls short of a 5.

4 / 5

Trigger Term Quality

The natural keyword "TeamCity" appears and "interact with TeamCity data" is a plausible phrase, but there are no synonyms or variations a user might actually say (CI server, builds, trigger a build, build status).

3 / 5

Distinctiveness Conflict Risk

The TeamCity niche is clearly distinct and unlikely to trigger for unrelated skills, but the generic "manage data, records" phrasing overlaps with other Membrane integration skills, preventing a 5.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
membranedev/application-skills
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.