slop-refinery-pipeline

Files (2)

• LICENSE
• SKILL.md

SKILL.md (first lines)

Execute this pipeline for the supplied feature:

1. Prepare the issue and PR:
    1. Create an appropriately named feature branch.
    2. Create and push an empty commit with the exact message `Initial empty commit to open PR`.
    3. Open a draft PR using the unchanged PR template as the verbatim starting text of its first comment.
    4. Use the supplied GitHub issue, reuse an existing matching issue, or create one from the feature description.
    5. Link the issue in the PR's Development section so merging closes it.
2. Execute the pipeline sequentially. Allow human interaction only for initial deliberation, implementation permission, findings deliberation, and final readiness permission. After implementation is authorized, work autonomously through step 2.3, pause for step 2.4, then complete step 2.5 autonomously before requesting final readiness permission; use best judgment, complete all unblocked work, check each completed PR checkbox, and use those checkboxes to recover progress.
    1. Deliberate with the human until the problem and an irreducibly simple implementation plan are sufficiently defined. Explicitly agree on every changed or introduced seam, interface, and API, especially exposed HTTP endpoints and database tables.
    2. With explicit human permission, implement the feature completely, then commit and push all changes.
    3. Run the following thirteen analyses in parallel, each in a fresh, context-independent subagent over the entire current branch change set, including uncommitted changes. Give each subagent the feature intent, change scope, repository instructions, and only its assigned analysis; it must not edit files, change Git or PR state, or see another subagent's work, and must report evidence, findings, recommendations, test results, and blockers to the main orchestrator. Use isolated transient test state where concurrent testing could interfere.
        1. **Backward compatibility:** Report every definite or possible mechanism preserving an old interface, behavior, schema, format, version, or implementation path, with evidence for human review; do not propose or make changes.
        2. **Manual testing:** Exercise every materially affected workflow through its real interface under realistic success, boundary, invalid-input, failure, permission, persistence, accessibility, viewport, and integration scenarios; assess end-to-end behavioral correctness and report evidence and defects.
        3. **Automated testing:** Run proportionate tests and identify missing coverage, defaulting recommendations to meaningful property-based or model-based tests with independent properties and supplementing them with examples, integration tests, or end-to-end tests where those provide distinct evidence. Do not run mutation testing or recommend changes to mutation-testing configuration.
        4. **System design irreducible simplicity:** Identify requirements, behaviors, concepts, workflows, states, data models, seams, interfaces, and dependencies that can be removed or merged while preserving the feature's essential purpose and integrity constraints; assess the system design rather than the code that implements it.
        5. **Implementation irreducible simplicity:** Given the feature's current system design, identify unnecessary code, state, branches, layers, dependencies, duplication, and indirection that can be removed while preserving every requirement and integrity constraint; assess the implementation rather than redesigning the feature.
        6. **Edge cases:** Identify all practical edge cases across inputs, state transitions, timing, concurrency, permissions, persistence, failures, retries, integrations, and resource limits, and verify each is handled or mitigated. Report technically possible cases whose mitigation may be impractical or disproportionate with evidence, likelihood, impact, current safeguards, and trade-offs for human deliberation.
        7. **Declarativeness:** Identify where intended rules, relationships, and outcomes could be expressed more directly through language, framework, schema, or data constructs.
        8. **Modularity:** Assess module cohesion, public surfaces, dependencies, boundary leaks, cycles, shared state, broad interfaces, and unnecessary coupling.
        9. **Immutability:** Identify state changes that could be more explicit, local, and predictable through immutable data flow or smaller mutation boundaries.
        10. **Abstractness:** Identify duplication, leakage, premature generalization, pass-through layers, and indirection that fails to capture a stable concept or hides essential behavior.
        11. **Performance:** Inspect affected paths under realistic load for practical latency, throughput, memory, I/O, query, rendering, serialization, concurrency, and unbounded-work risks, measuring when magnitude affects the finding.
        12. **Security:** Trace trust boundaries and abuse paths, checking authentication, authorization, isolation, validation, injection, secrets, data exposure, dependencies, logging, failures, and resource exhaustion.
        13. **Frontend UI/UX:** When the change set has user-visible graphical impact, inspect every materially affected interface and state in the real rendered application, not source code alone. Capture visual evidence at the minimum supported width, representative compact and large phones, portrait and landscape tablets, and desktop, plus immediately below and above every affected responsive breakpoint and through a continuous resize sweep across the supported range; emulate touch for phones and tablets. Against the product's established design language, assess visual hierarchy, typography, color and contrast, spacing and density, responsive adaptation, clipping, overlap, overflow, component consistency, loading, empty, error, success, dense, and post-interaction states, touch targets, hover independence, scrolling, gestures, focus and virtual-keyboard behavior, safe areas, dynamic viewport and orientation behavior, motion, feedback, and navigation; require a polished, cohesive experience that feels native to phone and tablet form factors rather than like scaled-down desktop UI. Report tested viewport and state combinations, evidence, defects, exclusions, and blockers; when no graphical interface is affected, report not applicable with change-set evidence.

        After all reports return, the main orchestrator must validate and adjudicate them, implement what it judges best, directly validate its changes, and commit and push. The orchestrator alone determines which findings are consequential subjective matters for step 2.4, but must carry every backward-compatibility finding and every edge-case finding whose mitigation may be impractical or disproportionate into that step without implementing it.

    4. Record and deliberate with the human on every consequential subjective finding, blocker, backward-compatibility finding, and edge-case finding whose mitigation may be impractical or disproportionate:
        1. Create or update one `## Human Review Findings` section at the end of the PR description; do not create a repository findings file, and write `No findings require human review.` when none exist.
        2. Represent each finding as an unchecked `- [ ] **<title>**` task containing its review area, affected code, evidence, consequence, implemented resolution or blocker, material alternatives and trade-offs, and the decision or confirmation needed.
        3. Never check a finding for the human. On reruns, preserve human checkbox states and notes, add new findings unchecked, and explain rather than delete findings that no longer apply.
    5. Perform final checks: Fetch and integrate fresh `origin/main`, verify the branch is zero commits behind, and audit the diff, committed paths, and untracked files for unrelated lockfiles, unnecessary Markdown specifications, logs, generated or local artifacts, and sensitive data. Verify new migrations are chronologically after base migrations, replay cleanly, upgrade production-like data safely, avoid unintended destruction, and can perform any intentional destruction under enforced production preconditions; restore any weakening of lint or test enforcement relative to the base, run every required check, refetch the base, restart if it advanced, and commit and push any final fixes.
    6. With explicit human permission, convert the PR from draft to ready and enable auto-merge.

From HOWMZofficial/slop-refinery, MIT.

More from HOWMZofficial/slop-refinery