CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

sdx-project-kickoff

Initializes a new spec-driven project repository from a concept document and optional architecture/datamodel docs. Sets up repository structure, OpenSpec configuration (a spec-as-code workflow tool), tech stack scaffolding, testing infrastructure, agent configs, and creates the full set of OpenSpec change proposals based on the provided documents. Use when: a user wants to start a new project, initialize a repository from design docs, bootstrap a codebase from a concept document, scaffold a project from scratch, create a repo from spec, or says things like "new project setup", "kick off a project", "set up a new repo from my design docs", or "create a project from my concept file".

7.30x
Quality

94%

Does it follow best practices?

Impact

95%

7.30x

Average score across 5 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

The canonical home for this skill is spec-driven-magic/sdx-project

SKILL.md
Quality
Evals
Security

Quality

Content

92%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-engineered orchestration skill: fully executable commands, exact file paths, a complete proposal template, and explicit validation checkpoints with retry/skip/abort feedback loops on the risky batch operations. The only weakness is redundancy — the stack-README read instruction, the git-repo confirmation, and stop-on-error handling are each stated two or three times.

Suggestions

State "Read references/stacks/<stack>/README.md first" once (e.g., at the top of Steps) and remove its repeats in step 3 and the Important Rules section.

Drop the duplicate git-repo-exists handling in step 2 — step 1 already requires confirming this and asking the user before proceeding.

Trim per-step restatements of stop-on-error behavior (steps 4 and 5) by relying on the global Validation Rule block, keeping explicit handling only where a concrete recovery loop exists (steps 7 and 10).

DimensionReasoningScore

Conciseness

The body is imperative and free of concept over-explanation, but has trimmable repetition: the "read the stack README" instruction appears in step 1, step 3, and again in Important Rules; the git-repo-exists confirmation is duplicated between step 1 and step 2; and stop-on-error handling is stated both in the Validation Rule section and per-step. Not 3 because there is no padding or explanation of things Claude already knows — every section carries operational content.

4 / 5

Actionability

Guidance is copy-paste executable: exact bash commands (git init, openspec init --tools claude,antigravity, openspec new change "<change-name>", openspec status --change --json, git add -A), exact file paths for every read/write, explicit placeholder-replacement mappings, and a complete proposal.md markdown template. Not 4 because the commands and template cover the common cases fully with no gaps requiring improvisation.

5 / 5

Workflow Clarity

Fourteen clearly sequenced steps with explicit validation checkpoints and feedback loops: input validation in step 1, "Verify success: Confirm the openspec/ directory was created. If openspec init fails, report the error output... and stop", and on openspec new change failure "ask the user whether to retry, skip, or abort" — matching the anchor-5 validate→fix→retry pattern for the batch change-creation operation.

5 / 5

Progressive Disclosure

The body is an overview that keeps stack-specific detail in bundle files, referenced by exact one-level-deep paths (references/stacks/<stack>/README.md, openspec-config.yaml, CLAUDE.md, references/common/roadmap-template.md), all of which exist in the bundle, with a closing References section for navigation. Not 4 because there are no organization gaps — every referenced path resolves and nothing that belongs in a reference is inlined.

5 / 5

Total

19

/

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 strong description: it states a comprehensive set of concrete capabilities in third person and pairs them with an explicit, richly varied Use-when clause covering natural user phrasings. Its only weakness is a couple of overly broad triggers ("start a new project", "scaffold a project from scratch") that could collide with generic scaffolding skills.

DimensionReasoningScore

Specificity

The description enumerates concrete actions: "Sets up repository structure, OpenSpec configuration (a spec-as-code workflow tool), tech stack scaffolding, testing infrastructure, agent configs, and creates the full set of OpenSpec change proposals" — comprehensive coverage of the skill's capabilities with no vague filler. Not 4 because the action list covers the entire workflow, not just several actions with gaps.

5 / 5

Completeness

Explicitly answers both questions: the "what" is a two-sentence concrete capability list, and the "when" is an explicit "Use when:" clause with multiple concrete trigger scenarios. This matches the anchor-5 example structure exactly.

5 / 5

Trigger Term Quality

Natural user phrasings are comprehensively covered with synonyms: "start a new project", "kick off a project", "new project setup", "bootstrap a codebase from a concept document", "scaffold a project from scratch", "set up a new repo from my design docs", "create a project from my concept file". These mirror what a user would actually say, matching the anchor-5 example's synonym coverage.

5 / 5

Distinctiveness Conflict Risk

The OpenSpec/spec-driven framing creates a clear niche, but broad triggers like "a user wants to start a new project" and "scaffold a project from scratch" could overlap with generic project-scaffolding or init skills, which is minor overlap risk per the anchor-4 wording. Not 5 because those generic triggers reduce it below "minimal conflict risk".

4 / 5

Total

19

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 3 deeper-than-1-level

Warning

referenced_paths_exist

Referenced path issues: 4 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository

xomyakus/spec-native-skills

Path

tiles/sdx-project/skills/sdx-project-kickoff/SKILL.md

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.