Agent skill

Implement Feature

by tddworks in tddworks/ClaudeBar

Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.

Apache-2.0Auto-check passedMobile

Install Implement Feature

skills CLI
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install tddworks/ClaudeBar implement-feature --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/implement-feature .claude/skills/implement-feature && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
implement-feature
GitHub stars
1.5k
Token cost
~4.1k tokens
SKILL.md length
1,126 words
Files
5 (incl. references)
Skills in repo
6
Repo updated
First seen
Licence
Apache-2.0

At a glance

Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.

  • Adding new functionality to the app
  • SKILL.md covers Workflow Overview, Phase 0: Architecture Design…, Core Principles and Architecture, plus 3 more sections
  • Calls xcodebuild
  • Creating domain models that follow users mental model

What it does

Implement Feature is an agent skill from tddworks/ClaudeBar. 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 modules (DataSources, Providers, Quotas) and the App

Its SKILL.md is about 4.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including reference files (for example `references/architecture-diagrams.md`, `references/domain-models.md` and `references/swift-observable.md`).

It sits in Mobile, covering iOS development and Test-driven development. It works with Swift and SwiftUI. The repository describes itself as: A macOS menu bar application that monitors AI coding assistant usage quotas. Keep track of your Claude, Codex, Antigravity ,and Gemini usage at a glance. The licence is Apache-2.0.

When your agent uses it

  • Adding new functionality to the app
  • Creating domain models that follow users mental model
  • Building SwiftUI views that consume domain models directly
  • User asks how do I implement X

Example prompts

  • “how do I implement X”
  • “add feature Y”
  • “/implement-feature”

What it can do on your machine

Read from SKILL.md and the folder at commit 35486e8. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • xcodebuild

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Implement Feature loads about 4.1k tokens when it runs, and up to ~9.6k if it reads all its reference files. Until then it costs about 120 tokens; SKILL.md has 1,126 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~120
When it runs · the whole SKILL.md, loaded when a task matches
~4.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~9.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from tddworks/ClaudeBar at commit 35486e8, republished under its Apache-2.0 licence (© tddworks). 1,126 words, ~4,090 tokens.

Download SKILL.mdSave it as .claude/skills/implement-feature/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
implement-feature
description
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 modules (DataSources, Providers, Quotas) and the App

Implement Feature in ClaudeBar

Implement features using architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.

Workflow Overview

┌─────────────────────────────────────────────────────────────┐
│  1. ARCHITECTURE DESIGN (Required - User Approval Needed)  │
├─────────────────────────────────────────────────────────────┤
│  • Read the design docs — they are the source of truth     │
│  • Place the feature: owner, capability, extension point    │
│  • Write the design change into the docs first              │
│  • Analyze requirements                                     │
│  • Create component diagram                                 │
│  • Show data flow and interactions                          │
│  • Present to user for review                               │
│  • Wait for approval before proceeding                      │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼ (User Approves)
┌─────────────────────────────────────────────────────────────┐
│  2. TDD IMPLEMENTATION                                      │
├─────────────────────────────────────────────────────────────┤
│  • Model tests → models (Quotas / Providers / Domain)       │
│  • Module tests → generic rules and workers (DataSources)   │
│  • Views, reading the domain directly                       │
└─────────────────────────────────────────────────────────────┘

Phase 0: Architecture Design (MANDATORY)

Before writing any code, design it in the docs and get user approval. The design docs are the source of truth (AGENTS.md → Design docs are the source of truth).

Step 0: Read the design docs, and place the feature in them

Read the design in order (ARCHITECTURE.md maps it): USER_JOURNEYS.md (the person and the moment), CANONICAL_MODEL.md (the tree, the words, each law and its owner, owned vs offered), TARGET_ARCHITECTURE.md (the pieces and their one job, the flows), then any docs/features/<x>/design.md it touches. Then answer:

QuestionIf yes
Does it answer another question than the product's lifecycle?it is a capability (CANONICAL §2.1): declared in the definition, its own types, reached through a handle that is nil when not declared — never a flag on Provider, never chosen by a provider's name. A runner outside the modules is supplied by the Engine (TARGET_ARCHITECTURE §10)
Does a provider need something the definition can't say?a generic rule or worker in DataSources (ENGINE_DESIGN), then a line of JSON — never a Swift line that names the provider
Does it react to a refresh, a selection, a setting?it observes an extension point (e.g. QuotaMonitor.onRefreshed) — the Monitor is not edited for it
Does it notify?its own port in Alerting — not a new method on an existing alerter
Is a law missing, or owned twice?add it to CANONICAL §5 with one owner

When the docs don't cover it, write the change into them first (tree lines, laws with owners, a pieces table, a TARGET section) — that doc change is the architecture you present in Step 4. Code that disagrees with the docs is behind; don't bend the design to it.

Step 1: Analyze Requirements

Identify:

  • What new models/types are needed
  • Which existing components will be modified
  • Data flow between components
  • External dependencies (CLI, API, etc.)
Step 2: Create Architecture Diagram

Use ASCII diagram showing all components and their interactions:

Example: Codex accounts (#326) — a definition change plus generic pieces

┌──────────────────────────────────────────────────────────────────────┐
│                            ARCHITECTURE                               │
├──────────────────────────────────────────────────────────────────────┤
│  Resources (data)        Modules (Swift, no vendor names)    App     │
│                                                                      │
│  ┌──────────────┐   ┌─────────────────────────────┐   ┌───────────┐  │
│  │ codex.json   │──▶│ Providers                   │──▶│ Accounts  │  │
│  │  accounts:   │   │  ProviderCatalog.detect()   │   │ card      │  │
│  │  folder, ids │   │  ProviderDefinition.Accounts│   └───────────┘  │
│  │  dataSources │   │  Provider owns its Accounts │                  │
│  └──────────────┘   └──────────────┬──────────────┘                  │
│                                    │                                 │
│                     ┌──────────────▼──────────────┐                  │
│                     │ DataSources                 │                  │
│                     │  identity, requiresFiles,   │                  │
│                     │  JSON-RPC `then`, env       │                  │
│                     └──────────────┬──────────────┘                  │
│                                    ▼                                 │
│                     ┌─────────────────────────────┐                  │
│                     │ Quotas  (UsageSnapshot …)   │                  │
│                     └─────────────────────────────┘                  │
└──────────────────────────────────────────────────────────────────────┘
Step 3: Document Component Interactions

List each component with:

  • Purpose: What it does
  • Inputs: What it receives
  • Outputs: What it produces
  • Dependencies: What it needs
Example:

| Component      | Purpose                | Inputs          | Outputs        | Dependencies    |
|----------------|------------------------|-----------------|----------------|-----------------|
| AddedAccounts  | Validate a login folder| folder path     | account config | DataSources     |
| identity rule  | Fail closed on swaps   | credential      | UsageError     | —               |
Step 4: Present for User Approval

IMPORTANT: Always ask user to confirm the design is correct before implementing — the doc change (tree, laws and owners, pieces), the diagram, and for UI a mockup in design-concept/<feature>/ on mock data.

Use AskUserQuestion tool with options:

  • "Approve - proceed with implementation"
  • "Modify - I have feedback on the design"

Do NOT proceed to Phase 1 until user explicitly approves.


Core Principles

1. Rich Domain Models (User's Mental Model)

Domain models encapsulate behavior, not just data:

swift
// Rich domain model with behavior
public struct UsageQuota: Sendable, Equatable {
    public let percentRemaining: Double

    // Domain behavior - computed from state
    public var status: QuotaStatus {
        QuotaStatus.from(percentRemaining: percentRemaining)
    }

    public var isDepleted: Bool { percentRemaining <= 0 }
    public var needsAttention: Bool { status.needsAttention }
}
2. Swift 6.2 Patterns (No ViewModel/AppState Layer)

Views consume domain models directly from QuotaMonitor:

swift
// QuotaMonitor is the single source of truth
@MainActor @Observable
public final class QuotaMonitor {
    // The providers you keep: add, delete, order, the derived lineup
    public let providers: Providers

    public var logins: [Account]   // every login
    public var lineup: [Account]   // the lineup
    public func login(id: String) -> Account?

    // Selection state
    public var selectedProviderId: String
    public var selectedLogin: Account?
    public var selectedProviderStatus: QuotaStatus
}

// Views consume domain directly - NO AppState layer
struct MenuContentView: View {
    let monitor: QuotaMonitor  // Injected from app

    var body: some View {
        // Use delegation methods, not monitor.providers.enabled
        ForEach(monitor.lineup, id: \.id) { login in
            ProviderPill(provider: login)
        }
    }
}
3. Protocol-Based DI with @Mockable

Ports for what lies outside the app live at a module's root and are @Mockable; their implementations are internal in Internal/:

swift
@Mockable
public protocol NetworkClient: Sendable {
    func request(_ request: URLRequest) async throws -> (Data, URLResponse)
}

Architecture

Reference: MODULAR_DESIGN.md (modules) · TARGET_ARCHITECTURE.md (how a provider runs) · ARCHITECTURE.md (the app layers)

The code is mid-migration from three layers to modules. Find which side the behaviour lives on before you change it:

WhereHoldsTests
Modules/Providers/Resources/Providers/<id>.json (+ .js)every built-in provider: where the key is, how to fetch, how to readModules/Providers/Tests/ (golden tests over StubbedProvider / ClaudeHarness)
Modules/Providers/SourcesProviderCatalog (finds every definition), Engine (the shared ports), Provider (the one lifecycle: refresh, fallback chain, accounts), ProviderDefinition, settings and account contracts, the capabilities (UsageHistory, GuestPasses, InUse)Modules/Providers/Tests/
Modules/DataSources/SourcesDataSource and its workers: credential lookups (environment, login shell, files, Keychain, browser cookies and storage, SQLite) and refreshes; HTTP, steps, JSON-RPC, terminal, command, file, directory, SQLite, local-server and CloudWatch fetches; JSON / text / script mapping; UsageLog and its log readers; the process runnersModules/DataSources/Tests/
Modules/Quotas/Sourcesthe usage model: UsageSnapshot, UsageQuota, UsageError, plans, costs, DailyUsageStat / DailyUsageReport (interim shapes, see each type's - Note:)Tests/DomainTests/ and the tests of the module that uses it
Modules/AWSClientsthe AWS SDK behind DataSources' CloudWatchClient and PriceCatalog portsModules/AWSClients/Tests/
Sources/DomainQuotaMonitor, Notify!, sessions, In use's NewSessionsTests/DomainTests/
Sources/Infrastructurestorage, notifications, hooks, the shell environment, Claude's guest-pass runnerTests/InfrastructureTests/
Sources/AppSwiftUI views reading the domain directly; ClaudeBarApp.init, the composition root, which builds the Engine and names no providerTests/AppTests/, Tests/AcceptanceTests/

A bug in a migrated provider is fixed in its JSON, or generically in DataSources, never with vendor-named Swift. Modules never import Domain.

Key patterns:

  • Modules by context — the domain at a module's root, its implementation in Internal/, one factory enum per module (DataSources.make, ProviderFactory.make)
  • Providers are data — a feature a provider needs becomes a generic rule or worker, then a line of JSON
  • Protocol-based DI — @Mockable ports; Chicago-school tests assert on state
  • No ViewModel layer — views read QuotaMonitor and Provider directly
  • Settings — generic per-provider values (dataSourceKind, isOn) before a new sub-protocol
Show full SKILL.md (344 more words)Show less

TDD Workflow (Chicago School)

Name each test should <outcome> [when <situation>], in the person's words, never a method, type or mechanism verb → Naming tests.

We follow Chicago school TDD (state-based testing):

  • Test state changes and return values, not interactions
  • Focus on the "what" (observable outcomes), not the "how" (method calls)
  • Mocks stub dependencies to return data, not to verify calls
  • Design emerges from tests (emergent design)
Phase 1: Domain Model Tests

Test state and computed properties:

swift
@Suite
struct FeatureModelTests {
    @Test func `should be normal when half is left`() {
        // Given - set up initial state
        let model = FeatureModel(value: 50)

        // When/Then - verify state/return value
        #expect(model.status == .normal)
    }

    @Test func `should have 70 left and stay healthy after using 30 of 100`() {
        // Given
        var model = FeatureModel(value: 100)

        // When - perform action
        model.consume(30)

        // Then - verify new state
        #expect(model.value == 70)
        #expect(model.status == .healthy)
    }
}
Phase 2: Module Tests (DataSources / Providers)

Stub dependencies to return data, assert on resulting state:

swift
@Suite
struct FeatureServiceTests {
    @Test func `should load three items when the service answers`() async throws {
        // Given - stub dependency to return data (not verify calls)
        let mockClient = MockNetworkClient()
        given(mockClient).fetch(any()).willReturn(validResponseData)

        let service = FeatureService(client: mockClient)

        // When
        let result = try await service.fetch()

        // Then - verify returned state, not interactions
        #expect(result.items.count == 3)
        #expect(result.status == .loaded)
    }
}
Phase 3: Integration

Create the views. ClaudeBarApp.init is the composition root: it builds the Engine (the ports every provider shares) and calls ProviderCatalog().detect(). A provider is never wired there; a new port is a new Engine field, built once in init (keep startup work there, never in ClaudeBarMain). Acceptance specs in Tests/AcceptanceTests/ compose real modules with stubbed ports.

bash
tuist test Providers         # one module's tests while working (schemes: Providers, DataSources, Domain, Infrastructure, AppTests, AcceptanceTests)
# tuist caches results; the final check, and a forced re-run of one suite, use xcodebuild:
xcodebuild test -workspace ClaudeBar.xcworkspace -scheme ClaudeBar-Workspace -destination 'platform=macOS,arch=arm64'
xcodebuild test -workspace ClaudeBar.xcworkspace -scheme ClaudeBar-Workspace \
  -destination 'platform=macOS,arch=arm64' -only-testing:ProvidersTests/ClaudeAPITests

References

Checklist

Architecture Design (Phase 0)
  • Read CANONICAL_MODEL, TARGET_ARCHITECTURE and the feature's design.md
  • Place it: owner, capability (handle nil when not declared), extension point
  • Write the design change into the docs first
  • Analyze requirements and identify components
  • Create ASCII architecture diagram with component interactions
  • Document component table (purpose, inputs, outputs, dependencies)
  • Get user approval before proceeding
Implementation (Phases 1-3) - Chicago School TDD
  • Write failing test asserting expected STATE (Red)
  • Write minimal code to pass the test (Green)
  • Refactor while keeping tests green
  • Put each type in the module MODULAR_DESIGN.md names (never a vendor-named type in a module)
  • Test state changes and return values (not interactions)
  • Define protocols with @Mockable for external dependencies
  • Stub mocks to return data, assert on resulting state
  • Implement ports in the module's Internal/
  • Create views consuming domain models directly
  • Views render and tell only — no comparing, counting or reading quotas to decide
  • Docs updated in the same change (status, build truth, laws)
  • Real UI screenshots on mock data (scripts/demo-screenshots.sh) for UI changes
  • Full xcodebuild test green (tuist test skips cached targets)

© tddworks, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files (references) in .claude/skills/implement-feature of tddworks/ClaudeBar.

  • SKILL.md
  • references/architecture-diagrams.md
  • references/domain-models.md
  • references/swift-observable.md
  • references/tdd-patterns.md

Open the folder on GitHubat commit 35486e8

Compare with similar skills

Implement Feature next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Implement Feature compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Implement Feature this skilltddworks/ClaudeBar1.5k—~4.1kAutomated safety check: PassApache-2.0
Implement Featuretddworks/SkillsManager169—~2.6kAutomated safety check: PassNone
iOS Testingpproenca/dot-skills214—~2.1kAutomated safety check: PassMIT
Swiftui Expert SkillAFK-surf/OpenBridge4302 repos~3.9kAutomated safety check: PassMIT
macOS DevelopmentKartikLabhshetwar/better-shot2.4k2 repos~735Automated safety check: PassCustom licence
Swiftui AnimationAstraFoundry/KumoApp290—~4.1kAutomated safety check: PassAGPL-3.0

Similar skills

  • Implement Feature

    tddworks/SkillsManager

    Guide for implementing features following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.

    169 GitHub stars~2.6k tokensUpdated 4 mo ago
    MobileAuto-check passed
  • iOS Testing

    pproenca/dot-skills

    Testing practices for iOS 26 / Swift 6.2 clinic modular MVVM-C applications.

    214 GitHub stars~2.1k tokensUpdated 1 mo ago
    MobileAuto-check passed
  • Swiftui Expert Skill

    AFK-surf/OpenBridge

    Write, review, or improve SwiftUI code following best practices for state management, view composition, performance, modern APIs, Swift concurrency, and iOS 26+ Liquid Glass adoption.

    430 GitHub starsUsed in 2 repos~3.9k tokens
    MobileAuto-check passed
  • macOS Development

    KartikLabhshetwar/better-shot

    Comprehensive macOS development guidance including Swift 6+, SwiftUI, SwiftData, architecture patterns, AppKit bridging, and macOS 26 Tahoe APIs.

    2.4k GitHub starsUsed in 2 repos~735 tokens
    MobileAuto-check passed
  • Swiftui Animation

    AstraFoundry/KumoApp

    Implement, review, or improve SwiftUI animations and transitions.

    290 GitHub stars~4.1k tokensUpdated 4 mo ago
    MobileAuto-check passed
  • Snapshot Tests

    microsoft/SwiftStreamingMarkdown

    Official

    Record and validate swift-snapshot-testing snapshots in the SwiftStreamingMarkdown package: regenerate reference PNGs, run snapshot tests, and diff failed snapshots.

    377 GitHub stars~2.2k tokensUpdated 12 days ago
    MobileAuto-check passed

More from tddworks/ClaudeBar

  • Add Provider

    tddworks/ClaudeBar

    Add an AI provider to ClaudeBar as a JSON definition run by the one generic Provider and DataSource.

    1.5k GitHub stars~4.1k tokensUpdated today
    Auto-check passed
  • Add Report

    tddworks/ClaudeBar

    Guide for adding new report cards to ClaudeBar that analyze local data sources and display metrics with comparison deltas.

    1.5k GitHub stars~3.1k tokensUpdated today
    Auto-check passed
  • GitHub Actions

    tddworks/ClaudeBar

    Manage ClaudeBar's GitHub Actions CI/CD pipelines: build, test, and release workflows.

    1.5k GitHub stars~1k tokensUpdated today
    Auto-check passed
  • Fix Bug

    tddworks/ClaudeBar

    Guide for fixing bugs in ClaudeBar following Chicago School TDD and rich domain design.

    1.5k GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Improvement

    tddworks/ClaudeBar

    Guide for making improvements to existing ClaudeBar functionality using TDD.

    1.5k GitHub stars~2.1k tokensUpdated today
    Auto-check passed

Works with

Questions about Implement Feature

What does Implement Feature do?

Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns. Implement Feature is an agent skill from tddworks/ClaudeBar.2 patterns.

When should I use Implement Feature?

Implement Feature fits situations like: adding new functionality to the app; creating domain models that follow users mental model; building SwiftUI views that consume domain models directly; user asks how do I implement X.

How do I install Implement Feature in Claude Code?

Run `npx skills add tddworks/ClaudeBar --skill implement-feature -a claude-code`. Or copy the skill folder (.claude/skills/implement-feature in tddworks/ClaudeBar) into .claude/skills/implement-feature in your project. Claude Code loads it when a task matches its description.

How do I install Implement Feature in Codex?

Run `npx skills add tddworks/ClaudeBar --skill implement-feature -a codex`. Or copy the skill folder (.claude/skills/implement-feature in tddworks/ClaudeBar) into .agents/skills/implement-feature in your project. Codex loads it when a task matches its description.

Can I use Implement Feature in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add tddworks/ClaudeBar --skill implement-feature -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/implement-feature, .gemini/skills/implement-feature, .github/skills/implement-feature and .opencode/skills/implement-feature in your project.

What does Implement Feature need to run?

Going by SKILL.md and its folder, Implement Feature needs the command-line tools its instructions call (xcodebuild).

Does Implement Feature access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Implement Feature safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Implement Feature use?

Implement Feature is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Implement Feature use?

About 4.1k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 5.5k tokens, read only when the agent opens those files.

What are the alternatives to Implement Feature?

Skills that share tags, products or a category with Implement Feature: Implement Feature (tddworks/SkillsManager, 169 stars), iOS Testing (pproenca/dot-skills, 214 stars), Swiftui Expert Skill (AFK-surf/OpenBridge, 430 stars) and macOS Development (KartikLabhshetwar/better-shot, 2.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Implement Feature?

tddworks (a GitHub organization) maintains it in tddworks/ClaudeBar, which has 1,527 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 7, 2026.

Source: tddworks/ClaudeBar on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.