← ClaudeAtlas

loom-incremental-implementationlisted

Use when non-trivial ticket or plan execution needs bounded implementation slices, sequencing, multiple-file/record changes, feature flags, refactor/behavior separation, worker handoff, evidence, and continuation state; not for unshaped asks with unresolved scope, system-shape, data-model, state, or coherence choices.
z3z1ma/agent-loom · ★ 15 · Data & Documents · score 78
Install: claude install-skill z3z1ma/agent-loom
# loom-incremental-implementation Incremental implementation is a playbook for executing one narrow slice at a time. It keeps each change bounded, verifiable, and recoverable through tickets, ticket-owned Ralph runs, evidence, audit, and retrospective follow-up. ## Loom Routing Common routes use these Loom skills for durable records or follow-up workflow: `loom-tickets`, `loom-ralph`, `loom-evidence`, `loom-audit`, `loom-plans`, `loom-retrospective`, and `loom-knowledge`. Follow any named Loom skill fully. This playbook adds workflow pressure; it does not shorten target-skill requirements. This workflow does not replace ticket scope, evidence, or audit. Execute only ticket-ready slices, and run delegated slices through ticket-owned Ralph runs. Do not use this playbook to turn a fuzzy ask into implementation. If the current input is not an active ticket or a concrete plan execution unit, stop and return to outer-loop shaping, `loom-idea-refine`, `loom-specs`, `loom-plans`, or `loom-tickets` before changing files. Implementation begins only after scope, system-shape, data-model, state, evidence, and coherence choices are concrete enough for the slice. ## Use This Playbook When Use this playbook when: - implementing a non-trivial ticket - a plan has child tickets that must land in a safe sequence - a change touches multiple files or records - a feature should be built behind a flag or safe default - refactor and behavior work need to stay separate - a ticket-owned work