@flancer32/skill-adsm-ctx 0.2.1

package/ctx/agent/prompt/cli/ai-intro.md

@@ -0,0 +1,141 @@
+# Generate AI Intro
+
+- Path: `ctx/agent/prompt/cli/ai-intro.md`
+- Changed: `20260422`
+
+## Purpose
+
+Defines the prompt for generating `ctx/docs/ai-intro.md` in ADSM projects when the agent works in CLI mode with direct access to the project files.
+
+The prompt is intended for agents such as Codex or Claude that can inspect repository content before writing the target document.
+
+## Prompt Role
+
+This prompt defines the expected purpose, scope, structure, and size of `ctx/docs/ai-intro.md`.
+
+It is not a template for the final document text. It is a declarative task definition that tells the agent what kind of document must be produced.
+
+## Prompt
+
+Generate the document `ctx/docs/ai-intro.md`.
+
+Assume that the project follows the common ADSM structure. General ADSM and TeqFW conventions are already defined elsewhere and do not need to be restated in detail unless they are necessary to position this specific project.
+
+Before writing, inspect the project files that define public and private project identity. Use the repository content as the source of truth. Prefer project-specific documents and published product materials over assumptions.
+
+The generated `ctx/docs/ai-intro.md` must be the first project-specific reading for AI agents entering the repository. Its role is to position the project in the broader software landscape rather than to explain the internal architecture in detail.
+
+The document must answer the following questions:
+
+- what kind of software product this project is;
+- which problem space it addresses;
+- what role it plays relative to adjacent classes of systems;
+- who the primary audience or users of the project are;
+- which technologies, platforms, and runtime assumptions define its technical family;
+- which methodological base shapes the project;
+- which distinctions make this project different from superficially similar tools;
+- what the project must not be confused with.
+
+The generated document must not duplicate `ctx/docs/AGENTS.md`. It must not restate level structure, hierarchy rules, mandatory-constraint language, or other context-governance mechanics except where a brief reference is necessary to position the project. The generated document must complement `ctx/docs/AGENTS.md`, not compete with it.
+
+The generated document must also avoid detailed explanation of internal architecture, component decomposition, directory maps, execution pipelines, configuration schema, or implementation contracts. Those concerns belong to the specialized documents under `ctx/docs/`.
+
+The generated document must remain declarative. It must describe identity, role, boundaries, and classification. Procedural instructions, workflows, and step-by-step reading guides must be absent or minimal.
+
+## Source Basis
+
+The generated document should be derived from the project's own artifacts, including where relevant:
+
+- `ctx/docs/` for normative project meaning;
+- `README.md`;
+- published documentation under `docs/`;
+- agent-facing published documentation under `ai/`;
+- package metadata such as `package.json`;
+- other repository-level materials that define the public role of the project.
+
+Project-specific facts must be taken from the repository rather than inferred from generic ADSM expectations.
+
+## Output Purpose
+
+The generated `ctx/docs/ai-intro.md` must give an AI agent fast orientation before deeper reading.
+
+After reading it, the agent should understand:
+
+- what kind of thing this repository defines in the world of software;
+- where the project sits relative to libraries, applications, frameworks, platforms, and automation systems;
+- what technical and methodological family the project belongs to;
+- which architectural misclassifications would lead to incorrect implementation decisions.
+
+The document is an orientation layer, not a detailed specification.
+
+## Output Constraints
+
+The generated document must:
+
+- use the standard document attribute block directly under the title;
+- use the canonical path `ctx/docs/ai-intro.md`;
+- follow the declarative style used by the cognitive context;
+- use only relative links to other documents;
+- remain readable as a compact introduction rather than a full survey.
+
+The generated document must not:
+
+- duplicate `ctx/docs/AGENTS.md`;
+- redefine product, architecture, environment, or code contracts already defined in specialized documents;
+- become a repository map;
+- become an implementation walkthrough;
+- become an onboarding checklist;
+- become a marketing text;
+- become a generic explanation of ADSM or TeqFW detached from the current project.
+
+## Volume Constraints
+
+The generated document should usually be between `700` and `1100` words.
+
+Recommended target size is `800` to `1000` words.
+
+The document should be shortened if it starts repeating statements better defined elsewhere. It should be expanded only when the project has unusual positioning that cannot be understood within a smaller text.
+
+## Recommended Structure
+
+The generated document should normally include sections equivalent to the following:
+
+1. `Purpose`
+2. `Project Type`
+3. `Problem Space`
+4. `Product Role In The Ecosystem`
+5. `Primary Audience`
+6. `Technology Base`
+7. `Methodological Base`
+8. `Distinguishing Characteristics`
+9. `What This Project Is Not`
+10. `External Reading Angle`
+11. `Boundary`
+
+Section titles may vary slightly if the project requires different wording, but the same informational shape must be preserved.
+
+## Section Intent
+
+The generated sections should satisfy the following intentions:
+
+- `Purpose` states why `ai-intro.md` exists.
+- `Project Type` classifies the product at the highest level.
+- `Problem Space` states the narrow problem the project solves.
+- `Product Role In The Ecosystem` positions it relative to neighboring software categories.
+- `Primary Audience` identifies who uses or integrates the project.
+- `Technology Base` identifies language, platform, packaging, runtime, and major technical assumptions.
+- `Methodological Base` identifies the project-governing method or architectural family only insofar as it helps classify the project.
+- `Distinguishing Characteristics` states the project choices that matter most for identity.
+- `What This Project Is Not` prevents common misclassification.
+- `External Reading Angle` points to a few high-value follow-up documents using relative links only.
+- `Boundary` states what the document does not define.
+
+## Acceptance Model
+
+The generated `ctx/docs/ai-intro.md` is valid when it:
+
+- gives a correct high-level picture of the project;
+- remains specific to the current repository;
+- avoids restating internal documentation structure in detail;
+- helps an AI agent classify the project correctly before reading deeper documents;
+- preserves declarative style and compact scope.

package/ctx/assets/.gitkeep

@@ -0,0 +1 @@
+

package/ctx/docs/AGENTS.md

@@ -0,0 +1,121 @@
+# Project Documentation
+
+- Path: `ctx/docs/AGENTS.md`
+- Changed: `20260813`
+
+## Purpose
+
+Defines the structure of project-level declarative documentation organized by ADSM levels.
+
+Documents at this level describe the system as a design object, including meaning, structure, environment, and implementation constraints.
+
+## Level Map
+
+- `architecture/` — structural form of the system, architectural entities, boundaries, and interaction model.
+- `code/` — engineering invariants governing how architecture is expressed in source code.
+- `environment/` — runtime environment and infrastructural prerequisites required for system operation.
+- `product/` — system meaning, domain entities, and product-level invariants.
+- `AGENTS.md` — level definition for `ctx/docs/`.
+- `ai-intro.md` — entry document for AI agents that positions the project in the broader software landscape and gives initial project understanding.
+- `filesystem.md` — declarative description of top-level repository directories and root-level files, defining repository boundaries and serving as a navigation map.
+
+## Level Boundary
+
+Defines:
+
+- System meaning and domain intent through the documentation dependency chain rooted in `product`.
+- System realization guardrails through `architecture`, `environment`, and `code`.
+- Mandatory declarative constraints that bound any valid implementation.
+
+All statements defined at this level and below are mandatory constraints for any valid implementation.
+
+Violation of these constraints constitutes an incorrect result, regardless of functional correctness.
+
+Does NOT define:
+
+- Agent operations, workflow execution, or prompt-routing assets under `ctx/agent/`.
+- Concrete implementation artifacts such as `src/`, `bin/`, `test/`, or other product files.
+- Ad hoc task instructions that bypass or override the documentation dependency order.
+
+## Documentation Rules
+
+- Use explicit line breaks to keep each durable statement easy to scan.
+- Keep agent documents dense, explicit, and maintainable.
+- Keep skin documents compact, human-readable, and easy to supervise.
+- Split large agent-document areas into natural nested subdocuments instead of over-compressing them for human readability.
+- Preserve project-specific nested subdirectories under the four top-level documentation levels.
+- Keep each documentation level to no more than nine direct directories and nine direct ordinary files, excluding `AGENTS.md` and all matching `*.skin.<lang>.md` files, where practical.
+- When a level deliberately exceeds either value, its `AGENTS.md` must include a `## Documentation Capacity Exception` section that states the exception and its reason.
+
+## Level Order
+
+Documentation levels form a strict dependency order:
+
+```
+product
+↓
+architecture
+↓
+environment
+↓
+code
+```
+
+`architecture` translates product intent into stable engineering structure.
+
+Lower levels may refine but must not redefine statements established at higher levels.
+
+Lower levels may increase explicitness, constraint, and operational precision, but must not introduce new meaning absent from higher levels.
+
+They must not add new product capabilities, invariants, authority, or semantic boundaries unless those are first named upstream.
+
+## Documentation As A Cognitive Interface
+
+Project documentation is the cognitive interface through which humans and agents cooperate across the documentation levels.
+
+- It communicates human goals, constraints, and decisions to agents.
+- It communicates agent findings, inconsistencies, and refinements back to humans.
+- It connects the human direction-setting and result-evaluation loop with the agent refinement and execution-support loop.
+- It must keep agent documents precise for agent execution and skin documents concise for human semantic control.
+- It must support the full dependency order from product through architecture, environment, and code.
+
+## Project Versus Skill Responsibility
+
+Documents under `ctx/docs/` should primarily govern project development rather than explain or enforce ADSM on their own.
+
+- Project documentation should define product meaning, architecture, constraints, decisions, and other load-bearing project knowledge.
+- The skill should enforce ADSM structure, document-shape discipline, audit criteria, and compression rules.
+- When a project document can either explain ADSM or help govern the project, prefer the project-governing content and leave ADSM conformance work to the skill.
+
+## Documentation Projection Model
+
+Documents under `ctx/docs/` are agent-facing operational context documents by default and are written in English unless a more specific rule applies.
+
+Human-facing semantic skins use the explicit `*.skin.<lang>.md` suffix, with lowercase ISO 639-1 language codes such as `en`, `ru`, or `es`.
+
+An unmarked `*.skin.md` file is invalid. One agent document and all skins with the same basename and directory form one document group.
+
+Agents must read every matching skin before changing its matching agent document.
+
+If a requested agent-document change would violate a skin, report a human decision instead of silently rewriting meaning.
+
+If an agent document and its skin conflict, treat the conflict as projection drift and request a human decision before changing controlled meaning.
+
+`overview.md` has no methodology-level status; it is an ordinary agent document unless paired with one or more `overview.skin.<lang>.md` files.
+
+`AGENTS.md` files remain short local reading, editing, and routing instructions for agents.
+
+`AGENTS.md` files are not full documentation artifacts and must not replace agent documents or semantic skins.
+
+Visual, generated, rendered, or auxiliary artifacts belong under `ctx/assets/**` and must not introduce authoritative project meaning.
+
+## Document Attributes
+
+Documents under `ctx/docs/` use:
+
+```md
+- Path: `ctx/docs/{{subdir}}/file.md`
+- Changed: `YYYYMMDD`
+```
+
+All stable documents use `Path` and `Changed` attributes.

package/ctx/docs/ai-intro.md

@@ -0,0 +1,37 @@
+# AI Introduction
+
+- Path: `ctx/docs/ai-intro.md`
+- Changed: `20260702`
+
+## Purpose
+
+Introduces this repository to an AI agent as a skill product whose responsibility is managing ADSM project cognitive context lifecycle.
+
+## Repository Identity
+
+This repository provides a generic orchestration skill for ADSM context lifecycle work.
+
+It helps initialize, design, validate, audit, compress, and upgrade project cognitive context.
+
+## Project Boundary
+
+This repository does not define the business or architecture of an external product.
+
+Its product is the skill package itself:
+
+- CLI tooling in `bin/` and `src/`
+- skill payload in `skill/`
+- reusable context templates in `skill/templates/ctx/`
+- working skill templates in `skill/templates/work/`
+- repository cognitive context in `ctx/`
+
+Documentation quality audit and documentation compression are agent-guided skill capabilities, not CLI commands.
+
+Do not treat `ctx/agent/` as part of the ADSM methodology baseline beyond its boundary file `skill/templates/ctx/agent/AGENTS.md`.
+
+## Reading Order
+
+1. Read `ctx/docs/filesystem.md` for repository boundaries.
+2. Read `ctx/docs/product/overview.md` for product meaning and scope.
+3. Read `ctx/docs/code/overview.md` for product-code boundaries.
+4. Read `skill/SKILL.md` when working as an agent using the packaged skill.

package/ctx/docs/architecture/AGENTS.md

@@ -0,0 +1,98 @@
+# Architecture Documentation
+
+- Path: `ctx/docs/architecture/AGENTS.md`
+- Changed: `20260715`
+
+## Purpose
+
+Defines the architecture documentation level.
+
+Documents at this level translate product intent into stable engineering structure, behavior, state ownership, integration boundaries, architectural constraints, durable decisions, and supervision rules.
+
+## Level Map
+
+- `AGENTS.md` — level definition for `ctx/docs/architecture/`.
+- `behavior.md` — major internal lifecycle flows and architectural processing behavior.
+- `checklists.md` — supervision and diagnosis checklists for reviewing agent behavior against architecture expectations.
+- `constraints.md` — non-negotiable architectural restrictions and trust boundaries.
+- `decisions.md` — durable architecture decisions, rejected alternatives, and reasoning.
+- `integration.md` — external integrations and major internal contracts between architectural areas.
+- `overview.md` — architectural style, major areas, and architecture-level orientation.
+- `state.md` — state ownership, sources of truth, derived state, and state-changing authority.
+- `structure.md` — major architectural blocks, runtime areas, and responsibility boundaries.
+- `supervision.md` — human-agent supervision rules, approval boundaries, and drift signals.
+
+## Architecture Knowledge Model
+
+Architecture knowledge is organized as one coordinated model rather than a set of isolated notes.
+
+Each document answers a different architectural question, and the set is intended to be read together:
+
+- `structure.md` — what is structurally built.
+- `behavior.md` — how the system behaves internally.
+- `checklists.md` — how a human quickly checks whether agent work remained inside architecture guardrails.
+- `state.md` — where authoritative state is owned, changed, and derived.
+- `integration.md` — what integrations and internal contracts exist.
+- `constraints.md` — what must not be violated.
+- `decisions.md` — why durable architectural choices were made.
+- `supervision.md` — how human and agents govern architectural consistency.
+- `overview.md` — architecture-level orientation.
+
+If an agent document grows too large to maintain, move operational detail into a natural architecture subdocument or nested subdirectory.
+
+## Local Rules
+
+- Preserve nested architecture subdirectories when they improve maintainability.
+
+## Level Boundary
+
+Defines:
+
+- Major architectural areas, system boundaries, and integration surfaces.
+- Internal behavior, state ownership, and authority distribution.
+- Durable architectural constraints, decisions, and supervision rules.
+
+Does NOT define:
+
+- Product meaning such as roles, domain entities, or use-case outcomes.
+- Deployment procedures, operational workflow routing, or environment-specific runbooks.
+- Source-level implementation details such as files, classes, tables, DTOs, or endpoint definitions.
+
+## Relationship To Product
+
+Architecture depends on product documentation and refines it. It is not an independent source of product truth.
+
+The dependency order is:
+
+```text
+product
+  → architecture
+  → environment
+  → code
+```
+
+Product documentation defines what the product is.
+
+Architecture documentation defines how that product is realized structurally.
+
+Architecture may refine product intent into engineering structure, but must not redefine:
+
+- what the product is;
+- who product roles are;
+- which domain entities exist;
+- which product outcomes matter.
+
+Architecture may add engineering precision, constraints, and internal mechanisms, but must not add new product meaning.
+
+Architecture must not invent new product behavior or silently resolve product contradictions.
+
+If an architectural concept becomes load-bearing for a product capability, invariant, authority boundary, or semantic boundary, that concept must be named in product documentation first.
+
+When product knowledge is missing or contradictory, architecture documents must expose the gap and escalate it instead of creating implicit meaning.
+
+## Authoring Rules
+
+- Keep agent documents dense, explicit, and maintainable.
+- Prefer declarative statements over implementation detail.
+- Respect the dependency order during analysis and change planning.
+- Do not introduce new architectural owners, new persistent state, new external integrations, or new system boundaries without corresponding document updates and human approval.

package/ctx/docs/architecture/behavior.md

@@ -0,0 +1,68 @@
+# Architecture Behavior
+
+- Path: `ctx/docs/architecture/behavior.md`
+- Changed: `20260708`
+
+## Purpose
+
+Defines how the skill behaves internally across its major lifecycle flows.
+
+## Core Flows
+
+- `init` creates a baseline cognitive context, writes starter documentation, and establishes metadata for later supervision.
+- `design` turns product-level intent into justified context branches, including architecture-level structure when the project needs it, and preserves project-defined workflow semantics when organizing workflow documentation.
+- `validate` checks that declared context structure exists and remains mechanically readable by verifying required paths, metadata headers, deterministic agent/skin projection rules, local markdown document links, and lightweight skin-shape heuristics without rewriting project meaning or downgrading project workflow semantics to template placeholders.
+- `quality-audit` guides an agent through evidence-backed review of a documentation corpus against ADSM documentation quality criteria, using a reference prompt and a working report template rather than CLI semantic scoring.
+- `documentation-compression` guides an agent through controlled rewrite of `ctx/docs/` to reduce redundancy and attention cost while preserving accepted project meaning.
+- `upgrade` applies or reports non-destructive migrations while preserving project-specific content.
+- `install-skill` installs the current `skill/` payload into a caller-provided skills root; it supports agent availability and is not a context lifecycle mode.
+
+## Architectural Processing
+
+The product operates through a documentation-first loop:
+
+1. read declared context and repository state;
+2. determine the applicable lifecycle mode;
+3. apply structure, checks, or migration logic;
+4. report gaps, contradictions, or specialization needs explicitly.
+
+Documentation quality audit follows the same documentation-first loop, but its output is an audit report rather than direct context mutation.
+
+`validate` is the deterministic pre-lint stage for `ctx/docs/**`.
+
+It should be run before semantic audit or compression-oriented review.
+
+Documentation compression follows the same documentation-first loop, but its output is a semantically conservative rewrite plus a compression report.
+
+The audit separates:
+
+- editorial fixes that preserve meaning;
+- cross-document consistency fixes;
+- upstream documentation gaps;
+- human decisions required before documentation can be corrected.
+
+Compression may apply editorial rewrites directly when authority is clear. It must report non-editorial uncertainty instead of resolving it.
+
+Validation findings separate:
+
+- hard structural failures such as missing paired agent documents, missing required skin sections, broken local markdown links, or missing `Includes:` / `Excludes:` blocks;
+- heuristic supervision warnings such as skin compactness threshold overrun;
+- semantic review concerns that remain outside deterministic validation and therefore belong to documentation quality audit.
+
+## Drift Handling
+
+When a new architectural concept appears, the expected sequence is:
+
+1. update product or architecture documentation;
+2. confirm supervision boundaries;
+3. change downstream environment or code artifacts.
+
+The architecture level must not be bypassed by direct code invention.
+
+## Escalation Rules
+
+- Missing product meaning must be surfaced to the human.
+- Documentation quality findings that require product or architecture decisions must be reported as human decision points, not resolved by invention.
+- Documentation compression must not invent, weaken, generalize, or silently delete project-specific knowledge.
+- Missing specialized skill coverage must be reported as a specialization gap, not treated as a reason to erase or invalidate project-defined workflow semantics.
+- Contradictions between templates, repository context, and implementation must be treated as drift.

package/ctx/docs/architecture/checklists.md

@@ -0,0 +1,48 @@
+# Architecture Checklists
+
+- Path: `ctx/docs/architecture/checklists.md`
+- Changed: `20260813`
+
+## Purpose
+
+Provides short recurring document checklists for supervision, diagnosis, and acceptance of architecture-level agent work.
+
+This file remains an agent-facing operational context document.
+
+Human-controlled semantic control belongs in a matching `checklists.skin.en.md` file if such control is needed.
+
+## Drift Diagnosis Checklist
+
+Use this checklist when an agent appears to be working in the wrong architectural direction.
+
+- Is the agent working inside the documented product and architecture boundaries?
+- Does the change stay inside declared architecture boundaries?
+- Does the change introduce a new owner, major area, integration, trust boundary, or durable state?
+- Does the change depend on product meaning that is not explicitly documented upstream?
+- Did the agent treat template guidance as if it overruled project-specific meaning?
+- Did the agent choose a direction that `constraints.md` already forbids?
+
+## Approval Checklist
+
+Use this checklist before allowing architecture expansion.
+
+- Is the proposed expansion named explicitly in product documentation where required?
+- Is the new boundary or owner documented in the appropriate architecture file?
+- Is the approval need already declared in `constraints.md` or `supervision.md`?
+- Does the change increase human supervision burden in a durable way?
+- Is the expansion being justified by real product need rather than by agent convenience?
+
+## Compression Safety Checklist
+
+Use this checklist before accepting compression of architecture documents.
+
+- Does the rewrite preserve the same authoritative meaning?
+- Did any precise rule become a vague summary?
+- Was any durable decision, exclusion, or boundary removed because it looked repetitive?
+- Did the rewrite keep one authoritative home for each load-bearing meaning?
+- Can a human still scan the control documents quickly after compression?
+
+## Related Documents
+
+- Read `constraints.md` next for forbidden directions and approval boundaries.
+- Read `supervision.md` when the question is about ownership of correction and escalation.

package/ctx/docs/architecture/constraints.md

@@ -0,0 +1,53 @@
+# Architecture Constraints
+
+- Path: `ctx/docs/architecture/constraints.md`
+- Changed: `20260813`
+
+## Purpose
+
+Defines non-negotiable architectural restrictions for this skill product.
+
+## Core Constraints
+
+- The product remains generic and orchestration-oriented.
+- Product knowledge precedes architecture, architecture precedes environment, and environment precedes code.
+- New architectural concepts are documented before code-level realization.
+- Templates remain project-neutral and must not guess domain-specific implementation.
+- The root `AGENTS.md` template must prevent agents from reading, loading, printing, searching for, or exposing secret-bearing project data, including `.env` files; non-secret example templates may describe configuration shape only.
+- Template-level workflow constraints must not be reinterpreted as limits on project-defined workflow semantics.
+- Validation, quality audit, and upgrade reporting remain non-destructive by default.
+- Documentation compression may rewrite `ctx/docs/` for density only when accepted meaning and authority are preserved.
+- Architecture agent documents remain dense, explicit, and maintainable.
+- Semantic skins remain short enough for frequent supervision and correction in live human-agent dialogue.
+
+## Boundary Constraints
+
+- Architecture must not redefine product roles, product use cases, or product domain entities.
+- Architecture must not introduce code structure as if it were architecture structure.
+- Architecture must not require project-specific technologies unless the project documentation states them explicitly.
+- Architecture must not downgrade project workflow documents to template-neutral content merely because specialized skill support is absent.
+- Architecture must not treat the absence of a specialized skill as evidence that project-defined workflow semantics are invalid.
+- Architecture must not allow documentation compression to replace precise project rules with vague summaries.
+- Architecture must not hide new persistent state, external integrations, or system boundaries behind implementation changes.
+- Architecture must not treat a control-oriented agent document as a semantic skin unless a matching `*.skin.<lang>.md` file exists.
+- Architecture must not impose a rigid internal tree under `ctx/docs/product/`, `ctx/docs/architecture/`, `ctx/docs/environment/`, or `ctx/docs/code/`.
+
+## Change Constraints
+
+The following changes require corresponding architecture-document updates and explicit human approval:
+
+- new architectural owners;
+- new persistent state;
+- new external integrations;
+- new trust boundaries;
+- new major system areas.
+
+## Review Use
+
+Use this document when the question is:
+
+- "Which architectural direction was forbidden here?"
+- "Did the agent expand the product beyond its declared structural boundary?"
+- "Does this change require approval before any implementation or deeper analysis continues?"
+
+If `constraints.skin.en.md` exists, read it before changing this document.

package/ctx/docs/architecture/constraints.skin.en.md

@@ -0,0 +1,38 @@
+# Architecture Constraints Skin
+
+- Path: `ctx/docs/architecture/constraints.skin.en.md`
+- Changed: `20260813`
+
+## Purpose
+
+This skin preserves the non-negotiable architectural restrictions that keep the skill generic, non-destructive, and context-preserving.
+
+## Mental Model
+
+Architecture may refine structure and control surfaces, but it must not expand product meaning or relax supervision-critical restrictions.
+
+## Scope
+
+Includes:
+
+- non-negotiable architectural restrictions;
+- non-destructive reporting expectations;
+- preservation of accepted meaning during compression.
+
+Excludes:
+
+- detailed code-module layout;
+- project-specific workflow semantics;
+- implementation-only optimizations.
+
+## Invariants
+
+- The product remains generic, orchestration-oriented, and protects secret-bearing project data from agent exposure.
+- Validation, quality audit, and upgrade reporting remain non-destructive by default.
+- Documentation compression must preserve accepted meaning and skin-controlled meaning.
+- Project-specific workflow semantics must not be downgraded because specialized skill support is absent.
+- Control-oriented `*.md` files remain agent documents; semantic control belongs in matching `*.skin.<lang>.md` files when needed.
+
+## Agent Document
+
+`constraints.md`