backend-development-feature-development
Orchestrate end-to-end backend feature development from requirements to deployment. Use when coordinating multi-phase feature delivery across teams and services.
34
29%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/backend-development-feature-development/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description suffers from excessive abstraction and buzzword-heavy language ('orchestrate', 'end-to-end', 'multi-phase feature delivery') without specifying any concrete actions or deliverables. While it includes a 'Use when' clause, both the capability statement and the trigger guidance are too vague to help Claude distinguish this skill from other backend or project management skills. The description reads more like a job posting than a functional skill description.
Suggestions
Replace abstract language with specific concrete actions, e.g., 'Generates API endpoints, database schemas, service contracts, and deployment configurations for new backend features.'
Add distinct trigger terms users would naturally use, such as 'new feature', 'API design', 'service architecture', 'backend scaffold', 'microservice', or specific file types/frameworks.
Make the 'Use when' clause more specific with concrete scenarios, e.g., 'Use when the user asks to build a new backend feature, scaffold a service, or coordinate changes across multiple backend services.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language like 'orchestrate end-to-end backend feature development' and 'coordinating multi-phase feature delivery' without listing any concrete actions. There are no specific capabilities mentioned—no mention of what actual tasks are performed (e.g., writing APIs, creating database migrations, configuring CI/CD pipelines). | 1 / 3 |
Completeness | It has a 'Use when' clause addressing the 'when' question, and the first sentence loosely addresses 'what'. However, the 'what' is extremely vague ('orchestrate end-to-end backend feature development') and the 'when' is equally abstract ('coordinating multi-phase feature delivery across teams and services'), providing no concrete triggers. | 2 / 3 |
Trigger Term Quality | Contains some relevant keywords like 'backend', 'feature development', 'requirements', 'deployment', and 'teams and services', but these are fairly generic. Missing natural user terms like 'API', 'microservices', 'database', 'endpoint', 'service integration', or specific technology references users would actually say. | 2 / 3 |
Distinctiveness Conflict Risk | The description is very generic and could easily conflict with any skill related to backend development, project management, deployment, or feature planning. 'End-to-end backend feature development' and 'multi-phase feature delivery' are broad enough to overlap with numerous other skills. | 1 / 3 |
Total | 6 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is an ambitious attempt to orchestrate a full feature development lifecycle but suffers from excessive verbosity, lack of executable specifics, and monolithic structure. It reads more like a project management playbook than a concise, actionable skill—listing many options and phases without providing the concrete mechanics (actual commands, validation gates, data-passing patterns) needed for reliable execution. The content would benefit significantly from aggressive trimming, adding explicit validation checkpoints, and splitting into multiple referenced files.
Suggestions
Reduce the SKILL.md to a concise overview (~50-80 lines) with phase summaries, and move detailed phase instructions, configuration options, and execution parameters into separate referenced files (e.g., PHASES.md, CONFIG.md).
Add explicit validation checkpoints between phases (e.g., 'Verify requirements sign-off before proceeding to Phase 2', 'Confirm all tests pass before deployment') with concrete verification commands or criteria.
Remove the extended thinking block and trim configuration/parameter listings to only what's non-obvious—Claude already understands concepts like canary deployments, TDD, and feature flags.
Clarify the data-passing mechanism between phases with a concrete example showing how output from one subagent step is actually passed to the next, rather than using vague '[include X from step N]' placeholders.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~200+ lines. The extended thinking block is unnecessary filler. Configuration options, execution parameters, and deployment strategies are exhaustively listed but largely describe concepts Claude already knows. Much of this reads like a project management template rather than actionable skill instructions. | 1 / 3 |
Actionability | Each phase provides specific subagent_type references and prompt templates, which gives some concrete guidance. However, there is no executable code, no real commands, and the prompts are template-like with placeholders ($ARGUMENTS, [from step X]) that are vague about actual data passing mechanics. The guidance describes what to do at a high level but lacks copy-paste-ready implementation details. | 2 / 3 |
Workflow Clarity | The 12-step phased workflow is clearly sequenced with logical dependencies between phases. However, validation checkpoints are weak—there are no explicit 'stop and verify before proceeding' gates between phases. The rollback strategy section lists timeframes but lacks concrete commands or verification steps. For a workflow involving destructive operations (deployments, data migrations), the absence of explicit feedback loops caps this at 2. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no bundle files or external references. All 12 phases, configuration options, parameters, success criteria, and rollback strategies are inlined into a single massive file. Content like configuration options, execution parameters, and per-phase details would benefit greatly from being split into separate referenced files. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- sickn33/antigravity-awesome-skills
- Commit
8854d4e
- 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.