project-tiny-context-harness 0.8.17 → 0.12.0

package/assets/skills/context_development_engineer/SKILL.md

@@ -1,58 +0,0 @@
----
-name: context_development_engineer
-description: Use when the user asks for an architecture or engineering design, technical design/plan, complex implementation design, high-level engineering assessment, 架构方案/工程设计/技术设计/复杂实现方案/系统拆分/工程取舍/架构审计, or when the actual task content materially requires owner/source-of-truth, API/schema/data/state/lifecycle, dependency, complex alternatives, concurrency/recovery, external-integration/shared-abstraction, performance, security, compatibility/migration, implementation tradeoff, or architecture-audit judgment. Do not trigger merely for routine coding, local bug fixes, small refactors, tests, documentation, styling, package/release work, generic requests to implement/build/change code, a generic implementation plan, role-only mentions, or mentions of multi-agent, subagent, or parallel work.
----
-
-# Context Development Engineer
-
-## Scope
-
-Add engineering-design and architecture judgment to the default Workflow Contract. This Skill is not the default implementation workflow, a coding persona, planner, agent allocator or verification authority. Routine implementation continues under root `AGENTS.md`.
-
-Project-specific engineering rules belong in `<harnessRoot>/skills/development_engineer/SKILL.md`; the repo-local Skill is more specific, while durable conclusions still belong in `project_context/**`.
-
-With a valid Long-Task binding, `long-task-workflow` alone owns its lifecycle and Final Gate. This Skill contributes architecture judgment only and creates no second plan, stage, delegation policy/state or acceptance path.
-
-## Progressive reasoning reference
-
-Read [engineering-design-reasoning.md](references/engineering-design-reasoning.md) completely. Apply only the methods triggered by actual uncertainty and risk; this is not a checklist, artifact schema or required sequence. An explicit-owner task without material design uncertainty stays on the lightweight default path.
-
-## Engineering-design workflow
-
-1. Read required core/default and implicated-owner Context. Before `Context Delta`, run the default bounded high-signal Context search; widen only for discovered dependency or semantic ownership.
-2. State the problem, success boundary and non-goals. Separate facts, constraints, assumptions and unknowns, and Source/Context requirements from current-code behavior.
-3. Identify the existing source of truth and extension point, affected owners, dependency direction, public/internal interfaces, state and lifecycle, failure/recovery boundaries, compatibility constraints and project-native verification entries.
-4. Compare the smallest material alternatives. Prefer the existing owner/facade/adapter when it carries the stable concept; introduce an abstraction only for an evidenced change axis or durable boundary with positive net value. When foundational machinery, a mature protocol/security boundary, a dependency/shared abstraction or a nearby extension point makes sourcing material, add the risk-triggered Build / Reuse / Buy judgment below.
-5. Before implementation edits, surface one externally observable, repository-bound `Architecture Deliberation`: selected design, rejected material alternatives, one plausible future-change challenge, touched technical debt and disposition, forbidden shortcuts, checks, and triggered quality attributes or preservation basis.
-6. Decide exactly one `Context Delta: none|required`. Durable ownership, architecture, API/schema/data, state/recovery, dependency, compatibility, verification/deployment or rationale changes are `required` and update the smallest owning Context before code. A task-local design that preserves those facts is `none`.
-7. Implement under the current Goal and Workflow Contract. After current-candidate checks, include Engineering/Architecture Conformance in default Contract Conformance, then run the separate Context drift check. Add no gate or proof ledger.
-
-## Architecture Deliberation content
-
-Risk changes depth, not whether the checkpoint occurs. Name the controlling Context/code path, concrete owner and unique source of truth, extension point, dependency direction and prohibited bypass; API/schema/data inputs/outputs; interface, state and lifecycle boundaries; material failure/recovery/resource-release behavior; and triggered concurrency, security or compatibility boundaries. State the selected design, material alternatives, a realistic future-change landing without duplicate truth or reverse dependency, technical debt disposition or bounded project-owned exception, forbidden shortcuts, and project-owned type/lint/AST/dependency/contract/behavior/benchmark/probe checks.
-
-Always judge correctness/invariants and maintainability/changeability. Activate reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability only when material. A performance claim requires workload, metric, baseline/budget, environment, comparator/tolerance and project-owned measurement; static shape is not runtime proof.
-
-Refresh the deliberation if scope, ownership, dependency direction, selected design, quality applicability or debt disposition materially changes.
-
-### Risk-triggered Build / Reuse / Buy
-
-Record an `allowed solution set`, `prohibited failure modes` and `required rationale/evidence`, not one required library or abstraction. Choices may include the owning service/facade/adapter, standard library, installed dependency, mature compatible external library, small bounded self-implementation or intentional non-abstraction.
-
-Enumerate every materially supported member before selecting one; selection never removes another supported member from the allowed set. Judge the viable set, retain each unselected but legal member as an alternative, and prohibit only a choice which actually exhibits a prohibited failure mode. `block` needs no supported member or missing safety/compatibility evidence; `decision-required` needs a genuine user/product/external choice.
-
-Reject duplicate owner-held rules, extension-point bypass, an unjustified heavy dependency, plainly incomplete reinvention of mature security-sensitive behavior, incompatible license/platform support, forced abstraction over structurally similar but semantically different code and a second source of truth for one stable rule. Do not add a mandatory open-source preference, DRY rule, generic quality score, artifact, stage or Gate. Conformance asks only whether the selected choice is in the allowed set, avoids prohibited failures and has risk-proportional current evidence.
-
-## Boundary routing
-
-Product goals and acceptance meaning belong to `context_product_plan`. Durable main/drilldown/surface information/action/feedback responsibility belongs to `context_surface_contract`. Durable Design Authority and UI Authority Closure belong to `context_uiux_design`. New design-resource generation/handoff belongs to `design-resource-authoring`. Exact non-UI semantic facts remain owned by Source/Context; exact selected UI values remain owned by selected-design closure.
-
-For monorepos, distinguish expandable read scope from intended/supporting workspaces. Existing Context workspace mappings are semantic routing rather than edit authorization or read ACLs. Do not add workspace registries, topology scans or empty Context mirrors.
-
-For capability scope, distinguish reusable system capability, representative sample validation, full-population operation and explicit non-requirement. A sample cannot prove an all-provider/all-interface/all-platform claim; unresolved scope remains decision-required.
-
-## Output
-
-Return a concise engineering design or assessment: selected owner/extension point, boundaries and invariants, alternatives/trade-offs, future-change/debt judgment, implementation surfaces, verification strategy, decision-required gaps and `Context: updated ...` or `Context: no durable fact change`.
-
-Do not create a required `plan.md`, Task Contract, architecture matrix, verdict, evidence ledger, generic analyzer, phase, lifecycle or second Authority/Gate. Do not claim checks or product acceptance that were not run on the current candidate.

package/assets/skills/context_development_engineer/references/engineering-design-reasoning.md

@@ -1,93 +0,0 @@
-# Engineering Design Reasoning
-
-Use this reference only after `context_development_engineer` has been selected for material engineering-design or architecture judgment. It deepens the existing Architecture Deliberation; it does not create a design phase, plan artifact, evidence ledger, second workflow or acceptance carrier. Apply the smallest useful subset below and state when a method is not material.
-
-## 1. Frame what is actually known
-
-Separate four categories before choosing a design:
-
-- **Facts:** user/Source/Context requirements, repository owners and extension points, observed code/test behavior and externally verified dependency facts.
-- **Constraints:** compatibility, platform, policy, budget, rollout, security, data, lifecycle and scope boundaries that a legal solution must preserve.
-- **Assumptions:** plausible but unproved premises currently needed to proceed. Name who can validate them and what changes if they are false.
-- **Unknowns:** missing information that distinguishes alternatives, changes safety or makes an acceptance claim unsupported.
-
-Current code is implementation evidence, not silent product or architecture authority. A genuine product, legal, security, commercial, safety or external choice remains `decision-required`; implementation-equivalent freedom belongs to the current Goal.
-
-## 2. Identify drivers and path dependence
-
-Name the few forces that materially shape the solution: owner/source-of-truth location, dependency direction, data/state boundaries, lifecycle and failure semantics, compatibility commitments, load/threat conditions and verification reachability. Distinguish an enduring invariant from historical path dependence such as an old API, migration window, installed dependency or deployment constraint. Preserve path dependence only while its reason still applies; do not mistake legacy shape for the desired architecture.
-
-For each material driver, point to repository evidence or authoritative external evidence. If current dependency/library behavior matters and may have changed, use current primary documentation rather than memory.
-
-## 3. Build the smallest material alternative set
-
-Enumerate only alternatives that could plausibly change an owner, boundary, lifecycle, dependency, operational risk or future change cost. Include the current extension point or intentional non-abstraction when viable. When sourcing is material, express Build / Reuse / Buy as the existing allowed solution set, prohibited failure modes and required rationale/evidence.
-
-Steelman every material alternative before rejecting it:
-
-- where it fits the requirements well;
-- its cleanest owner and dependency direction;
-- the strongest reason a competent maintainer would select it; and
-- the evidence or condition under which it would become preferable.
-
-Do not manufacture alternatives for a local choice whose owner and semantics are already explicit. Do not relabel an unselected allowed option as a prohibited failure.
-
-## 4. Use counterfactuals and failure paths
-
-Challenge the leading design with at least one realistic adjacent change and one relevant failure:
-
-- If the next client, provider, state, data volume, permission model or workflow variation arrives, which existing extension point absorbs it?
-- If the selected dependency is unavailable, stale, slow, partial or incompatible, which failure is visible and where does recovery live?
-- If the main assumption is false, which decision changes and which parts remain valid?
-- What would make the rejected alternative win?
-
-Trace only triggered retry, timeout, cancellation, idempotency, transaction, concurrency, consistency, degradation, recovery and resource-release semantics. A family that is not material gets a concise preservation basis rather than invented machinery.
-
-## 5. Select risk-triggered methods
-
-Choose methods for the actual uncertainty; never run all of them by default:
-
-| Trigger | Useful method | Minimum output |
-| --- | --- | --- |
-| Unclear owner or dependency boundary | Repository owner/extension-point trace | One source of truth, legal dependency direction and prohibited bypass |
-| API/schema/data/state change | Contract and state-transition analysis | Inputs/outputs/errors, invariants, ownership, compatibility and recovery |
-| Shared mutable state or parallel execution | Interleaving/consistency analysis | Atomicity boundary, ordering, idempotency and failure recovery |
-| External integration or mature protocol | Current primary-source and repository-fit research | Supported allowed set, compatibility/security/maintenance evidence |
-| Material performance/capacity/cost risk | Complexity model plus project-owned measurement | Workload, metric, baseline/budget, environment and comparator/tolerance |
-| Trust, permission or sensitive data boundary | Threat/abuse-path analysis | Assets, actors, trust crossings, prohibited failures and attributable checks |
-| Public or versioned compatibility change | Migration/rollout analysis | Compatibility window, upgrade/rollback path and current-version evidence |
-| High uncertainty that code can cheaply resolve | Minimum architecture experiment | Hypothesis, smallest observable probe, budget and exit condition |
-
-Research or an experiment informs the decision but is not durable authority or product acceptance. Preserve only stable conclusions in their owning Context.
-
-## 6. Design a minimum architecture experiment
-
-Use an experiment only when a material unknown distinguishes legal alternatives and repository inspection or authoritative documentation cannot answer it cheaply. Define:
-
-- the exact question and competing hypotheses;
-- the smallest representative fixture or probe that can falsify the leading assumption;
-- environment, inputs, metric/observation and comparator;
-- time/resource budget and stop condition; and
-- how each possible result changes the design.
-
-Do not turn a spike into production by default. Representative input proves only its declared scope; it cannot establish an all-provider, all-interface, all-platform or full-population claim.
-
-## 7. Project the decision into implementation
-
-Before handoff to the current Goal, make the design concrete enough to implement without inventing a second architecture:
-
-- owning modules, paths and symbols plus the existing extension point;
-- public/internal interfaces, inputs, outputs and explicit error semantics;
-- data and state owner, persistence boundary and invariants;
-- runtime/resource lifecycle, initialization, cleanup, recovery and observability;
-- dependency direction and forbidden shortcuts;
-- compatibility/migration/rollout handling when applicable;
-- the smallest complete implementation surface and any intentional non-goals;
-- project-owned type/lint/AST/dependency/contract/behavior/benchmark/probe checks; and
-- `Context Delta: none|required`, with the smallest durable owner updated before code when required.
-
-## Architecture audit route
-
-For an audit, compare the current implementation against controlling Source/Context and the concrete owner/boundary model above. Report wrong owner, duplicate truth, reversed dependency, extension-point bypass, silent failure, incomplete lifecycle/recovery, unsupported quality claim and new/worsened debt separately. Distinguish observed defects from assumptions and unverified risks. Do not implement repairs unless the request also authorizes change.
-
-The final current-candidate Engineering/Architecture Conformance remains in the existing default Contract Conformance or, when validly active, the sole Long-Task Final Gate. This reference creates neither.

package/assets/skills/context_full_project_export/SKILL.md

@@ -1,70 +0,0 @@
----
-name: context_full_project_export
-description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
----
-
-# Context Full Project Export
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_full_project_export` Skill directly.
-
-This Skill creates a temporary export artifact only. It does not author durable Context and does not change `project_context/context.toml`.
-
-## Purpose
-
-When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
-
-When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
-
-## Workflow
-
-1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
-2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
-3. Use `--task-context <name>` for focused handoff, preferably with a profile or explicit include selectors:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --profile <profile-id>`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --include-context project_context/areas/main.md --include-code 'src/example/**'`
-4. Use legacy `--all` when the user explicitly wants both old temporary artifacts in one command. Do not hand-write tracked export documents:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`
-5. Use legacy `--full` when only the project Context bundle is needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full`
-6. Use legacy `--code` when only the full code-level implementation snapshot is needed. It generates one Markdown file by default and is the full fallback when Source Pack bundles are not enough:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code`
-7. Custom output paths are allowed only for legacy single-artifact modes and must stay under the temporary export directory. `--all` and Source Pack modes do not accept `--output`:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --output tmp/ty-context/context-exports/my-export.md`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --output tmp/ty-context/context-exports/my-code-export.md`
-8. Use dry-run mode to inspect planned sources before writing:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --check`
-9. After exporting, report artifact paths, source counts, recommended upload sets and warnings to the user. Do not summarize export contents back into Context.
-
-## Output Boundaries
-
-- Export artifacts must remain temporary export artifacts, not Context.
-- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
-- `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
-- `--code-index` creates a navigation index and manifest without complete source bodies.
-- `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.
-- `--full` defaults to `tmp/ty-context/context-exports/full-project-context-<timestamp>.md`.
-- `--code` defaults to `tmp/ty-context/context-exports/code-level-implementation-<timestamp>/code-level-implementation.md`.
-- `--all` generates both default artifacts with the same timestamp.
-- `--all` does not accept `--output`; custom filenames are supported only for `--full` or `--code`.
-- `--code` creates one Markdown file, not shards or `all.md`.
-- Do not output to `project_context/**`.
-- Do not modify `project_context/context.toml`.
-- Do not register export artifacts as `[[context]]`, `implementation-index` or any Context graph node.
-- Do not write tracked docs; if the user asks for an ordinary docs path, redirect to `tmp/ty-context/context-exports/**`.
-- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key/credential/bearer/authorization filtering. Use `--redaction-strict` when the user wants the command to fail if any redaction occurred.
-- Profiles under `<harnessRoot>/config.yaml` are export selectors only. They must not become durable Context facts or execute verification commands.
-
-## Handoff
-
-- Report `Export: generated <path>` or `Export: check completed; no files written`.
-- If the CLI rejects an output path, explain that this prevents temporary exports from polluting durable fact sources and suggest `tmp/ty-context/context-exports/<name>.md`.
-- Context drift check should be `Context: no durable project facts changed` unless the task also changes Harness rules.

package/assets/skills/context_harness_upgrade/SKILL.md

@@ -1,60 +0,0 @@
----
-name: context_harness_upgrade
-description: Use when the user asks to upgrade Tiny Context, update Tiny Context, use the Tiny Context upgrade skill to upgrade this project, upgrade project-tiny-context-harness, run ty-context upgrade, run make ty-context-upgrade, Project Tiny Context Harness upgrade, 用 Tiny Context upgrade skill 升级这个项目, 升级 tiny context, 升级tiny context, or 更新 project-tiny-context-harness in a Minimal Context Harness project.
----
-
-# Context Harness Upgrade
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_harness_upgrade` Skill directly.
-
-This Skill handles Harness package upgrade and migration orchestration only. It does not author product facts, refactor business code, replace project tests or prove application quality.
-
-## Purpose
-
-When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an existing project, run the canonical `upgrade` path, handle only migration-scoped follow-up, and leave durable project semantics to the project Context and user-owned code. A `sync-only` release means no new migration is expected; it does not change the default upgrade entry for explicit upgrade requests.
-
-## Workflow
-
-1. Read the project routing and Context entry points before changing files:
-   - `AGENTS.md`
-   - `project_context/global.md`
-   - `project_context/architecture.md`
-   - `project_context/context.toml`
-2. Inspect the working tree with `git status --short`. Do not revert unrelated user changes.
-3. Prefer project wrappers when present:
-   - `make ty-context-sync`
-   - `make ty-context-upgrade`
-   - `make ty-context-doctor`
-   - `make validate-context`
-4. If no wrapper exists, use the package CLI explicitly:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context sync`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context doctor`
-5. Run `upgrade --check` when useful, then run `upgrade`. This remains the default after package updates and for explicit upgrade requests because it plans migrations, applies safe migrations, refreshes managed assets and runs diagnostics.
-6. Do not run standalone `sync` before `upgrade` for explicit upgrade requests. A direct `sync` is only a shortcut for releases explicitly marked `sync-only` when the user asks for managed-asset refresh instead of upgrade diagnostics.
-7. Do not run standalone `sync` after a successful `upgrade` unless the project wrapper did not run sync or the user explicitly asks for another managed-asset refresh.
-8. If `upgrade --check` or `upgrade` reports only `safe_pending` items and the command succeeds, do not invent additional manual cleanup.
-9. If the report includes `manual_required` or `blocked`, handle only the listed migration scope. Use `project_context/context.toml`, role placement scan and the existing area graph to decide placement. Do not guess product or business semantics.
-10. If the report includes `blocked`, treat it as a write preflight failure: resolve the blocked migration scope and rerun `upgrade` before expecting safe migrations or managed asset sync to have been applied.
-11. Run diagnostics after migration-scoped follow-up:
-   - `make ty-context-doctor` or the CLI `doctor`
-   - `make validate-context`
-12. Report commands run, migration status, diagnostics, files changed and any remaining manual items. Use `Context: no durable project facts changed` unless the upgrade exposed or required a real long-term project fact change.
-
-## Manual Handling Rules
-
-- `manual_required` means the Harness detected a migration-scoped item but cannot safely choose the project meaning. Fix it only when the existing Context or file structure proves the intended placement.
-- `blocked` means the safe target already exists or another conflict prevents a mechanical write. Do not overwrite. Compare source and target, preserve user content and ask for direction if the conflict cannot be resolved from project facts.
-- Deprecated override Skills under `ty-context-managed/override_skills/**` should be migrated to standalone project-local Skills only when their content is still relevant. Do not merge them into package-managed default Skills.
-- Ambiguous Context roles should not be guessed from filenames like `api.md`, `notes.md` or `main.md` alone. Register a role only when the manifest, path convention or durable content makes it clear.
-- If `upgrade` creates default `project_context/areas/main.md` or `project_context/areas/main/verification.md` but `project_context/context.toml` already declares real project areas and does not register `main`, remove those generated defaults instead of preserving them as durable project facts. If `main` is registered or contains user-authored facts, do not delete it automatically.
-
-## Boundaries
-
-- Do not restore legacy stage workflow, sprint documents or phase gates.
-- Do not modify application code, product behavior, deployment settings or tests unless the user explicitly asks or a migration report points to a Harness-owned file in that scope.
-- Do not write one-off command output, release logs, diagnostics or temporary migration notes into `project_context/**`.
-- Do not edit package-managed generated surfaces directly in a consumer project unless the change is part of a migration conflict that cannot be resolved another way. Prefer rerunning `upgrade` / `sync` from the package source.

package/assets/skills/context_product_plan/SKILL.md

@@ -1,42 +0,0 @@
----
-name: context_product_plan
-description: Use when the user explicitly asks for a product plan/spec, product-manager analysis, requirements, goals/scope, business rules, user stories/flows, acceptance criteria, 产品方案, 需求方案, 功能方案, 业务规则方案, 用户流程, 用户故事, or 验收标准 in a Minimal Context Harness project. Do not trigger for ordinary coding, debugging, package/release work, visual design/resource generation, or a request whose durable question is only Product Surface responsibility.
----
-
-# Context Product Plan
-
-## Ownership
-
-Own product meaning: goals, users, problem, scope/non-goals, business and user-visible rules, user flows, product feedback, success/acceptance meaning and genuine product decisions. This Skill does not own Product Surface placement, visual Design Authority, generated design resources, technical architecture, implementation, verification authority or a Gate.
-
-Project-specific product behavior belongs in `project_context/**` and may be specialized by `<harnessRoot>/skills/product_plan/SKILL.md`. Durable conclusions never live only in the Skill output.
-
-When Long-Task is active, it alone owns Source/Contract lifecycle and Final Gate. This Skill may clarify product meaning for the existing Source/Context, but creates no second plan, requirement ledger, stage or acceptance path.
-
-## Workflow
-
-1. Read `project_context/global.md`, `project_context/context.toml`, the default area and product owners triggered by the request. Use the default Workflow Contract's bounded high-signal Context search before `Context Delta`.
-2. Establish target users/actors, problem and desired outcome, scope/non-goals, relevant objects/capabilities, main flow and material alternatives, business/user rules, failure/degraded/recovery expectations, success signals and real decision gaps.
-3. Treat explicit user/product/legal/security/commercial/external constraints as Source. Internally classify each material constraint as Context-covered, requiring Context update, task-local, out of scope or decision-required. Current code reveals implementation; it cannot silently redefine product intent.
-4. Keep conditions and acceptance concrete enough to be observed through the actual product entry. A representative sample cannot satisfy a declared full-population/all-provider/all-interface/all-platform outcome; unresolved scope is decision-required.
-5. Route durable information/action/feedback placement, main-versus-drilldown responsibility, screen ownership or cross-surface IA to `context_surface_contract`. Provide goals, users, flows, rules and acceptance meaning as inputs; do not compile a Surface Contract here.
-6. Route durable visual identity/tokens/rationale/adopted-target interpretation to `context_uiux_design`; new resource generation to `design-resource-authoring`; architecture/engineering design to `context_development_engineer`.
-7. Decide exactly one `Context Delta: none|required`. Update the smallest product owner before implementation when goals, scope, business/user rules, flow ownership, acceptance semantics or durable rationale change. Local bugs or implementation drift that preserve meaning are `none`.
-8. Under the default Workflow Contract, hand implementation to the current Goal and include product conformance in its one current-candidate Contract Conformance. Under Long-Task, project exact non-UI meaning from this product owner into its existing Source/Contract mechanism only—never build a nested Fact ledger or second closure.
-
-## Product-plan output
-
-Keep the result concise and implementation-usable:
-
-- goal, user/problem and success outcome;
-- in-scope and non-goals;
-- product objects/capabilities and owner;
-- main and material degraded/recovery flows;
-- business/user-visible rules and product feedback;
-- acceptance boundaries and observation entry;
-- assumptions, external constraints and decision-required gaps;
-- durable Context changes and downstream owner routes.
-
-Do not invent missing business, legal, security, commercial or external decisions. Do not create a required PRD, `plan.md`, Task Contract, Source-to-Context table, matrix, evidence ledger, phase or lifecycle. Context may name repeatable validation/deployment entries but never say a test or deployment passed unless current evidence establishes it.
-
-Finish with `Context: updated ...` or `Context: no durable fact change`, and clearly separate judged, verified, unverified and decision-required scope.

package/assets/skills/context_surface_contract/SKILL.md

@@ -1,205 +0,0 @@
----
-name: context_surface_contract
-description: Use when the user asks for Product Surface Contract, Surface Contract, Screen Contract, durable product-surface responsibility, information/action/feedback ownership, information architecture governance, main/drilldown ownership, UI product boundary, 产品界面职责治理, 产品接触面, 用户接触面, 页面职责契约, 界面责任契约, or 主层/下钻归属 in a Minimal Context Harness project. Do not trigger for ordinary CSS/UI fixes, product-goal planning, visual Design Authority, design-resource generation, or implementation-only work unless durable surface responsibility is explicitly being defined or repaired.
----
-
-# Context Surface Contract
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_surface_contract` Skill directly.
-
-Project-specific Product Surface responsibilities belong in `project_context/**` and an optional `<harnessRoot>/skills/surface_contract/SKILL.md`. This is the sole package-managed owner for durable surface responsibility; it must not contain business-specific page duties, provider facts, project names, raw payload schemas or product examples.
-
-## Purpose
-
-Help agents turn broad product/UI principles into concrete, project-owned Product Surface Contracts while keeping Minimal Context small.
-
-This Skill owns where user-facing information, actions and feedback belong, including main/drilldown/diagnostic/detail responsibility and cross-surface ownership. `context_product_plan` owns goals, users, business rules, flows and acceptance meaning; `context_uiux_design` owns Design Authority/tokens/rationale/adopted-target interpretation; `design-resource-authoring` owns resource generation. This Skill owns none of those, performs no implementation acceptance and creates no Gate.
-
-A Product Surface is any user-facing interface where users make judgments, take actions and receive feedback. Covered platforms include Web apps, dashboards, admin or operations UI, mobile screens, desktop windows, game UI/HUD/menu scenes, CLI/TUI output, browser extension or plugin UI, and embedded, kiosk or device UI.
-
-Use two depths without creating new roles: Product Surface Contract for cross-surface/main-versus-drilldown ownership, and an optional on-demand Screen Contract when one screen needs stable entry/exit/shared-state, information hierarchy, layout regions, navigation, variants or material-control semantics. Start from managed `product-surface-contract.md` or `screen-contract.md`; do not require both for every task.
-
-## Context Roles
-
-Do not add a new `context_role`.
-
-Use existing roles:
-
-- `contract` for cross-surface, cross-area or project-level Product Surface Contracts.
-- `area` or `subdomain` for owning product-domain Screen Contracts.
-- `verification` for repeatable UI, CLI, app or product-surface validation paths.
-- `decision-rationale` for stable product-surface tradeoff reasons.
-- `implementation-index` for code navigation only.
-
-Forbidden roles include `surface-contract`, `product-surface`, `web-contract`, `app-contract` and `game-surface`.
-
-Use `DESIGN.md` only for visual identity, visual tokens and visual rationale. Do not put surface responsibility, main/drilldown ownership or diagnostic placement into `DESIGN.md`.
-
-Keep one meaning owner: Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable screen/control behavior, `DESIGN.md` owns visual-system semantics and target interpretations, authored targets own concrete declared composition, and verification Context owns repeatable proof paths. Link them with stable surface/control/target keys instead of copying facts.
-
-## Mode Selection
-
-Use the narrowest mode that matches the request:
-
-- Audit Mode: inspect whether existing surfaces have clear responsibility.
-- Compile Mode: turn audit findings or user decisions into Context candidates.
-- Apply Mode: write durable Context only when the user explicitly allows durable writes, or when already-authorized product/UI implementation independently yields `Context Delta: required` in the current Goal.
-- Conformance Mode: check implementation against an existing Product Surface Contract.
-
-Do not run implementation, long validation, browser smoke, app smoke or CLI smoke unless the user explicitly asks for execution.
-
-## Audit Mode
-
-Use when the user asks to inspect, review or audit surface responsibility.
-
-Output only:
-
-- Surface list.
-- Surface platform.
-- Code, screenshot, CLI or app evidence inspected.
-- Existing Context expectation.
-- Drift, missing contract or backend complexity exposure.
-- Candidate `Context Delta`.
-- Suggested durable placement.
-- Optional temporary audit path under `tmp/**` when useful.
-
-Do not edit durable Context by default. Code, screenshots and CLI output are evidence of current implementation, not authority for product responsibility.
-
-## Compile Mode
-
-Use when turning audit findings or user decisions into Context candidates.
-
-Output:
-
-- Project-level Product Surface Contract candidate when responsibilities cross surfaces or areas.
-- Area-level Screen Contract candidate when ownership belongs inside one domain.
-- `context.toml` candidate registration with `role = "contract"` when durable registration is needed.
-- `global.md#Context Index` candidate entry when a new Context file is added.
-- Verification candidate for repeatable surface checks.
-- Internal source classification when an external product, architecture, technical or acceptance source changes durable surface responsibility; do not create a Markdown coverage table.
-- Repo-local Skill task-block candidate when the user wants project-specific enforcement.
-
-Do not assume business responsibilities from current code shape alone. Ask for confirmation if the candidate would silently choose between competing product or information-architecture meanings.
-
-## Apply Mode
-
-Use only when the user explicitly allows durable writes, or when product/UI implementation is already authorized and the current Goal independently decides that durable Surface/Screen responsibility changed. Skill activation, analysis, audit, candidate comparison or resource generation alone never grants write authority.
-
-Allowed writes:
-
-- `project_context/**`.
-- `project_context/context.toml`.
-- `project_context/global.md#Context Index`.
-- Optional `verification` role Context.
-- Optional separate project-local Skill files when the user explicitly wants project-local enforcement.
-
-Forbidden writes:
-
-- Package-managed generated Skills in a consumer project.
-- `<harnessRoot>/ty-context-managed/**` in a consumer project.
-- Business code unless the user also requested implementation.
-- Generated files.
-- `DESIGN.md`, except visual tokens or visual rationale that do not belong in a Product Surface Contract.
-
-If `Surface Contract Hit` is `none` and the task creates durable surface responsibility, set `Context Delta: required` and update project Context before implementation alignment.
-
-## Conformance Mode
-
-Use after implementation or during review.
-
-Output:
-
-- Surface Contract Conformance.
-- External-source constraint classification and implementation alignment status.
-- Remaining Drift.
-- Missing Context.
-- Implementation Drift.
-- Verification run / not_run / failed.
-
-Do not store one-off evidence, screenshots, logs, raw outputs or implementation summaries in Context.
-
-## Compiler Questions
-
-For each touched surface, answer only what is relevant:
-
-- What surface is being touched?
-- What platform shape does it have?
-- Which authoritative target-user and usage-context reference applies?
-- What primary user question does it answer?
-- What primary task outcome, primary work object and shortest task loop does it support?
-- Which critical context must remain visible while the user acts?
-- How are each material operation, affected object and feedback related?
-- Does the task force repeated scrolling, navigation or context switching to make one judgment?
-- Which client/host, input-method and size-class constraints change the interaction topology?
-- What belongs on the main surface?
-- What must move to drilldown, diagnostics, operations, evidence or technical detail?
-- Which long-running or mutating actions require task id, progress, retry, import, recovery or history?
-- Which empty, loading, stale, unavailable, fixture or fallback states matter?
-- What validation path can prove conformance?
-- If this came from an external plan/source, which source constraints are covered by existing Context, require new Context, are task-local only, are explicitly out of scope, need user decision or remain under-scoped?
-
-When screen depth is material, also answer only the applicable questions:
-
-- What stable surface/route key, entry context, exit outcome, inherited state and committed state identify the screen?
-- What is the semantic information order and which regions are fixed, scrolling or overlay-owned?
-- Across supported size classes, which regions remain, reflow, collapse, become sheets/sidebars/modals or move to another surface, and how is the primary work object preserved?
-- Which navigation, back/cancel, focus restoration, interruption and responsive/mode/state variants are durable?
-- For each material stable control key, what are its region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics?
-- Which exact-target/constraint/inspiration IDs govern which declared conditions, and which verification path proves each independent claim?
-
-Before applying material UI facts, perform UI Authority Closure: classify each item as Context-covered, Context update, task-local, out of scope or decision-required. Conflicting controlling owners fail closed; current code, timestamps and Contract YAML do not silently win.
-
-## Repo-Local Task Block Candidate
-
-When the user wants project-local enforcement, propose a separate project-local Skill block like this and tailor only the project-specific answers:
-
-```markdown
-## Surface Contract Task Block
-
-For any task touching user-facing surfaces, information placement, forms, filters, search, long-running UI actions, diagnostics, evidence, CLI/TUI output or main/drilldown ownership, answer before implementation:
-
-- Surface Contract Hit: `<context file / none>`
-- Surface: `<route / screen / window / panel / command / HUD / menu>`
-- Surface Platform: `<web | mobile | desktop | game | cli-tui | extension | embedded | mixed>`
-- Owning Product Domain: `<area / subdomain>`
-- Primary User Question: `<one concrete user judgment>`
-- Primary Task Outcome / Work Object / Loop: `<outcome; object; orient-act-feedback-finish loop>`
-- Critical Context Kept Visible: `<context required while acting>`
-- Operation–Object–Feedback: `<material relationship>`
-- Client / Size-Class Topology: `<host/input constraints and region changes>`
-- Main Surface Allows: `<durable visible information and actions>`
-- Main Surface Forbids: `<backend fields, raw payloads, diagnostics, debug ids, fake states, etc.>`
-- Drilldown Ownership: `<details / evidence / operations / diagnostics / technical details>`
-- Long Task State Requirement: `<run id, progress, retry, recovery, import, history, or none>`
-- Context Delta: `<none | required>`
-- Verification: `<view-model test / component test / browser smoke / CLI smoke / manual check>`
-```
-
-Do not add this task block to package-managed default Skills as a universal gate. Projects opt in through separate project-local Skills.
-
-## Implementation Alignment
-
-When implementation is also requested, align code with the Product Surface Contract:
-
-- View-models or presenters should expose user-facing states instead of raw backend payloads when that contract exists.
-- Components or commands should render main-surface facts and move technical details to the owning drilldown.
-- Long-running actions should persist or recover the required operation state.
-- Tests should assert user-facing state semantics, not only backend field plumbing.
-- Browser, app, CLI or game smoke checks should validate actual surface behavior when feasible.
-
-Final handoff should include concise `Surface Contract Conformance`: contract source, implementation alignment, remaining drift and verification status.
-
-Conformance must internally confirm that every important external-source constraint is covered by Context, updated into Context, task-local, explicitly out of scope or awaiting a genuine user decision, and that controlling surface facts reached the correct implementation. Unresolved constraints or non-aligned surface implementation mean the work cannot be described as fully aligned; component, modal, viewmodel or unit evidence alone cannot prove main-surface ownership. Do not create a fixed `plan.md`, Task Contract file or Markdown mapping tables for this check.
-
-## Output Boundaries
-
-- Do not create PRDs, UI/UX handoff docs, ADRs, stage artifacts, lifecycle state or phase gates.
-- Do not update Context for ordinary CSS tweaks, copy edits or one-off UI bug fixes unless durable surface responsibility changes.
-- Do not treat current backend fields, enums, JSON, screenshots or terminal output as product intent.
-- Do not invent rationale; rejected alternatives or tradeoffs belong in Context only when they are stable enough to affect future surface decisions.
-- Do not add a surface-specific validator, edit-order gate, plan-contract validator or package-level mandatory Surface Contract gate.
-- Do not create a `design`/`screen` Context role, per-surface readiness state, UI/UX Contract lifecycle or required Screen Contract for local fixes.
-- Do not include business-domain examples in this package-managed Skill.
-- Do not author visual values, `DESIGN.md`, design resources, product acceptance evidence, a verification verdict or a workflow Gate.

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,53 +0,0 @@
----
-name: context_uiux_design
-description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual tokens/rationale, adopted target interpretation, UI Authority Closure, selected-design alignment or durable visual standards; or when actual task content requires material UI/UX analysis or audit for a new page/flow/complex control, information hierarchy, fixed/scroll/overlay/sheet/sidebar/modal topology, map/canvas/editor work, primary task and feedback loop, client adaptation, navigation/recovery/states or accessibility in a Minimal Context Harness project. Do not trigger merely for product/surface responsibility, design-resource generation, ordinary local UI implementation, CSS/copy/icon/image fixes, local exact-target alignment, a single-control visual preview or an unselected visual exploration.
----
-
-# Context UI/UX Design
-
-## Ownership
-
-Own durable Design Authority only: root `DESIGN.md`, visual identity and exact-value token source/generation direction, visual rationale, canonical adopted-target interpretation/selection basis, adoption records, UI Authority Closure and selected-design alignment.
-
-This Skill does not own product goals/business rules/acceptance (`context_product_plan`), information/action/feedback and main/drilldown responsibility (`context_surface_contract`), resource generation (`design-resource-authoring`), implementation, or acceptance. Route rather than duplicate those owners.
-
-Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL.md`; durable facts remain in `DESIGN.md` and owning `project_context/**`. When a valid Long-Task binding is active, `long-task-workflow` alone owns Source/Contract lifecycle, formal verification, Final Gate and completion. This Skill may contribute non-authoritative task-level UI/UX analysis and Design Authority closure, but creates no second plan, lifecycle, Authority, Gate or acceptance path.
-
-## Task-level analysis adapter
-
-For a material task-analysis trigger, read [task-uiux-analysis.md](references/task-uiux-analysis.md) completely and apply only the relevant methods. This adapter is non-authoritative: Product/Surface/Screen Source owns the user, page duty, primary task/work object, information/action/feedback and interaction-topology facts; this Skill still owns durable Design Authority only. The current Goal may compare and select implementation candidates under those constraints. A conflicting candidate cannot proceed to resource generation or implementation until the stale owner is authoritatively updated or a genuine decision is obtained.
-
-## UI Authority Closure
-
-1. Read core/default and owning surface/interaction Context, root `DESIGN.md`, its authored token source/generation direction, existing production route/components and every affected selected `exact-target` or `constraint` through its immutable locator. Run `ty-context design-resource preflight <handoff.md>` before treating a formal handoff as input.
-2. Classify references as `exact-target`, `constraint` or `inspiration`. Inspiration authorizes no reproduction claim. Provider success, a hash/index or an implementation screenshot proves neither selection nor fidelity.
-3. For every affected stable surface/control/target key, classify durable meaning as Context/`DESIGN.md` covered, requiring update, task-local, out of scope or decision-required. Conflicting, missing, stale, unreadable or unselected authority fails closed for the affected claim.
-4. Confirm exactly one canonical adoption record per adopted target:
-   - project/system/component-family targets are fully owned by `DESIGN.md`;
-   - screen/interaction targets are fully owned by the owning Screen Contract, with `DESIGN.md` keeping only the stable key and owner/anchor;
-   - the record preserves interpretation, selection basis, immutable path/URI and digest, applicable conditions and editable upstream owner/locator/update route.
-5. Never overwrite an adopted baseline. Create a new immutable version/digest, review it deliberately and update the unique canonical record. An implementation render/diff is evidence and cannot become the target it claims to match.
-6. Decide exactly one `Context Delta: none|required`. Skill activation, analysis, audit or candidate comparison alone authorizes no durable write. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is `required`; ordinary UI/CSS fixes that preserve authority are `none`. When product/UI implementation is already authorized and the current Goal independently finds a durable Surface/Screen change, update the smallest owning Surface Context before code or return `decision-required`.
-7. Route unresolved surface placement to `context_surface_contract`; route any request to generate/iterate a wireframe, prototype, visual candidate, state study or handoff to `design-resource-authoring`. Do not invoke resource generation implicitly.
-
-## Selected-design alignment
-
-For a selected implementation handoff, consume the actual canonical resource and its dependency/Fact closure; do not stop at an index or aggregate `complete` label. Preserve exact located values and design-system lineage through stable keys rather than duplicating them into Context.
-
-An `exact-target` claim requires condition-specific full-target layout and pixel comparison through a project-owned Oracle; a named constraint requires proof of that constraint only. Validate affected state, viewport/platform, theme/mode, content stress, accessibility/input and motion conditions declared by Source. Never replace declared combinations with representative/pairwise sampling unless Source narrows scope or a project-owned complete equivalence proof exists.
-
-Implementation conformance runs on the real production route/component and affected cold-start journey after the final change. Detached specimens and deep links are supplemental. Report conditions not established; resource integrity/preflight is not production conformance, and screenshot baseline replacement merely to erase a failure is forbidden.
-
-## DESIGN.md boundary
-
-Use Google `@google/design.md` compatible structure: supported YAML tokens plus Markdown rationale. Maintain Design Authority status, one authored exact-value token source/generation direction and the canonical records owned at project/system/component-family scope. Do not add unsupported front-matter keys or duplicate exact values already owned by a project-native token source.
-
-If available after a change, run `npx @google/design.md lint DESIGN.md`. Exported CSS/theme files are generated implementation outputs, not competing authored truth.
-
-Missing/unconfigured authority blocks invented style-bearing production design. Only an explicit request to initialize/generate/select/adopt the project design system routes to `design-system-authoring`; local fixes and explicit non-fidelity prototypes remain lightweight.
-
-## Output
-
-Report affected authority owners/keys, selected resource classification and condition coverage, immutable/editable provenance, closure/update decisions, implementation-alignment checks, unresolved claims and `Context: updated ...` or `Context: no durable fact change`.
-
-Do not create a UI lifecycle, resource pack, Product Surface Contract, acceptance record, fixed plan/matrix, phase or second Authority/Gate. Do not write one-time screenshots, test logs, debug notes or implementation summaries into Context/`DESIGN.md`.