Refactor dotcraft-dev into two separate plugins

.craft/plugins/marketplace.json

@@ -147,6 +147,18 @@
         "authentication": "ON_INSTALL"
       },
       "category": "Productivity"
+    },
+    {
+      "name": "harness-workflow",
+      "source": {
+        "source": "local",
+        "path": "./plugins/harness-workflow"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Engineering"
     }
   ]
 }

plugins/dotcraft-dev/.craft-plugin/plugin.json

@@ -1,19 +1,19 @@
 {
   "schemaVersion": 1,
   "id": "dotcraft-dev",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "displayName": "DotCraft Dev",
   "description": "Development plugin for working on DotCraft itself.",
   "capabilities": ["skill"],
   "skills": "./skills/",
   "interface": {
     "displayName": "DotCraft Dev",
-    "shortDescription": "DotCraft development guidance, workflows, docs standards, UI prototyping, and SVG support.",
-    "longDescription": "A DotCraft development plugin for contributors working on DotCraft itself. It bundles repository guidance, feature workflow planning, documentation writing standards, Desktop UI prototyping, and SVG asset design skills under one shared DotCraft Developer logo.",
+    "shortDescription": "DotCraft development guidance, documentation standards, and release drafting.",
+    "longDescription": "Product-specific guidance for contributors working on DotCraft itself, including repository development norms, localized documentation standards, and evidence-based GitHub release drafting.",
     "developerName": "DotHarness",
     "category": "Engineering",
     "capabilities": ["Skill"],
-    "defaultPrompt": "Use the bundled DotCraft development skills for repository guidance, feature workflow planning, documentation writing, Desktop UI prototyping, or SVG asset design.",
+    "defaultPrompt": "Help me make this change to DotCraft while following the project's development, documentation, and release conventions.",
     "brandColor": "#2458F7",
     "composerIcon": "./assets/dotcraft-developer.svg",
     "logo": "./assets/dotcraft-developer.svg"

plugins/dotcraft-dev/skills/dev-guide/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: dotcraft-dev-guide
-description: Development workflow and project-specific norms for DotCraft. Use when changing protocol behavior, or shipping user-facing features. Covers spec-first workflow, testing rules and bilingual docs.
+description: DotCraft development conventions. Use when changing protocols or shipping user-facing functionality.
 ---
 
 # DotCraft Development Guide
 
 Project-specific workflow and norms for DotCraft.
-For generic C#/Rust/React style, follow each ecosystem's standard conventions.
-For repo orientation, read `CLAUDE.md`.
+For general language and framework style, follow the relevant ecosystem conventions.
+For repo orientation, read the applicable `AGENTS.md` files.
 
 ## Development Workflow
 
@@ -19,7 +19,7 @@ If a proposed change conflicts with an existing spec, resolve the spec-level con
 ### Steps
 
 1. **Plan**: Search the codebase for similar features before adding new abstractions.
-2. **Implement**: Follow the project-specific norms below. Add XML docs for public C# APIs. Update user-facing docs in both languages when behavior changes.
+2. **Implement**: Follow the project-specific norms below. Add XML docs for public C# APIs. Update affected user-facing docs and localized content when behavior changes.
 3. **Test**: Follow the testing rules below.
 4. **Verify**: Confirm changes conform to the relevant spec and docs/examples are in place.
 
@@ -31,64 +31,23 @@ Mode-specific tool removal is appropriate only when the mode represents a genuin
 
 ### Testing Rules
 
-Tests are required for:
+Add tests when an observable contract changes, especially for protocol-dependent behavior and complex multi-step flows or state machines. Pure visual polish, copy changes, trivial refactors, and fixes that do not change an observable contract do not require new tests.
 
-- Protocol-dependent code (JSON-RPC, wire format, session/appserver protocol): add conformance tests aligned with the spec.
-- Complex multi-step flows or state machines: cover key paths and edge cases.
+A meaningful test catches a real regression without duplicating existing coverage or testing language, framework, or private implementation details. Prefer assertions on public behavior, state, persisted data, wire payloads, and user-visible output. Use real temporary dependencies or small fakes instead of extensive mocking unless an interaction is itself the contract.
 
-Tests are not required for:
-
-- Small bug fixes that do not change an observable contract.
-- Pure UI polish (layout, styling, copy tweaks) in desktop or TUI.
-- Trivial refactors with no behavior change.
-
-A test is meaningful only when (applies to C# xUnit and TypeScript tests equally):
-
-- It catches a real regression, not language semantics, trivial getters/setters, or framework internals.
-- It is not redundant with existing coverage; check before adding.
-- It does not merely restate implementation details via excessive mocking; prefer state/output assertions unless interaction itself is the contract.
-- It is not written just to inflate coverage numbers.
-
-Desktop frontend tests:
-
-- Test behavior, not static styling. Cover user-visible output, accessibility names,
-  enabled/disabled state, navigation, store updates, IPC calls, serialization, and
-  data mapping.
-- Do not assert one-to-one visual implementation details such as CSS variables,
-  colors, borders, shadows, spacing, radii, widths/heights, token values, source
-  string snippets, or class names whose only purpose is styling.
-- Keep style-related assertions only when the style is the functional contract,
-  such as computed positions from a drag/drop or popover placement algorithm,
-  ANSI color parsing, virtualized geometry, or resize behavior.
-- Prefer short interaction tests over source/CSS guards. If a UI change is pure
-  polish, document it or verify it manually instead of adding test volume.
-
-DotCraft.Core C# xUnit tests:
-
-- Test observable behavior through public APIs, persisted state, wire payloads, or user-visible results; do not test private implementation shape.
-- When using TDD, work in vertical slices: write one behavior test, make the smallest useful implementation pass, then repeat.
-- For protocol, session, and persistence behavior, prefer real temp stores/services and small fakes over mocks; use interaction assertions only when the interaction is the contract.
-- Do not add tests for trivial formatters, getters, record equality, text passthrough, description/prompt wording, framework behavior, or coverage inflation.
-- Use theories to consolidate repetitive variants only when each row protects a meaningful externally visible case.
-
-Pre-commit: run the relevant full suites for touched areas (`dotnet test` for C#, and corresponding `npm test`/`cargo test` where applicable). Do not commit with known failures.
+- **Frontend**: Test behavior such as accessibility, state, navigation, IPC, serialization, and data mapping. Do not assert styling details unless geometry or visual state is the functional contract; verify pure polish manually.
+- **Core C#**: Test through public APIs and observable results. Skip trivial formatters, getters, record equality, text passthrough, prompt wording, and framework behavior.
 
 ### Language Preference
 
+Before changing localized UI or documentation, inspect the repository's current locale configuration, catalogs, and existing mirrors. Treat those as the source of truth and update every currently supported locale; do not rely on a locale list embedded in this skill.
+
 - **Code comments**: English
-- **Desktop UI strings**: Desktop owns UI localization. Localize for all supported app locales — `en`, `zh-Hans`, `ja`, `ko`, `es`, `fr`, `de` (the source of truth is `desktop/src/shared/locales/types.ts`). This applies to message catalogs and to data-driven UI text such as plugin/extension descriptor `localizedLabel`; provide every supported locale, missing ones fall back to the base string.
+- **UI strings**: The client owns UI localization. Update every locale discovered from the current source of truth, including message catalogs and data-driven UI text such as localized plugin or extension labels.
 - **C# runtime/UI-adjacent messages**: Do not add UI localization state or server-side translation catalogs. C# should emit stable machine-readable keys/codes plus English fallback text (`FallbackText` for CLI/server fallback copy). Desktop owns UI localization.
 - **Protocol-visible system messages**: New client-visible notifications and errors must provide a stable key/code, structured params where useful, and an English fallback. User text, model output, and raw tool output must pass through unchanged.
-- **Docs vs UI**: Documentation (`docs/`) is bilingual (English + Chinese) only; UI strings cover all supported locales above.
+- **Documentation**: Discover the currently supported documentation locales and mirror structure before writing, then update every affected version in the same change.
 
 ## Documentation Guidelines
 
-DotCraft documentation lives under `docs/` as a VitePress documentation site.
-For the full documentation writing standard — audience/purpose routing, per-archetype page templates, voice rules, and the bilingual style guide — use the `dotcraft-docs-guide` skill. The essentials:
-
-When creating or updating documentation:
-
-- Provide all documentation in both Chinese and English.
-- Consider whether the documentation location fits the existing site structure. When inserting new documentation, ask the user where it should go unless the user has already approved a location.
-- Keep documentation concise and current. Do not include historical explanations, such as old-version migration rationale or why legacy behavior existed.
-- Keep the style user-friendly. Avoid excessive code references unless the document is explicitly providing code examples, such as SDK documentation.
+Use `dotcraft-docs-guide` for audience routing, page structure, voice, localization, and site conventions. Before writing, inspect the current documentation structure and supported locales. Place new pages with the appropriate audience, ask only when placement is ambiguous, and document current behavior without historical rationale.

plugins/dotcraft-dev/skills/docs-guide/SKILL.md

@@ -1,17 +1,13 @@
 ---
 name: dotcraft-docs-guide
-description: Standards for writing and editing DotCraft documentation under `docs/` (the bilingual VitePress site). Use whenever creating or revising a docs page — overview/getting-started, a feature page, an architecture/concept explainer, an SDK/API/CLI/protocol reference, or a how-to — or when deciding the right tone, structure, and code density for a page. Trigger this even when the user just says "write docs for X", "add a page about Y", "the docs for Z read badly", or "make this doc more user-friendly", and especially when a page must serve end users vs. developers differently. Does not cover GitHub release notes (use release-draft) or in-code XML/JSDoc comments.
+description: Guidance for writing and editing DotCraft documentation for users and developers, including localized content. Does not cover release notes or code comments.
 ---
 
 # Documentation Guide
 
-A reusable standard for writing product documentation. The single most important decision for any page is **who it is for** and **what job it does** — that choice drives tone, structure, code density, and what you leave out. Most weak docs fail because they mix a beginner's "show me" with a developer's "give me the contract" on one page. This skill keeps those separate.
+The key decision for every page is **who it is for** and **what job it does**. That choice determines tone, structure, code density, and what to omit.
 
-The principles here are project-agnostic. Everything specific to *this* repository — doc framework, section layout, languages, file paths, callout syntax, protected product terms — lives in `references/project-profile.md`. Read that profile first; to reuse this skill on another project, replace only that file. (For the broader DotCraft dev workflow, see the `dotcraft-dev-guide` skill.)
-
-## When to use
-
-Use this when you write or revise any documentation page, or user-facing README copy. Before drafting prose, settle the two questions in Step 1 — they are the whole game.
+Repository-specific details — doc framework, section layout, localization, paths, syntax, and terminology examples — live in `references/project-profile.md`. Read it first and verify changeable details against the current repository. Use `dotcraft-dev-guide` for the broader development workflow.
 
 ## Step 1 — Decide audience and purpose
 
@@ -35,7 +31,7 @@ Every page answers two questions before you write a sentence.
 
 If you can't name one cell in each table, the page has no focus yet — split it. A feature page that drifts into protocol field tables should hand that off to a reference page and link to it.
 
-**Routing examples:** a "Getting Started" page = end user × tutorial → warm, one path, almost no code internals. A protocol page = developer × reference → neutral, exhaustive, table-driven. A "what is feature X" page = end user × explanation → friendly concept page with a diagram, light on code.
+**Illustrative routing examples (e.g., not an exhaustive mapping):** a "Getting Started" page = end user × tutorial → warm, one path, almost no code internals. A protocol page = developer × reference → neutral, exhaustive, table-driven. A "what is feature X" page = end user × explanation → friendly concept page with a diagram, light on code.
 
 ## Step 2 — Match the voice to the reader
 
@@ -57,7 +53,7 @@ The detailed mechanics — person, headings, capitalization, sentence length, co
 
 ## Step 3 — Use the right page template
 
-Don't invent structure. Copy the matching skeleton from `references/page-templates.md` (quickstart, feature overview, how-to, concept/architecture, reference, troubleshooting) and fill it in.
+Use the matching skeleton from `references/page-templates.md` (quickstart, feature overview, how-to, concept/architecture, or reference) rather than inventing a new structure.
 
 ## House conventions (apply to every page)
 
@@ -70,32 +66,20 @@ These principles are universal; the exact syntax, paths, and terms for this repo
 - **End with a "Related docs" footer** of 2–5 sibling links. Assume the reader arrived from search; always give them a next step. Use relative links.
 - **Diagrams carry alt text**; reuse existing ones before drawing new. (Location: profile.)
 - **Stay current; no history.** Don't document old-version migration rationale or "why the legacy behavior existed." Describe how it works now.
-- **Preserve product/brand terms exactly** — don't paraphrase them. (List: profile.)
+- **Preserve established product and brand terms exactly.** The profile contains examples, not an exhaustive vocabulary; inspect current product UI, specs, code, and nearby docs for additional terms.
 - **If the project ships more than one language**, keep all versions structurally identical and edit them in the same change. (Languages + paths: profile.)
 
 ## What must NOT appear
 
-Docs most often lose readers by *including* things that don't belong on the page — not by leaving things out. This is the most common failure mode. Before shipping a page, hunt these down and cut or relocate them.
-
-1. **Internal mechanics on a user or feature page.** Storage paths, config keys, tool/function schemas, state-machine enums, wire formats, class names. A feature page explains *what / why / when*; the instant one of these appears, replace it with a link to the reference page. *Smell: a "what is X" page whose first table exposes an internal storage path and data model the reader doesn't need.*
-
-2. **Architecture explained before the reader needs it.** Don't introduce internal subsystem names or "how it's built" in onboarding or a feature intro. Establish what it does and why first; defer the internals to the developer section and link. *Smell: a getting-started page that lectures on the execution engine right after the user's first action.*
-
-3. **Register whiplash within one page.** Swinging from marketing voice to spec voice leaves everyone unsure who the page is for. One audience per page; if two are genuinely needed, split and link.
-
-4. **Any term used before it's defined.** Internal nouns, acronyms, and load-bearing rules relied on before — or without ever — being explained. Define on first use or link to the definition, especially on the onboarding path.
-
-5. **Historical, migration, or compatibility rationale.** "previously…", "this used to…", "kept for compatibility", "older data isn't migrated". The reader can't act on it — it's changelog material. Describe only current, observable behavior.
-
-6. **Internal-only and spec-voice content.** Maintainer-only env flags, internal TODOs, and requirement phrasing ("the screen **should** open settings…"). Reference docs describe how the product behaves *to a consumer*, not how it ought to behave *to its own developers*.
-
-7. **Duplicated content that drifts.** The same comparison table or value-prop copied across pages — worse, with different labels in each — confuses instead of reinforcing. Single-source it on one page and link from the rest.
-
-8. **Unnatural, translated-feeling phrasing.** Quote-as-subject sentences, actor-hidden noun piles, and long enumerations crammed into one sentence where a list would read instantly. Read it aloud — if you wouldn't say it, rewrite it.
-
-9. **Load-bearing rules left implicit.** If a rule matters, state it once, plainly, as a rule — don't make the reader reverse-engineer it by diffing examples across pages.
+Before shipping, remove or relocate:
 
-10. **Troubleshooting, FAQ, or Q&A sections.** A small problem that keeps recurring means the guidance above it is too thin — strengthen that guidance so the problem doesn't arise, instead of bolting on an error→fix entry. A genuine bug belongs in the issue tracker, where it can be tracked and fixed, not frozen into a doc that quietly goes stale. When you remove a troubleshooting block, fold any load-bearing hint into the relevant step as positive guidance and cut the rest.
+1. Internal mechanics or premature architecture on user-facing pages.
+2. Mixed user and developer registers on one page.
+3. Undefined terms, acronyms, or implicit load-bearing rules.
+4. Historical, migration, compatibility-rationale, maintainer-only, or spec-voice content.
+5. Duplicated content that should have one source of truth.
+6. Unnatural translated phrasing or dense noun-heavy sentences.
+7. Troubleshooting, FAQ, or Q&A sections. Fold essential prevention into the relevant guidance; track genuine bugs in the issue tracker.
 
 Worked before/after examples for each are in `references/style-and-mechanics.md` (§10).
 
@@ -110,8 +94,8 @@ Before you call a page done:
 - [ ] Admonitions earn their place; no callout spam.
 - [ ] "Related docs" footer present with relative links.
 - [ ] No troubleshooting / FAQ / Q&A block — guidance gaps fixed inline, genuine bugs left to the issue tracker.
-- [ ] Nothing from "What must NOT appear" is present — no internal mechanics on user pages, no premature architecture, no history/migration notes, no internal flags or spec-voice "should", no drifting duplicates, no undefined jargon.
-- [ ] Product terms preserved; all project-profile conventions followed (languages in sync, callout/code syntax, asset location).
+- [ ] Nothing from "What must NOT appear" remains.
+- [ ] Established product terms are preserved, including relevant terms not listed in the profile; all current project-profile conventions are followed.
 - [ ] New page placed where its audience already lives — if unsure, ask before creating it.
 
 ## Reference files

plugins/dotcraft-dev/skills/docs-guide/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "DotCraft Docs Guide"
-  short_description: "Standards for writing DotCraft's bilingual docs by audience and purpose"
+  short_description: "Write and edit DotCraft documentation"
   default_prompt: "Use $dotcraft-docs-guide to write or revise DotCraft documentation with the right tone and structure for end users vs developers."