devlyn-cli 3.3.1 → 4.0.0

package/config/skills/_shared/resolve-bootstrap.py

@@ -1,5 +1,5 @@
 #!/usr/bin/env python3
-"""Deterministic PHASE-0 bootstrap for /devlyn:resolve."""
+"""Deterministic PHASE-0 bootstrap for /devlyn-resolve."""
 from __future__ import annotations
 
 import contextlib
@@ -1027,7 +1027,7 @@ def self_test() -> int:
             "phases": {name: None for name in PHASE_NAMES},
             "verify": {"coverage_failed": False, "pair_trigger": None},
         }
-        schema_dirs = [script_shared.parent / name for name in ("devlyn:resolve", "devlyn\uF03Aresolve")
+        schema_dirs = [script_shared.parent / name for name in ("devlyn-resolve",)
                        if (script_shared.parent / name).is_dir()]
         assert len(schema_dirs) == 1, schema_dirs
         schema = (schema_dirs[0] / "references" / "state-schema.md").read_text(encoding="utf-8")

package/config/skills/_shared/runtime-principles.md

@@ -1,6 +1,6 @@
 # Runtime principles — sub-agent contract
 
-The runtime contract every sub-agent inside `/devlyn:resolve` (PLAN / IMPLEMENT / BUILD_GATE / CLEANUP / VERIFY) and `/devlyn:ideate` must satisfy. Source of truth for sub-agent behavior on user tasks. NOT for autoresearch-loop / harness-developer concerns (see `autoresearch/PRINCIPLES.md`).
+The runtime contract every sub-agent inside `/devlyn-resolve` (PLAN / IMPLEMENT / BUILD_GATE / CLEANUP / VERIFY) and `/devlyn-ideate` must satisfy. Source of truth for sub-agent behavior on user tasks. NOT for autoresearch-loop / harness-developer concerns (see `autoresearch/PRINCIPLES.md`).
 
 The three sections below mirror the corresponding CLAUDE.md sections (Subtractive-first editing, Goal-locked execution, Evidence over claim). No-workaround discipline lives in CLAUDE.md Core Principle #1 only — it does not have a runtime-mirror block. Each mirrored section is wrapped in `<!-- runtime-principles:section=NAME:begin -->` / `:end -->` markers in BOTH this file and CLAUDE.md; lint Check 12 extracts each named block from both files and diffs to detect drift.
 
@@ -58,7 +58,7 @@ This rule exists because LLMs (including you) are trained to be helpful, compreh
 
 **The single drift test before any deviation from the stated goal:** *"Did the user ask for this, OR does the user's stated goal strictly require it?"* If the answer to both is no, do not do it. Surface it as a note (commit message, end-of-turn summary, finding) and continue on the original path.
 
-**Creative-mode is the narrow exception, not the default.** Creative-mode applies only when (a) the user explicitly invoked an ideation/exploration surface (`/devlyn:ideate`, `/devlyn:design-ui`, "let's brainstorm", "explore options for"), OR (b) the goal is genuinely under-specified and a clarifying question is impossible (extremely rare — usually you should ask). For everything else — bug fixes, feature work, refactors, doc updates, pipeline runs, code review, debugging — execution-mode is the default and drift is a defect, not a feature.
+**Creative-mode is the narrow exception, not the default.** Creative-mode applies only when (a) the user explicitly invoked an ideation/exploration surface (`/devlyn-ideate`, `/devlyn-design-ui`, "let's brainstorm", "explore options for"), OR (b) the goal is genuinely under-specified and a clarifying question is impossible (extremely rare — usually you should ask). For everything else — bug fixes, feature work, refactors, doc updates, pipeline runs, code review, debugging — execution-mode is the default and drift is a defect, not a feature.
 
 **Anti-rationalization clause** — explicitly guarding against LLM hedging:
 
@@ -67,7 +67,7 @@ This rule exists because LLMs (including you) are trained to be helpful, compreh
 - "It would be incomplete without this" is **not** a justification. The user defines completeness, not your sense of it.
 - "I'm being thorough" is **not** a justification. Thoroughness on the requested goal is required; thoroughness extending past the goal is drift.
 
-**When in doubt, ask — outside hands-free pipelines.** In interactive sessions a short clarification ("the requested fix touches the X code path; I notice Y also looks broken — should I fix it in this change or surface it as a follow-up?") is always cheaper than a wrong-scope diff. Asking is not a weakness; silently expanding scope is. **Inside hands-free pipelines** (`/devlyn:resolve`, scheduled remote agents, autonomous skill runs) the contract forbids mid-pipeline prompts — there asking is unsafe because there is no user to answer. The substitute is: stay strictly on the requested goal, do not expand scope, and log the question/assumption explicitly in the final report (or `.devlyn/runs/<run_id>/` artifacts) so the user can adjudicate after the run completes. Choosing scope creep over logging-and-staying-on-path is always wrong.
+**When in doubt, ask — outside hands-free pipelines.** In interactive sessions a short clarification ("the requested fix touches the X code path; I notice Y also looks broken — should I fix it in this change or surface it as a follow-up?") is always cheaper than a wrong-scope diff. Asking is not a weakness; silently expanding scope is. **Inside hands-free pipelines** (`/devlyn-resolve`, scheduled remote agents, autonomous skill runs) the contract forbids mid-pipeline prompts — there asking is unsafe because there is no user to answer. The substitute is: stay strictly on the requested goal, do not expand scope, and log the question/assumption explicitly in the final report (or `.devlyn/runs/<run_id>/` artifacts) so the user can adjudicate after the run completes. Choosing scope creep over logging-and-staying-on-path is always wrong.
 
 **Stopping rule.** A task is done when the user's stated goal is closed AND no off-path work was added. If you find yourself hesitating because "I should also do Z" — Z is drift. Note it for follow-up, do not execute.
 <!-- runtime-principles:section=goal-locked:end -->
@@ -82,7 +82,7 @@ Every finding cites concrete evidence. Vague claims are speculation; exclude the
 - **Doc findings**: quote of the stale text + section/line reference.
 - **Browser findings**: screenshot reference + URL/route.
 
-**Negative existence claims** ("X lacks Y", "X cannot Z", "X is Y-specific") are the highest-risk shape — they feel like recall but fail to any single counter-example. They require active search at write time, not absence-of-memory. This rule applies to conversational answers and comparison-table cells, not only `/devlyn:resolve` findings — every cell of a trade-off table is a falsifiable claim.
+**Negative existence claims** ("X lacks Y", "X cannot Z", "X is Y-specific") are the highest-risk shape — they feel like recall but fail to any single counter-example. They require active search at write time, not absence-of-memory. This rule applies to conversational answers and comparison-table cells, not only `/devlyn-resolve` findings — every cell of a trade-off table is a falsifiable claim.
 
 **A position reversal is itself a claim.** In an oracle-less debate — design, strategy, trade-off, any decision with no spec or verifier to check against — changing your mind after a critique requires a NAMED DELTA: cite the specific prior claim, evidence, or criterion that changed, not a post-hoc rationale invented to justify a flip you were already going to make. Before reversing or choosing between contested positions, state each side's strongest form and the decisive criterion; the chosen outcome may adopt one side wholesale — synthesis means the best decision, not a forced blend. Flipping to whoever spoke last without a cited delta is capitulation, not reasoning; genuinely unresolved disagreement is escalated to the user, never closed by deferring to the last speaker. When you commission an adversarial review, require the critic to return the strongest counter, the strongest form of your own position, AND a synthesis — a refute-only mandate produces debate, not better decisions.
 
@@ -94,8 +94,8 @@ A finding without one of these forms is excluded. Vague findings produce vague f
 ## Consumption
 
 **Consumers**:
-- `devlyn:resolve/SKILL.md` `<harness_principles>` points here as the contract source. Phase prompt bodies inline the operational excerpt needed for each phase.
-- `devlyn:ideate/SKILL.md` consumes this file for spec-shaping and conversation discipline through its own `<harness_principles>` block.
+- `devlyn-resolve/SKILL.md` `<harness_principles>` points here as the contract source. Phase prompt bodies inline the operational excerpt needed for each phase.
+- `devlyn-ideate/SKILL.md` consumes this file for spec-shaping and conversation discipline through its own `<harness_principles>` block.
 
 **Codex routing**: Codex-routed phases must inline the contract excerpt directly into the prompt body. Bounded read-only Codex critique, probe, or judge calls must also follow `_shared/codex-config.md` isolation rules.
 <!-- runtime-principles:consumption:end -->

package/config/skills/_shared/spec-verify-check.py

@@ -48,7 +48,7 @@ Check mode (`--check <markdown_path>`):
   its own inline validation and must not use this sibling-precedence route.
 
 Expected-contract check mode (`--check-expected <json_path>`):
-- Used by /devlyn:ideate after writing sibling `spec.expected.json`.
+- Used by /devlyn-ideate after writing sibling `spec.expected.json`.
 - Exits 0 if the file is valid JSON and matches `_shared/expected.schema.json`
   shape, and if sibling `spec.md` has supported `complexity` frontmatter.
   Exits 2 on unreadable, malformed, unsupported fields, or unsupported sibling
@@ -605,7 +605,7 @@ def validate_expected_shape(data) -> str | None:
     """Return None if shape matches the sibling spec.expected.json schema.
 
     Keep this dependency-free: it mirrors `_shared/expected.schema.json` enough
-    to catch malformed ideate output before /devlyn:resolve consumes it.
+    to catch malformed ideate output before /devlyn-resolve consumes it.
     """
     if not isinstance(data, dict):
         return "top-level must be a JSON object"
@@ -4667,7 +4667,7 @@ def main() -> int:
             external_diff,
             fix_hint=(
                 "Remove `.devlyn/external-diff.patch` for ordinary runs, or use "
-                "`/devlyn:resolve --verify-only <diff-or-PR-ref> --spec <path>` only when "
+                "`/devlyn-resolve --verify-only <diff-or-PR-ref> --spec <path>` only when "
                 "intentionally verifying an external patch."
             ),
         )

package/config/skills/_shared/task-complete.py

@@ -2,7 +2,7 @@
 """Outer-owner delivery and recoverable cleanup (task-completion spec, R1–7).
 
 No phase/state writer, staging, scheduler, or implicit adoption. See
-devlyn:resolve/references/task-completion.md for the owner acceptance contract.
+devlyn-resolve/references/task-completion.md for the owner acceptance contract.
 """
 from __future__ import annotations
 

package/config/skills/{devlyn:design-ui → devlyn-design-ui}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devlyn:design-ui
+name: devlyn-design-ui
 description: Assemble a world-class design team (Creative Director, Product Designer, Visual Designer, Interaction Designer, Accessibility Designer) to generate N (default 5) radically distinct, portfolio-worthy UI style explorations. Pass a leading integer or `count:N` in the brief to change the count.
 source: project
 ---

package/config/skills/{devlyn:engines → devlyn-engines}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: devlyn:engines
+name: devlyn-engines
 description: Show and pin engine roles for the devlyn pipeline (executor / pair judge). Reads and writes machine-local .devlyn/engines.json with fail-closed validation. Use when the user asks which models are configured, wants to force a specific model for pipeline work ("수동모드", "engine 고정", "use codex to implement"), or wants to clear pins back to auto-detection.
 ---
 
-Utility front-end for the role-resolution contract in `_shared/engine-preflight.md#role-resolution`. It adds no semantics of its own: everything it writes is exactly what `/devlyn:resolve` PHASE 0 reads.
+Utility front-end for the role-resolution contract in `_shared/engine-preflight.md#role-resolution`. It adds no semantics of its own: everything it writes is exactly what `/devlyn-resolve` PHASE 0 reads.
 
 <args>
 $ARGUMENTS

package/config/skills/{devlyn:ideate → devlyn-ideate}/SKILL.md

@@ -1,16 +1,16 @@
 ---
-name: devlyn:ideate
-description: Extract a verifiable spec from a user's idea by driving the conversation with focused questions. Output is a single-feature `spec.md` + `spec.expected.json` that `/devlyn:resolve --spec` consumes directly. Use when the user has an idea but not a spec, or wants AI to elicit the missing engineering context. Modes — default (single spec, AI drives Q&A), `--quick` (assume-and-confirm from one-line goal), `--from-spec <path>` (normalize external spec), `--project` (plan.md index + N specs). Optional in the pipeline — `/devlyn:resolve` works standalone via free-form mode for users who skip ideate.
+name: devlyn-ideate
+description: Extract a verifiable spec from a user's idea by driving the conversation with focused questions. Output is a single-feature `spec.md` + `spec.expected.json` that `/devlyn-resolve --spec` consumes directly. Use when the user has an idea but not a spec, or wants AI to elicit the missing engineering context. Modes — default (single spec, AI drives Q&A), `--quick` (assume-and-confirm from one-line goal), `--from-spec <path>` (normalize external spec), `--project` (plan.md index + N specs). Optional in the pipeline — `/devlyn-resolve` works standalone via free-form mode for users who skip ideate.
 ---
 
-Spec-elicitation surface for users who have ideas but not engineering specifications. AI drives the conversation with focused questions until a structurally-valid, verifiable spec exists. Output consumed directly by `/devlyn:resolve --spec`.
+Spec-elicitation surface for users who have ideas but not engineering specifications. AI drives the conversation with focused questions until a structurally-valid, verifiable spec exists. Output consumed directly by `/devlyn-resolve --spec`.
 
 <elicit_config>
 $ARGUMENTS
 </elicit_config>
 
 <orchestrator_context>
-This skill is OPTIONAL. `/devlyn:resolve` is standalone-capable: free-form mode handles trivial/medium tasks without a spec, `--spec` mode accepts handwritten specs from any source. Use ideate when the user wants AI to do the elicitation work.
+This skill is OPTIONAL. `/devlyn-resolve` is standalone-capable: free-form mode handles trivial/medium tasks without a spec, `--spec` mode accepts handwritten specs from any source. Use ideate when the user wants AI to do the elicitation work.
 </orchestrator_context>
 
 <elicitation_contract>
@@ -24,7 +24,7 @@ The user does not know context engineering. They will under-specify and over-ass
 </elicitation_contract>
 
 <harness_principles>
-Read `_shared/runtime-principles.md` (Subtractive-first / Goal-locked / Evidence-over-claim). The principles bind the spec content as well as your conversation. A spec that says "for future flexibility" is a Subtractive-first violation. A spec that asks for `try { ... } catch { return null }` is a No-workaround violation. AI flags these in elicitation, not after `/devlyn:resolve` has built them.
+Read `_shared/runtime-principles.md` (Subtractive-first / Goal-locked / Evidence-over-claim). The principles bind the spec content as well as your conversation. A spec that says "for future flexibility" is a Subtractive-first violation. A spec that asks for `try { ... } catch { return null }` is a No-workaround violation. AI flags these in elicitation, not after `/devlyn-resolve` has built them.
 </harness_principles>
 
 <runtime_paths>
@@ -64,8 +64,8 @@ Four modes, selected by flag:
 <spec_kind_escape_hatch>
 The spec carries `spec.kind ∈ {feature, spike, prototype}` in its frontmatter. The kind changes downstream behavior:
 
-- **feature** — production-quality implementation expected. `/devlyn:resolve --spec` runs the full pipeline (PLAN → IMPLEMENT → BUILD_GATE → CLEANUP → VERIFY).
-- **spike** — exploratory work; deliverable is learning, evidence, or a disposable demo. `/devlyn:resolve --spec` proceeds but VERIFY's quality bar is relaxed for code that the spike says is throwaway.
+- **feature** — production-quality implementation expected. `/devlyn-resolve --spec` runs the full pipeline (PLAN → IMPLEMENT → BUILD_GATE → CLEANUP → VERIFY).
+- **spike** — exploratory work; deliverable is learning, evidence, or a disposable demo. `/devlyn-resolve --spec` proceeds but VERIFY's quality bar is relaxed for code that the spike says is throwaway.
 - **prototype** — between feature and spike. Production-shape but not production-grade. CLEANUP runs; VERIFY's quality bar is stricter than spike, looser than feature.
 
 The user picks the kind during elicitation. Default = feature when not specified. `--quick` infers from the goal text (verbs like "explore", "investigate", "spike" → spike; "implement", "ship", "add" → feature).
@@ -112,7 +112,7 @@ After lint passes:
 2. Generate `<spec-dir>/<id>-<slug>/spec.expected.json` following `references/spec-template.md` § "Sibling file: `spec.expected.json`" for constraint coverage, diff scope and guard controls.
 3. Run `python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check <spec-path>` to validate the actual spec's carrier shape and supported `complexity` frontmatter. Sibling `spec.expected.json` takes precedence over the legacy inline `## Verification` JSON carrier. If exit 2, fix the file named in the error and re-run.
 4. Run `python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check-expected <expected-path>` to validate sibling `spec.expected.json` against `_shared/expected.schema.json` plus sibling spec `complexity` frontmatter. If exit 2, fix the JSON/frontmatter and re-run.
-5. Print: `spec ready — /devlyn:resolve --spec <spec-path>`.
+5. Print: `spec ready — /devlyn-resolve --spec <spec-path>`.
 
 ## PHASE 1Q: QUICK MODE
 
@@ -145,9 +145,9 @@ Prompt body: `references/project-mode.md`.
 2. AI decomposes the project into 3-7 feature specs. Each feature is independently shippable; cross-feature dependencies surface explicitly in the spec frontmatter `depends_on:` field.
 3. AI writes `<spec-dir>/plan.md` — index file with: project name, decomposition rationale, list of feature specs with id + title + dependency, suggested implementation order.
 4. AI writes one `<spec-dir>/<id>/spec.md` + `<spec-dir>/<id>/spec.expected.json` per feature, each lint-validated.
-5. Announce: `project ready — N specs at <spec-dir>/. Start with /devlyn:resolve --spec <first-spec-path>`.
+5. Announce: `project ready — N specs at <spec-dir>/. Start with /devlyn-resolve --spec <first-spec-path>`.
 
-`/devlyn:resolve` consumes one spec at a time; the user works through `plan.md`'s suggested order. Multi-feature parallel runs are Mission 2 work.
+`/devlyn-resolve` consumes one spec at a time; the user works through `plan.md`'s suggested order. Multi-feature parallel runs are Mission 2 work.
 
 ## State management
 

package/config/skills/{devlyn:ideate → devlyn-ideate}/references/elicitation.md

@@ -84,7 +84,7 @@ Two files in `<spec-dir>/<id>-<slug>/`:
 - `spec.md` (per template).
 - `spec.expected.json` (per `_shared/expected.schema.json`).
 
-Final announcement (one line): `spec ready — /devlyn:resolve --spec <spec-path>`.
+Final announcement (one line): `spec ready — /devlyn-resolve --spec <spec-path>`.
 
 Do NOT include the conversation transcript in the output. The spec stands alone.
 </output>
@@ -105,6 +105,6 @@ Quick mode trades thoroughness for speed. Use it for trivial-medium tasks where
 
 - Walls of questions in one turn.
 - Open-ended "what would you like" questions when the user clearly does not know.
-- Adding "for future flexibility" or "just in case" sections to the spec — the user did not ask for those, and the principles binding `/devlyn:resolve` reject them.
+- Adding "for future flexibility" or "just in case" sections to the spec — the user did not ask for those, and the principles binding `/devlyn-resolve` reject them.
 - Saving the conversation transcript alongside the spec.
 - Stalling when the user gives a vague answer — re-ask with a more specific shape ("should it be A, B, or other?") rather than re-asking the same question.

package/config/skills/{devlyn:ideate → devlyn-ideate}/references/from-spec-mode.md

@@ -43,7 +43,7 @@ You must NOT:
 9. If the preserved Requirements combine state mutation with ordering/priority,
    idempotency, auth/error priority, or exact output shape but the Verification
    section lacks a compound end-to-end scenario, do not rewrite the author's
-   content. Add a final warning that `/devlyn:resolve` may need default-mode
+   content. Add a final warning that `/devlyn-resolve` may need default-mode
    ideation or a stronger Verification section before pair-relevant risks are
    measurable.
 </flow>
@@ -51,7 +51,7 @@ You must NOT:
 <output>
 Same as default mode: `<spec-dir>/<id>-<slug>/spec.md` + `<spec-dir>/<id>-<slug>/spec.expected.json`.
 
-Final announcement: `spec normalized — /devlyn:resolve --spec <spec-path>`. If the spec was lint-passing with no changes needed, announce: `spec already canonical — /devlyn:resolve --spec <spec-path>`. If step 9 applies, append: `warning: Verification may need one compound end-to-end scenario before pair-relevant risks are measurable`.
+Final announcement: `spec normalized — /devlyn-resolve --spec <spec-path>`. If the spec was lint-passing with no changes needed, announce: `spec already canonical — /devlyn-resolve --spec <spec-path>`. If step 9 applies, append: `warning: Verification may need one compound end-to-end scenario before pair-relevant risks are measurable`.
 
 If lint failed unfixably: print the specific failure, exit non-zero. Do not write a partial output.
 </output>

package/config/skills/{devlyn:ideate → devlyn-ideate}/references/project-mode.md

@@ -21,7 +21,7 @@ The user wants to build a project, not a single feature. Your job is to elicit t
 - Features should be vertically sliced (full stack of one user-facing capability), not horizontally sliced (a layer that other features will need to consume).
 - A feature whose ONLY value is enabling other features (pure infrastructure) belongs in the first feature that needs it OR as an explicit "enabling spec" with the dependent feature waiting on it.
 - Feature dependencies are explicit in `frontmatter.depends_on`. The plan's suggested implementation order respects topological dependency.
-- Aim for features that take 1-3 hours of `/devlyn:resolve --spec` work each. Larger → split. Trivial → merge with neighbor.
+- Aim for features that take 1-3 hours of `/devlyn-resolve --spec` work each. Larger → split. Trivial → merge with neighbor.
 </decomposition_rules>
 
 <plan_md_shape>
@@ -48,8 +48,8 @@ Output `<spec-dir>/plan.md`:
 
 ## Suggested implementation order
 
-1. `/devlyn:resolve --spec <spec-dir>/<id-1>/spec.md`
-2. `/devlyn:resolve --spec <spec-dir>/<id-2>/spec.md`
+1. `/devlyn-resolve --spec <spec-dir>/<id-1>/spec.md`
+2. `/devlyn-resolve --spec <spec-dir>/<id-2>/spec.md`
 3. ...
 
 The order respects `depends_on`. Topologically equivalent specs can be parallelized later (Mission 2 work); single-task L1 ships them sequentially.
@@ -59,7 +59,7 @@ The order respects `depends_on`. Topologically equivalent specs can be paralleli
 Anything binding all features (e.g. "no new top-level dependencies", "all CLI output must support `NO_COLOR`"). Each feature spec inherits these in its Constraints section.
 ```
 
-`plan.md` is the **index**, not a hidden dependency. `/devlyn:resolve` reads only the spec it is invoked with; it does not parse `plan.md`.
+`plan.md` is the **index**, not a hidden dependency. `/devlyn-resolve` reads only the spec it is invoked with; it does not parse `plan.md`.
 </plan_md_shape>
 
 <output>
@@ -69,7 +69,7 @@ Anything binding all features (e.g. "no new top-level dependencies", "all CLI ou
 
 Each per-feature spec is structurally lint-validated using `python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check <spec-path>`, including supported `complexity` frontmatter, and each sibling expected contract plus sibling spec `complexity` frontmatter is validated using `python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check-expected <expected-path>`.
 
-Final announcement: `project ready — N specs at <spec-dir>/. Start with /devlyn:resolve --spec <first-spec-path>`.
+Final announcement: `project ready — N specs at <spec-dir>/. Start with /devlyn-resolve --spec <first-spec-path>`.
 </output>
 
 <anti_patterns>

package/config/skills/{devlyn:ideate → devlyn-ideate}/references/spec-template.md

@@ -1,6 +1,6 @@
 # Canonical spec template
 
-The shape `/devlyn:ideate` writes and `/devlyn:resolve --spec` consumes. Single source of truth for spec structure.
+The shape `/devlyn-ideate` writes and `/devlyn-resolve --spec` consumes. Single source of truth for spec structure.
 
 ## Frontmatter
 

package/config/skills/{devlyn:queue → devlyn-queue}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: devlyn:queue
-description: Manage and drain the intent queue (docs/specs/queue.md) — the backlog the loop-engineering contract runs on. Use when the user wants to stack work for later ("큐에 넣어줘", "queue this"), see what is queued, or start an unattended serial drain ("큐 드레인 시작", "밤새 돌려줘", "drain the queue") that takes each item through spec → /devlyn:resolve → verified done.
+name: devlyn-queue
+description: Manage and drain the intent queue (docs/specs/queue.md) — the backlog the loop-engineering contract runs on. Use when the user wants to stack work for later ("큐에 넣어줘", "queue this"), see what is queued, or start an unattended serial drain ("큐 드레인 시작", "밤새 돌려줘", "drain the queue") that takes each item through spec → /devlyn-resolve → verified done.
 ---
 
 Utility front-end for the intent-queue contract in the project instructions ("Intent queue" in CLAUDE.md / AGENTS.md — whichever this CLI loads). It adds no semantics of its own: the queue file is the API, and the drain loop follows the documented contract exactly — a runner (this skill, a long session, or a future devlyn-os daemon) is a replaceable driver over the same file.
@@ -21,7 +21,7 @@ DEVLYN_SHARED_DIR="$(cd "$DEVLYN_SKILL_DIR/../_shared" && pwd)"
 ```
 
 Before processing the first item, read and obey
-`../devlyn:resolve/references/outer-loop.md`. Its scoped-commit order is binding.
+`../devlyn-resolve/references/outer-loop.md`. Its scoped-commit order is binding.
 
 Queue state is base's `docs/specs/queue.md` plus owned receipts: for each `$(git rev-parse --git-common-dir)/devlyn-completion/*/receipt.json`, read `git show <ref>:docs/specs/queue.md` from its `recovery_ref` if that ref exists (it is never deleted), else its `branch` if it still exists; an item unmarked on base but `[x]`/`[F]` there counts as that mark. Two different terminal marks for one item stop for inspection. Status and drain selection both use this view.
 
@@ -33,11 +33,11 @@ Read the queue state above (absent `docs/specs/queue.md` → report "queue empty
 
 - `add <intent text>` — append `- [ ] <intent>` to `docs/specs/queue.md` (create the file with its header if missing). If the intent came out of a conversation that already produced a spec, link it: `- [ ] (spec: docs/specs/<id>/spec.md) <intent>`.
 - `drain` — serial drain per the project-instructions contract. For each pending item, in order:
-  1. Allocate the owner's absent task branch with `--worktree <absent path>` per `../devlyn:resolve/references/task-completion.md`, and work in that worktree; then spec it if unspecced (the queue entry is the user's go-ahead). Unattended assumptions may only take scope-narrowing, reversible, non-user-visible defaults; material ambiguity (user-visible behavior, data/state semantics, new files/scripts/flags, implementation surface) → mark `[F] needs-review: <question>`, commit that queue transition, and continue.
-  2. Bring only the current queue-item delta and linked spec bundle from the queue view into the task worktree, which starts from the fetched remote base with no other local commits, commit that scoped owner baseline, then run `/devlyn:resolve --spec <path>` hands-free.
+  1. Allocate the owner's absent task branch with `--worktree <absent path>` per `../devlyn-resolve/references/task-completion.md`, and work in that worktree; then spec it if unspecced (the queue entry is the user's go-ahead). Unattended assumptions may only take scope-narrowing, reversible, non-user-visible defaults; material ambiguity (user-visible behavior, data/state semantics, new files/scripts/flags, implementation surface) → mark `[F] needs-review: <question>`, commit that queue transition, and continue.
+  2. Bring only the current queue-item delta and linked spec bundle from the queue view into the task worktree, which starts from the fetched remote base with no other local commits, commit that scoped owner baseline, then run `/devlyn-resolve --spec <path>` hands-free.
      After every resolve invocation, run `python3 "$DEVLYN_SHARED_DIR/terminal-claim-check.py" .`; exit 79 marks `[F] FAILED-INCOMPLETE` from the predicate, never from the session self-report.
   3. Outer loop on the terminal verdict: PASS → mark `[x]`. Findings-backed verdicts (NEEDS_WORK, BLOCKED:repair-budget-exhausted) → amend the spec, commit that scoped amendment, then re-run — at most 3 outer iterations. Infrastructure / invalid-input / engine-availability / implement-empty BLOCKED verdicts are not spec-amendable → mark `[F] <verdict>` immediately.
   4. Commit each terminal `[x]` / `[F]` queue transition before advancing. For successfully archived normal runs, invoke owner completion once after that declared queue-file-only commit; bind it separately from the verified source. Honor local-only/no-push. Failed products never publish. Retain PR/pending workspaces and use a separate owned branch from base for the next item; unavailable safe placement stops the drain with remaining items pending. A product-blocked item otherwise never halts the queue.
   5. When the queue is drained (or the session must stop), emit the drain report: per-item product verdict and separate delivery status/URL/resume, every logged assumption, and the commit range produced.
 
-Strictly SERIAL — one `/devlyn:resolve` run at a time, never parallel. Never invent queue items, never reorder them, and never delete an item — only mark `[x]` / `[F]`.
+Strictly SERIAL — one `/devlyn-resolve` run at a time, never parallel. Never invent queue items, never reorder them, and never delete an item — only mark `[x]` / `[F]`.

package/config/skills/{devlyn:resolve → devlyn-resolve}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devlyn:resolve
+name: devlyn-resolve
 description: Default to direct work after inspecting scope and verification, including bounded multi-file changes. Use full resolve for explicit resolve/spec-mode requests, queue drains, or concrete interacting requirements or verification too complex for the current context. Domain labels, file count, spec documents and quoted skill paths alone do not trigger it. Investigate or clarify missing intent/access first. Explicit small resolve retains all phases and independent verification. Verify dual-judge is default-when-available.
 ---
 
@@ -62,9 +62,9 @@ Each model-invoked phase routes to an engine and prepends the per-engine adapter
 <modes>
 Three input shapes:
 
-1. **Free-form**: `/devlyn:resolve "fix the login bug"` (inline goal) or `/devlyn:resolve --goal-file <path>` (goal text read from a file — the devlynd `ResolveAdapter` launcher path, injection-safe). PHASE 0 runs the complexity classifier and either proceeds with an internal mini-spec (trivial), drafts focused questions for in-prompt resolution (medium), or synthesizes a best-effort spec with a logged `## Assumptions` block (large; zero-scope-signal goals halt). No mid-pipeline prompts in any branch.
-2. **Spec**: `/devlyn:resolve --spec docs/roadmap/phase-N/X.md`. Supplied specs and expected files are read-only inside resolve. Stage verification commands from sibling `spec.expected.json`; if absent, use the legacy `## Verification` JSON block.
-3. **Verify-only**: `/devlyn:resolve --verify-only <diff-or-PR-ref> --spec <path>`. Skips PHASE 1-4. Runs PHASE 5 (VERIFY) on the supplied diff against the spec.
+1. **Free-form**: `/devlyn-resolve "fix the login bug"` (inline goal) or `/devlyn-resolve --goal-file <path>` (goal text read from a file — the devlynd `ResolveAdapter` launcher path, injection-safe). PHASE 0 runs the complexity classifier and either proceeds with an internal mini-spec (trivial), drafts focused questions for in-prompt resolution (medium), or synthesizes a best-effort spec with a logged `## Assumptions` block (large; zero-scope-signal goals halt). No mid-pipeline prompts in any branch.
+2. **Spec**: `/devlyn-resolve --spec docs/roadmap/phase-N/X.md`. Supplied specs and expected files are read-only inside resolve. Stage verification commands from sibling `spec.expected.json`; if absent, use the legacy `## Verification` JSON block.
+3. **Verify-only**: `/devlyn-resolve --verify-only <diff-or-PR-ref> --spec <path>`. Skips PHASE 1-4. Runs PHASE 5 (VERIFY) on the supplied diff against the spec.
 </modes>
 
 <post_implement_invariant>

package/config/skills/{devlyn:resolve → devlyn-resolve}/references/free-form-mode.md

@@ -1,6 +1,6 @@
 # Free-form mode — complexity classifier
 
-When `/devlyn:resolve` is invoked with a free-form goal (no `--spec`) — whether the goal is the inline positional text or the content of `--goal-file <path>` (PHASE 0 resolves `goal_text` from either source before classifying) — PHASE 0 runs this classifier to set `state.complexity ∈ {trivial, medium, large}` and either proceeds with an internal mini-spec, drafts focused questions for in-prompt resolution, synthesizes a best-effort spec with logged assumptions, or halts zero-scope-signal goals with `/devlyn:ideate` guidance.
+When `/devlyn-resolve` is invoked with a free-form goal (no `--spec`) — whether the goal is the inline positional text or the content of `--goal-file <path>` (PHASE 0 resolves `goal_text` from either source before classifying) — PHASE 0 runs this classifier to set `state.complexity ∈ {trivial, medium, large}` and either proceeds with an internal mini-spec, drafts focused questions for in-prompt resolution, synthesizes a best-effort spec with logged assumptions, or halts zero-scope-signal goals with `/devlyn-ideate` guidance.
 
 The classifier is rules-based / deterministic — not an LLM judgment call. Decision rules below.
 
@@ -49,7 +49,7 @@ Conditions (any one):
 - The goal mentions a new feature whose surface area requires design decisions the harness cannot make from a one-shot prompt.
 
 Action:
-- Default: synthesize a best-effort spec from the goal with an explicit `## Assumptions` block (every assumption scope-narrowing and reversible — when in doubt, narrower); log `recommend: /devlyn:ideate first` in `.devlyn/criteria.generated.md` AND the final report; proceed to PHASE 1; the final report flags every assumption for user review.
+- Default: synthesize a best-effort spec from the goal with an explicit `## Assumptions` block (every assumption scope-narrowing and reversible — when in doubt, narrower); log `recommend: /devlyn-ideate first` in `.devlyn/criteria.generated.md` AND the final report; proceed to PHASE 1; the final report flags every assumption for user review.
 - Zero-signal exception: if the large classification includes `file_scope_signals == 0` (classifier cannot pick scope), halt with terminal verdict `BLOCKED:large-needs-ideation` — assumptions there would be scope-invention, not narrowing.
 
 ## Anti-pattern: drift to LLM judgment
@@ -63,7 +63,7 @@ When the rules are silent (rare — pathological goal text), default to `medium`
 The internal mini-spec written for trivial / medium / large-assumptions paths must satisfy:
 
 - `## Requirements` non-empty, each bullet testable (CLI command, test command, observable file change).
-- For executable generated verification, put one fenced `json` object with `verification_commands` inside the sentinel-marked `## Verification` section. Generated mode reads this inline carrier, not a sibling file. Follow `../../devlyn:ideate/references/spec-template.md` § "Sibling file: `spec.expected.json`" for constraint coverage, diff scope and violating/allowed controls, but express those checks as executable `verification_commands`; sibling-only fields such as `required_files` and `forbidden_patterns` are rejected inline. Preserve uncovered semantics as source-review obligations.
+- For executable generated verification, put one fenced `json` object with `verification_commands` inside the sentinel-marked `## Verification` section. Generated mode reads this inline carrier, not a sibling file. Follow `../../devlyn-ideate/references/spec-template.md` § "Sibling file: `spec.expected.json`" for constraint coverage, diff scope and violating/allowed controls, but express those checks as executable `verification_commands`; sibling-only fields such as `required_files` and `forbidden_patterns` are rejected inline. Preserve uncovered semantics as source-review obligations.
 - `## Verification` is preceded by a `<!-- devlyn:verification -->` sentinel on its own line directly above the heading — the machine locator `spec-verify-check.py` uses; the heading text itself is decorative and may be any language. When all Requirements are pure-design with no runnable acceptance check, put `{"pure_design": true, "verification_commands": []}` in the fenced `json` block and retain semantic source-review obligations. This explicit declaration is required; a missing block, an unmarked empty list, or `pure_design: true` with commands is invalid.
 - Free-form mode mini-specs are written to `.devlyn/criteria.generated.md` (not to a roadmap path) — this is run-scoped artifact, not a documented spec.
 - After writing `.devlyn/criteria.generated.md`, set `state.source.type = "generated"`, `state.source.spec_path = null`, `state.source.spec_sha256 = null`, `state.source.criteria_path = ".devlyn/criteria.generated.md"`, and `state.source.criteria_sha256` to the raw-byte SHA-256 of the generated criteria file. Downstream PLAN/IMPLEMENT/VERIFY phases and `spec-verify-check.py --include-risk-probes` depend on this pointer; do not rely on the file existing by convention.

package/config/skills/{devlyn:resolve → devlyn-resolve}/references/outer-loop.md

@@ -1,6 +1,6 @@
 # Outer-loop commit boundary
 
-A full `/devlyn:resolve` run starts only from committed owner inputs. Keep each
+A full `/devlyn-resolve` run starts only from committed owner inputs. Keep each
 commit scoped: no unrelated paths or queue-item changes.
 
 1. Before task writes, the outer owner allocates an absent task branch per

package/config/skills/{devlyn:resolve → devlyn-resolve}/references/state-schema.md

@@ -1,6 +1,6 @@
 # pipeline.state.json schema
 
-Single authoritative verdict source for `/devlyn:resolve`. The orchestrator branches on `state.phases.<name>.verdict` directly — never parses `.devlyn/*.findings.jsonl` for routing. Living document; bump `version` on a breaking change.
+Single authoritative verdict source for `/devlyn-resolve`. The orchestrator branches on `state.phases.<name>.verdict` directly — never parses `.devlyn/*.findings.jsonl` for routing. Living document; bump `version` on a breaking change.
 
 ## Top-level shape
 

package/config/templates/prompt-templates.md

@@ -23,7 +23,7 @@ Start with the minimum viable solution, then improve if time allows.
 
 ## Debugging
 
-For systematic debugging, use `/devlyn:resolve [issue description]` which includes:
+For systematic debugging, use `/devlyn-resolve [issue description]` which includes:
 - Code path mapping
 - Hypothesis-driven analysis
 - Test-driven fix validation
@@ -61,7 +61,7 @@ have working, tested code ready for PR.
 For complex bugs that need autonomous resolution:
 
 ```
-/devlyn:resolve [bug description]
+/devlyn-resolve [bug description]
 
 After analysis, implement the fix autonomously:
 - Write failing test first

package/optional-skills/{devlyn:pencil-pull → devlyn-pencil-pull}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devlyn:pencil-pull
+name: devlyn-pencil-pull
 description: Pull Pencil designs into code with exact visual fidelity.
 ---
 

package/optional-skills/{devlyn:pencil-push → devlyn-pencil-push}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devlyn:pencil-push
+name: devlyn-pencil-push
 description: Push codebase UI to Pencil canvas for design sync.
 ---
 

package/optional-skills/{devlyn:reap → devlyn-reap}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devlyn:reap
+name: devlyn-reap
 description: Safely count and kill orphaned child processes (PPID=1) left behind by Claude Code MCP plugins, Superset terminal tabs, and codex wrappers. Use this whenever the user says "too many processes", "can't open terminals", "pty/process limit", "hundreds of bun/codex/workerd piling up", "clean up orphans", "reap processes", or reports new terminals failing to spawn on macOS. Also use proactively after long Claude sessions to prevent hitting kern.maxprocperuid or kern.tty.ptmx_max limits. ONLY touches a conservative whitelist of known leaks — never guesses on unknown processes.
 allowed-tools: Read, Bash(ps:*), Bash(lsof:*), Bash(pgrep:*), Bash(awk:*), Bash(id:*), Bash(sysctl:*), Bash(bash:*)
 argument-hint: [scan | kill | kill --force | kill --include workerd | kill --only telegram-bun]
@@ -38,10 +38,10 @@ If the user's intent is ambiguous (e.g., they say "지워줘" but didn't specify
 
 Always run scan first — even in KILL mode — so the user sees what is about to happen.
 
-Run the bundled scanner. The skill is installed at `~/.claude/skills/devlyn:reap/`:
+Run the bundled scanner. The skill is installed at `~/.claude/skills/devlyn-reap/`:
 
 ```bash
-bash ~/.claude/skills/devlyn:reap/scripts/scan.sh
+bash ~/.claude/skills/devlyn-reap/scripts/scan.sh
 ```
 
 Report the output verbatim to the user. Then add your own 2-line summary:
@@ -60,7 +60,7 @@ sysctl kern.maxprocperuid kern.tty.ptmx_max 2>/dev/null
 Run the reap script with the parsed flags:
 
 ```bash
-bash ~/.claude/skills/devlyn:reap/scripts/reap.sh [flags]
+bash ~/.claude/skills/devlyn-reap/scripts/reap.sh [flags]
 ```
 
 Show the output verbatim. The script re-verifies `PPID==1 && user==current` for every PID right before signaling — a process that was legitimately adopted since the scan will be skipped, not killed.
@@ -72,7 +72,7 @@ After kill, re-run scan to confirm the counts dropped. If any whitelisted PIDs a
 If `telegram-bun` count > 10 OR oldest whitelisted orphan > 24h, tell the user this is a recurring leak and suggest one of:
 
 1. **Patch the telegram plugin** — add `process.stdin.on('end', () => process.exit(0))` to `server.ts` so the child dies when Claude Code exits.
-2. **Schedule this skill** — run `/devlyn:reap kill` periodically (e.g., via the `/loop` skill or a launchd agent).
+2. **Schedule this skill** — run `/devlyn-reap kill` periodically (e.g., via the `/loop` skill or a launchd agent).
 3. **Update Superset** — newer versions may SIGTERM process groups on tab close.
 
 Do NOT apply these automatically. Recommend and let the user choose.

package/optional-skills/{devlyn:reap → devlyn-reap}/scripts/reap.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# devlyn:reap — kill orphan processes from safe whitelist categories.
+# devlyn-reap — kill orphan processes from safe whitelist categories.
 # Verifies PPID==1 and user-ownership AGAIN at kill time to avoid racing a
 # legitimately-reparented process. Unknown orphans are never killed.
 #

package/optional-skills/{devlyn:reap → devlyn-reap}/scripts/scan.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# devlyn:reap — scan orphan processes by safe-to-kill category.
+# devlyn-reap — scan orphan processes by safe-to-kill category.
 # Read-only. Never kills anything. Always exits 0 on success.
 #
 # Output format: one TSV line per category with

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "devlyn-cli",
-  "version": "3.3.1",
+  "version": "4.0.0",
   "description": "Loop & harness engineering for AI coding agents (Claude Code, Codex, and any AGENTS.md-driven agent) — take intent to shipped, engineer-quality software hands-free with phase-gated pipelines and agent orchestration",
   "homepage": "https://github.com/fysoul17/devlyn-cli#readme",
   "bin": {
@@ -13,6 +13,8 @@
     "!config/skills/preflight-workspace/**",
     "!config/skills/devlyn:ideate-workspace",
     "!config/skills/devlyn:ideate-workspace/**",
+    "!config/skills/devlyn-ideate-workspace",
+    "!config/skills/devlyn-ideate-workspace/**",
     "!config/skills/devlyn:auto-resolve-workspace",
     "!config/skills/devlyn:auto-resolve-workspace/**",
     "!config/skills/roadmap-archival-workspace",