Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Apply this principle when developing NeoHaskell's language, framework, and toolchain internals.
Structural decisions protect option value. Code-level decisions protect simplicity.
Data structures first. Get the data shape right before writing logic. Define core types early, trace every access pattern, and choose structures that match the dominant paths. For framework APIs, define the semantic contract alongside the types, including evaluation and representation behavior when relevant. Typechecking alone does not establish that contract.
At code level, DRY the structure, not every line. Types and data models should converge. Three similar statements still beat a premature abstraction. Prefer explicit over clever. Test behavior and edge cases, not line counts.
Concurrency corollary. Before sharing mutable state, identify the invariant concurrent operations must preserve. Choose the existing NeoHaskell concurrency module whose ownership, blocking, atomicity, communication, and lifetime guarantees fit the operation. Read the relevant implementations in core/concurrency/ before choosing their APIs. Isolate ownership or provide synchronization that preserves the invariant. A read followed by a dependent write may need one atomic operation even when each individual access is safe.
Scaffold first. If something helps every later phase, do it first. Ask "does every subsequent phase benefit from this existing?" CI, linting, test infrastructure, and shared types are scaffold. Sequence for option value: setup before features, tests before fixes. Keep commits small and single-purpose.
Each increment should land a coherent abstraction or deepen one that exists. Updating a core type or API can legitimately require coordinated changes to pure consumers, class instances, and code generators. Use compiler feedback to guide those changes, then check the semantic contract. Do not make callers duplicate a framework rule or depend on an undocumented effect order. Put that rule or ordering in the abstraction that owns it.
Consider subtraction before scaffolding. Remove proven dead code, accounting for exported and generated uses before declaring framework code dead.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
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.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
Inspect or supervise a PR or stack through review and CI to merge-ready, using current GitHub evidence and the requested mode.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
Restate the last message in plain human language, with no jargon.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。