@flancer32/skill-adsm-ctx 0.2.1 → 0.4.0

package/ctx/docs/environment/AGENTS.md

@@ -1,50 +0,0 @@
-# Environment Documentation
-
-- Path: `ctx/docs/environment/AGENTS.md`
-- Changed: `20260708`
-
-## Purpose
-
-Defines the environment documentation level.
-
-Documents at this level describe the runtime environment, infrastructural prerequisites, and operational assumptions required for system operation.
-
-## Level Map
-
-- `AGENTS.md` — level definition for `ctx/docs/environment/`.
-- `overview.md` — runtime assumptions, execution surfaces, external prerequisites, and operational constraints.
-
-## Level Boundary
-
-Defines:
-
-- Runtime environment assumptions — language runtime, filesystem model, and execution surfaces.
-- External prerequisites — required tooling, minimum versions, and expected infrastructure.
-- Operational constraints — conditions under which the system must remain valid regardless of deployment context.
-
-Does NOT define:
-
-- Product meaning, domain entities, or use-case outcomes.
-- Architecture structure, system boundaries, or state ownership.
-- Source-level implementation details, testing conventions, or code invariants.
-
-## Relationship To Upstream Levels
-
-Environment depends on architecture documentation and feeds into code.
-
-The dependency order is:
-
-```text
-product
-  → architecture
-  → environment
-  → code
-```
-
-Environment may add operational precision and constraints but must not redefine architecture structure or introduce new product capabilities.
-
-Code-level documents must respect environment assumptions as non-negotiable prerequisites.
-
-## Local Rules
-
-- Preserve nested environment subdirectories when they improve maintainability.

package/ctx/docs/environment/overview.md

@@ -1,33 +0,0 @@
-# Environment Overview
-
-- Path: `ctx/docs/environment/overview.md`
-- Changed: `20260702`
-
-## Purpose
-
-Defines the runtime environment assumptions for this repository.
-
-## Runtime Assumptions
-
-- Node.js executes the CLI, lifecycle logic, and automated tests.
-- The package operates on local filesystem paths in the current repository or in explicitly provided target directories.
-- The package must not depend on hardcoded absolute paths at runtime.
-
-## Execution Surfaces
-
-- local CLI execution runs through `node` and the installed `adsm-ctx` entry point;
-- package installation provides the CLI and bundled `skill/` payload to the host machine;
-- agent-skill installation copies the packaged skill payload into the inter-agent skills root under `~/.agents/skills`;
-- repository automation runs against a checked-out repository and uses the repository-local `ctx/` as its context source.
-
-## External Prerequisites
-
-- Node.js `>=20` is required by the package contract.
-- npm is the expected package-installation surface for local development and global installation.
-- The repository is expected to be available as a writable working tree when lifecycle commands or workflow automation modify files.
-
-## Operational Environment Constraints
-
-- Runtime behavior must remain valid whether the repository is executed from a developer checkout or from a globally installed package.
-- Installation and validation flows must work with relative target paths supplied by the caller.
-- Automation assumptions that depend on concrete tools, events, labels, or trusted actors belong to project-local materials under `ctx/agent/` rather than to the ADSM baseline.

package/ctx/docs/filesystem.md

@@ -1,44 +0,0 @@
-# Filesystem Structure
-
-- Path: `ctx/docs/filesystem.md`
-- Changed: `20260707`
-
-## Purpose
-
-Defines the declarative structure of the skill repository at the top level only and establishes repository boundaries as a navigation model.
-
-## Root Structure
-
-- `.github/` — GitHub automation definitions, including the workflow that publishes `github-flows` application configuration.
-- `bin/` — executable entry points for local lifecycle tooling.
-- `ctx/` — cognitive context containing declarative documentation for this repository itself.
-- `migrations/` — future migration definitions for context upgrades.
-- `skill/` — installable skill payload consumed by agents.
-- `src/` — implementation logic for CLI-backed lifecycle operations and shared helpers.
-- `test/` — executable tests for CLI and lifecycle behavior.
-
-## Root Files
-
-- `.gitignore` — version-control exclusion rules.
-- `AGENTS.md` — root-level ADSM invariants.
-- `jsconfig.json` — JavaScript language-service configuration.
-- `LICENSE` — license definition.
-- `README.md` — public human-facing documentation for the package.
-- `package-lock.json` — npm dependency lockfile.
-- `package.json` — package metadata, scripts, and CLI registration.
-- `types.d.ts` — project-local type declarations.
-
-## Scope Rule
-
-This document describes only top-level directories and root-level files.
-
-Subdirectory structure, including anything inside `ctx/`, must be described in the corresponding lower-level documentation and service-control files when needed.
-
-`AGENTS.md` files may describe local operational boundaries, but the normative rules for their structure belong to the declarative documentation under `ctx/docs/`.
-
-## Product Boundary
-
-- `skill/` and `src/` are product artifacts of this repository.
-- `skill/templates/ctx/` is the reusable template baseline installed into other projects.
-- `skill/templates/work/` contains working templates for agent operations and is not installed into project `ctx/` by default.
-- `ctx/` documents this repository as a skill product.

package/ctx/docs/product/AGENTS.md

@@ -1,51 +0,0 @@
-# Product Documentation
-
-- Path: `ctx/docs/product/AGENTS.md`
-- Changed: `20260708`
-
-## Purpose
-
-Defines the product documentation level.
-
-Documents at this level describe the system as a product: its meaning, purpose, scope, domain language, user roles, product boundaries, and product-level invariants.
-
-## Level Map
-
-- `AGENTS.md` — level definition for `ctx/docs/product/`.
-- `domain.md` — product domain model; describes the product world, domain areas, business entities, ownership, and semantic relations, not storage structure.
-- `glossary.md` — product terminology; defines stable product terms and prevents terminology drift.
-- `overview.md` — product identity, scope, boundaries, and product-level orientation.
-- `roles.md` — user role model; describes role categories, authority, permissions, ownership boundaries, and responsibility boundaries.
-- `use-cases.md` — product use cases; describes user goals and expected outcomes, not UI, API, or implementation flows.
-
-## Product Knowledge Model
-
-Product knowledge is organized through complementary agent documents:
-
-- `domain.md` — the product world.
-- `roles.md` — product participants and authority.
-- `use-cases.md` — user goals and expected outcomes.
-- `glossary.md` — product language.
-- `overview.md` — product identity, scope, and boundaries.
-
-Together these models provide the primary understanding of the product.
-
-If an agent document grows too large to maintain, move operational detail into a natural product subdocument or nested subdirectory.
-
-## Local Rules
-
-- Preserve nested product subdirectories when they improve maintainability.
-
-## Level Boundary
-
-Defines:
-
-- Product identity, scope, and explicit exclusions.
-- Product language, roles, and authority boundaries.
-- Product-level user goals, expected outcomes, and durable invariants.
-
-Does NOT define:
-
-- Architectural structure, system decomposition, or integration boundaries.
-- Execution environment, deployment topology, or code-level implementation constraints.
-- Agent workflow behavior, repository operations, or methodological rules above this level.

package/ctx/docs/product/domain.md

@@ -1,63 +0,0 @@
-# Product Domain
-
-- Path: `ctx/docs/product/domain.md`
-- Changed: `20260813`
-
-## Domain Purpose
-
-The domain of this product is ADSM project cognitive context lifecycle management.
-
-The skill manages the structure, validation, audit, compression, upgrade, and agent-facing guidance for project cognitive context without inventing project-specific product meaning.
-
-## Core Domain Objects
-
-- **ADSM context** — the project cognitive context mounted under `ctx/`; it is the durable communication medium between humans and agents.
-- **Skill payload** — the installable `skill/` bundle consumed by an agent skill host as `adsm-ctx`.
-- **Skills root** — the caller-provided directory under which `install-skill` installs the bundled skill payload.
-- **Documentation level** — one of the four top-level documentation branches under `ctx/docs/`: `product/`, `architecture/`, `environment/`, and `code/`.
-- **Project-specific nested substructure** — directories and documents inside a documentation level; it is chosen by the project and is not fixed by ADSM.
-- **Agent document** — an ordinary `*.md` file under `ctx/docs/**`; it contains operational project knowledge in a form optimized for agent interpretation and maintenance.
-- **Semantic skin** — a short `*.skin.<lang>.md` file under `ctx/docs/**`; it captures human-facing semantic invariants for the matching agent document.
-- **Agent/skin pair** — an agent document and skin with the same basename in the same directory, such as `domain.md` and `domain.skin.en.md`.
-- **Projection drift** — conflict between an agent document and its skin, an orphan skin without a matching agent document, or an artifact that introduces authoritative meaning not present in agent or skin documents.
-- **AGENTS.md local routing file** — a short service-control file that tells agents how to read, edit, and route work in its local directory scope.
-- **ctx/assets artifact space** — the place for visual, generated, rendered, or auxiliary artifacts that may illustrate meaning but must not define authoritative project knowledge.
-- **Lifecycle mode** — a skill operation such as `init`, `design`, `validate`, `quality-audit`, `documentation-compression`, or `upgrade`.
-- **Human decision / escalation** — a required human intervention when an agent detects projection drift, missing upstream meaning, a skin conflict, or an unsafe change in controlled meaning.
-
-## Core Relations
-
-- An ADSM context contains project-facing documentation under `ctx/docs/` and project-local agent materials under `ctx/agent/`.
-- The skill payload is installed separately from initialized project context and must remain a coherent copy of `skill/`.
-- The skills root is an external installation target and is not a project cognitive context.
-- `ctx/docs/` contains exactly four top-level documentation levels by ADSM convention: `product/`, `architecture/`, `environment/`, and `code/`.
-- Each documentation level may contain project-specific nested substructure when that improves maintainability.
-- Agent documents carry operational detail by default.
-- Skins govern matching agent documents only when human semantic control is needed.
-- Agents must read a matching skin before changing its matching agent document.
-- An agent-document change that violates its skin requires a human decision.
-- Assets may support agent and skin documents visually, but those documents remain the source of authoritative meaning.
-- `AGENTS.md` routes local agent behavior; it does not replace agent documents, skins, or product meaning.
-
-## Lifecycle Behavior
-
-- `init` creates a minimal ADSM-compatible context baseline.
-- `design` shapes documentation levels and project-specific substructure without guessing project meaning.
-- `validate` reports structural and deterministic projection-model findings, including lightweight document-shape and local-link checks for `ctx/docs/**`, without destructive edits.
-- `quality-audit` evaluates agent documents, skins, and their alignment against ADSM quality criteria.
-- `documentation-compression` rewrites agent documents for density only when accepted meaning and skin-controlled meaning are preserved.
-- `upgrade` migrates existing contexts to current conventions while preserving project-specific content.
-- `install-skill` installs the current skill payload into a caller-provided skills root; it is a package-support operation, not a context lifecycle mode.
-
-## Domain Invariants
-
-- The skill remains generic and orchestration-oriented.
-- ADSM defines the four top-level documentation levels, not a rigid internal tree below them.
-- Ordinary `*.md` files are agent-facing operational context documents by default.
-- `*.skin.<lang>.md` files are optional semantic control surfaces, not summaries.
-- Deterministic validation may require paired agent documents, required skin sections, `Scope` subblocks, valid local markdown links, and compactness thresholds for skins.
-- `overview.md` has no special methodology-level status.
-- `README.md` is not required inside `ctx/docs/`.
-- `agents-files.md` is not required.
-- Human decisions are required when agents would need to invent project meaning, weaken a skin, or silently resolve projection drift.
-- Skill payload installation must not alter a target project's `ctx/` content.

package/ctx/docs/product/domain.skin.en.md

@@ -1,40 +0,0 @@
-# Product Domain Skin
-
-- Path: `ctx/docs/product/domain.skin.en.md`
-- Changed: `20260813`
-
-## Purpose
-
-This skin preserves the stable domain objects and relations for ADSM context lifecycle management.
-
-## Mental Model
-
-ADSM context uses agent-facing operational documents by default, while optional skins preserve the human semantic frame for selected key documents.
-
-## Scope
-
-Includes:
-
-- the stable domain objects and relations behind the ADSM context lifecycle;
-- the distinction between agent documents, skins, assets, and `AGENTS.md` routing files;
-- the optional nature of `*.skin.<lang>.md` pairing.
-
-Excludes:
-
-- low-level implementation behavior;
-- validation internals;
-- CLI command wording.
-
-## Invariants
-
-- ADSM context uses agent-facing operational documents by default.
-- ADSM defines four top-level documentation levels: `product/`, `architecture/`, `environment/`, and `code/`.
-- Humans control meaning through optional matching `*.skin.<lang>.md` files.
-- Agent documents carry operational detail; skins control semantic invariants.
-- Project-specific nested substructure is allowed inside each documentation level.
-- `AGENTS.md` files are local routing files, not full documentation artifacts.
-- `ctx/assets/**` contains artifacts that illustrate meaning but do not define it.
-
-## Agent Document
-
-`domain.md`

package/ctx/docs/product/glossary.md

@@ -1,31 +0,0 @@
-# Product Glossary
-
-- Path: `ctx/docs/product/glossary.md`
-- Changed: `20260813`
-
-## Terms
-
-- **ADSM** — Agent-Driven Software Management.
-- **Agent External Context** — the reserved `ctx/agent/` branch used for project-local materials about tools, relationships, or routines that sit outside ADSM methodology.
-- **Agent Skill Host** — the environment that loads installed agent skill payloads.
-- **Bootstrap Marker** — the minimal text left in installed project-facing templates to identify the context as ADSM-managed and direct agents to skill `adsm-ctx` for validation and methodology rules.
-- **Cognitive Context** — the declarative project context mounted under `ctx/`.
-- **Agent Document** — an ordinary `*.md` document under `ctx/docs/**`; agent documents are optimized primarily for agent routing, interpretation, and execution without guessing.
-- **Agent/Skin Pair** — an agent document and its matching semantic skin in the same directory with the same basename, such as `domain.md` and `domain.skin.en.md`.
-- **Documentation Compression** — agent-performed controlled rewrite of a project documentation corpus that reduces attention cost while preserving accepted project meaning.
-- **Documentation Quality Audit** — agent-performed review of a documentation corpus against ADSM documentation quality criteria, producing evidence-backed findings rather than automatic semantic scoring.
-- **Documentation Quality Criterion** — one of the ADSM corpus quality dimensions used during documentation quality audit: declarativity, consistency, completeness, connectedness, density, compactness, non-redundancy, or absence of obvious descriptions.
-- **Projection Drift** — a conflict between an agent document and matching skin, an orphan skin without a matching agent document, or an asset that introduces meaning not present in agent or skin documents.
-- **Semantic Skin** — a short `*.skin.<lang>.md` document that acts as a human-facing semantic control surface for the matching agent document.
-- **Human Supervisor** — the human role that sets goals and guardrails, reviews outcomes, and intervenes when agent work drifts from expected product or architecture boundaries.
-- **Lifecycle Mode** — one of `init`, `design`, `validate`, `quality-audit`, `documentation-compression`, or `upgrade`.
-- **Specialized Skill** — a separate skill that may help produce or refine a domain-specific context branch, but is not the only valid source of project-specific semantics.
-- **Skill Payload** — the bundled contents of `skill/` installed into an agent skill host as `adsm-ctx`.
-- **Skills Root** — the caller-provided installation root under which the skill payload is installed.
-- **Specialization Gap** — a required context area for which no specialized skill is available.
-- **Audit Finding** — a documented discovery produced during a documentation quality audit, including criterion, severity, location, issue, evidence, impact, suggested action, and decision status.
-- **Working Report Template** — an agent-facing output template used during skill operations such as audit, compression, and validation and not installed into project `ctx/` by default.
-- **Context Template** — a reusable starter artifact from `skill/templates/ctx/` that provides the baseline cognitive-context structure for downstream projects while keeping ADSM methodology in the skill and references rather than in project-facing template text.
-- **Validation Finding** — a documented structural discrepancy produced during context validation, reporting missing or malformed expected files against the ADSM baseline.
-- **Migration** — a controlled, non-destructive transformation of project cognitive context from one convention version to another, preserving project-specific content.
-- **Specialization Support** — the capability to detect, route toward, or integrate with specialized skills for project-specific documentation branches.

package/ctx/docs/product/overview.md

@@ -1,112 +0,0 @@
-# Product Overview
-
-- Path: `ctx/docs/product/overview.md`
-- Changed: `20260708`
-
-## Product Identity
-
-This product is an ADSM skill package for building and evolving project cognitive context.
-
-It serves a human-and-agent working group in which agents perform most lifecycle work and humans set guardrails, inspect results, and correct drift.
-
-## Product Mission
-
-Provide a generic, reusable foundation for project cognitive context management without inventing project-specific knowledge.
-
-## Product Scope
-
-The product is responsible for:
-
-- creating baseline context structure;
-- installing the bundled skill payload into a configured agent skills root;
-- providing reusable product-level and architecture-level templates with only minimal ADSM bootstrap markers;
-- validating structural conformance and lightweight deterministic document shape under `ctx/docs/`;
-- guiding agent-performed quality audits of documentation corpora against ADSM documentation quality criteria;
-- guiding agent-performed documentation compression of `ctx/docs/` corpora without changing accepted project meaning;
-- guiding context design and upgrade decisions;
-- reserving the `ctx/agent/` boundary file while leaving project-local tool materials outside the ADSM baseline.
-
-This scope is intentionally stated as stable product orientation, with operational detail left to the matching domain, roles, use-case, and glossary documents.
-
-## Product Areas
-
-- lifecycle tooling;
-- skill payload installation;
-- agent-facing guidance and routing documents;
-- audit and compression guidance;
-- reusable product and architecture context templates;
-- semantic control surfaces for high-level orientation and drift diagnosis;
-- reserved boundary support for `ctx/agent/`;
-- repository self-documentation.
-
-## Core Lifecycle
-
-The primary lifecycle is:
-
-1. initialize baseline context;
-2. design project-specific structure;
-3. validate the resulting context;
-4. audit documentation quality when corpus-level supervision is needed;
-5. compress documentation when accepted meaning is stable but attention cost is high;
-6. upgrade the context when conventions evolve.
-
-Operationally, agents perform most of this lifecycle work. Humans intervene mainly to set boundaries, approve expansion, and correct unexpected agent interpretation.
-
-Skill payload installation is a package-support capability that enables agents to use this lifecycle guidance.
-
-It is not itself a context lifecycle mode.
-
-## Product Boundaries
-
-### In Scope
-
-- generic ADSM context lifecycle management;
-- installation of the bundled `skill/` payload into a caller-provided agent skills root;
-- minimal template markers that identify an installed context as ADSM-managed and point agents to skill `adsm-ctx` for validation and methodology rules;
-- agent guidance for documentation quality audit and controlled documentation compression;
-- structural management of the `ctx/agent/` boundary file without prescribing project-local subdirectories;
-- orchestration toward specialized skills;
-- non-destructive structure validation and upgrade support.
-
-### Out of Scope
-
-- product-specific requirements definition;
-- embedding detailed ADSM conformance rules directly into downstream project-facing templates;
-- automatic semantic scoring or automatic semantic correction of project documentation quality;
-- changing project meaning during documentation compression;
-- authoritative tool-specific instructions, workflow meaning, event semantics, or project-specific flow rules;
-- specialized browser, backend, data, or deployment documentation logic;
-- implementation of business-domain documentation as guessed content.
-
-## MVP Boundary
-
-The current version provides a working skeleton with executable CLI commands, bundled skill installation, bundled templates, baseline validation, documentation quality audit guidance, documentation compression guidance, and upgrade hooks.
-
-The documentation quality audit and documentation compression capabilities are agent-guidance capabilities, not CLI validation capabilities.
-
-`validate` is the deterministic preflight for the documentation corpus.
-
-It may reject structural defects such as broken pairing, missing required skin sections, missing `Scope` subblocks, or broken local markdown links, and it may emit heuristic warnings when a semantic skin grows beyond compact supervision thresholds.
-
-## Product Invariants
-
-- Project cognitive context is the main managed object.
-- The skill must remain generic and orchestration-oriented.
-- Agents perform the default operating work; humans provide guardrails and correction.
-- Project documents should govern the project itself; ADSM conformance checking belongs to the skill.
-- `AGENTS.md` files are service control files for agent work inside a project and must not act as the originating specification for ADSM rules about themselves.
-- Installed project-facing templates may contain only the minimal ADSM bootstrap signal needed to identify the context and route validation to skill `adsm-ctx`.
-- The skill defines only the `ctx/agent/` boundary file; project-local tool materials under that branch remain outside the ADSM baseline.
-- Skill payload installation copies the current `skill/` bundle as a coherent agent-consumed payload and must not modify project context.
-- Documentation quality audits must report evidence-backed findings and must not silently invent or correct project meaning.
-- Deterministic validation may check skin structure and compactness heuristics, but ordinary agent documents remain minimally constrained.
-- Documentation compression must preserve accepted project meaning while reducing attention cost.
-- Specialized skills may help formulate tool-specific semantics, but they are optional support rather than the only valid source of such semantics.
-- Missing specialization must be reported, not guessed around.
-
-## Related Bodies
-
-- Read `domain.md` for the product domain boundary.
-- Read `roles.md` for participating roles.
-- Read `use-cases.md` for lifecycle-oriented user goals.
-- Read `glossary.md` for stable terminology.

package/ctx/docs/product/overview.skin.en.md

@@ -1,38 +0,0 @@
-# Product Overview Skin
-
-- Path: `ctx/docs/product/overview.skin.en.md`
-- Changed: `20260813`
-
-## Purpose
-
-This skin preserves the high-level product identity of the skill package as a generic ADSM context lifecycle product.
-
-## Mental Model
-
-The product manages cognitive-context lifecycle rules and guidance, not a downstream business domain.
-
-## Scope
-
-Includes:
-
-- product identity, mission, and scope boundaries;
-- the generic and orchestration-oriented character of the skill;
-- the role split between humans and agents.
-
-Excludes:
-
-- detailed lifecycle mechanics;
-- internal implementation structure;
-- project-specific consumer-domain semantics.
-
-## Invariants
-
-- The product manages project cognitive context, not an external consumer project.
-- Agents do default lifecycle work; humans set guardrails, inspect outcomes, and correct drift.
-- The skill must remain generic and must not invent project-specific business or architecture meaning.
-- Installed project-facing templates keep only minimal ADSM bootstrap signals.
-- `overview.md` is an agent document, not a required human entry frame by methodology.
-
-## Agent Document
-
-`overview.md`

package/ctx/docs/product/roles.md

@@ -1,17 +0,0 @@
-# Product Roles
-
-- Path: `ctx/docs/product/roles.md`
-- Changed: `20260702`
-
-## Roles
-
-- **Human Supervisor** — defines goals, sets guardrails, reviews outcomes, and intervenes when agent work drifts from expected product or architecture boundaries.
-- **Agent** — performs most lifecycle work inside declared ADSM boundaries, including analysis, structure changes, audits, and controlled documentation compression.
-- **Developer** — maintains implementation and repository mechanics needed for the product to operate as a skill package.
-- **Context Maintainer** — evolves templates, validation rules, documentation quality audit guidance, documentation compression guidance, and upgrade conventions.
-
-## Authority Pattern
-
-- The human supervisor owns direction, acceptance, and boundary expansion.
-- The agent owns default operational execution inside documented boundaries.
-- The developer and context maintainer may be the same human, but their responsibilities remain distinct from the autonomous agent role.

package/ctx/docs/product/use-cases.md

@@ -1,15 +0,0 @@
-# Product Use Cases
-
-- Path: `ctx/docs/product/use-cases.md`
-- Changed: `20260708`
-
-## Use Cases
-
-- Initialize cognitive context in a repository so agents have a baseline `ctx/` structure, metadata, and local routing files.
-- Install the bundled skill payload into a caller-provided skills root so an agent skill host can load `adsm-ctx`.
-- Assess whether an existing repository has the required ADSM baseline, documentation levels, metadata, and projection shape.
-- Audit an existing documentation corpus against ADSM documentation quality criteria and produce evidence-backed findings.
-- Compress an existing `ctx/docs/` corpus while preserving accepted project meaning and skin-controlled meaning in matching agent documents.
-- Define or revise the reserved `ctx/agent/` boundary while leaving project-local tool materials outside the ADSM baseline.
-- Route documentation work toward specialized skills when project-specific context requires narrower expertise.
-- Upgrade a context when conventions or template structure change while preserving project-specific content.

package/src/Bootstrap/Cli.mjs

@@ -1,62 +0,0 @@
-// @ts-check
-
-/**
- * @namespace Fl32_Skill_Adsm_Ctx_Bootstrap_Cli
- * @description Parses CLI arguments for the ADSM context lifecycle application.
- */
-
-const usage = [
-  "Usage: adsm-ctx <command> [target-path]",
-  "Commands:",
-  "  init [target-path]",
-  "  design [target-path]",
-  "  validate [target-path]",
-  "  upgrade [target-path]",
-  "  install-skill <skills-root>",
-  "  --help",
-].join("\n");
-
-export default class Cli {
-  /**
-   * @param {object} deps
-   * @param {Fl32_Skill_Adsm_Ctx_Shared_Path} deps.pathService
-   */
-  constructor({pathService}) {
-    /**
-     * Parses CLI arguments.
-     *
-     * @param {object} params
-     * @param {string[]} params.cliArgs
-     * @param {string} params.projectRoot
-     * @returns {{
-     *   command?: string,
-     *   errors: string[],
-     *   helpRequested: boolean,
-     *   targetPath: string,
-     *   usage: string
-     * }}
-     */
-    this.parse = function ({cliArgs = [], projectRoot}) {
-      const [command, targetArg] = cliArgs;
-      const errors = [];
-      const helpRequested = !command || command === "--help" || command === "-h";
-      const targetPath = targetArg ? pathService.resolve(targetArg) : projectRoot;
-
-      if (!helpRequested) {
-        const supported = new Set(["init", "design", "validate", "upgrade", "install-skill"]);
-        if (!supported.has(command)) {
-          errors.push(`Unknown command: ${command}`);
-        }
-        if (command === "install-skill" && !targetArg) {
-          errors.push("Usage: adsm-ctx install-skill <skills-root>");
-        }
-      }
-
-      return {command, errors, helpRequested, targetPath, usage};
-    };
-  }
-}
-
-export const __deps__ = Object.freeze({
-  pathService: "Fl32_Skill_Adsm_Ctx_Shared_Path$",
-});