devlyn-cli 4.1.0 → 4.2.0

package/config/skills/devlyn-ideate/references/from-spec-mode.md

@@ -1,61 +0,0 @@
-# `--from-spec` mode
-
-Per-engine adapter prepended at runtime.
-
-<role>
-The user already wrote a spec (or has one from elsewhere — a teammate, a previous project, a copy-paste from a doc). Your job is to lint and normalize it to the canonical shape — without reshaping the user's substantive intent.
-</role>
-
-<input>
-- `<path>` — the external spec markdown file.
-- `_shared/expected.schema.json` — the schema for the sibling `spec.expected.json`.
-- `references/spec-template.md` — the canonical shape.
-</input>
-
-<allowed_changes>
-You may:
-1. Add missing frontmatter fields (id from filename, kind=feature default, status=planned, complexity=medium default; set complexity=high only when preserved Requirements clearly combine state/order/failure/output-shape risks).
-2. Rename non-canonical section headings to canonical (`## Goals` → `## Requirements`, `## Notes` ignored unless they clearly belong in Constraints).
-3. Add a missing `## Out of Scope` section with `- (no explicit non-goals provided by author)`.
-4. Add a missing `## Verification` section if Requirements imply observable runtime checks — best-effort one-command-per-Requirement, then surface to user for review.
-5. Generate `spec.expected.json` from the `## Verification` block if the file is absent.
-6. Fix structurally invalid `spec.expected.json` (malformed JSON, missing required keys per `_shared/expected.schema.json`).
-</allowed_changes>
-
-<forbidden_changes>
-You must NOT:
-- Reshape Requirements content. The user's substantive intent is preserved verbatim.
-- Add new Constraints the user did not write.
-- Move items between Requirements and Out of Scope.
-- "Improve" the prose in Context. Author voice stays.
-- Add `## Assumptions` or `## Open questions` sections — that is default-mode work, not normalization.
-</forbidden_changes>
-
-<flow>
-1. Read `<path>`. Parse frontmatter. Identify present sections.
-2. Lint structurally (same checks as default mode).
-3. For each missing/malformed piece: apply the smallest allowed fix.
-4. Write the normalized spec. Default location: `<spec-dir>/<id>-<slug>/spec.md`. With `--in-place` flag: write to `<path>` directly (overwrites the original).
-5. Generate or fix `spec.expected.json` per the rules above. Same dir as the spec.
-6. 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.
-7. Run `python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check-expected <expected-path>` to validate sibling `spec.expected.json` plus sibling spec `complexity` frontmatter.
-8. If lint still fails after allowed fixes (e.g. Requirements section is empty in the source), surface the issue and exit non-zero — do NOT invent Requirements.
-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
-   ideation or a stronger Verification section before pair-relevant risks are
-   measurable.
-</flow>
-
-<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`.
-
-If lint failed unfixably: print the specific failure, exit non-zero. Do not write a partial output.
-</output>
-
-<rationale>
-`--from-spec` exists for power users with external context. Adding friction by forcing them through default-mode elicitation defeats the purpose. The mode trades elicitation depth for normalization speed; the user accepts that any author-side under-specification stays under-specified.
-</rationale>

package/config/skills/devlyn-ideate/references/project-mode.md

@@ -1,80 +0,0 @@
-# `--project` mode
-
-Per-engine adapter prepended at runtime.
-
-<role>
-The user wants to build a project, not a single feature. Your job is to elicit the project description, decompose it into 3-7 independently-shippable features, and write `plan.md` (the index) plus one spec.md + spec.expected.json per feature.
-</role>
-
-<conversation_rules>
-1. Project elicitation warrants more turns than single-spec mode. Hard ceiling: 12 turns instead of 8.
-2. Ask the same question categories as default mode (input/output/failure/scope/constraints/verification) but at the project level first, then drill into each feature.
-3. Decompose into 3-7 features. Fewer = the project is actually one big feature; recommend default mode. More = the project is too large; recommend splitting into separate ideate runs.
-4. Each feature must be independently shippable: a feature whose verification depends on another feature's runtime behavior is a dependency, not a feature.
-5. When a feature combines state mutation with ordering/priority, idempotency,
-   auth/error priority, or exact output shape, its per-feature Verification must
-   include one compound end-to-end scenario; do not hide the interaction in
-   project-level prose.
-</conversation_rules>
-
-<decomposition_rules>
-- 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.
-</decomposition_rules>
-
-<plan_md_shape>
-Output `<spec-dir>/plan.md`:
-
-```markdown
-# <Project name>
-
-## Goal
-
-2-4 sentences from the elicitation — what the project delivers and why.
-
-## Decomposition rationale
-
-1-2 paragraphs explaining how the project was sliced into features. Includes the order rationale.
-
-## Feature specs
-
-| ID | Title | Depends on | Status |
-|----|-------|-----------|--------|
-| <id-1> | ... | (none) | planned |
-| <id-2> | ... | <id-1> | planned |
-| ... | ... | ... | ... |
-
-## Suggested implementation order
-
-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.
-
-## Project-level constraints
-
-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_shape>
-
-<output>
-- `<spec-dir>/plan.md` (the index above).
-- `<spec-dir>/<id-N>/spec.md` for each feature (per `references/spec-template.md`).
-- `<spec-dir>/<id-N>/spec.expected.json` for each feature (per `_shared/expected.schema.json`).
-
-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>`.
-</output>
-
-<anti_patterns>
-- Decomposing into more features than the project needs (10+ features for a CLI). Project mode is for genuine multi-feature work.
-- Hidden coupling between features (feature B's spec assumes feature A's internal data structure). Surface as `depends_on` or fold into one spec.
-- Vision documents, roadmaps as separate tiers, market-positioning paragraphs. The locked design is index + specs. Anything else is context pollution.
-- Continuing past 12 turns of elicitation. If the project is still not clear at turn 12, recommend the user split it into 2-3 separate ideate runs.
-</anti_patterns>

package/config/skills/devlyn-ideate/references/spec-template.md

@@ -1,121 +0,0 @@
-# Canonical spec template
-
-The shape `/devlyn-ideate` writes and `/devlyn-resolve --spec` consumes. Single source of truth for spec structure.
-
-## Frontmatter
-
-```yaml
----
-id: "<spec-id>"          # kebab-case, unique per spec-dir; auto-generated if user omits
-title: "<short title>"    # one line, descriptive
-kind: feature             # feature | spike | prototype
-status: planned           # planned → in_progress → done. ideate writes "planned"; resolve's CLEANUP flips to "done".
-complexity: medium        # trivial | medium | high. Use high when Verification needs compound state/order/failure checks.
-depends_on: []            # list of spec ids this depends on (empty for standalone). project mode populates this.
----
-```
-
-## `# <title>`
-
-Top-level heading repeats the title.
-
-## `## Context`
-
-2-4 sentences answering "why does this exist." User-facing motivation, not implementation detail. Traceable to whatever the user said during elicitation.
-
-## `## Requirements`
-
-Checklist of testable, scoped statements. Each bullet is one observable behavior:
-
-```markdown
-- [ ] `node bin/cli.js doctor` exits 0 on a clean machine.
-- [ ] `--verbose` lists installed plugins by name.
-- [ ] Exit code is `1` when any FAIL line appears.
-```
-
-Rules:
-- Each Requirement is independently verifiable (a command, a test, a file existence check).
-- Avoid implementation language ("use a try/catch") in Requirements; that goes in Constraints.
-- Pure-design Requirements are allowed (e.g. "follow the existing pattern in `lib/X.js`") but mark them "design-only" so Verification can be omitted for that bullet.
-
-## `## Constraints`
-
-Concrete rules with reasoning. Examples:
-
-```markdown
-- **Zero new npm dependencies.** Use only Node.js built-ins.
-- **No silent error catches.** Errors must be visible to the user with actionable messages.
-- **Touch only `bin/cli.js` and `tests/cli.test.js`.** Other files are out of scope.
-```
-
-Each constraint has a one-line "why" — bare constraints invite negotiation; reasoned constraints lock the contract.
-
-## `## Out of Scope`
-
-Explicit "must NOT build" list. Examples:
-
-```markdown
-- Auto-repair (report only).
-- Checking remote/registry state.
-- Refactoring the argument parser.
-```
-
-If the spec is small enough that nothing meaningful is out of scope, write `- (nothing notable; see Constraints for boundary)`.
-
-## `## Verification`
-
-Immediately precede the heading with a `<!-- devlyn:verification -->` sentinel
-comment on its own line, directly above `## Verification` (no blank line
-between them). This is the machine locator `spec-verify-check.py` uses to
-find the section — it is language-neutral: the heading text after the
-sentinel may be any human language (`## Verification`, `## 검증`, etc.); only
-the sentinel itself is fixed ASCII and must never be translated.
-
-Concrete commands or tests whose expected behavior names the success condition:
-
-```markdown
-<!-- devlyn:verification -->
-## Verification
-
-- `node bin/cli.js doctor` exits 0; output contains `doctor:`.
-- `HOME=/nonexistent node bin/cli.js doctor` exits 1; output mentions `/nonexistent`.
-- `node --test tests/cli.test.js` passes.
-- `git diff -- package.json` is empty.
-```
-
-The body of the section reads humanely; the machine-readable contract lives in `spec.expected.json` (sibling file). Each command in this section maps to one entry in `spec.expected.json.verification_commands`.
-
-If all Requirements are pure-design (no observable runtime check), the body of this section is a single descriptive line (e.g. `- No runtime verification commands.`) and sibling `spec.expected.json` declares `"pure_design": true` instead of listing `verification_commands`.
-
-## Sibling file: `spec.expected.json`
-
-Schema: `_shared/expected.schema.json`. Required when Requirements have observable checks; optional when all Requirements are pure-design (declare `"pure_design": true` in that case — contradictory, and rejected, alongside a non-empty `verification_commands`). Validate before announcing ready:
-
-```bash
-python3 "$DEVLYN_SHARED_DIR/spec-verify-check.py" --check-expected <expected-path>
-```
-
-Map mechanically decidable rules from both Requirements and Constraints into the existing carriers. Preserve specific file constraints even when narrower than PLAN's scope. During BUILD_GATE, with `state.base_ref.sha` recorded, the existing `authorized_surface` check enforces PLAN's scope over the run diff and newly created untracked paths (`.devlyn/` exempt). Do not duplicate this general scope check with a whole-checkout scan in `verification_commands`. Validate each new guard with a violating control that fails and an allowed control that passes, preserving permitted pre-existing occurrences:
-- `verification_commands` ← `## Verification` + commands the conversation surfaced. While drafting both Verification and its carrier, omit a standalone check only when another command in that contract runs the same assertions under the required execution conditions and propagates failure; describe that shared coverage in Verification and keep both carriers aligned. Preserve distinct scenarios and required independent verification; execute approved commands unchanged without reusing results across phases. For semantic annotation or exception-handling rules, use a suitable syntax-aware/executable check, preferring existing checks; explicitly retain uncovered semantics as source-review obligations.
-- `forbidden_patterns` ← literal syntax constraints only; regex does not prove semantics. It scans the whole file-filtered diff, including context, deletions and headers; additions-only guards must exclude those lines.
-- `required_files` / `forbidden_files` ← literal file paths from Requirements, Constraints and Out of Scope; `forbidden_files` matches exact Git-relative paths (forward slashes, no leading `./`), including both names of a rename. Globs and directory-wide exclusions need a suitable `verification_commands` guard, not wildcard-looking entries in these lists.
-- `max_deps_added` ← dependency limits in Requirements or Constraints (default 0 unless the spec licenses a new dep).
-- `required_risk_probe_requirements` ← for specs where a Requirement combines ordering/priority, rollback, idempotency, auth/signature, concurrency, atomic-batch, or exact output shape, declare the risk categories PHASE 1.5 risk-probe derivation must cover directly, e.g. `[{"tag": "rollback_state", "derived_from": "<exact ## Verification bullet>"}]`. This replaces guessing the required categories from prose — declare them explicitly so the check works in any language. `tag` must be one of the risk-probe tags in `_shared/spec-verify-check.py:RISK_PROBE_TAGS`; `derived_from` must be an exact substring of `## Verification`. Omit entirely when the spec has no ordering/rollback/idempotency/auth/concurrency/atomic-batch/exact-shape risk.
-
-## Quality bar (lint enforces structurally; ideate enforces substantively)
-
-Structural (lint):
-- Frontmatter valid + required fields present.
-- All five H2 sections present.
-- Requirements has ≥ 1 bullet.
-- Verification has either commands or `spec.expected.json` declares `"pure_design": true`.
-
-Substantive (ideate's job during elicitation):
-- Each Requirement is independently verifiable.
-- Each Constraint has a reasoning clause.
-- Out of Scope explicitly enumerates non-goals.
-- Verification commands actually verify the Requirement they map to (no "looks plausible" verification).
-- Avoid formatter-sensitive single-line adjacency checks — prefer a semantic test (runtime, DB, or CLI check), or grep one stable line-local anchor and assert required context separately.
-- Frontmatter `complexity` reflects verification shape: `high` when the spec combines state mutation with ordering/priority, idempotency, auth/error priority, rollback/failure handling, or exact output shape; `medium` for ordinary multi-step work; `trivial` only for a single localized behavior.
-- When Requirements combine state mutation, ordering/priority, idempotency, auth/error priority, or exact output shape, Verification includes at least one compound scenario that exercises the interaction end-to-end; isolated happy paths are insufficient.
-- Spec text is plain language — no jargon walls, no "for future flexibility" hedging.

package/config/skills/devlyn-ideate/references/templates/decision.md

@@ -1,48 +0,0 @@
-# Decision Record Template
-
-Generate decision records at `docs/roadmap/decisions/{NNN}-{title}.md`. These capture WHY a decision was made, preventing future agents and collaborators from re-debating settled questions.
-
----
-
-```markdown
----
-id: [NNN]
-title: "[Decision Title]"
-date: [YYYY-MM-DD]
-status: accepted
----
-
-# [NNN] [Decision Title]
-
-## Context
-<!-- What situation or question prompted this decision? -->
-
-## Decision
-<!-- What was decided. Be specific and concrete. -->
-
-## Alternatives Considered
-
-### [Alternative 1]
-- Pros: [advantages]
-- Cons: [disadvantages]
-- Why rejected: [the deciding factor]
-
-### [Alternative 2]
-- Pros: [advantages]
-- Cons: [disadvantages]
-- Why rejected: [the deciding factor]
-
-## Consequences
-<!-- What changes as a result. Include both positive tradeoffs and costs accepted. -->
-- [Positive consequence]
-- [Cost or constraint accepted]
-```
-
-## Guidelines
-
-- Status values: `proposed` | `accepted` | `superseded`
-- Number decisions sequentially: 001, 002, 003...
-- Focus on the "why rejected" for alternatives — this is what prevents re-debating
-- Keep decisions atomic: one decision per record
-- If a decision is later reversed, mark the original as `superseded` and create a new record referencing it
-- Only create decision records for choices that affect multiple roadmap items or have non-obvious reasoning. Don't document every small implementation choice.

package/config/skills/devlyn-ideate/references/templates/roadmap.md

@@ -1,50 +0,0 @@
-# ROADMAP.md Template
-
-Generate `docs/ROADMAP.md` using this structure. This is an **index** — brief descriptions and links to detail specs. No inline specifications.
-
----
-
-```markdown
-# [Project Name] Roadmap
-
-> **North Star**: [One sentence from VISION.md]
-
-## Phase 1: [Theme Name] (Target: [date or timeframe])
-<!-- 1-2 sentences: what this phase delivers and why it comes first -->
-
-| # | Feature | Status | Priority | Complexity | Spec |
-|---|---------|--------|----------|-----------|------|
-| 1.1 | [Feature Name] | Planned | High | Medium | [spec](roadmap/phase-1/1.1-feature-name.md) |
-| 1.2 | [Feature Name] | Planned | High | High | [spec](roadmap/phase-1/1.2-feature-name.md) |
-| 1.3 | [Feature Name] | Planned | Medium | Low | [spec](roadmap/phase-1/1.3-feature-name.md) |
-
-## Phase 2: [Theme Name] (Target: [date or timeframe])
-<!-- 1-2 sentences -->
-
-| # | Feature | Status | Priority | Complexity | Spec |
-|---|---------|--------|----------|-----------|------|
-| 2.1 | [Feature Name] | Planned | High | Medium | [spec](roadmap/phase-2/2.1-feature-name.md) |
-
-## Backlog
-<!-- Ideas acknowledged but not yet phased -->
-| Feature | Reason Deferred | Revisit |
-|---------|----------------|---------|
-| [Name] | [Why not now] | [When to reconsider] |
-
-## Decisions
-| # | Decision | Date | Record |
-|---|----------|------|--------|
-| 1 | [Decision Title] | [YYYY-MM-DD] | [record](roadmap/decisions/001-decision-title.md) |
-```
-
-## Guidelines
-
-- Status values: `Planned` | `In Progress` | `Done` | `Blocked`
-- Priority: `High` | `Medium` | `Low`
-- Complexity: `Low` | `Medium` | `High`
-- Feature names should be user-facing descriptions, not technical jargon
-- Each phase should deliver usable value — no "infrastructure only" phases
-- The spec column links to the detail spec in `roadmap/phase-N/`
-- Numbering: `{phase}.{item}` (e.g., 1.1, 1.2, 2.1)
-- Slug format for filenames: `{id}-{kebab-case-name}.md` (e.g., `1.1-user-auth.md`)
-- Keep this file under 150 lines — it's an index, not a specification

package/config/skills/devlyn-ideate/references/templates/vision.md

@@ -1,44 +0,0 @@
-# VISION.md Template
-
-Generate `docs/VISION.md` using this structure. Keep it under 100 lines — this is a strategic orientation document, not a detailed specification.
-
----
-
-```markdown
-# [Project Name] Vision
-
-## North Star
-<!-- One sentence. Every decision should move toward this. -->
-
-## Principles
-<!-- 3-5 guiding principles. Each includes what it means AND the tradeoff it implies. -->
-1. **[Principle Name]** — [What this means in practice]. Tradeoff: [what we accept giving up].
-2. ...
-
-## Target Users
-### Primary
-<!-- Be specific: role, context, pain, what they need -->
-**[Who]** — [Their situation]. Pain: [what frustrates them]. Need: [what they want].
-
-### Not For
-<!-- Explicitly state who this isn't for, so the team doesn't try to serve everyone -->
-- [Audience] — Why: [reason this isn't our focus]
-
-## Anti-Goals
-<!-- Things we deliberately choose NOT to do, even if they seem like good ideas -->
-- **[Anti-goal]** — Why: [the reasoning behind this constraint]
-- ...
-
-## Success Metrics
-<!-- How we know this is working. Outcomes, not outputs. -->
-- [Metric]: [target] (e.g., "Time to first value: under 5 minutes")
-- ...
-```
-
-## Guidelines
-
-- North Star should be ambitious but specific — "make X better" is too vague
-- Principles without tradeoffs are platitudes — if a principle has no cost, it's not a real principle
-- Anti-goals prevent scope creep downstream — be generous with these
-- Success metrics should be measurable, even if the measurement is qualitative
-- Write in the user's primary language, technical terms in English

package/config/skills/devlyn-queue/SKILL.md

@@ -1,66 +0,0 @@
----
-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.
-
-<args>
-$ARGUMENTS
-</args>
-
-Before `add` or `drain`, establish the bindings below.
-
-Resolve bundled resources from the SKILL.md loaded for this invocation.
-
-Reader-rendered directory hint:
-```text
-${CLAUDE_SKILL_DIR}
-```
-
-Treat the hint as literal path data, never shell code. If the reader
-replaced it with an absolute directory, use that directory. Otherwise
-use the filesystem path or base directory reported for this loaded
-SKILL.md. Resolve virtual URIs through the reader's native filesystem
-mapping. If available source locations name different directories,
-stop.
-
-Bind DEVLYN_SKILL_DIR to that absolute directory. Do not obtain this
-binding from an environment variable, cwd, or another installation.
-Verify its SKILL.md before proceeding. Missing or conflicting source
-identity is BLOCKED:skill-source-unresolved; include the failed path
-when known.
-
-Resolve bundled references against this directory. These bindings are
-workflow values: establish them explicitly using each tool or shell's
-literal-path rules, and include their absolute values in every fresh
-worker's prompt, telling it to set them from those values, never from
-its inherited environment. Do not rely on shell state surviving between
-calls.
-
-Resolve directory symlinks on DEVLYN_SKILL_DIR before deriving its
-sibling _shared. Bind that directory as DEVLYN_SHARED_DIR. References
-written as _shared/... use this binding. Verify the directory and each
-required resource before use; failure is BLOCKED:shared-dir-unresolved
-with the failed path. Never search another installation.
-
-For `add`, verify DEVLYN_SKILL_DIR/scripts/append.py before invoking it. For `drain`, before processing the first item, read and obey ../devlyn-resolve/references/outer-loop.md (its scoped-commit order is binding) and read ../devlyn-resolve/references/task-completion.md, both relative to this bound skill directory. Load the sibling devlyn-resolve/SKILL.md by its absolute path and preserve this bundle's DEVLYN_SHARED_DIR when handing off; do not rediscover resolve by its bare command name. In omp, use `printf '%s\n' skill://devlyn-queue`.
-
-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.
-
-## No args — status
-
-Read the queue state above (absent `docs/specs/queue.md` → report "queue empty — nothing staged" and how to add). Print pending `[ ]`, done `[x]`, and blocked `[F]` counts, the next item up, and one usage line per subcommand.
-
-## Subcommands
-
-- `add <intent text>` — use the Write tool to place the exact full intent in a new file `.devlyn/queue-intent-<unique>.txt` (a name no other add uses, made of letters, digits, `.`, `_` and `-`, e.g. `queue-intent-20261001-1230-k3x9.txt`); do not create it with shell syntax. If the conversation already produced a spec, the file must start with `(spec: docs/specs/<id>/spec.md)`. Then, from the project root, run exactly once `python3 "$DEVLYN_SKILL_DIR/scripts/append.py" .devlyn/queue-intent-<unique>.txt`. The helper consumes that file, appends one `- [ ] <intent>` line at the physical end of `docs/specs/queue.md` under a lock (creating it with its header if missing), and is the sole queue writer. Never edit `docs/specs/queue.md` directly for `add` and never use a direct-edit fallback; a nonzero helper exit is shown to the user and stops the `add`.
-- `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 the sibling devlyn-resolve loaded above with `--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]`.

package/config/skills/devlyn-queue/scripts/append.py

@@ -1,94 +0,0 @@
-#!/usr/bin/env python3
-"""Append one normalized pending intent to the project queue."""
-
-import argparse
-import os
-import re
-import sys
-from contextlib import contextmanager
-from pathlib import Path
-
-
-QUEUE_PATH = Path("docs/specs/queue.md")
-LOCK_PATH = Path(".devlyn/queue.lock")
-# Each `add` writes its own handoff file, so two adds never consume each other's intent.
-HANDOFF = re.compile(r"\.devlyn/queue-intent-[A-Za-z0-9._-]+\.txt")
-MINIMAL_HEADER = b"# Intent Queue\n\n"
-
-
-@contextmanager
-def queue_lock():
-    """One writer at a time across processes, from creating the queue to the append."""
-    LOCK_PATH.parent.mkdir(parents=True, exist_ok=True)
-    fd = os.open(LOCK_PATH, os.O_RDWR | os.O_CREAT, 0o644)
-    try:
-        if os.name == "nt":
-            import msvcrt
-
-            # The CRT locks bytes that exist; give a new lock file its one byte.
-            if os.fstat(fd).st_size == 0:
-                os.write(fd, b"\0")
-            os.lseek(fd, 0, os.SEEK_SET)
-            msvcrt.locking(fd, msvcrt.LK_LOCK, 1)
-            try:
-                yield
-            finally:
-                os.lseek(fd, 0, os.SEEK_SET)
-                msvcrt.locking(fd, msvcrt.LK_UNLCK, 1)
-        else:
-            import fcntl
-
-            fcntl.flock(fd, fcntl.LOCK_EX)
-            yield
-    finally:
-        os.close(fd)
-
-
-def append_intent(queue_path, intent):
-    normalized = " ".join(intent.split())
-    if not normalized:
-        raise ValueError("intent must contain non-whitespace text")
-    item = f"- [ ] {normalized}\n".encode("utf-8")
-
-    with queue_lock():
-        if not queue_path.exists():
-            queue_path.parent.mkdir(parents=True, exist_ok=True)
-            queue_path.write_bytes(MINIMAL_HEADER + item)
-            return
-
-        with queue_path.open("rb") as queue:
-            queue.seek(0, 2)
-            size = queue.tell()
-            if size:
-                queue.seek(-1, 2)
-                ends_with_newline = queue.read(1) == b"\n"
-            else:
-                ends_with_newline = True
-
-        prefix = b"" if ends_with_newline else b"\n"
-        with queue_path.open("ab") as queue:
-            queue.write(prefix + item)
-
-
-def main(argv=None):
-    parser = argparse.ArgumentParser(
-        description="Append one pending intent at the physical end of docs/specs/queue.md."
-    )
-    parser.add_argument("handoff", type=Path, help=".devlyn/queue-intent-<unique>.txt, relative to the project root")
-    args = parser.parse_args(argv)
-    if not HANDOFF.fullmatch(args.handoff.as_posix()):
-        parser.error(f"handoff must be .devlyn/queue-intent-<unique>.txt: {args.handoff}")
-    try:
-        try:
-            intent = args.handoff.read_text(encoding="utf-8")
-        finally:
-            args.handoff.unlink(missing_ok=True)
-        append_intent(QUEUE_PATH, intent)
-    except (OSError, UnicodeError, ValueError) as error:
-        print(f"queue add failed: {error}", file=sys.stderr)
-        return 1
-    return 0
-
-
-if __name__ == "__main__":
-    raise SystemExit(main())