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.
57
38%
Does it follow best practices?
Impact
89%
2.22xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/backend-development-feature-development/SKILL.mdQuality
Discovery
49%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 follows good structural conventions with an explicit 'Use when...' clause, but suffers from vague, buzzword-heavy language that fails to specify concrete actions or carve out a distinct niche. Terms like 'orchestrate', 'end-to-end', and 'multi-phase feature delivery' sound impressive but don't help Claude distinguish this skill from other backend or project management skills.
Suggestions
Replace abstract language with specific concrete actions, e.g., 'Generates API designs, writes database schemas, creates service integration plans, and produces deployment configurations'.
Add natural trigger terms users would actually say, such as 'new feature', 'API endpoint', 'microservice', 'backend project', 'service architecture', 'sprint planning'.
Narrow the scope to reduce conflict risk — specify what kind of backend features (e.g., REST APIs, event-driven services) or what distinguishes this from a general project management or code generation skill.
| 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. No specific tasks like 'generate API endpoints', 'write database migrations', or 'create service contracts' are mentioned. | 1 / 3 |
Completeness | The description does explicitly answer both 'what' ('Orchestrate end-to-end backend feature development from requirements to deployment') and 'when' ('Use when coordinating multi-phase feature delivery across teams and services'). It has an explicit 'Use when...' clause. | 3 / 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', 'integration', or specific technology references users would actually say. | 2 / 3 |
Distinctiveness Conflict Risk | The description is extremely broad and would conflict with many skills — any backend development skill, deployment skill, project management skill, or service coordination skill could overlap. 'End-to-end backend feature development' is too generic to carve out a clear niche. | 1 / 3 |
Total | 7 / 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 a comprehensive but overly verbose orchestration document that reads more like a project management playbook than a concise skill instruction. While it provides good structural sequencing across 12 steps with clear agent delegation patterns, it suffers from excessive inline detail, lack of validation checkpoints between phases, and no progressive disclosure to separate reference material from core workflow. The content would benefit significantly from being condensed to a lean overview with detailed phase instructions in separate files.
Suggestions
Reduce the main skill to a concise overview (~50 lines) with phase summaries, and move detailed step instructions, configuration options, and parameter lists into separate referenced files (e.g., PHASES.md, CONFIG.md).
Remove the extended thinking block and configuration enumerations that Claude already understands—focus only on project-specific decision points and constraints.
Add explicit validation checkpoints between phases (e.g., 'Phase 2 gate: Confirm architecture review approved before starting implementation') and feedback loops for failure recovery at each phase transition.
Replace verbose prompt templates with concise structured templates showing only the unique context-passing pattern, not full natural language prompts that Claude can generate itself.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~200+ lines. The extended thinking block is unnecessary filler. Configuration options, execution parameters, and deployment strategies are exhaustive enumerations that Claude already understands. Much of this reads like a project management document rather than a concise skill instruction. | 1 / 3 |
Actionability | Provides specific subagent_type references and prompt templates which give concrete guidance, but no actual executable code or commands. The prompts are templates with placeholders rather than copy-paste ready instructions. The steps describe what to ask agents to do rather than how to do things directly. | 2 / 3 |
Workflow Clarity | The 4-phase, 12-step sequence is clearly laid out with logical ordering and each step references outputs from previous steps. However, there are no explicit validation checkpoints or feedback loops between phases—no 'if step fails, do X' guidance except in the final rollback section. For a workflow involving destructive operations like deployments and data migrations, this caps at 2. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. All 12 detailed phase steps, configuration options, execution parameters, success criteria, and rollback strategies are inlined. The configuration options, parameter lists, and detailed phase instructions should be split into separate reference 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
43280f9
- 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.