litclaude-ai 0.3.9 → 0.3.10

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 0.3.10 - 2026-06-20 — build-decision gate and reuse self-review
+
+- Add a pre-write minimum-first build-decision gate and a necessity/reuse self-review to the
+  programming skill.
+
 ## 0.3.9 - 2026-06-19 — hook activation and mode-discipline parity
 
 - Port the LitOpenCode v0.1.17 workflow contract into Claude Code-native surfaces without copying

package/README.md

@@ -9,7 +9,7 @@
 </p>
 <p align="center">
   <img src="https://img.shields.io/badge/npm-litclaude--ai-cb3837" />
-  <img src="https://img.shields.io/badge/version-0.3.9-2ea44f" />
+  <img src="https://img.shields.io/badge/version-0.3.10-2ea44f" />
   <img src="https://img.shields.io/badge/Claude%20Code-plugin-blueviolet" />
   <img src="https://img.shields.io/badge/license-MIT-blue" />
 </p>
@@ -22,10 +22,10 @@
 > `litclaude@litclaude-ai`, so normal `claude` launches can load the
 > LitClaude skills and hooks without a long `--plugin-dir` command.
 
-This checkout is prepared as `litclaude-ai@0.3.9` for personal install
+This checkout is prepared as `litclaude-ai@0.3.10` for personal install
 convenience. The repo can remain quiet; preparing npm package metadata here does
 not imply public repo promotion, marketplace publication, or advertisement.
-Future package releases still require explicit user approval. The v0.3.9
+Future package releases still require explicit user approval. The v0.3.10
 release materials preserve the v0.3.8 skill-depth work and add Claude-native
 hook activation, prompt/mode contract, safe mode-transition, primary-order, and
 installer permission-preference discipline.
@@ -95,7 +95,7 @@ directory, the normal install command works:
 
 ```bash
 cd /tmp
-npx --yes litclaude-ai@0.3.9 install
+npx --yes litclaude-ai@0.3.10 install
 ```
 
 Validate the installed plugin:
@@ -108,7 +108,7 @@ The installer also sets Claude Code's `statusLine` command to the packaged
 LitClaude HUD. A typical no-color render starts like:
 
 ```text
-[🔥LITCLAUDE v0.3.9] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
+[🔥LITCLAUDE v0.3.10] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
 ```
 
 The `↻` suffix is a compact rate-limit reset countdown. It is separated from

package/README_ko-KR.md

@@ -9,7 +9,7 @@
 </p>
 <p align="center">
   <img src="https://img.shields.io/badge/npm-litclaude--ai-cb3837" />
-  <img src="https://img.shields.io/badge/version-0.3.9-2ea44f" />
+  <img src="https://img.shields.io/badge/version-0.3.10-2ea44f" />
   <img src="https://img.shields.io/badge/Claude%20Code-plugin-blueviolet" />
   <img src="https://img.shields.io/badge/license-MIT-blue" />
 </p>
@@ -26,11 +26,11 @@
 > 설치되므로, 매번 긴 `--plugin-dir` 없이 일반 `claude` 실행에서
 > LitClaude skill과 hook을 불러올 수 있습니다.
 
-현재 checkout은 `litclaude-ai@0.3.9` 배포 준비용으로 정리되어 있습니다. 목적은
+현재 checkout은 `litclaude-ai@0.3.10` 배포 준비용으로 정리되어 있습니다. 목적은
 다른 PC에서도 빠르게 설치하기 위한 개인용 package metadata를 갖추는 것입니다.
 npm package metadata를 준비했다고 해서 홍보, 공개 저장소 운영, Claude
 marketplace 등록을 의미하지는 않습니다. 새 버전 배포는 항상 별도의 명시적
-승인 후에 진행합니다. v0.3.9 release material은 v0.3.8 skill-depth 작업을
+승인 후에 진행합니다. v0.3.10 release material은 v0.3.8 skill-depth 작업을
 보존하고, Claude-native hook activation, prompt/mode contract, safe
 mode-transition, primary-order, installer permission preference discipline을
 추가합니다.
@@ -100,7 +100,7 @@ checkout을 먼저 해석해서 `sh: litclaude-ai: command not found`로 실패
 
 ```bash
 cd /tmp
-npx --yes litclaude-ai@0.3.9 install
+npx --yes litclaude-ai@0.3.10 install
 ```
 
 설치 상태를 확인합니다.
@@ -113,7 +113,7 @@ installer는 Claude Code의 `statusLine` command도 packaged LitClaude HUD로
 설정합니다. 색상을 제거한 예시는 다음처럼 시작합니다.
 
 ```text
-[🔥LITCLAUDE v0.3.9] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
+[🔥LITCLAUDE v0.3.10] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
 ```
 
 `↻` 표시는 rate-limit reset까지 남은 시간을 짧게 보여주는 countdown입니다.

package/RELEASE_CHECKLIST.md

@@ -1,13 +1,13 @@
 # LitClaude Release Checklist
 
-Status: `litclaude-ai@0.3.9` is the current release candidate — a Claude-native
+Status: `litclaude-ai@0.3.10` is the current release candidate — a Claude-native
 hook activation and mode-discipline parity pass based on LitOpenCode v0.1.17.
 It routes natural `lit` prompts by mode, blocks natural-language start-work with
 a safe handoff, reinforces planning/execution/review/research/goal contracts,
 documents primary role order, and records installer permission preferences
 without copying OpenCode-only permission objects.
-`package.json` is aligned to `0.3.9`, and
-`plugins/litclaude/.claude-plugin/plugin.json` is aligned to `0.3.9`.
+`package.json` is aligned to `0.3.10`, and
+`plugins/litclaude/.claude-plugin/plugin.json` is aligned to `0.3.10`.
 
 This release carries the v0.2.2 Dynamic workflow hardening surfaces:
 `/dynamic-workflow`, `workflow-check --json`, native `/goal` fallback guidance,
@@ -56,8 +56,8 @@ No npm publication is required for this track.
 Before requesting publication approval, confirm these artifacts from the current
 checkout:
 
-- `package.json` version is `0.3.9`.
-- `plugins/litclaude/.claude-plugin/plugin.json` version is `0.3.9`.
+- `package.json` version is `0.3.10`.
+- `plugins/litclaude/.claude-plugin/plugin.json` version is `0.3.10`.
 - `plugins/litclaude/commands/dynamic-workflow.md` documents subagent delegation.
 - `node bin/litclaude-ai.js workflow-check --json` reports `status: pass`.
 - `node bin/litclaude-ai.js workflow-check --json` reports

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "litclaude-ai",
-  "version": "0.3.9",
+  "version": "0.3.10",
   "description": "Claude Code-native workflow distribution.",
   "type": "module",
   "bin": {

package/plugins/litclaude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "litclaude",
   "description": "Claude Code-native workflow plugin.",
-  "version": "0.3.9",
+  "version": "0.3.10",
   "author": {
     "name": "LitClaude contributors"
   },

package/plugins/litclaude/skills/programming/SKILL.md

@@ -16,7 +16,40 @@ writing a single line of code, then apply the shared philosophy on top.
 
 ---
 
-## PHASE 0 — LANGUAGE GATE (RUN THIS FIRST, EVERY TIME)
+## PHASE -1 — BUILD-DECISION GATE (RUN BEFORE PHASE 0)
+
+Before writing or editing a single line of implementation code, work down these
+checks and stop at the first one that cleanly meets the need:
+
+1. Does this need to exist at all? If the outcome does not require it, do not build it.
+2. Does the standard library already do it well? If so, use it.
+3. Is there a native platform, runtime, or framework feature for it? If so, use it.
+4. Does an already-installed dependency cover it cleanly? If so, reuse it — do not add or hand-roll.
+5. Can the remaining gap be one clear line? If so, write the one line.
+6. Only after all of the above fail: write the minimum code that genuinely works — nothing speculative.
+
+Scope and floor (these keep the gate from under-building):
+
+- Judge "minimum that works" over the WHOLE task, not per call site. If the same
+  logic appears at more than one call site, the minimum that works IS one small
+  shared helper — extract it.
+- "Works" includes error handling for any failure the code can realistically hit
+  (network, parse, missing file, bad state) and the tests that prove the behavior
+  you just wrote. Only handling for states that genuinely cannot occur is the
+  speculative part to cut.
+- Reach for a stdlib / native / dependency option only when it fits the need
+  cleanly, not merely because it technically can.
+- Never shorten away, for the sake of fewer lines: input validation at trust
+  boundaries, handling that prevents data loss or corruption, security controls
+  (auth, secret handling, injection/escaping), or accessibility. The point is to
+  remove redundancy and speculation, never to lower the correctness floor.
+
+PHASE -1 decides WHETHER and FROM WHAT to build; PHASE 0 and the per-language iron
+list decide HOW.
+
+---
+
+## PHASE 0 — LANGUAGE GATE (RUN AFTER PHASE -1, EVERY TIME)
 
 **Do not write or edit a single line of code before completing this gate.**
 
@@ -341,6 +374,10 @@ Answer these in your reply before declaring done:
 6. **Helpers for one-off?** Any abstraction with a single caller that will never
    get a second?
 7. **Tests?** Is the new behavior locked by a test that fails if you revert it?
+8. **Necessity & reuse?** Did everything you wrote need to exist, and did you
+   confirm the standard library, a native feature, or an already-installed
+   dependency did not already cover it before you hand-rolled? Remove anything
+   that fails this.
 
 If any answer fails, fix it before declaring done.