project-development

This skill should be used for project-level decisions about LLM-powered systems: whether an LLM is the right primitive for the task at hand, the shape of a multi-stage batch or agent pipeline, token and cost estimation, choosing between single-agent and multi-agent at the project level, structured output design for downstream parsing, and structuring agent-assisted iteration. Use this when the unit of work is a whole project or a multi-stage pipeline. Route individual tool design to tool-design and individual skill-loading or context-budget tactics to context-optimization.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./skills/project-development/SKILL.md

Quality

Content

50%

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

The body is a thorough, well-organized methodology document with concrete decision aids, but it is held back by repeated routing sections, no in-body executable code, an invisible script bundle, and implicit validation checkpoints in the batch workflow.

Suggestions

Link the scripts/pipeline_template.py bundle from the body (e.g., in Pipeline Architecture or a 'Reference implementation' line) so the provided executable artifact is discoverable.

Collapse the three near-identical routing/ownership lists (description, 'When to Activate' do-not list, 'Integration') into one canonical 'Integration / Routing' section and reference it elsewhere.

Add explicit validate-gate steps to the Project Planning Template and batch workflow (e.g., 'Validate parsed output against the schema before proceeding to render') to raise workflow clarity.

Dimension	Reasoning	Score
Conciseness	The body is dense and avoids explaining concepts Claude already knows, but the ownership/routing statements are repeated three times (the description's routing, the 'When to Activate' do-not-activate list, and the full 'Integration' section), so it is 'mostly efficient but could be tightened' rather than every token earning its place at score 3.	2 / 3
Actionability	It gives concrete guidance — a cost formula, named pipeline stages, a file-system layout, and a 5-step planning template — but provides no in-body executable code and leaves the existing scripts/pipeline_template.py bundle unlinked, so key executable detail is missing per the score-2 anchor.	2 / 3
Workflow Clarity	A clear 5-stage sequence and ordered planning template are present, with a manual-prototype gate and a delete-and-rerun feedback loop, but explicit validate-then-proceed checkpoints in the batch execution flow are largely implicit; per the batch-operation scoring note this caps at 2 rather than 3.	2 / 3
Progressive Disclosure	The two references are well-signaled with 'Read when:' guidance (a score-3 pattern), but the provided scripts/pipeline_template.py bundle is never linked from the body and ~300 lines of detailed-topics/planning content that could live in references are inline, matching 'some structure but could be better organized.'	2 / 3
	Total	8 / 12 Passed

Description

85%

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 is specific, complete, and well-differentiated, with an explicit 'Use this when...' trigger and sibling-routing that sharply bounds its scope. Its only weakness is trigger-term naturalness: the keywords are domain-technical rather than phrases a user would naturally say.

Suggestions

Add user-natural trigger phrases to the 'when' clause (e.g., 'how much will this LLM project cost,' 'should I build this with an LLM,' 'how should I structure this pipeline') so it matches how users actually ask for help.

Soften or contextualize jargon like 'task-model fit' and 'primitive for the task at hand' with plainer equivalents to broaden natural-keyword coverage.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete project-level actions — 'whether an LLM is the right primitive,' 'token and cost estimation,' 'choosing between single-agent and multi-agent,' 'structured output design for downstream parsing' — matching the score-3 anchor of multiple specific concrete actions rather than the partial coverage of score 2.	3 / 3
Completeness	Explicitly answers what ('project-level decisions about LLM-powered systems: whether an LLM is the right primitive...') and when ('Use this when the unit of work is a whole project or a multi-stage pipeline'), satisfying the score-3 anchor for both with an explicit trigger clause.	3 / 3
Trigger Term Quality	Contains relevant domain keywords ('multi-stage batch or agent pipeline,' 'token and cost estimation,' 'single-agent and multi-agent') but they skew technical and lack common natural user phrasings, so it lands at 'some relevant keywords but missing common variations' rather than full coverage at score 3.	2 / 3
Distinctiveness Conflict Risk	A clear niche ('whole project or a multi-stage pipeline') is reinforced by explicit routing away from siblings ('Route individual tool design to tool-design and individual skill-loading or context-budget tactics to context-optimization'), making conflict unlikely per the score-3 anchor.	3 / 3
	Total	11 / 12 Passed

Validation

100%

Warnings & errors only

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.

Repository: muratcankoylan/Agent-Skills-for-Context-Engineering
Commit: c578e85

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

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.