Harness AI Kit
Manage reproducible AI engineering assets through manifests, lockfiles, and runtime synchronization.
- Source repo
- seed-forge/harness-ai-kit
- Stars
- ★ 25
- Last updated
- 2mo ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 69/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer using Codex, Claude Code, Cursor, Kiro, or dsh wants to install a selected Skill from a public Git repository and synchronize it into a project runtime.
- Not a fit if
- Solo developers who want one manually installed Skill without a manifest or lockfile
- Users seeking a ready-made conversational agent or hosted execution service
- Teams needing a registry, browser, or org admin console, which remain future milestones
- Source review
- 69/100 · Some gaps
What does this agent do, and when should you use it?
Harness AI Kit is a package manager and composition layer for Skills, CLIs, MCPs, plugins, hooks, subagents, and loops used in AI coding environments. A project declares its desired assets in harness-ai-kit.yml, and dependency resolution produces harness-ai-kit.lock with resolved sources, versions, features, and SHA-256 checksums. Runtime adapters materialize the selected assets for Codex, Claude Code, Cursor, Kiro, or DeepSeek Harness at project or global scope. Installation prepares and verifies assets in a staging directory before replacing the target, while user-specific endpoints and credentials remain in ~/.harness-ai-kit/config.yaml. It is a fit for developers and teams that need a reproducible, auditable asset baseline, rather than users seeking a standalone conversational agent or hosted execution service.
The workflow begins with harness-ai-kit init, which creates or updates shared configuration, followed by harness-ai-kit init-project to create the project manifest. harness-ai-kit add skill declares a Skill sourced from a Git repository. The resolver reads the manifest and dependencies, selects sources, versions, and features, and records them with SHA-256 checksums in harness-ai-kit.lock. harness-ai-kit sync uses source adapters and a cache to acquire assets, verifies them in staging, and invokes runtime adapters to materialize managed Skills, CLIs, MCPs, plugins, hooks, subagents, or loops. Synchronization reconciles managed assets without blindly wiping unrelated local files. harness-ai-kit doctor checks the resulting setup, while the documented CLI surface also includes install, lock, validate, and upgrade.
- A developer using Codex, Claude Code, Cursor, Kiro, or dsh wants to install a selected Skill from a public Git repository and synchronize it into a project runtime.
- A team maintaining a shared AI engineering environment wants to commit a manifest and lockfile so every teammate resolves the same asset set after cloning the project.
- An engineering lead needs an auditable record of asset sources, versions, features, and SHA-256 checksums instead of copied runtime directories.
- A team combining Skills, CLIs, MCPs, and other runtime assets wants to manage them through one typed dependency contract.
- A Skill or plugin author needs to validate asset metadata locally and publish through an explicit reviewed release path.
How do you install or deploy this agent?
Prerequisites are Python 3.10+ and Git. Install the documented pinned release and initialize shared configuration:
python -m pip install --upgrade harness-ai-kit==0.18.18
harness-ai-kit initThe initialization command creates or updates ~/.harness-ai-kit/config.yaml. If selected assets require private endpoints or credentials, those user-specific values belong in this configuration file; the source does not specify one universal credential requirement for all assets.
How do you use this agent?
Create a project, declare a Git-hosted Skill, synchronize it, and inspect the environment:
mkdir my-agent-project
cd my-agent-project
harness-ai-kit init-project
harness-ai-kit add skill https://github.com/OWNER/REPO/tree/main/path/to/skill
harness-ai-kit sync
harness-ai-kit doctorReplace the example URL with the actual Skill path. For team use, commit the project manifest and harness-ai-kit.lock, not copied runtime directories. A teammate can clone or pull the project and run harness-ai-kit sync to materialize the locked asset set.
What are this agent's strengths and limitations?
- One typed asset model covers Skills, CLIs, MCPs, plugins, hooks, subagents, and loops instead of requiring an unrelated installation process for each asset type.
- The lockfile records resolved sources, versions, features, and SHA-256 checksums, supporting reproducible and auditable team installations.
- Runtime adapters explicitly cover Codex, Claude Code, Cursor, Kiro, and dsh, with project-level and global installation modes.
- Materialization uses staging, verification, and target replacement, and synchronization is documented not to blindly erase unrelated local files.
- Installed Skills remain ordinary Markdown and metadata directories that can be read, copied, or installed directly from Git without the package manager.
- Adoption adds a project manifest, lockfile, and user-level configuration that may be unnecessary for a single manually installed Skill.
- The environment requires Python 3.10+ and Git, plus network access when installing from PyPI or public Git sources.
- The supplied quickstart demonstrates adding a Git Skill but does not show complete configuration examples for every advertised asset type, such as hooks, subagents, and loops.
- Registry, browser, and organization administration are described as separate future platform milestones rather than current core CLI capabilities.
- Private endpoints, credentials, and deployment topology are intentionally excluded from public assets, so teams must configure and distribute that operating context separately.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Harness AI Kit This agent | 69 · Some gaps | CLIFree | ★ 25 | 2mo ago | Python | Codex · Claude Code |
| Caliber — AI Agent Config Sync | 58 · Major gaps | CLIFree + model costs | ★ 1.3k | 1mo ago | TypeScript | Codex · Claude Code |
| Deep Code CLI | 49 · Major gaps | CLIFree + model costs | ★ 2.2k | 1d ago | TypeScript | — |
| Firecrawl CLI | 47 · Major gaps | — | ★ 678 | 3d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The evidence shows read-only contents permissions by default in CI, with id-token:write or contents:write limited to publishing steps. SHA-256 lock integrity, staged installation, credential masking, environment-variable resolution, an asserted sensitive-data scan, dry-run behavior, and separation of configuration from assets provide meaningful privilege, integrity, and secret-handling controls. The README discloses that sync writes a lockfile and materializes runtime assets, while tests cover remote credential mutation, automatic login refresh, and configuration writeback. Deductions apply because implementation source is absent and scanning/rollback are partly asserted; auth-set, auth-remove, and automatic credential refresh/writeback show no per-operation interactive confirmation, and Linux browser automation uses --no-sandbox. Third-party Git asset attribution, licensing, and review policy are also incomplete in the supplied evidence.
The README, package metadata, and workflows are broadly consistent about the package name, version 0.18.18, Python 3.10+, and the core entry point. CI spans three Python versions, performs CLI smoke checks and release gates, while the Dify tests demonstrate validation, explicit exceptions, HTTP fallback decisions, and error payloads. The major deduction is that SECURITY.md claims only 0.1.x is supported, conflicting with version 0.18.18. The displayed core CI commands also do not execute the supplied cli/sf-difyctl test suite. Dependencies have lower bounds but no supplied lock or offline strategy, limiting availability and compatibility assurance.
The documentation clearly addresses individual adoption, shared team baselines, asset authors, public and internal assets, and five named runtimes, earning strong scenario coverage. Typed manifests, runtime adapters, configuration boundaries, roadmap non-goals, and Dify mode validation provide meaningful capability and environment boundaries. Deductions apply because much detail is deferred to unavailable linked documents, and trigger evidence is mostly CLI routing plus selected workflow/chatflow checks rather than the 42 skills themselves. Linux automation's --no-sandbox requirement and approximate Dify DSL-version fallback also expose environmental fragility.
The README has strong information architecture across motivation, architecture, quick start, team workflow, capabilities, usage paths, and documentation navigation. Naming is mostly stable across package metadata, entry points, and configuration, and the full Apache-2.0 license is present. Releases use TestPyPI gating, immutable-version preflight, publication waves, and readback; maintenance channels include issues, Discussions, and a security email. Deductions apply because the referenced quickstart, FAQ/troubleshooting, changelog, roadmap, and contribution material were not supplied for review. SECURITY.md has stale supported-version information, and responsibility is attributed only to the unverified SeedForge identity without named maintainers or succession/governance details.
Unifying resolution, locking, validation, and cross-runtime synchronization for several agent-asset types while retaining ordinary directory formats offers substantial marginal value for reproducible team environments. Concrete commands, structured JSON responses, doctor/validate operations, DSL scaffolding, and ledger-migration tests support practical output usability. Deductions apply because no statically reviewable benchmarks, adoption outcomes, or complete end-to-end example are included. The broad value claims for 42 skills and five CLIs remain mostly descriptive, and the costs of dependencies, Git/network access, browser automation, and lockfile maintenance are not systematically assessed.
Version, dependencies, entry point, license, CI permissions, and publishing steps are directly traceable to supplied metadata and workflows. Some README claims about reproducibility and safety receive cross-file support from release gates and Dify unit tests, and the tests distinguish authoritative DSL detection from approximate fallback. Deductions apply because the core resolver, synchronizer, scanner, release-gate implementations, most documentation, and most assets are absent, preventing claim-by-claim tracing. Tests focus on one Dify CLI and are not visibly run by the supplied CI, while badge claims and the stated inventory of 42 skills are not independently corroborated in the supplied files.
- SECURITY.md lists 0.1.x as supported while package metadata and installation instructions use 0.18.18; confirm the actual security-support and patch scope before deployment.
- Linux browser automation explicitly passes --no-sandbox. Use it only in an isolated environment and assess whether browser sandboxing can be restored.
- Sync, credential add/remove, automatic login refresh, and configuration writeback cause local or remote changes. Use dry-run where available, review target paths and configuration sources, and back up manifests, lockfiles, and credential configuration.
- Skills added from arbitrary Git repositories are outside this project's security-policy scope. Independently review their code, instructions, dependencies, licenses, and network behavior before use.
- The supplied CI does not visibly run the extensive sf-difyctl tests, and core sync/resolution implementation is absent from the evidence. Do not treat test files or badges as proof of successful execution or validation.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/harness-ai-kit)<a href="https://followagents.com/en/agents/harness-ai-kit"><img src="https://followagents.com/badge/harness-ai-kit.svg" alt="FARS review"></a>Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.2.0 v0.2.0 - Naming Unification
Release notes excerpt
harness-ai-kit v0.2.0 — Naming Unification The project name is now consistently harness-ai-kit across package, command, manifest, lockfile, config directory and env var. This release also adds 11 curated skills (34 total). ⚠️ BREAKING — naming unified to harness-ai-kit | Was | Now | |-----|-----| | Python package ai_kit | harness_ai_kit | | Primary command ai-kit | harness-ai-kit (short ai-kit alias still works) | | Manifest ai-kit.yml | harness-ai-kit.yml | | Lockfile ai-kit.lock | harness-ai-kit.lock | …View on GitHub ↗ -
v0.1.0 v0.1.0 — Initial Release
Release notes excerpt
ai-kit v0.1.0 First public release of the AI asset package manager. Features - Unified asset schema (skills / CLIs / MCPs / plugins / hooks / subagents / loops) - Dependency resolution with resolvelib + lockfile (ai-kit.lock) + SHA-256 checksums - Multi-runtime support: Codex, Claude Code, Cursor, Kiro (project + global scope) - GitHub direct install 鈥?no private registry required - Staging + atomic rollback on install failure - Offline cache mode - Sensitive-reference CI scan (0 internal hostnames/credentials) Curated Skill Library (23 skills) …View on GitHub ↗
FAQ
Does it place credentials in project assets or the lockfile?
~/.harness-ai-kit/config.yaml, not in published assets. The supplied source does not state that credentials are stored in the lockfile.Which files should a team commit?
harness-ai-kit.lock, not copied runtime directories. Teammates then run harness-ai-kit sync after cloning or pulling the project.Will synchronization delete custom files from a runtime directory?
sync reconciles managed assets and is not a blind wipe of unrelated local files.