Hearting

One complete agent workflow across Claude Code, Codex, and OpenCode.

A local-first workflow layer for Claude Code, Codex, and OpenCode.

English · 한국어

Landing page & agent map ↗

Hearting closes research, planning, implementation, and verification work
consistently across supported coding-agent runtimes. It is not a setup for a
single runtime. Shared contracts are defined once, then projected only onto
the native skill, agent, hook, mode, and command surfaces that each runtime
actually discovers.

"Implement and test the login API, then leave a change report."
                                  ↓
       plan → execute → test → report + durable evidence

Why Hearting

• Finish the whole cycle. Research, specs, plans, implementation, tests,
  reports, and durable evidence stay connected.
• Keep one contract across three runtimes. Shared behavior is projected
  onto the surfaces Claude Code, Codex, and OpenCode actually discover.
• Spend the right model on the right node. Stage meaning and risk select
  the execution profile, sealed at route-compile time rather than passed as a
  trailing flag.
• Watch the work while it runs. fleet shows interactive sessions and
  dispatched workers from every runtime in one live tree.
• Know what is running. Inspect the active release or checkout, revision,
  freshness, duplicates, and required session action.
• One activation, the whole harness. Every runtime discovers the full
  manifest-derived capability set — no forked subsets or separate setups.
• Carry decisions safely. Durable memory and executable guards preserve
  conventions while checking spec, artifact, git, and projection boundaries.

Quick start

Requirements

• Python 3.10+
• curl or wget
• The CLI for each runtime you want to activate

Install

curl -fsSL https://github.com/dmlguq456/agent_setting/releases/latest/download/install.sh | sh
~/.local/bin/harness runtime doctor --runtime all --strict

The installer and distribution logic come from the same immutable Release tag;
that exact tag's SHA-256 integrity-checked archive is then installed. It activates
the full capability set for all three runtimes as immutable packaged bundles and
registers a daily user-level update check where the OS supports it. It does not
touch runtime credentials, sessions, logs, or databases.

When Codex is installed, the same transaction also installs a reversible
~/.local/bin/codex launcher. Plain interactive codex, codex resume, and
codex fork enter the harness-managed App Server automatically; codex exec,
plugin administration, login, and other non-interactive commands pass through to
the recorded real CLI. Updates repair the launcher, and harness uninstall codex
restores the exact previous command binding. If Codex is not installed yet, this
step is reported as skipped and can be applied by a later runtime refresh.

Once ~/.local/bin is on your PATH, manage it with:

harness runtime status --runtime all
harness update
harness auto-update status
harness runtime doctor --runtime all --strict

fleet          # live cross-harness dashboard; --once for a plain snapshot

The installer also drops a fleet launcher into ~/.local/bin. The live
full-screen view needs curses; fleet --once and fleet --json do not, so
scripting and snapshots work anywhere Python does.

auto-update status also reports the installed release, channel, and live
scheduler health when Linux systemd-user or macOS LaunchAgent exposes it.
Unavailable probes are reported as unknown; unsupported platforms are reported
explicitly without changing the scheduler configuration. For a periodic
LaunchAgent, active means the job is loaded and scheduled; its updater process
does not need to remain running between triggers.

harness update stages and verifies a new release before switching the active
pointer, and rolls back on failure. Existing agent sessions still follow their
runtime-specific re-invocation, new-session, or restart boundary; check
runtime status after an update.

The checksum sidecar detects transfer or asset corruption. Publisher
authenticity is anchored to the repository's GitHub Release and HTTPS account
boundary; it is not an independent signature.

To pin a version or disable scheduled checks:

curl -fsSL https://github.com/dmlguq456/agent_setting/releases/download/v2.0.0/install.sh | sh -s -- --no-auto-update

Use natural language

You do not need to memorize command names. Describe the outcome and constraints
in your natural communication language. Runtime-native skills select the
relevant pipeline, and user-facing output follows the conversation, audience,
or artifact language instead of inheriting the language of this README.

“Analyze this repository and create a PRD for the next feature.”

“Implement and test the login API, then leave a change report.”

“Review these papers and experiment code, then build a reproduction plan.”

“Render the current screen, refine the design, and produce a development handoff.”

“Find the previous decision and apply this project's existing naming convention.”

See capabilities/README.md for every entrypoint and
roles/README.md for the portable role model.

What actually runs your request

One sentence in, a routed pipeline out. Routing, model selection, verification
depth, and evidence are the harness's job — and each decision is recorded
rather than improvised.

When a leg cannot start on its intended surface it degrades along a checked
chain — same-harness-headless → cross-harness-headless → native-subagent → inline — preserving the route id, write scope, completion gate, and attempt
identity. The degradation is recorded with its failure class; it is never
silent.

The landing page and agent map
shows the same structure as a diagram.

How it works

                       harness-manifest.json
                        capability · role
                               │
             ┌─────────────────┼─────────────────┐
             │                 │                 │
      Claude Code native   Codex native    OpenCode native
      skills / agents      skills / agents  skills / agents
      hooks / commands     hooks / modes    commands / plugins
             └─────────────────┼─────────────────┘
                               │
              activate · status · refresh · doctor

Managed releases are the general-user default. linked remains the maintainer
mode: checkout changes appear immediately on the discovery path, and the
release updater never fetches, pulls, or repoints that checkout. File visibility
and instruction reload are separate concerns, so runtime status reports
whether each runtime needs a re-invocation, new session, or restart through
session_action.

Runtime support

Runtime differences are reported rather than hidden. The installer marks
unsupported surfaces as SKIP with a reason, while credentials, sessions,
databases, logs, and foreign caches remain outside its ownership. See
INSTALL_LAYOUT.md for the detailed mapping.

Develop the harness

Maintainers can keep a live checkout instead of the managed release:

git clone https://github.com/dmlguq456/agent_setting.git ~/agent_setting
cd ~/agent_setting
./tools/install/harness.sh runtime activate --runtime all --mode linked

Enable the repository's own Git hooks once per clone:

git config core.hooksPath tools/git-hooks

pre-push runs the same generated-projection check CI runs and refuses a push
that would fail it, so drift is caught before the commit is public and before
the release workflow tags it. git push --no-verify still bypasses it.

After changing a shared definition, refresh every generated projection and
check for drift:

python3 tools/generate.py
python3 tools/generate.py --check

./tools/generated-projections.test.sh
./tools/install/projection-completeness.test.sh
./tools/install/runtime-activation.test.sh
./tools/skill-conformance/check.sh
./tools/check-adaptation-boundary.sh
adapters/codex/bin/preflight.sh doctor

tools/generate.py is the single build/check entrypoint for every core
projection — runtime adapter metadata, the operator hub, and the published
landing surface included. Run the lifecycle suites from a clean working tree:
packaged activation deliberately refuses to build a bundle from a dirty repo.

Marketplace bundle generation is not part of this path. Humans own the root
README's value proposition and explanation; only machine contracts and runtime
projections are generated.

Documentation

License

MIT