implement-feature

Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns. Use this skill when: (1) Adding new functionality to the app (2) Creating domain models that follow user's mental model (3) Building SwiftUI views that consume domain models directly (4) User asks "how do I implement X" or "add feature Y" (5) Implementing any feature that spans Domain, Infrastructure, and App layers

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

77%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-organized, highly actionable skill body with concrete Swift 6.2 patterns, a clear gated workflow, and clean one-level-deep references. Its lone weakness is structural redundancy across the Core Principles, Architecture, and overview-diagram sections.

Suggestions

State the "No ViewModel / views consume domain directly" pattern once (e.g. in Core Principles) and reference it from the Architecture table and Key patterns list instead of repeating it.

Replace the generic FeatureModel/FeatureService placeholders with a single consistent running example (the UsageQuota/QuotaMonitor one already in the doc) so the code is copy-paste concrete.

Trim the Workflow Overview ASCII diagram or fold it into the Phase 0/1/2/3 headings to remove the duplication with the prose workflow that follows.

Dimension	Reasoning	Score
Conciseness	The body is information-dense with no padding of concepts Claude already knows, but it repeats the same points across sections — "No ViewModel/AppState layer" appears in Core Principles, the Architecture table, and the Key patterns list, and the Workflow Overview ASCII diagram restates the phase structure spelled out below it — so it could be tightened.	3 / 5
Actionability	Provides concrete, executable Swift — a rich UsageQuota model, a QuotaMonitor actor with nonisolated delegation methods, a SwiftUI view consuming it, an @Mockable protocol, and @Test suites with given(...).willReturn stubbing — though some examples use generic placeholders (FeatureModel, FeatureService, FeatureServiceTests) rather than fully concrete types.	4 / 5
Workflow Clarity	The Phase 0 → 1 → 2 → 3 sequence is explicit with a hard approval checkpoint ("Do NOT proceed to Phase 1 until user explicitly approves" plus an AskUserQuestion Approve/Modify gate), a Red/Green/Refactor feedback loop, and a closing checklist that verifies with `swift test`.	5 / 5
Progressive Disclosure	All four referenced files (architecture-diagrams.md, swift-observable.md, domain-models.md, tdd-patterns.md) exist and are one level deep, each clearly signaled in the References section with a short descriptor, while the body stays an overview that delegates deep examples to those files.	5 / 5
	Total	17 / 20 Passed

Description

88%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, well-structured description that clearly states what the skill does and gives five explicit, mostly natural trigger conditions. Its main weakness is reliance on domain jargon and a couple of generic phrasings that slightly limit trigger-term breadth and distinctiveness.

Suggestions

Add a couple of plain-language synonyms/variants (e.g. "building a new screen", "wiring up a provider") alongside the SwiftUI/domain-model jargon to broaden natural trigger coverage.

Tie the generic "how do I implement X" trigger more tightly to the ClaudeBar context (e.g. "in ClaudeBar") to reduce overlap with general coding skills.

Consider adding the file/area cues users actually mention (e.g. Sources/Domain, Sources/Infrastructure) as trigger terms to sharpen distinctiveness.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions across five numbered cases — "Adding new functionality", "Creating domain models", "Building SwiftUI views", responding to "how do I implement X", and spanning "Domain, Infrastructure, and App layers" — giving comprehensive coverage of what the skill does.	5 / 5
Completeness	Explicitly answers both: the "what" ("Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns") and the "when" via a five-clause "Use this skill when:" list with concrete trigger phrases.	5 / 5
Trigger Term Quality	Includes the natural phrases a user would actually say ("User asks 'how do I implement X' or 'add feature Y'") plus several task-oriented triggers, but leans on specialized jargon (SwiftUI, domain models) and omits common synonyms or variations, so it stops short of comprehensive.	4 / 5
Distinctiveness Conflict Risk	The ClaudeBar-specific framing and the layer-spanning trigger carve a clear niche, but triggers like "how do I implement X" / "add feature Y" are generic enough to risk minor overlap with general feature-implementation coding skills.	4 / 5
	Total	18 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 1 suspicious	Warning

	Total	15 / 16 Passed

Repository: tddworks/ClaudeBar
Path: .claude/skills/implement-feature/SKILL.md
Commit: 80de433

Reviewed: 4 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.