本文へ移動
cccskills
無料GitHub で公開

wfa-platform-services

Phase C of a WinForms-to-Avalonia migration: implement platform and infrastructure adapters for dependencies discovered in Phase A/B, such as persistence, process execution, dialogs, notifications, or environment capabilities. Use only in an explicit migration when such dependencies leak into Forms/core or when the orchestrator routes here. Do not invent adapters for capabilities the product does not have, and do not implement main-window XAML.

インストール方法を見る

含まれるファイル(4)

  • SKILL.md4.0 KB
  • references/external-processes.md1.1 KB
  • references/platform-abstraction.md1.2 KB
  • references/settings-migration.md1.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Phase C — Platform / Infrastructure services

Replace legacy static helpers and environment coupling with injectable, testable adapters.

Read platform abstraction to define ports, external processes only when the product launches child processes, and settings migration only when settings exist.

Workflow

1. Catalog touchpoints

Legacy patternService direction
UI prompts hidden in helpershost-owned interaction port
Static notifications or loggingstructured diagnostic/logging port
Persisted application preferencestyped, versioned store
Filesystem or process callsnarrow adapter with cancellation and failure semantics
Environment capability checkscapability query plus supported/unsupported result
Legacy deployment integrationreplace, isolate, or explicitly retire

2. Interfaces vs implementations

  • Abstractions consumable without Avalonia types where possible
  • Implementations in Infrastructure, or in the UI host when they require a UI lifetime

3. Persisted state, when present

Evolve toward a versioned single document when multiple stores appear:

  • schemaVersion + sections
  • Ordered migrators
  • Reject future versions (do not overwrite with defaults)
  • Preserve predecessor data while migration is being validated
  • Validate the complete document before commit
  • Write to a temporary sibling, flush as required, then atomically replace
  • Preserve the last known-good state when parsing or migration fails
  • Define in-process and cross-process coordination from the actual deployment model

4. External processes, when present

  • Argument arrays, never shell string concatenation with user-controlled values
  • Timeout + cancellation
  • Distinguish not-found vs started-but-failed
  • Document selection and fallback policy

Unavailable dependencies return a structured unavailable result without changing product state.

5. Dependency-backed adapters

Implement the ports defined in Phase B and test success, failure, cancellation, timeout, and partial-result cleanup with fakes or controlled integration fixtures.

6. Secondary-surface API only

Use a narrow host interaction/window service for secondary surfaces; XAML belongs in Phase D.

7. Logging

Structured logging; bounded UI buffer with events after append; localize at display time.

Corrections seen in practice

  • Resolve optional dependencies according to documented product policy, not a universal search order.
  • Account for platform differences in process I/O, paths, permissions, and lifecycle when relevant.
  • Prefer portable implementations when cross-platform support is an explicit requirement.
  • Use one transaction boundary for one logical settings update.
  • Treat migration as validated best effort, not a promise of lossless conversion.
  • Do not silently change product defaults without an explicit decision.

Deliverables

  • Service interfaces + registration
  • Persisted-state store and migration story when persistence exists
  • Required platform adapters implemented; absent capabilities were not invented
  • Environment-dependent adapters covered with fakes or integration tests
  • Unsupported platform behavior is explicit and recoverable
  • Persisted writes are versioned, validated, and durable when persistence exists
  • No UI prompts or direct environment calls leak into the application core

Handoff

  • UI → wfa-avalonia-ui
  • Post-port product evolution -> wfa-post-port-evolve

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

Archive multiple completed changes at once. Use when archiving several parallel changes.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.

日本語の概要は準備中です。原文の説明を表示しています。

tautcony/ChapterTool1132026年10月11日 更新

tautcony のスキルをすべて見る

このスキルの問題を報告する