@ai-content-space/loopx 0.1.10 → 0.2.1

package/skills/ai-slop-cleaner/SKILL.md

@@ -1,114 +0,0 @@
----
-name: ai-slop-cleaner
-description: Run an anti-slop cleanup/refactor/deslop workflow
----
-
-# AI Slop Cleaner Skill
-
-Reduce AI-generated slop with a regression-tests-first, smell-by-smell cleanup workflow that preserves behavior and raises signal quality.
-
-## When to Use
-
-Use this skill when:
-- A code path works but feels bloated, noisy, repetitive, or over-abstracted
-- A user asks to “cleanup”, “refactor”, or “deslop” AI-generated output
-- Follow-up implementation left duplicate code, dead code, weak boundaries, missing tests, or unnecessary wrapper layers
-- You need a disciplined cleanup workflow without broad rewrites
-
-## GPT-5.4 Guidance Alignment
-
-- Keep outputs concise and evidence-dense unless risk or the user requests more detail.
-- Treat newer user instructions as local workflow updates without discarding earlier non-conflicting constraints.
-- Keep using inspection, tests, diagnostics, and verification until the cleanup is grounded.
-- Proceed automatically through clear, reversible cleanup steps; ask only when a choice materially changes scope or behavior.
-
-## Scoped File Lists and Ralph Workflow
-
-- This skill can accept a **file list scope** instead of a whole feature area.
-- When the caller provides a changed-files list (for example, Ralph session-owned edits), keep the cleanup strictly bounded to those files.
-- In the **Ralph workflow**, the mandatory deslop pass should run this skill on Ralph's changed files only, in standard mode unless the caller explicitly requests otherwise.
-
-## Procedure
-
-1. **Lock behavior with regression tests first**
-   - Identify the behavior that must not change
-   - Add or run targeted regression tests before editing cleanup candidates
-   - If behavior is currently untested, create the narrowest test coverage needed first
-
-2. **Create a cleanup plan before code**
-   - List the specific smells to remove
-   - Bound the pass to the requested files/scope
-   - If a file list scope is provided, keep the pass restricted to that changed-files list
-   - Order fixes from safest/highest-signal to riskiest
-   - Do not start coding until the cleanup plan is explicit
-
-3. **Categorize issues before editing**
-   - **Duplication** — repeated logic, copy-paste branches, redundant helpers
-   - **Dead code** — unused code, unreachable branches, stale flags, debug leftovers
-   - **Needless abstraction** — pass-through wrappers, speculative indirection, single-use helper layers
-   - **Boundary violations** — hidden coupling, leaky responsibilities, wrong-layer imports or side effects
-   - **Missing tests** — behavior not locked, weak regression coverage, gaps around edge cases
-
-4. **Execute passes one smell at a time**
-   - **Pass 1: Dead code deletion**
-   - **Pass 2: Duplicate removal**
-   - **Pass 3: Naming/error handling cleanup**
-   - **Pass 4: Test reinforcement**
-   - Re-run targeted verification after each pass
-   - Avoid bundling unrelated refactors into the same edit set
-
-5. **Run quality gates**
-   - Regression tests stay green
-   - Lint passes
-   - Typecheck passes
-   - Relevant unit/integration tests pass
-   - Static/security scan passes when available
-   - Diff stays minimal and scoped
-   - No new abstractions or dependencies unless explicitly required
-
-6. **Finish with an evidence-dense report**
-   - Changed files
-   - Simplifications made
-   - Tests/diagnostics/build checks run
-   - Remaining risks
-   - Residual follow-ups or consciously deferred cleanup
-
-## Output Format
-
-```text
-AI SLOP CLEANUP REPORT
-======================
-
-Scope: [files or feature area]
-Behavior Lock: [targeted regression tests added/run]
-Cleanup Plan: [bounded smells and order]
-
-Passes Completed:
-1. Pass 1: Dead code deletion - [concise fix]
-2. Pass 2: Duplicate removal - [concise fix]
-3. Pass 3: Naming/error handling cleanup - [concise fix]
-4. Pass 4: Test reinforcement - [concise fix]
-
-Quality Gates:
-- Regression tests: PASS/FAIL
-- Lint: PASS/FAIL
-- Typecheck: PASS/FAIL
-- Tests: PASS/FAIL
-- Static/security scan: PASS/FAIL or N/A
-
-Changed Files:
-- [path] - [simplification]
-
-Remaining Risks:
-- [none or short deferred item]
-```
-
-## Scenario Examples
-
-**Good:** The user says `continue` after tests already lock behavior and the next smell pass is clear. Continue with the next bounded cleanup pass.
-
-**Good:** The user narrows the scope to a specific file after planning. Keep the regression-tests-first workflow, but apply the new scope locally.
-
-**Bad:** Start rewriting architecture before protecting behavior with tests.
-
-**Bad:** Collapse multiple smell categories into one large refactor with no intermediate verification.

package/skills/archive/SKILL.md

@@ -1,55 +0,0 @@
----
-name: archive
-description: "Archives an approved loopx change delta into long-lived specs and writes an ADR candidate after done approval. Not for active builds or unapproved reviews."
-when_to_use: "archive, done workflow, spec delta, long-lived specs, ADR candidate, review approved, 归档, 同步规格"
-metadata:
-  version: "0.1.10"
-argument-hint: "<workflow slug>"
----
-
-# loopx Archive
-
-## Purpose
-
-Use `archive` after a loopx workflow has reached `done`, or immediately after an approved review that is waiting for `review -> done` completion. It syncs the accepted change delta into long-lived `.loopx/specs/` files, archives the change staging directory, and writes an advisory ADR candidate.
-
-The accepted delta is requirement-based, not a changelog block. Archive applies:
-
-- `## ADDED Requirements`
-- `## MODIFIED Requirements`
-- `## REMOVED Requirements`
-- `## RENAMED Requirements`
-
-into the current long-lived `## Requirements` state for each target domain.
-
-## Inputs
-
-- `<workflow slug>` for a completed loopx workflow, or for a review-approved workflow whose next route is `done`
-
-## Behavior
-
-Run:
-
-```bash
-loopx archive <slug>
-```
-
-If review already approved the workflow and the only pending transition is `review -> done`, this command consumes that completion transition before archiving. Do not ask the user to run a separate `loopx approve <slug> --from review --to done` command in that case.
-
-Then report in Chinese:
-
-- whether the change was archived
-- whether `review -> done` was consumed by archive
-- which long-lived spec files were updated
-- the archived change path
-- the ADR candidate path, if written
-- any blocker if the workflow is not done, the spec delta is incomplete, or the execution record still declares partial scope
-
-## Boundaries
-
-- Do not run archive before review has approved the workflow and routed it to `done`.
-- Do not archive malformed requirement deltas. ADDED and MODIFIED entries must use `### Requirement:`, SHALL/MUST language, and at least one `#### Scenario:`.
-- Do not archive when `execution-record.md` declares non-empty `remaining_scope`, `completion_claim` other than `full`, or a mismatch between `planned_scope` and `implemented_scope`; route back to build/plan instead.
-- Do not edit implementation code.
-- Do not promote ADR candidates into `docs/adr/` automatically; report the candidate path for human follow-up.
-- Do not treat `loopx status` as a user-facing skill. Use status only as a runtime diagnostic when needed.

package/skills/autopilot/SKILL.md

@@ -1,93 +0,0 @@
----
-name: autopilot
-description: "Runs one bounded autonomous loopx orchestration over clarify, plan, build, and review while preserving canonical artifacts. Not for manual gate-by-gate control."
-when_to_use: "autopilot, autonomous loopx run, end-to-end workflow, run all stages, bounded orchestration, 自动执行, 全流程"
-metadata:
-  version: "0.1.10"
-argument-hint: "<workflow slug>"
----
-
-# loopx Autopilot
-
-<Purpose>
-`autopilot` is loopx's autonomous orchestration surface. It upgrades the current bounded composition model by adding richer internal phases while keeping loopx's public stage model authoritative.
-
-Externally, the user still reasons about:
-
-- `clarify`
-- `plan`
-- `build`
-- `review`
-
-Internally, `autopilot` may orchestrate richer phases such as expansion, planning, execution, QA, and validation.
-</Purpose>
-
-<Use_When>
-- One owner wants loopx to run end-to-end with internal autonomous orchestration.
-- A clarified or workflow-local spec already exists, or the workflow is ready to begin from loopx stages.
-- The task benefits from richer internal planning/execution/QA/validation behavior without exposing a more complex public stage surface.
-</Use_When>
-
-<Do_Not_Use_When>
-- The user wants manual control over each stage gate.
-- The task should stop after planning or execution rather than run end-to-end.
-- Requirements are too ambiguous for bounded autonomous orchestration.
-</Do_Not_Use_When>
-
-<Core_Principles>
-- loopx public stage truth remains authoritative.
-- Richer internal phases are allowed, but they stay internal.
-- Internal stage approvals may be auto-consumed and must be recorded as control events.
-- Canonical loopx artifacts remain the source of truth; `run.json` is an orchestration ledger.
-- Reuse strengthened loopx stage runtimes rather than re-implementing contradictory truths.
-</Core_Principles>
-
-<Internal_Phases>
-Suggested internal phase model:
-
-- `expansion`
-- `planning`
-- `execution`
-- `qa`
-- `validation`
-
-Phase-to-stage alignment:
-
-- `expansion` -> clarified-spec reuse or clarify preparation
-- `planning` -> loopx `plan`
-- `execution` + `qa` -> loopx `build`
-- `validation` -> pre-review validation plus loopx `review`
-</Internal_Phases>
-
-<Control_Plane>
-- one autopilot invocation authorizes one bounded autopilot run
-- autopilot may internally consume stage approvals for:
-  - `clarify -> plan`
-  - `plan -> build`
-  - `build -> review`
-  - `review -> done`
-- these decisions must be recorded as internal control events
-</Control_Plane>
-
-<Artifact_Contract>
-Canonical stage artifacts remain authoritative:
-
-- clarify spec artifacts
-- `.loopx/plans/prd-<slug>.md`
-- `.loopx/plans/test-spec-<slug>.md`
-- canonical build `execution-record.md`
-- canonical review `review-report.md`
-
-Autopilot also writes an orchestration ledger:
-
-- `.loopx/autopilot/<slug>/run.json`
-
-`run.json` may include internal phase progression, blockers, and control events, but it must not replace canonical stage artifacts as the source of truth.
-</Artifact_Contract>
-
-<Must_Not_Decide_Automatically>
-- do not create a new public stage family
-- do not bypass loopx canonical artifacts
-- do not fork a second workflow truth that contradicts loopx stages
-- do not literally port the parent autopilot where it conflicts with loopx runtime contracts
-</Must_Not_Decide_Automatically>

package/skills/autoresearch/SKILL.md

@@ -1,68 +0,0 @@
----
-name: autoresearch
-description: Stateful validator-gated research loop with native-hook persistence
----
-
-# Autoresearch
-
-Autoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.
-It keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.
-
-## Use when
-- You want a Ralph-ish persistent research loop
-- The task should keep nudging until explicit validation evidence exists
-- You want init-time choice between script validation and prompt+architect validation
-
-## Do not use when
-- You want the old `omx autoresearch` command surface (hard-deprecated)
-- You want detached tmux or split-pane launch parity
-- You have not decided the validation regime yet
-
-## Core contract
-1. **Init chooses validation mode.** Pick exactly one:
-   - `mission-validator-script`
-   - `prompt-architect-artifact`
-2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:
-   - `validation_mode`
-   - `completion_artifact_path`
-   - `mission_validator_command` **or** `validator_prompt`
-   - optional `output_artifact_path`
-3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.
-4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.
-
-## Completion artifact contract
-
-### `mission-validator-script`
-The completion artifact must exist and record a passing validator result, for example:
-
-```json
-{
-  "status": "passed",
-  "passed": true,
-  "summary": "metric improved beyond baseline"
-}
-```
-
-### `prompt-architect-artifact`
-The completion artifact must include both an architect approval verdict and an output artifact path, for example:
-
-```json
-{
-  "validator_prompt": "Review the research output against the mission.",
-  "architect_review": { "verdict": "approved" },
-  "output_artifact_path": ".omx/specs/autoresearch-demo/report.md"
-}
-```
-
-## Recommended flow
-1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.
-2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.
-3. Start `$autoresearch` with the chosen validation mode stored in mode state.
-4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.
-5. Finish only after the validator artifact is complete.
-
-## Migration note
-- `omx autoresearch` is hard-deprecated.
-- No direct CLI launch.
-- No tmux split-pane launch.
-- No noop-count completion gate.

package/skills/build/SKILL.md

@@ -1,228 +0,0 @@
----
-name: build
-description: "Executes an approved loopx plan or review rework contract with evidence, verification, deslop, and regression gates. Not for unclear requirements or independent review."
-when_to_use: "build, implement approved plan, execute PRD, --from-review, review rework, implementation fixes, 执行, 实现, 修改"
-metadata:
-  version: "0.1.10"
-argument-hint: "[--no-deslop] <approved PRD path or workflow slug> | --from-review <review artifact path>"
----
-
-# loopx Build
-
-<Purpose>
-`build` is loopx's canonical execution lane. It executes an approved plan with Ralph-style rigor while keeping the public loopx stage surface unchanged.
-
-By default, `build` is not a one-shot draft writer. It is a persistence loop with internal parallel lanes, fresh verification, architect gating, deslop, and regression re-verification before `review` can start.
-</Purpose>
-
-<Use_When>
-- `plan -> build` has already been explicitly approved.
-- `review -> build` was requested for implementation fixes and a review artifact is supplied with `--from-review`.
-- Canonical plan artifacts already exist and execution should now proceed.
-- The task needs execution persistence, verification evidence, and explicit pre-review quality gates.
-</Use_When>
-
-<Do_Not_Use_When>
-- Requirements or planning are still incomplete.
-- The user wants to skip execution and only review or inspect the plan.
-- A valid build run is already review-ready and the next action is `review`.
-</Do_Not_Use_When>
-
-<Core_Principles>
-- Public surface stays `build`; internal strength can still match Ralph-style execution.
-- Execution may parallelize internally without exposing a public `team` stage.
-- `build` does not replace `review`.
-- `execution-record.md` remains the sole canonical execution and verification artifact.
-- `.loopx/config.json` is supporting context for existing project AI rules, existing spec sources, and discovered verification commands; use it to preserve local sources of truth, not to skip loopx stages.
-- Feature work and bug fixes should use `tdd`: write a failing test, confirm it fails for the intended reason, then implement the smallest passing change.
-- Bug, test-failure, build-failure, and unexpected-behavior work should use `debug` before proposing fixes.
-- Completion and review-ready claims should use `verify` before they are stated.
-- Go edits should use `go-style` and preserve local repository conventions.
-- Go-Kratos work should use `kratos` when Kratos project signals or Kratos-specific tasks are present.
-- Fresh evidence is required before review handoff.
-- Deslop and regression re-verification are part of the default build path.
-- `build` has one owner for persistence. Delegation may run in parallel, but the owner remains accountable for draining delegated work and proving completion before review handoff.
-</Core_Principles>
-
-<Preconditions>
-For initial execution, `build` starts only when all of the following are true:
-
-- approved `plan -> build` transition exists
-- `.loopx/plans/prd-<slug>.md` exists
-- `.loopx/plans/test-spec-<slug>.md` exists
-- workflow-local planning artifacts required by the execution lane exist
-
-For review-requested implementation fixes, `build` may instead start from:
-
-- `$build --from-review .loopx/workflows/<slug>/review-report.md`
-- or `$build --from-review .loopx/workflows/<slug>/review.md`
-
-In that mode, the review artifact is the direct rework contract. The approved PRD, test spec, previous execution record, and workflow-local plan package remain required context, but they are not the primary user-facing argument.
-</Preconditions>
-
-<Inputs>
-Preferred skill input:
-
-- `.loopx/plans/prd-<slug>.md`
-
-Preferred review rework input:
-
-- `--from-review .loopx/workflows/<slug>/review-report.md`
-
-Compatible skill / CLI input:
-
-- `<slug>`
-
-When invoked with a PRD path, derive `<slug>` from `prd-<slug>.md` and still use the matching workflow-local plan package and test spec.
-
-When invoked with `--from-review`, derive `<slug>` from the workflow directory, treat the review artifact as the implementation-fix contract, and load the matching PRD, test spec, previous `execution-record.md`, and workflow-local plan package as supporting context. This Codex skill invocation consumes the `review -> build` rework intent; users should not need a separate bash `loopx approve ... --from review --to build` step for the normal Codex-facing flow.
-
-Also load `.loopx/config.json` when present. Its `project_conventions` entries identify existing project rule/spec files that should be preserved, and its `verification_commands` entries are the first project-native commands to consider for fresh evidence.
-</Inputs>
-
-<Execution_Model>
-`build` should behave like a Ralph-style execution runtime:
-
-1. Initialize or resume build iteration state.
-2. If running from `--from-review`, load the review artifact first and constrain implementation work to the requested implementation fixes unless the review artifact exposes a real plan or clarify blocker.
-3. Run internal execution / evidence / verification lanes in parallel.
-4. For implementation work, apply `tdd` unless the approved plan explicitly classifies the change as non-behavioral or test-inapplicable.
-5. For failures discovered during execution or verification, apply `debug` before attempting fixes.
-6. For `.go` edits, apply `go-style`; for Kratos API/service/biz/data work, apply `kratos` before changing framework structure.
-7. Aggregate lane results into canonical `execution-record.md`.
-8. Run fresh verification and read actual output using `verify` discipline.
-9. Run architect verification as a hard pre-review gate.
-10. Run deslop on build-owned changes.
-11. Re-run regression verification after deslop.
-12. Write/update the build delegation ledger and ensure blocking delegated work is drained.
-13. Write/update the completion audit mapping approved plan, slices, and review rework inputs to evidence.
-14. Stop only when review handoff gates are satisfied or a real blocker remains.
-
-`build` may persist support artifacts for runtime inspection, but they must not replace `execution-record.md`.
-</Execution_Model>
-
-<Continuation_Discipline>
-`build` is a persistence loop, not a "one phase per invocation" runner.
-
-If approved plan work remains, continue executing within the same `$build` invocation until either review handoff gates are satisfied or a real blocker prevents further progress.
-
-The following are **not** real blockers by themselves:
-
-- a planned phase is unfinished
-- a runtime adapter is not fully migrated yet
-- store-layer branches still need to be moved to the new service/client path
-- more files remain in the approved implementation scope
-- verification has not been rerun after the latest edits
-
-Those are remaining execution work. Keep working them down.
-
-A real blocker must identify why execution cannot safely continue now, such as:
-
-- missing human product/architecture decision that is not specified by the approved plan
-- unavailable credential, service, fixture, dependency, or environment that cannot be mocked or bypassed responsibly
-- verification failure caused by a pre-existing repository condition that blocks evaluating this change and cannot be isolated
-- repeated implementation failure after the build iteration budget is exhausted
-- a conflict between the approved plan and current repository facts that requires re-planning
-
-Do not end a build response with "continue in the next build" for unfinished approved work. If work remains and no real blocker exists, keep executing. If a real blocker exists, name the concrete blocker and record it in `execution-record.md`.
-</Continuation_Discipline>
-
-<Runtime_State_Machine>
-`build` should track at minimum:
-
-- `build_run_id`
-- `build_current_iteration`
-- `build_max_iterations` (default `10`)
-- `build_parallel_mode`
-- `build_lane_statuses`
-- `build_verification_status`
-- `build_architect_verification_status`
-- `build_deslop_status`
-- `build_regression_status`
-- `build_blockers`
-- `build_progress_artifact_paths`
-- `build_support_evidence_paths`
-- `build_owner_id`
-- `build_owner_session_id`
-- `build_owner_status`
-- `build_delegation_status`
-- `build_delegation_ledger_path`
-- `build_active_delegation_count`
-- `build_completion_audit_status`
-- `build_completion_audit_path`
-- `execution_record_status`
-
-`build -> review` is blocked until:
-
-- all internal lanes are complete
-- fresh verification passes
-- architect verification is approved
-- deslop is complete, unless explicitly skipped
-- post-deslop regression passes
-- blocking delegated build work is drained
-- completion audit passes
-- `execution-record.md` is complete
-</Runtime_State_Machine>
-
-<Artifact_Contract>
-Canonical artifact:
-
-- `execution-record.md`
-
-`execution-record.md` must make the completion scope explicit when a plan is larger than the current implementation slice:
-
-- `planned_scope`: the approved PRD/workflow scope being measured.
-- `implemented_scope`: the scope actually completed in this build run.
-- `remaining_scope`: empty only when the approved workflow scope is fully implemented.
-- `completion_claim`: use `full` only when the whole approved workflow is complete; use `slice` or another non-full value for partial implementation.
-
-If `remaining_scope` is non-empty or `completion_claim` is not `full`, build may still hand off for slice review, but review/archive must not treat that as full workflow completion.
-
-Support artifacts may exist for:
-
-- iteration progress
-- lane evidence summaries
-- architect gate summaries
-- deslop summaries
-- regression summaries
-- `build-support/delegation-ledger.json`
-- `build-support/completion-audit.json`
-
-These support artifacts are runtime aids only. They must not become new canonical review inputs.
-</Artifact_Contract>
-
-<Review_Boundary>
-- build-internal architect verification is an execution-quality gate
-- review remains the final independent stage
-- review continues to own provenance checks, evidence completeness checks, completion/rollback decisions, and code-review
-</Review_Boundary>
-
-<Final_Response_Contract>
-When `build` reaches review handoff readiness, the final response must include an explicit next skill command using the execution record path:
-
-Default review handoff after build readiness:
-
-```text
-Next:
-$review .loopx/workflows/<slug>/execution-record.md
-```
-
-If the user needs the CLI/runtime-debug form, use:
-
-```bash
-loopx review <slug>
-```
-
-Do not end with prose-only guidance such as "next step should enter review" when the workflow is ready for review. Do not emit `$review <slug>` as the primary skill handoff when the execution record path is known. If review handoff is blocked, state the blocker instead of emitting a `$review` command.
-</Final_Response_Contract>
-
-<Flags>
-- `--no-deslop`: skip the deslop pass and the post-deslop regression loop, while still requiring the latest successful pre-deslop verification evidence
-</Flags>
-
-<Must_Not_Decide_Automatically>
-- do not self-approve review
-- do not mark the workflow complete
-- do not replace `execution-record.md` with support artifacts
-- do not widen execution into public `team`, `ultrawork`, or `ralph` command surfaces
-</Must_Not_Decide_Automatically>