feat(loop-me): v0.1.0 — workflow-spec design gate adapted from mattpocock/skills @ 84fdeffd (done-when-implementer-asks-no-questions + independent check)

README.md

@@ -116,6 +116,7 @@ an explicit `adapted-from` marker in its frontmatter.
 | `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — family collapsed to one skill (pi hides `disable-model-invocation` wrappers) |
 | `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — divergent phase, visual-companion dropped |
 | `diagnosing-bugs` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) + superpowers 6.2.0 concepts (Iron Law, red flags) |
+| `loop-me` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — workflow-spec design gate |
 | `writing-skills` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — TDD-for-skills core + ideya 8 self-skill-authoring |
 | all other `skills/*` | `author: ours` |
 

README.ru.md

@@ -86,6 +86,7 @@ bash scripts/build.sh caveman          # один
 | `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — семейство схлопнуто в один скил (pi прячет `disable-model-invocation` обёртки) |
 | `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — расходящаяся фаза, visual-companion выброшен |
 | `diagnosing-bugs` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) + superpowers 6.2.0 (Iron Law, red flags) |
+| `loop-me` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — дизайн-гейт workflow-спец |
 | `writing-skills` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — TDD-for-skills ядро + идея 8 self-skill-authoring |
 | остальные `skills/*` | `author: ours` |
 

skills/loop-me/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: loop-me
+adapted-from: mattpocock/skills @ 84fdeffd12f2ee307994d1eb6feb48173b6e0502 (MIT)
+version: 0.1.0
+description: >
+  Design workflow specs for recurring patterns worth delegating — a stateful
+  grilling session whose only output is workflow specs. Trigger (user):
+  «спроектируй workflow», «опиши мои повторяющиеся процессы», «что у меня
+  можно делегировать», «специфицируй процесс», "design a workflow", "loop me",
+  "what can I delegate". Differs from grilling: grilling sharpens an existing
+  plan/decision (convergence); loop-me finds + fully specifies recurring
+  processes (workflow specs) until an implementer could build them without a
+  single question.
+---
+
+# Loop me
+
+Design **workflow specs** for the recurring patterns in the user's life that
+are worth **delegating** — to an agent, a poller, a script, another person.
+Run the grilling discipline (relentless, a round of questions at a time, a
+recommended answer attached to each) aimed at the vocabulary and goal below.
+
+The session is done when every workflow spec meets the **definition of done**
+— nothing is done while a question remains.
+
+## The loop lens
+
+A **loop** is a recurring pattern in the user's life: their career, their
+week, their morning, a single repeated activity. Picturing a life as loops
+within loops reveals how predictable its activities really are — which is what
+makes them worth delegating. Use the lens to find loops worth specifying, and
+propose ones the user hasn't noticed.
+
+A **workflow** is the spec of one loop, made real. You run a workflow on a
+loop — the loop is its running instantiation.
+
+**Ask about the user's world first** (tools, channels, terminology, frequency,
+pain points) before specifying anything. Sharpened fuzzy terms into canonical
+ones as they surface, and record them.
+
+## Vocabulary
+
+A shared language, reached for only when a workflow calls for it — never a
+checklist. **Mandate nothing structural**: a workflow needs no AI, no
+checkpoint, and no schedule unless the grilling shows it does.
+
+- **Trigger** — what fires each run: an **event** (a new email, a new issue)
+  or a **schedule** (every morning). Event-triggering is usually the more
+  efficient.
+- **Checkpoint** — a human-in-the-loop point where the user is asked to verify
+  or decide. Some workflows have none and run autonomously; some use no AI at
+  all.
+- **Push right** — defer the checkpoint as far as it will go. Do maximal work
+  before involving the human, so they are asked once, late, with everything
+  prepared.
+- **Brief** — what a checkpoint presents: a tight, decision-ready summary —
+  what was produced, why, and a link down to the asset itself — never the raw
+  output. The user reads a brief, not a draft. Speed of review is imperative.
+
+## Definition of done
+
+A workflow spec is done when **an implementer agent could build it without
+asking a single question**. Grill until then; nothing is done while a question
+remains.
+
+Concretely, a spec must answer, explicitly:
+
+- **Trigger** — what starts a run (event / schedule / manual), with the exact
+  signal.
+- **Steps** — ordered, unambiguous; each step has an owner (agent / script /
+  human / poller) and an input→output contract.
+- **Data & sources** — where inputs come from, where outputs go, credentials
+  needed (redacted, referenced by name).
+- **Checkpoints** — where (if anywhere) a human is asked, and what the brief
+  looks like.
+- **Failure modes** — what can go wrong per step, and the default handling
+  (retry / park / notify / abort).
+- **Verification** — how the implementer (or the poller) proves a run
+  succeeded — a verifier command or an observable completion signal.
+
+If you cannot write any of these without asking, ask. If the user cannot
+answer, the workflow is not ready to specify — narrow it.
+
+### Independent check (before done)
+
+Before declaring a spec done, verify it with a fresh-context non-implementer
+agent (review-kit method): give it the spec alone and ask "what would you need
+to ask before building this?" Any question it raises means the spec is not
+done — resolve it in the spec, don't answer the agent.
+
+## Spec location
+
+Where workflow specs live (per project-discipline Rule 1):
+
+- regular project → `.wiki/concepts/<topic>-workflow.md`
+- workshop zone → `.brainstorm/<topic>.md` (running record), then the
+  promotion pipeline takes over
+- user preference overrides the default
+
+The session's raw notes on the user's world (tools, channels, terminology)
+go in the same running record / a `NOTES.md`-style section — kept thin and
+canonical, not a dump.
+
+## Implementation handoff
+
+Once a spec is done (definition of done met + independent check passed):
+
+1. Break it into tasks on the project's `.tasks/` board (task-format; a
+   poller-driven workflow gets `**Weight:**` + `**Notify:**`).
+2. Add a verifier to each implementation task (ralph-loop-execution style) —
+   the spec's Verification line is the verifier command.
+3. Promote the spec to the wiki (workshop: promotion pipeline; project:
+   `.wiki/concepts/`).
+
+Do NOT delegate a workflow whose spec is not done — the implementer would
+have to ask questions the grilling should have resolved.
+
+## Cross-agent applicability
+
+Pure dialogue + spec methodology — no harness-specific tool references. The
+"implementer agent" / "fresh-context check" is any agent runtime (pi, Claude,
+codex, hermes); on a runtime without sub-agent spawning, do the fresh-context
+check by re-reading the spec against the definition-of-done list with fresh
+eyes after a break.
+
+## Out of scope
+
+- Does NOT stress-test a finished plan (that's grilling).
+- Does NOT run the divergent brainstorm (that's brainstorming).
+- Does NOT define the task-board format (see task-format) or the verifier
+  loop mechanics (see ralph-loop-execution).
+- Does NOT decide WHAT is worth delegating — the lens proposes, the user
+  decides.