Implement Feature
tddworks/SkillsManager
Guide for implementing features following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.
Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install tddworks/ClaudeBar implement-feature --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .claude/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-featureType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install tddworks/ClaudeBar implement-feature --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/implement-feature .agents/skills/implement-feature && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .agents/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install tddworks/ClaudeBar implement-feature --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/implement-feature .cursor/skills/implement-feature && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .cursor/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/tddworks/ClaudeBar.git --path .claude/skills/implement-feature--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install tddworks/ClaudeBar implement-feature --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/implement-feature .gemini/skills/implement-feature && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .gemini/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install tddworks/ClaudeBar implement-featureInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/implement-feature .github/skills/implement-feature && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .github/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add tddworks/ClaudeBar --skill implement-feature -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install tddworks/ClaudeBar implement-feature --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/tddworks/ClaudeBar.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/implement-feature .opencode/skills/implement-feature && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "implement-feature" agent skill from https://github.com/tddworks/ClaudeBar/tree/main/.claude/skills/implement-feature into .opencode/skills/implement-feature/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement-feature", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
implement-featureGuide 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. 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.
Read from SKILL.md and the folder at commit 35486e8. It shows what the files ask for, not the result of running them.
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.
Shell commands in SKILL.md call:
xcodebuildFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from tddworks/ClaudeBar at commit 35486e8, republished under its Apache-2.0 licence (© tddworks). 1,126 words, ~4,090 tokens.
.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.Implement features using architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.
┌─────────────────────────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────────────────────────┘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).
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:
| Question | If 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.
Identify:
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 …) │ │
│ └─────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘List each component with:
Example:
| Component | Purpose | Inputs | Outputs | Dependencies |
|----------------|------------------------|-----------------|----------------|-----------------|
| AddedAccounts | Validate a login folder| folder path | account config | DataSources |
| identity rule | Fail closed on swaps | credential | UsageError | — |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:
Do NOT proceed to Phase 1 until user explicitly approves.
Domain models encapsulate behavior, not just data:
// 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 }
}Views consume domain models directly from QuotaMonitor:
// 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)
}
}
}Ports for what lies outside the app live at a module's root and are
@Mockable; their implementations are internal in Internal/:
@Mockable
public protocol NetworkClient: Sendable {
func request(_ request: URLRequest) async throws -> (Data, URLResponse)
}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:
| Where | Holds | Tests |
|---|---|---|
Modules/Providers/Resources/Providers/<id>.json (+ .js) | every built-in provider: where the key is, how to fetch, how to read | Modules/Providers/Tests/ (golden tests over StubbedProvider / ClaudeHarness) |
Modules/Providers/Sources | ProviderCatalog (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/Sources | DataSource 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 runners | Modules/DataSources/Tests/ |
Modules/Quotas/Sources | the 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/AWSClients | the AWS SDK behind DataSources' CloudWatchClient and PriceCatalog ports | Modules/AWSClients/Tests/ |
Sources/Domain | QuotaMonitor, Notify!, sessions, In use's NewSessions | Tests/DomainTests/ |
Sources/Infrastructure | storage, notifications, hooks, the shell environment, Claude's guest-pass runner | Tests/InfrastructureTests/ |
Sources/App | SwiftUI views reading the domain directly; ClaudeBarApp.init, the composition root, which builds the Engine and names no provider | Tests/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:
Internal/, one factory enum per module (DataSources.make, ProviderFactory.make)@Mockable ports; Chicago-school tests assert on stateQuotaMonitor and Provider directlydataSourceKind, isOn) before a new sub-protocolName 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 and computed properties:
@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)
}
}Stub dependencies to return data, assert on resulting state:
@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)
}
}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.
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/ClaudeAPITestsnil when not declared), extension point@Mockable for external dependenciesInternal/scripts/demo-screenshots.sh) for UI changesxcodebuild 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
SKILL.md and 4 other files (references) in .claude/skills/implement-feature of tddworks/ClaudeBar.
Open the folder on GitHubat commit 35486e8
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Implement Feature this skilltddworks/ClaudeBar | 1.5k | — | ~4.1k | Automated safety check: Pass | Apache-2.0 | |
| Implement Featuretddworks/SkillsManager | 169 | — | ~2.6k | Automated safety check: Pass | None | |
| iOS Testingpproenca/dot-skills | 214 | — | ~2.1k | Automated safety check: Pass | MIT | |
| Swiftui Expert SkillAFK-surf/OpenBridge | 430 | 2 repos | ~3.9k | Automated safety check: Pass | MIT | |
| macOS DevelopmentKartikLabhshetwar/better-shot | 2.4k | 2 repos | ~735 | Automated safety check: Pass | Custom licence | |
| Swiftui AnimationAstraFoundry/KumoApp | 290 | — | ~4.1k | Automated safety check: Pass | AGPL-3.0 |
tddworks/SkillsManager
Guide for implementing features following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns.
pproenca/dot-skills
Testing practices for iOS 26 / Swift 6.2 clinic modular MVVM-C applications.
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.
KartikLabhshetwar/better-shot
Comprehensive macOS development guidance including Swift 6+, SwiftUI, SwiftData, architecture patterns, AppKit bridging, and macOS 26 Tahoe APIs.
AstraFoundry/KumoApp
Implement, review, or improve SwiftUI animations and transitions.
microsoft/SwiftStreamingMarkdown
Record and validate swift-snapshot-testing snapshots in the SwiftStreamingMarkdown package: regenerate reference PNGs, run snapshot tests, and diff failed snapshots.
tddworks/ClaudeBar
Add an AI provider to ClaudeBar as a JSON definition run by the one generic Provider and DataSource.
tddworks/ClaudeBar
Guide for adding new report cards to ClaudeBar that analyze local data sources and display metrics with comparison deltas.
tddworks/ClaudeBar
Manage ClaudeBar's GitHub Actions CI/CD pipelines: build, test, and release workflows.
tddworks/ClaudeBar
Guide for fixing bugs in ClaudeBar following Chicago School TDD and rich domain design.
tddworks/ClaudeBar
Guide for making improvements to existing ClaudeBar functionality using TDD.
Categories
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.
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.
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.
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.
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.
Going by SKILL.md and its folder, Implement Feature needs the command-line tools its instructions call (xcodebuild).
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.
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.
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.
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.
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.
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.