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

principle-separate-before-serializing-shared-state

Apply when changing shared mutable state, worker coordination, or task lifetimes in NeoHaskell framework internals. Reuse the owning subsystem, separate genuinely independent state, and use existing concurrency primitives where synchronization is required.

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

neohaskell/NeoHaskellスター 348(GitHub 348 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(2)

  • SKILL.md1.8 KB
  • agents/openai.yaml43 B

SKILL.md(原文)

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

Separate Before Serializing Shared State

Start with the framework subsystem that owns the state and its lifecycle, such as a dispatcher, store, or cache. Keep concurrency decisions there, behind operations callers can use. Keep pure transformations pure.

Why: Coordination belongs with the invariant it protects. Spreading mutable state or synchronization across callers makes the invariant harder to enforce. Instructions and conventions are not concurrency control.

Pattern:

  1. Find the owner and invariant. Identify the subsystem that owns the affected state or worker lifetime and read its existing concurrency design before changing it.
  2. Reuse or extend the owner's operations. If a new capability needs an atomic transition or coordinated lifecycle step, implement it at that boundary and have callers use it.
  3. Separate genuinely independent state. Prefer independent ownership when the state does not need to be shared. Preserve a canonical store or coordinated worker registry when its invariant requires one.
  4. Use NeoHaskell concurrency primitives when needed. Within the owning subsystem, read the relevant implementations in core/concurrency/ and choose the module whose ownership, blocking, atomicity, communication, and lifetime guarantees fit the operation. Preserve the whole transition: separately safe reads and writes may not form an atomic update. Follow the Foundational Thinking concurrency guidance.

レビュー

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

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

architect

無料

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

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

neohaskell/NeoHaskell3482026年10月26日 更新

arena

無料

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

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

neohaskell/NeoHaskell3482026年10月26日 更新

babysit

無料

Inspect or supervise a PR or stack through review and CI to merge-ready, using current GitHub evidence and the requested mode.

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

neohaskell/NeoHaskell3482026年10月26日 更新

Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you benchmark or report a measured speedup or regression, including complete framework flows and compilation of projects that consume the framework.

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

neohaskell/NeoHaskell3482026年10月26日 更新

bro

無料

Restate the last message in plain human language, with no jargon.

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

neohaskell/NeoHaskell3482026年10月26日 更新

Build or adapt a local harness to drive, inspect, and profile an interactive CLI or TUI without external services. Use for CLI UX checks, startup regressions, memory leaks, hangs, prompt flows, or terminal demos.

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

neohaskell/NeoHaskell3482026年10月26日 更新

neohaskell のスキルをすべて見る

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