@open-agent-toolkit/cli 0.1.22 → 0.1.24

package/assets/docs/cli-utilities/overview.md

@@ -1,33 +0,0 @@
----
-title: CLI Utilities Overview
-description: Plain-language explanation of the OAT CLI surface that lives outside provider sync, docs tooling, and tracked workflows.
----
-
-# CLI Utilities Overview
-
-Not every OAT command belongs to a single product lane. Some commands are general-purpose setup, configuration, pack-management, or diagnostic utilities that support the rest of the toolkit without being specific to provider sync, docs tooling, or tracked workflow execution.
-
-That is what this section covers.
-
-## What Lives Here
-
-- bootstrap and setup flows such as `oat init`
-- bundled pack management through `oat tools`
-- general configuration guidance
-- utility command groups for config, local state, diagnostics, and related inspection flows
-
-## When To Use This Section
-
-Use CLI Utilities when:
-
-- you are first setting up OAT in a repo
-- you need to install or update OAT packs
-- you are looking for configuration or local-state inspection help
-- you need the general CLI surface without committing to one of the deeper lanes yet
-
-## Continue Here
-
-- [CLI Bootstrap](bootstrap.md) for initial setup
-- [Tool Packs](tool-packs.md) for pack lifecycle management
-- [Configuration](configuration.md) for config semantics
-- [Config and Local State](config-and-local-state.md) for the wider utility command map

package/assets/docs/docs-tooling/overview.md

@@ -1,31 +0,0 @@
----
-title: Docs Tooling Overview
-description: Plain-language explanation of OAT docs support, docs app choices, and the index contract.
----
-
-# Docs Tooling Overview
-
-OAT can help bootstrap and maintain a structured docs surface, not just code and provider assets. The docs tooling is built around a simple contract: each directory owns an `index.md`, and that index owns a `## Contents` section that supports local discovery and generated navigation.
-
-OAT supports both Fumadocs and MkDocs. The site framework changes the surrounding app setup, but the underlying documentation contract stays the same.
-
-## When To Use This Section
-
-Use Docs Tooling when:
-
-- you are adding a docs app to a repo
-- you need to keep index pages and nav structure in sync
-- you want a controlled analyze/apply loop for docs restructuring work
-
-## Typical Flow
-
-1. Bootstrap or adopt a docs app in the repo.
-2. Use the docs commands to generate or sync index/navigation structure.
-3. Apply the docs workflow when you want analysis-backed restructuring rather than ad hoc manual edits.
-
-## Continue Here
-
-- [Add Docs to a Repo](add-docs-to-a-repo.md) for initial setup
-- [Commands](commands.md) for the CLI surface
-- [Workflows](workflows.md) for governed docs changes
-- [Docs Index Contract](../reference/docs-index-contract.md) for the underlying rules

package/assets/docs/provider-sync/overview.md

@@ -1,38 +0,0 @@
----
-title: Provider Sync Overview
-description: Plain-language explanation of canonical assets, provider views, and the first-sync loop.
----
-
-# Provider Sync Overview
-
-Provider sync lets OAT manage one canonical set of agent assets and then project those assets into provider-specific views. In practice, that means you edit the canonical layout in `.agents/` and `.oat/`, then let OAT generate or reconcile the provider copies.
-
-This is useful when you want consistent instructions, skills, and rules across multiple providers without treating each provider directory as a long-lived hand-maintained source of truth.
-
-## What OAT Treats As Canonical
-
-- canonical skills, agents, and rules under `.agents/`
-- sync state and related metadata under `.oat/`
-- provider-specific files as derived views unless they are explicitly adopted back into canonical form
-
-## Typical Flow
-
-1. Run `oat init` to create the base OAT layout and setup state.
-2. Inspect current sync state with `oat status`.
-3. Adjust provider enablement with `oat providers ...` if needed.
-4. Run `oat sync` to materialize provider views from canonical assets.
-5. Re-run `oat status` after edits to confirm whether anything drifted or needs adoption.
-
-## When To Use This Section
-
-Use Provider Sync when:
-
-- you want to adopt OAT incrementally, without committing to tracked project workflows yet
-- you need a clear model for drift, strays, and adoption
-- you want to understand which files should be edited directly and which should be regenerated
-
-## Continue Here
-
-- [CLI Bootstrap](../cli-utilities/bootstrap.md) for the first sync setup flow
-- [Scope and Surface](scope-and-surface.md) for the canonical/provider-view model
-- [Commands](commands.md) for the exact CLI behavior

package/assets/docs/workflows/overview.md

@@ -1,38 +0,0 @@
----
-title: Agentic Workflows Overview
-description: Plain-language explanation of when to use tracked OAT projects versus direct CLI usage.
----
-
-# Agentic Workflows Overview
-
-OAT workflow mode adds a tracked lifecycle on top of the base CLI. Instead of just running commands directly, you work through explicit project artifacts such as `state.md`, `plan.md`, and `implementation.md`, with stable task IDs and review checkpoints.
-
-That extra structure is optional. You only need it when the work is large enough, risky enough, or long-lived enough that resumability and explicit coordination matter.
-
-## When To Use Workflow Mode
-
-Use workflow mode when:
-
-- the work spans multiple sessions or contributors
-- you want explicit discovery, plan, implementation, and review artifacts
-- you need stable task sequencing and resumable execution
-- you want human-in-the-loop checkpoints around risky transitions
-
-Stay with direct CLI usage when:
-
-- the task is straightforward and bounded
-- you mainly need provider sync or a utility command
-- the overhead of project artifacts would outweigh the value
-
-## Workflow Modes In Practice
-
-- CLI only: direct commands, no tracked project artifacts
-- Quick mode: tracked work with a lighter upfront planning path
-- Spec-driven mode: explicit discovery, requirements, design, and plan artifacts
-- Import mode: an externally-authored plan imported into OAT for tracked execution
-
-## Continue Here
-
-- [Skills](skills/index.md) for task-oriented workflow skill discovery
-- [Ideas](ideas/index.md) for lightweight capture and refinement
-- [Workflow & Projects](projects/index.md) for the lifecycle, artifact, and review model