cc-discipline 2.15.1 → 2.16.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-discipline",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
   "bin": {
     "cc-discipline": "bin/cli.js"

package/templates/.claude/hooks/git-guard.sh

@@ -643,7 +643,12 @@ AWK
 if [ ${#INPUT} -gt 65536 ]; then
     VERDICT=TOOLONG
 else
-    VERDICT=$(awk "$PROG" <<<"$INPUT" 2>/dev/null)
+    # awk runs with LC_ALL=C: byte semantics everywhere, which is how this code is
+    # written. Under a UTF-8 locale, macOS's awk is still byte-based for substr()
+    # and length(), but a regex match against half a multi-byte character is
+    # fatal ("towc: multibyte conversion failure"). 2.15.1 died that way on
+    # "## 2026-08-04（三）" and fell back to the file's tail (2026-09-25).
+    VERDICT=$(LC_ALL=C awk "$PROG" <<<"$INPUT" 2>/dev/null)
 fi
 TAB=$'\t'
 NOTE=""    # never inherited from the environment

package/templates/.claude/hooks/session-start.sh

@@ -43,6 +43,11 @@ fi
 #     condition" is only said when every item actually has one.
 # Comment state is tracked on every line, before any heading test, so a heading
 # written inside <!-- ... --> neither opens nor closes a section.
+# awk runs with LC_ALL=C: byte semantics everywhere, which is how this code is
+# written. Under a UTF-8 locale, macOS's awk is still byte-based for substr()
+# and length(), but a regex match against half a multi-byte character is
+# fatal ("towc: multibyte conversion failure"). 2.15.1 died that way on
+# "## 2026-08-04（三）" and fell back to the file's tail (2026-09-25).
 # Every fork costs tens of milliseconds on Windows Git Bash, so awk strips the
 # CRs itself and its output is parsed with bash builtins: this runs at the
 # start of every session.
@@ -83,7 +88,7 @@ function skip() {
 STATUS=""; STATUS_NOTE=""
 if [ -f "docs/progress.md" ]; then
     # One pass. Emits "@key=value" lines, then the capped body as "|line".
-    PROGRESS=$(awk "$AWK_LIB"'
+    PROGRESS=$(LC_ALL=C awk "$AWK_LIB"'
         BEGIN { lines = 15 }
         { sub(/\r$/, "") }
         /<!--[ \t]*cc-discipline:[ \t]*status-lines=/ {
@@ -152,7 +157,7 @@ if [ -f "docs/todo.md" ]; then
     # One pass: the Now body (capped at 20), and Later's top-level items. An open
     # item is a top-level bullet that isn't ticked ("- [ ] x" or "- x", not
     # "- [x] x"); indented lines belong to the item above them.
-    TODO=$(awk "$AWK_LIB"'
+    TODO=$(LC_ALL=C awk "$AWK_LIB"'
         function close_item() { if (item && !cond) nocond++; item = 0 }
         { sub(/\r$/, "") }
         { k = skip() }

package/templates/.claude/skills/ask-me/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: ask-me
+description: Put a decision to the user so they can answer in one step — a few lines of background, then a single- or multi-select question with the recommended option first.
+when_to_use: When the user types /ask-me or says "带着背景和选项问我" / "带着选项问我" / "ask me with options". On your own, only when you are blocked on something that is the user's call (scope, approach, a trade-off, anything irreversible or outward-facing) or on intent or environment that no file or command can tell you. Not for what the code, the docs or a conventional default settles.
+---
+
+Ask the user a question they can answer in one step.
+
+This replaces two failures. One is a wall of text with the real question buried at the end. The other is a bare open question the user cannot answer, because the context needed to answer it is in your head, not theirs.
+
+## 1. Decide what actually needs asking
+
+- **Topic.** If the user gave arguments, that is the topic. Otherwise it is whatever decision is pending in the conversation: the thing you would otherwise ask in prose, or quietly guess.
+- **Settle what you can first.** Read the file, run the command, check `docs/progress.md` and `docs/todo.md`. Ask only what is left, which should be the user's preferences and direction, or facts only they know. A question whose answer is in the repo wastes the user's turn.
+- **Nothing pending?** If nothing is actually open, say so in one line and stop. Do not invent a question so that the skill has something to do.
+
+## 2. Background first, in plain text, briefly
+
+Write three to six lines before the question, covering only what the user needs in order to choose:
+
+- what is already settled;
+- where things are stuck, and why it is the user's call: a trade-off, a preference, a risk;
+- anything you checked that changes the options, with `file:line` when it helps.
+
+Save the analysis of each option for that option's description. If the background runs past about six lines, you are explaining too much or asking too early.
+
+## 3. Ask with AskUserQuestion
+
+- **Questions.** Ask one to four per call, and only ones whose answer changes what you do next. Put related questions in the same call rather than drip-feeding them. Write them in the user's language.
+- **Options.**
+  - Give two to four per question, and make them genuinely different.
+  - Do not add an "Other" option; the tool provides one.
+  - Put your recommendation first and mark it in the user's language, "（推荐）" or "(Recommended)". Its description says why in one sentence.
+  - If you have no basis for recommending one, say that in the background rather than marking one at random.
+- **Descriptions.** Each option's description says what happens if it is chosen and what that costs. Do not restate the label.
+- **Header.** At most 12 characters.
+- **multiSelect.** Use it only when the choices combine, for example which items to include. An empty multi-select answer is ambiguous: ask again rather than assume.
+- **preview.** Use it when the user needs to compare concrete artifacts: code, configuration, layouts. It works for single-select questions only.
+
+## 4. After the answer
+
+- **Act on what was answered, and only that.** An answer to "which approach" chooses the approach. It is not approval for irreversible or outward-facing steps, such as publishing, pushing or deleting; those still get their own confirmation.
+- **"Other" with free text.** Treat it as the user's own words. If it changes the premise, re-plan instead of squeezing it into one of your options.
+- **Question rejected or interrupted.** Stop and wait: the user is about to tell you something. Do not re-ask the same questions. When they reply, work out which of your assumptions their correction overturns.
+
+## When the tool is unavailable
+
+Some contexts block the question tool: `/self-check` lists it under `disallowed-tools`, and non-interactive runs have no UI. Fall back to text:
+
+1. Give the same background.
+2. Number the questions and letter the options, recommendation first and marked, so the user can reply "1A 2B".
+
+Keep it as short as the tool version would be.

package/templates/.claude/skills/think/SKILL.md

@@ -28,15 +28,14 @@ State your assessment: "This looks [small/medium/large] because [reason]."
 
 ## Step 2: Understand
 
-Ask 2-3 clarifying questions about the task. Focus on:
+Ask only what Step 0 could not settle. After the research, what is left should be preference and direction, not facts you could have read. A question asked before looking is one the user should never have had to answer. Focus on:
 - What exactly should change? (scope)
 - What should NOT change? (boundaries)
 - How will we know it's done? (success criteria)
 
 Rules:
-- One message, all questions at once (don't drip-feed)
-- Prefer multiple-choice over open-ended when possible
-- Reference what you learned in Step 0 — ask about gaps in your understanding, not things you can read yourself
+- Ask them the `/ask-me` way: a few lines of background from Step 0, then the question tool, with your recommendation first
+- As many questions as the task needs, up to four per call, all at once rather than drip-fed
 - If the task is already crystal clear from Step 0, say so and skip to Step 3
 
 ## Step 3: Propose
@@ -91,6 +90,8 @@ If self-review reveals issues, revise your proposals before presenting. Don't sh
 
 **Stop here. Do not proceed until the user picks an approach or gives a green light.**
 
+Ask for the pick the `/ask-me` way: one question, the approaches from Step 3 as its options, your recommendation first. The write-up from Step 3 is the background. If `/coplan` is stacked, it writes the plan and offers the review first, and the pick comes after.
+
 Do not:
 - Start coding "while waiting"
 - Create files or scaffolding — **except** writing the plan itself to disk, which is not implementation. `/coplan` does exactly that and is designed to stack here.