add-provider
Skill12 starsChanged 6 days agoMITView on GitHub
Plan or implement a MeterBar provider integration with verified source contracts, safe credentials, offline fixtures, and app/widget/CLI parity. Use for adding a provider or auditing a provider addition; does not authorize a new provider, credential access, or unsupported integrations.
18 other projects use a version of this.
Adopted by
Most recently taken up by
- SDSLeon/lightcodetheir own version, first seen Nov 8, 2026
- Porabuild/Poracodetheir own version, first seen Nov 8, 2026
- agentconfig/agentconfig.orgtheir own version, first seen Nov 8, 2026
- tddworks/ClaudeBartheir own version, first seen Nov 3, 2026
- Adham-Aly/quartermastertheir own version, first seen Nov 1, 2026
- Adham-Aly/implement-looptheir own version, first seen Nov 1, 2026
Used with
Projects with it also use add-tool, release-notes and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MicrosoftSkilladd-tool
Add a new tool to PilotSwarm. Covers defining the tool with defineTool(), registering it on the worker (worker-level or per-session), referencing it from the client via toolNames, and adding an integration test.
Also in 3 projects that use this
Microsoft AzureSkillrelease-notes
Author and update release notes for Azure App Configuration libraries and providers. USE FOR: write release notes, add release note entry, update release notes, draft release notes, new version release notes, format release notes. DO NOT USE FOR: generating changelogs from git history, writing internal engineering notes.
Also in 3 projects that use this
SentrySkillcommit
Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.
Also in 3 projects that use this
MicrosoftSkillrelease
Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).
Also in 3 projects that use this
Other versions18 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 18
- ThinkInAIXYZ/deepchat★ 6.4ksame name
- tddworks/ClaudeBar★ 1.6ksame name
- pydantic/genai-prices★ 411same name
- Porabuild/Poracode★ 121same name
- SDSLeon/lightcode★ 121same name
- agent-cli-framework/aclif★ 20same name
- hyhmrright/StockAI★ 14same name
- yerdaulet-damir/vibe-coding-rules★ 10same name
- kiminmonaco/ClaudeBar★ 8same name
- agentconfig/agentconfig.org★ 7same name
8 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- macos-menubar-appSkill
- verify-meterbarSkill
- xcode-swift-devSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 0 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Read AGENTS.md, .agents/memory/MEMORY.md, providers.md, conventions.md and the complete issue contract.
- Very specific: line 42
Use the repository's installed format/lint tools without reformatting unrelated files.
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Add a MeterBar provider
Deliver a provider whose supported account shapes, quota meaning and failure states agree across MeterBar's surfaces. A provider service that fetches successfully is only one part of this outcome.
Establish the contract before code
Read AGENTS.md, .agents/memory/MEMORY.md, providers.md, conventions.md and the complete issue contract. Provider additions need explicit task authorization; the repository's default deferral still applies. For a decision-complete issue, implement its settled choices and escalate gaps rather than redesigning the feature.
Research the provider's first-party documentation, official client/plugin source and API schema first. Record source URLs, revision/API version, verification date, auth scopes, request/response shape, account coverage, quota/reset units, pagination bounds and rate limits on the issue. Distinguish a documented public API from a first-party internal endpoint. A provider marketing plan is not proof of an API allowance.
Compare the relevant CodexBar integration as a secondary implementation witness after establishing the first-party contract. Note disagreements and fixture coverage; do not copy its credentials, assume its endpoint is supported, or treat its denominator/reset assumptions as evidence. If only an unofficial endpoint exists, state the maintenance risk and resolve feasibility in the issue before implementation.
Produce a support matrix for personal/managed/organization plans, documented quota, usage-only, unsupported account shape, missing permission, missing/expired/rejected credentials and malformed/drifted payloads. If no denominator is documented, report usage-only or unavailable with an authored reason. Never invent a cap from pricing, CLI/TUI prose or another account's entitlement. Unsupported optional integrations must be explicit capability decisions, not placeholders promising future support.
Set the credential/storage boundary now: approved credential source and precedence, provider-owned login/refresh, minimum scopes, allowed hosts, non-secret settings needed by CLI, and fields permitted in shared cache. Keep secrets in Keychain or read-only provider-owned storage; never write tokens, raw bodies or billing detail to fixtures, logs, diagnostics, errors or app-group state. Don't scan unrelated credentials or initiate login/refresh to prove feasibility. Credential-gated live probes require existing authorization and an available test account; record absence honestly.
Choose a current implementation lane
Search open issues/PRs before claiming the surface. Record owned paths on the issue and use a separate git wt tree under .worktrees/; preserve active work. Before adding a pattern, read three comparable service/parser/settings implementations on the chosen base and their tests. On master, start with CursorLocalService (the Cursor source of the xAI provider), OpenRouterService and GrokCLIUsageService (its Grok source); their credential and account models differ, so copy only the applicable seam.
Read the prepared stack when Kimi, Z.ai, Copilot or their reusable seams are relevant. Verify merge state and actual source at use time. Unmerged code is a dependency, not an available master API. Name required PRs, base branch and merge order; do not transplant a sibling's entire implementation or silently build against absent symbols. Resolve consequential support/auth choices before writing code.
Implement and prove parity
Use the parity map during implementation and again before delivery. Record each row as implemented with evidence, already covered by a generic path with a focused assertion, or unavailable with a capability/reason. Explicitly unavailable wake/reset/history/status integrations do not justify omitting the core app/widget/CLI/diagnostic/settings/notification surfaces.
Keep parsing pure and fixture-tested. Tolerate optional fields and documented numeric variants, reject unreadable shapes as parse drift, leave unknown cadence neutral, and omit uncapped/invalid limits. Maintain last-good metrics on refresh failure; distinguish auth rejection from parsing, transient transport and unsupported accounts. Disabled providers must perform no credential reads or network requests. New providers are opt-in, including existing installations whose stored hidden-provider set predates the new case.
Use ServiceSupport transport/isolation patterns and injectable dependencies. Apply @Published state on the main actor; do I/O/parsing off it. Preserve shared cache encoding/date strategy and stable CLI JSON tokens. Additional quota windows must survive generic row planning rather than disappearing behind a primary-window assumption. Safe errors and parse health must explain drift without including provider text.
Build redacted, deterministic fixtures from the first-party schema or authorized captures; label documented/synthetic versus live-captured provenance. Cover complete, missing, null, numeric-string, unknown enum/unit, invalid denominator/nonfinite values, malformed JSON, empty/unreadable payloads, reset boundaries, credential expiry, auth/envelope errors, rate limits, pagination and foreign-account/unit filtering as applicable. Service tests assert host/headers/request bounds, secret redaction, disabled-provider behavior and stale-cache preservation. Fixtures cannot prove live account entitlement.
Verify and report delivery gates
Identify the host from $HOME. Run tests on Mac Studio (/Users/decod3rslabs), or reach it via ssh mac-studio-2022; unknown/MacBook homes must not run tests/typechecks. Never replace XCTest, SwiftUI or the toolchain with shims to turn an unavailable verification gate into a pass.
Use the repository's installed format/lint tools without reformatting unrelated files. Review .swiftformat, .swiftlint.yml, Package.swift, MeterBarCLI/Package.swift and .github/workflows/ci.yml for current commands/toolchain. On Studio, run:
swiftformat --lint <changed Swift paths>
swiftlint lint --strict --quiet
swift test --filter <affected test class or regex>
swift build
swift build --package-path MeterBarCLI
xcodebuild -project MeterBar.xcodeproj -scheme MeterBar -configuration Debug \
-destination 'generic/platform=macOS' CODE_SIGN_IDENTITY='-' \
CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO build
xcodebuild -project MeterBar.xcodeproj -scheme MeterBar -configuration Release \
-destination 'generic/platform=macOS' ARCHS='arm64 x86_64' ONLY_ACTIVE_ARCH=NO \
CODE_SIGN_IDENTITY='-' CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO buildThe Xcode scheme builds the real app and widget extension; confirm both in build output. Run scripts/verify-build-identities.sh, scripts/test-cli-json-smoke.sh and scripts/verify-cli-json-smoke.sh <built CLI> as relevant. Exercise provider-filtered usage/refresh/doctor JSON with isolated test state and safe credentials; do not refresh a real account as an unapproved smoke test. Report tool absence, license failures, skipped live tests and unavailable accounts as blockers/limitations. CI's real tests, coverage and builds remain mandatory at the final head.
After focused verification, commit intended files only, push a scoped ready PR and attach it to the chat. Record the exact head SHA, implementation lab, reviewer lab and actual review state, local verification, required CI at that SHA, dependency state and remaining blockers. OpenAI implementation needs independent read-only claude-review-gen review (Sonnet high, gen); a same-lab self-check is not that gate. If capacity is unavailable or calls are prohibited, record the blocked gate without probing accounts, substituting a reviewer or claiming approval. Recheck exact-head review and required CI after any fixes. Done requires the repository's merge/deployment evidence; publishing a PR does not authorize an independent merge, release or install.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

