Loop Me — Experimental

What it does

Loop Me explores how a person repeatedly performs work before choosing automation. The experimental source records what is learned about the user in NOTES.md and develops individual workflow specifications under workflows/. It distinguishes event-driven work from scheduled work and asks where a human should re-enter. A checkpoint should come late enough that the user reviews a concrete brief or result rather than a vague plan. The skill deliberately avoids forcing AI, a timer or an approval step into every workflow. Its output is a specification an implementer can use, rather than a running scheduler.

When to use it

• Specify a recurring editorial review without confusing draft preparation with publication.
• Describe support triage that starts from an incoming request rather than a clock.
• Decide which parts of a weekly reporting routine require judgment and which are deterministic.

Step-by-step workflow

1. Describe an actual recent run, including inputs, tools, decisions and the final artifact.
2. Ask focused questions about repetition, exceptions, data boundaries and who owns the outcome.
3. Choose an event or schedule only when it fits how the work really begins.
4. Define each human checkpoint around a concrete result and describe what happens after rejection or missing data.
5. Save the workflow specification and user notes, then identify any unanswered implementation questions before calling the design complete.

Example request

Use loop-me to specify our weekly release-note preparation. Interview me about one recent release. Record the source of merged changes, exclusions, editor review and where the final draft belongs. Do not assume publication is authorized. Define what happens when the changelog is empty or a linked issue is unavailable. Finish with a workflow another engineer can implement without guessing.

Worked example

A weekly release-note routine might initially sound like a Friday timer. The interview discovers that releases actually happen after a signed tag, so the trigger becomes that event. The draft includes linked changes and unresolved customer-facing wording, giving the editor a concrete checkpoint. A rejection returns the draft for revision; it does not trigger another public post. An empty release produces an explicit no-content outcome. These decisions make the specification useful before any scheduler or AI service is selected.

What you get

Workflow Markdown files with triggers, inputs, decisions, checkpoints and completion conditions, plus accumulated user-context notes.

How to evaluate the result

• A reader can identify the trigger and the exact delivered artifact.
• Missing input, rejection and duplicate-event behavior have explicit outcomes.
• No publication or other external action is silently inferred from drafting permission.

What you need

A user who knows the recurring work, representative inputs and permission to write specifications in an agreed location. An implementation runtime is chosen later.

Setup and activation

Experimental source: this folder is under skills/in-progress and is not a stable-release recommendation. Its frontmatter disables automatic model invocation, so explicitly select it in a host that supports that behavior. This directory reviewed source only; it did not install or execute the skill. Before adopting it, scan the exact version, inspect requested tools and permissions, and test on disposable non-sensitive inputs. A compatible instruction format does not establish identical host capabilities.

Limits and considerations

Experimental interviewing guidance does not deploy integrations or guarantee automation is appropriate. User notes can contain sensitive operational context; agree what is safe to retain. An incomplete interview should remain an incomplete specification.

Related workflows

• Use software-factory vocabulary when the workflow is a ticket-to-code system.
• Use a separate implementation plan after the workflow’s unresolved decisions are settled.

License and reuse

MIT at repository level. Preserve copyright and license notices; check companion files and external dependencies for their own terms.

Further reading

• Publisher setup and compatibility instructions
• Reviewed source at immutable commit