@ai-content-space/loopx 0.2.2 → 0.2.4

package/skills/doc-readability/references/prd.md

@@ -0,0 +1,269 @@
+# PRD Readability and Completeness
+
+Use this reference only when the confirmed document type is `Requirements document / PRD`, or when the user explicitly asks to evaluate a document as a PRD.
+
+## Core Standard
+
+A PRD is readable only if it lets reviewers decide whether the product should be built and lets designers, engineers, QA, operations, and stakeholders understand what must be delivered. For PRDs, readability includes requirement completeness, not just prose clarity.
+
+## Required Checks
+
+Check the PRD across these areas:
+
+| Area | What must be clear |
+|---|---|
+| Problem | What problem exists, who has it, why it matters now, and what current workaround or failure it replaces. |
+| Goal | What outcome this release must achieve, and how success will be judged. |
+| Non-goals | What is explicitly out of scope, deferred, or intentionally unsupported. |
+| Users / roles | Which user roles exist, what each role can see or do, and which role owns each decision or operation. |
+| Scope and priority | What is MVP / phase-one / required, what is optional, and what is future work. |
+| Workflow | Trigger, preconditions, main path, branch paths, exception paths, and terminal states. |
+| Functional requirements | Inputs, outputs, state changes, permissions, validation, dependencies, and failure handling. |
+| Business rules | Who evaluates the rule, using which fields, at what time, and what happens when the rule fails. |
+| Page / operation behavior | Entry point, displayed fields, action buttons, enable/disable conditions, submit validation, success/failure feedback, and audit logs. |
+| Data / integration | Source systems, target systems, required fields, idempotency, versioning, retries, and consistency expectations. |
+| Acceptance criteria | Testable Given/When/Then-style outcomes or equivalent concrete verification criteria. |
+| Open questions | Unknowns, decision owners, deadlines, and whether they block delivery. |
+
+## Detail Gap Patterns
+
+Flag these as PRD detail gaps, even if the prose is readable:
+
+- A feature says `support`, `process`, `identify`, `generate`, `sync`, `notify`, `confirm`, or `handle`, but does not define input, output, owner, timing, or terminal state.
+- A workflow lists stages but omits trigger, precondition, branch conditions, exception handling, or completion criteria.
+- A status is named but its transitions, allowed actions, owner, or exit condition are missing.
+- A page lists fields but omits action behavior, button availability, validation, empty states, errors, permissions, or logs.
+- A rule describes intent but not the exact field, calculation, priority, source of truth, or conflict handling.
+- A Plan / task / event is generated, but the recipient, payload, idempotency, retry, cancellation, and failure handling are unclear.
+- A dependency is mentioned but its contract, SLA, missing-data behavior, or fallback is undefined.
+- A requirement cannot be tested because it lacks concrete examples or acceptance criteria.
+
+## Ambiguity Probes
+
+Use these probes to expose unclear requirements. Do not ask all of them to the user; use them to inspect the document and report the gaps that matter.
+
+### Feature Scope
+
+- What exactly does `support X` include and exclude?
+- What is the minimum acceptable behavior for phase one?
+- Is this automatic, manual, or semi-automatic?
+- Who can trigger it, and from where?
+- What happens if the user starts but does not finish?
+- What behavior is intentionally not supported?
+- What is the smallest shippable version of the feature?
+- Which users, accounts, markets, regions, products, channels, or data types are included?
+- Which cases are explicitly excluded even if they look similar?
+- Does "support" mean display only, calculate, persist, send, execute, reconcile, notify, or audit?
+- Does the requirement apply to historical data, only new data, or both?
+- Is there a migration, backfill, or cleanup requirement?
+
+### Actors and Ownership
+
+- Which role owns each decision, confirmation, correction, and exception?
+- Which actions are system actions, user actions, operator actions, or downstream-system actions?
+- Who is allowed to override system output?
+- Who reviews or approves high-risk actions?
+- Who is notified when something is blocked, failed, revised, or completed?
+- Who owns manual follow-up when automation cannot continue?
+
+### Workflow and State
+
+- What triggers the workflow?
+- What preconditions must be true?
+- What is the happy path?
+- What branches exist and what condition selects each branch?
+- What are the terminal states?
+- Which states allow edit, retry, cancel, ignore, approve, reject, archive, or rollback?
+- Who owns each state transition?
+- What happens when two events, tasks, or users act on the same object concurrently?
+- What is the first state after creation?
+- What is the difference between draft, pending, confirmed, sent, failed, completed, archived, ignored, or cancelled?
+- Which transitions are automatic and which require user action?
+- Are any transitions irreversible?
+- What events reopen or revise a completed item?
+- What stale states require timeout handling or escalation?
+- What should the system do if a workflow is interrupted mid-step?
+
+### Timing and Snapshot
+
+- Which date or time controls eligibility, calculation, display, execution, and notification?
+- Is the date in user timezone, market timezone, system timezone, or source-system timezone?
+- What snapshot is used for positions, balances, orders, customers, permissions, or source data?
+- Can the snapshot be regenerated? If yes, does it replace or version prior results?
+- What happens if source data arrives late, is revised, or is cancelled?
+- What is the cutoff time for each action?
+- What is allowed before cutoff, after cutoff, and after execution?
+
+### Data and Rules
+
+- What is the source of truth for each important field?
+- Which field is required, optional, calculated, derived, or manually entered?
+- What is the rule priority when multiple rules match?
+- What happens when source systems disagree?
+- What happens when required data is missing, stale, duplicated, revised, or cancelled?
+- Are historical values preserved when current effective values change?
+- Is there versioning, and which version is current?
+- What is the unique key for deduplication?
+- Which fields are immutable after creation?
+- Which fields can be manually corrected, and how are original/system/manual/effective values preserved?
+- What validation prevents invalid combinations?
+- What precision, rounding, currency, unit, or formatting rule applies?
+- What happens when two rules produce different outputs?
+- What is the conflict priority between source data, manual confirmation, downstream return, and recalculation?
+- Is the rule evaluated per user, per account, per task, per event, per order, or per item?
+
+### Page and Operation Behavior
+
+- Where is the entry point?
+- What fields are visible by default, and what is hidden behind details?
+- Which actions are available in each status?
+- What disables an action button?
+- What validation runs before submit?
+- What confirmation, warning, or preview is shown before an irreversible operation?
+- What success, failure, partial-success, retry, and timeout feedback does the user see?
+- What audit log is written?
+- What filters, sorting, grouping, search, export, or bulk actions are required?
+- What empty, loading, error, no-permission, and no-data states are shown?
+- What fields are editable, read-only, calculated, or drill-down only?
+- What happens when a user edits data that has already changed in the background?
+- What is the behavior for batch selection, partial selection, and disabled rows?
+- What is the exact result of save, submit, approve, reject, retry, ignore, archive, cancel, rollback, or resend?
+- Does the user need a preview of generated output before sending?
+
+### Integration and Execution
+
+- Who receives generated tasks, events, Plans, notifications, or files?
+- What payload is sent?
+- What idempotency key or duplicate-prevention rule exists?
+- What is retryable and what requires manual intervention?
+- What happens on partial success?
+- What happens if the downstream system accepts the request but later reports failure?
+- What cancellation, correction, reversal, or compensation path exists?
+- Is execution synchronous, asynchronous, scheduled, or manual?
+- What acknowledgement does the upstream system need?
+- What return payload is expected?
+- What retry policy applies: count, interval, backoff, manual retry, or no retry?
+- What makes a request idempotent?
+- How are duplicate sends, duplicate callbacks, or out-of-order callbacks handled?
+- What monitoring, alerting, or reconciliation is required?
+- What should happen when integration is unavailable but users continue operating?
+
+### Permissions and Risk
+
+- Who can view, create, edit, approve, send, retry, cancel, or archive?
+- Which operations require dual review or elevated permission?
+- What is the blast radius of a wrong operation?
+- What guardrails prevent sending incomplete, stale, or unconfirmed data?
+- What must be recoverable from logs?
+- Which fields or actions are sensitive?
+- Which roles can see customer-level, account-level, financial, or operational details?
+- Is approval required before customer-facing or financially impactful actions?
+- What is the rollback or compensation path for wrong execution?
+- What operational dashboard or report proves the feature is healthy?
+- What audit evidence must be retained for compliance or customer support?
+
+### Notifications and External Visibility
+
+- Who receives notifications: internal operators, downstream teams, customers, support, or all?
+- What triggers notification creation?
+- What template, channel, language, and timing are required?
+- What fields are shown to customers versus internal users?
+- What happens if notification delivery fails?
+- Can notifications be resent, corrected, suppressed, or cancelled?
+- What customer support or audit view is needed after notification?
+
+## Acceptance Criteria Patterns
+
+When a requirement is vague, propose a testable acceptance shape. Use domain language from the document.
+
+```text
+Given [precondition / status / role / data]
+When [user action / system trigger / external event]
+Then [observable result / state change / generated output]
+And [audit / notification / error / retry behavior]
+```
+
+Include acceptance coverage for:
+
+- Happy path.
+- Missing or invalid input.
+- Permission denied.
+- Duplicate submission or duplicate event.
+- External dependency failure.
+- Partial success.
+- Revised or cancelled source data.
+- No impacted users / empty result.
+- Manual override.
+- Audit and traceability.
+
+For page requirements, check:
+
+```text
+Given [task status and user role]
+When [page opens or action is clicked]
+Then [fields/actions visible]
+And [disabled/enabled conditions]
+And [validation / feedback / log behavior]
+```
+
+For rules, check:
+
+```text
+Given [source data and priority conditions]
+When [rule evaluation runs]
+Then [selected result]
+And [fallback or conflict result]
+```
+
+## PRD Severity
+
+Use this severity model in addition to the main skill's severity model:
+
+| Severity | Meaning |
+|---|---|
+| Blocking requirement gap | A builder or reviewer cannot know what to implement, test, approve, or operate. |
+| Important requirement gap | The requirement is implementable only with assumptions; different readers may implement it differently. |
+| Optional refinement | The requirement is understandable, but examples, wording, or organization could reduce review effort. |
+
+Do not label every missing detail as blocking. A missing detail is blocking only if implementation, testing, or review would require guessing.
+
+## PRD Output Requirement
+
+When assessing a PRD, include a section for requirement detail gaps. Use natural headings in the user's language. Cover:
+
+- The gap.
+- Why it affects delivery or review.
+- What question must be answered or what detail must be added.
+- A suggested acceptance or clarification shape when useful.
+
+Example shape:
+
+```text
+Requirement detail gaps:
+- [Gap]: ...
+  Impact: ...
+  Need to clarify: ...
+  Suggested acceptance shape: ...
+```
+
+## Rewrite Guidance for PRDs
+
+When rewriting a PRD, prefer this structure:
+
+```text
+1. Summary
+2. Background / problem
+3. Goals and non-goals
+4. Users and roles
+5. Scope and priorities
+6. Core workflows
+7. Functional requirements
+8. Rules and edge cases
+9. Page / operation requirements
+10. Data and integration requirements
+11. Acceptance criteria
+12. Open questions
+13. Appendix
+```
+
+Keep implementation contracts in the PRD only when they are needed for product review. Move exhaustive field tables, enum lists, API payloads, and state-machine details to appendices or companion engineering specs when they interrupt the product decision path.

package/skills/exec/SKILL.md

@@ -3,7 +3,7 @@ name: exec
 description: "Executes a written loopx implementation plan sequentially with review checkpoints. Not for unclear plans, missing requirements, or subagent-first execution."
 when_to_use: "written implementation plan, inline execution, sequential plan execution, review checkpoints, no subagent lane"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Exec
@@ -35,9 +35,12 @@ For each task:
 ### Step 3: Complete Development
 
 After all tasks complete and verified:
+- Announce: "I'm using the final-review skill to review the completed feature."
+- **REQUIRED SUB-SKILL:** Use loopx:final-review
+- If final-review finds Critical or Important issues, use loopx:fix-review to handle feedback before proceeding
 - Announce: "I'm using the finish skill to complete this work."
 - **REQUIRED SUB-SKILL:** Use loopx:finish
-- Follow that skill to verify tests, present options, execute choice
+- Follow finish to verify tests, present options, execute choice
 
 ## When to Stop and Ask for Help
 
@@ -68,4 +71,6 @@ After all tasks complete and verified:
 
 **Required workflow skills:**
 - **loopx:plan** - Creates the plan this skill executes
+- **loopx:final-review** - Final whole-feature runtime and integration risk review
+- **loopx:fix-review** - Handles final-review feedback before finish
 - **loopx:finish** - Complete development after all tasks

package/skills/final-review/SKILL.md

@@ -3,7 +3,7 @@ name: final-review
 description: "Performs whole-feature review after implementation and staged task review. Not for per-task review, unresolved scope, implementation, or pure documentation polish."
 when_to_use: "final-review, final code review, whole feature review, integration review, pre-finish review, after subagent-exec, runtime risk review, 最终评审"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Final Review

package/skills/finish/SKILL.md

@@ -3,7 +3,7 @@ name: finish
 description: "Finishes completed loopx development work after tests pass by presenting merge, PR, keep, or discard options. Not for unfinished work or failing verification."
 when_to_use: "implementation complete, tests pass, finish branch, create pull request, merge locally, keep branch, discard work"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Finish

package/skills/fix-review/SKILL.md

@@ -3,7 +3,7 @@ name: fix-review
 description: "Handles received code review feedback with verification, technical evaluation, pushback, and one-item-at-a-time fixes. Not for requesting a new review or implementing unrelated changes."
 when_to_use: "fix-review, received code review feedback, review comments, reviewer suggestions, requested changes, 处理评审意见"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Fix Review

package/skills/go-style/SKILL.md

@@ -3,7 +3,7 @@ name: go-style
 description: "Applies loopx Go coding style for .go edits, tests, errors, context, naming, and interface boundaries. Not for non-Go code or Kratos-specific architecture by itself."
 when_to_use: "go-style, Go, golang, .go files, go tests, gofmt, idiomatic Go, Go style, Go 代码"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Go Style
@@ -59,7 +59,13 @@ Choose the one already used in the codebase.
 
 - Exported symbols should have Go doc comments that start with the symbol name.
 - Short local comments are acceptable when they explain why, not what.
-- Prefer complete sentences for package, exported type, exported function, and non-obvious behavior comments.
+- Prefer complete sentences for package, exported type, exported function, exported method, and non-obvious behavior comments.
+- Match new comments to the user's requested language. If the user asks in Chinese or explicitly requests Chinese comments, write new comments in Chinese while preserving Go doc naming conventions such as `// UserService ...` and `// CreateUser ...`.
+- Do not translate existing comments unless the user explicitly asks for translation; preserve the surrounding file's established comment language when no user preference is stated.
+- Remove comments that only restate syntax, names, or immediately obvious control flow.
+- Add comments for non-obvious business rules, ordering constraints, compatibility behavior, concurrency assumptions, performance tradeoffs, and external API quirks.
+- Check nearby existing comments when behavior changes; stale comments are worse than missing comments.
+- Prefer clearer names, smaller functions, or stronger types over comments that explain avoidable confusion.
 
 ## Verification
 

package/skills/kratos/SKILL.md

@@ -3,7 +3,7 @@ name: kratos
 description: "Supports Go-Kratos microservices, proto/buf APIs, service/biz/data layers, middleware, auth, config, and troubleshooting. Not for generic Go style alone."
 when_to_use: "kratos, Go-Kratos, proto, buf, service layer, biz layer, data layer, middleware, auth, config, Kratos 微服务"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Kratos

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: "Creates bite-sized implementation plans from approved requirements, clarify output, or design specs with exact files, tests, commands, expected output, and execution handoff. Not for unresolved requirements, design decisions, PRD generation, or code changes."
 when_to_use: "plan, implementation plan, execution plan, task breakdown, approved requirements, approved design spec, docs/loopx/design, 实施计划, 执行计划, 任务拆分"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 argument-hint: "<design spec path or feature name>"
 ---
 
@@ -156,13 +156,13 @@ Plan complete and saved to `docs/loopx/plans/<filename>.md`.
 
 Two execution options:
 
-1. Subagent-Driven (recommended) - dispatch a fresh subagent per task, review between tasks, fast iteration
+1. Subagent Exec (recommended) - dispatch a fresh subagent per task, review between tasks, fast iteration
 2. Inline Execution - execute tasks in this session using exec, batch execution with checkpoints
 
 Which approach?
 ```
 
-If Subagent-Driven is chosen:
+If Subagent Exec is chosen:
 
 - REQUIRED SUB-SKILL: Use `loopx:subagent-exec`
 - Fresh subagent per task plus two-stage review

package/skills/refactor-plan/SKILL.md

@@ -3,7 +3,7 @@ name: refactor-plan
 description: "Creates a behavior-preserving refactor plan with user interview, repo evidence, tiny commits, scope boundaries, and testing decisions. Not for feature changes or immediate implementation."
 when_to_use: "refactor-plan, refactor request, refactoring RFC, tiny commits, behavior-preserving cleanup, architecture cleanup, 重构计划"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.

package/skills/review/SKILL.md

@@ -3,7 +3,7 @@ name: review
 description: "Dispatches a loopx code reviewer subagent against a concrete git range and requirements. Not for implementation, planning, or unresolved review scope."
 when_to_use: "request code review, completed task review, major feature review, pre-merge review, subagent code quality check"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Review

package/skills/spec/SKILL.md

@@ -3,7 +3,7 @@ name: spec
 description: "Writes software design specs from already-clarified requirements, including solution approach, architecture outline, detailed design, tradeoffs, verification design, and handoff context. Not for unresolved requirements, PRD generation, implementation task planning, or code changes."
 when_to_use: "spec, design spec, technical design, design proposal, detailed design, architecture design, 设计方案, 概要设计, 详细设计, 技术方案"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # loopx Spec

package/skills/subagent-exec/SKILL.md

@@ -3,7 +3,7 @@ name: subagent-exec
 description: "Executes approved loopx implementation plans with fresh subagents per independent task and staged review. Not for planning, unclear requirements, or tightly coupled edits."
 when_to_use: "approved implementation plan, independent tasks, subagent execution, staged spec review, code quality review, parallel-capable execution"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Subagent Exec

package/skills/subagent-exec/agents/openai.yaml

@@ -1,3 +1,3 @@
 interface:
-  display_name: "Subagent-Driven Development"
-  short_description: "Execute implementation plans with staged subagent reviews"
+  display_name: "Subagent Exec"
+  short_description: "Execute loopx plans with staged subagent reviews"

package/skills/subagent-exec/codex-subagents.md

@@ -17,7 +17,7 @@ Use this reference before executing this skill in Codex.
 
 Subagent dispatch requires Codex multi-agent support. If `spawn_agent`,
 `wait_agent`, or `close_agent` are unavailable, do not pretend this skill ran
-as subagent-driven development. Use `loopx:exec` instead.
+as subagent-exec. Use `loopx:exec` instead.
 
 Codex environments that require explicit feature flags should enable:
 

package/skills/tdd/SKILL.md

@@ -3,7 +3,7 @@ name: tdd
 description: "Guides feature and bugfix implementation through a failing test before production code and red-green-refactor discipline. Not for generated files or throwaway prototypes."
 when_to_use: "tdd, failing test first, feature implementation, bugfix, regression test, red green refactor, 测试先行"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Test-Driven Development (TDD)

package/skills/verify/SKILL.md

@@ -3,7 +3,7 @@ name: verify
 description: "Requires fresh verification evidence before claiming work is complete, fixed, passing, review-ready, or ready to commit. Not for speculative confidence or stale results."
 when_to_use: "verify, completion claim, fixed claim, tests pass, review-ready, commit, fresh evidence, 验证, 完成前检查"
 metadata:
-  version: "0.2.2"
+  version: "0.2.4"
 ---
 
 # Verification Before Completion

package/src/build-stop-gate.mjs

@@ -73,7 +73,7 @@ export function evaluateBuildStopGate(state) {
     const delegationCount = Number.isFinite(Number(state.active_delegation_count)) ? Number(state.active_delegation_count) : null;
     const delegationText = delegationCount !== null ? ` active delegations=${delegationCount}.` : '';
     const auditText = state.completion_audit_status ? ` completion audit: ${state.completion_audit_status}.` : '';
-    const nextAction = state.next_action ? ` next action: ${state.next_action}` : ' next action: continue the contract-covered next step in $build.';
+    const nextAction = state.next_action ? ` next action: ${state.next_action}` : ' next action: continue the contract-covered loopx build step.';
     const completionSignal = state.completion_signal ? ` completion signal: ${state.completion_signal}` : ' completion signal: review handoff readiness, a real blocker, user stop, or a return to plan/clarify.';
     return {
       allow: false,

package/src/cli.mjs

@@ -6,7 +6,7 @@ import { createInterface } from 'node:readline/promises';
 import { archiveStage, autopilotStage, approveStage, buildStage, clarifyStage, initWorkspace, planStage, reviewStage, statusSummary } from './workflow.mjs';
 import { renderHtmlViews } from './html-views.mjs';
 import { installBundledSkills, installSkillsForTargets } from './install-discovery.mjs';
-import { nextSkillCommand, withNextSkill } from './next-skill.mjs';
+import { nextCliCommand, nextSkillCommand, withNextSkill } from './next-skill.mjs';
 import { doctorRuntime, migrateLegacyRuntime } from './runtime-maintenance.mjs';
 import { setupWorkspaceContext } from './workspace-context.mjs';
 
@@ -178,6 +178,10 @@ function printHumanStatus(status) {
   if (nextSkill) {
     console.log(`next skill: ${nextSkill}`);
   }
+  const nextCli = nextCliCommand(status.state);
+  if (nextCli) {
+    console.log(`next cli: ${nextCli}`);
+  }
   console.log(`next: ${status.next_action}`);
 }
 

package/src/install-discovery.mjs

@@ -28,21 +28,10 @@ const LOOPX_SKILLS = [
   'debug',
   'tdd',
   'verify',
+  'doc-readability',
   'go-style',
   'kratos',
 ];
-const LOOPX_LEGACY_SKILLS = [
-  'build',
-  'autopilot',
-  'archive',
-  'writing-plans',
-  'executing-plans',
-  'subagent-driven-development',
-  'requesting-code-review',
-  'receiving-code-review',
-  'finishing-a-development-branch',
-  'request-refactor-plan',
-];
 const LOOPX_INSTALLATION_IDENTITY = 'loopx';
 const LOOPX_MANAGED_SCRIPT_ITEMS = [
   {
@@ -453,20 +442,6 @@ async function removeStaleOwnedInstall(currentRow) {
   await removeInstalledSkill(currentRow.installedPath);
 }
 
-async function pruneLegacyLoopxOwnedSkills(nextData, env = process.env) {
-  const pruned = [];
-  for (const skillName of LOOPX_LEGACY_SKILLS) {
-    const row = nextData.skills?.[skillName];
-    if (!isLoopxOwnedIdentity(skillName, row, env)) {
-      continue;
-    }
-    await removeStaleOwnedInstall(row);
-    delete nextData.skills[skillName];
-    pruned.push({ skillName, installedPath: row.installedPath });
-  }
-  return pruned;
-}
-
 async function removeInstalledFile(path) {
   if (!existsSync(path)) {
     return;
@@ -668,7 +643,6 @@ export async function installBundledSkills(env = process.env, options = {}) {
   const nextData = jsonClone(data);
   nextData.version = nextData.version || 3;
   nextData.skills = nextData.skills || {};
-  const pruned = await pruneLegacyLoopxOwnedSkills(nextData, env);
   const baselinePath = getTemplateBaselinePath(env);
   const existingBaseline = await readTemplateBaseline(baselinePath);
   const baselineItemsByPath = new Map((existingBaseline?.items || []).map((item) => [templateItemKey(item), item]));
@@ -767,7 +741,6 @@ export async function installBundledSkills(env = process.env, options = {}) {
     installed,
     conflicts,
     skipped,
-    pruned,
     templateGovernance,
     inspection: await inspectInstallState(env),
   };

package/src/next-skill.mjs

@@ -2,7 +2,6 @@ export function nextSkillCommand(state) {
   if (!state || !state.slug) {
     return null;
   }
-  const reviewBuildCommand = `$build --from-review .loopx/workflows/${state.slug}/review-report.md`;
   if (state.current_stage === 'clarify'
     && state.clarify_current_round > 0
     && state.unresolved_ambiguity_count === 0
@@ -28,7 +27,7 @@ export function nextSkillCommand(state) {
     return null;
   }
   if (state.current_stage === 'plan' && Array.isArray(state.plan_blockers) && state.plan_blockers.length === 0) {
-    return `$build .loopx/plans/requirements-snapshot-${state.slug}.md`;
+    return `$subagent-exec .loopx/plans/requirements-snapshot-${state.slug}.md`;
   }
   if (state.current_stage === 'build'
     && state.stage_status === 'awaiting-approval'
@@ -48,13 +47,13 @@ export function nextSkillCommand(state) {
       || state.approval?.build === 'requested'
       || state.approval?.build === 'approved'
     )) {
-    return reviewBuildCommand;
+    return null;
   }
   if (state.current_stage === 'review'
     && state.review_verdict === 'request-changes'
     && state.requested_transition === 'review->build'
     && state.approval?.build === 'approved') {
-    return reviewBuildCommand;
+    return null;
   }
   if (state.current_stage === 'review'
     && state.review_verdict === 'request-changes'
@@ -71,20 +70,62 @@ export function nextSkillCommand(state) {
   return null;
 }
 
+export function nextCliCommand(state) {
+  if (!state || !state.slug) {
+    return null;
+  }
+  if (state.stage_status === 'awaiting-approval'
+    && state.current_stage === 'plan'
+    && Array.isArray(state.plan_blockers)
+    && state.plan_blockers.length === 0) {
+    return `loopx build .loopx/plans/requirements-snapshot-${state.slug}.md`;
+  }
+  if (state.current_stage === 'review'
+    && state.review_verdict === 'request-changes'
+    && state.rollback_target === 'build'
+    && (
+      state.pending_user_decision === 'review->build'
+      || state.requested_transition === 'review->build'
+      || state.approval?.build === 'requested'
+      || state.approval?.build === 'approved'
+    )) {
+    return `loopx build --from-review .loopx/workflows/${state.slug}/review-report.md`;
+  }
+  if (state.current_stage === 'review'
+    && state.review_verdict === 'request-changes'
+    && state.requested_transition === 'review->build'
+    && state.approval?.build === 'approved') {
+    return `loopx build --from-review .loopx/workflows/${state.slug}/review-report.md`;
+  }
+  return null;
+}
+
 export function nextSkillHint(state) {
   const command = nextSkillCommand(state);
   if (!command) {
     return null;
   }
-  return `Next: ${command}`;
+  return `Next skill: ${command}`;
+}
+
+export function nextCliHint(state) {
+  const command = nextCliCommand(state);
+  if (!command) {
+    return null;
+  }
+  return `Next CLI: ${command}`;
 }
 
 export function withNextSkill(payload, state) {
   const nextCommand = nextSkillCommand(state);
   const nextHint = nextSkillHint(state);
+  const cliCommand = nextCliCommand(state);
+  const cliHint = nextCliHint(state);
   return {
     ...payload,
     next_skill_command: nextCommand,
     next_skill_hint: nextHint,
+    next_cli_command: cliCommand,
+    next_cli_hint: cliHint,
   };
 }