loopany-new-concept

---

name: loopany-new-concept description: Use when picking between note / new kind / new domain — before loopany kind propose, before extracting a new domain, or any time the user says "I want to track X" / "should we add a kind for…" / "let's make a domain for…". Default: write a note. Triggers on any new-concept decision in a loopany workspace.

new-concept — note, kind, or domain?

Default: write a note. Promote only when structure pays back.

Three questions, in order

1. Does an existing kind already fit? Use it. Stop here.

2. Does at least one of these hold?

• moves through enforced states
• many references resolve to one identity (dedup)
• queried/filtered by typed fields
• downstream needs fixed body sections

If none → it's a note. If yes → continue.

3. Is it about HOW any agent operates (not WHAT it operates on)?

• yes, every agent wants this slot, distinct lifecycle → core kind
• no, it's a vertical or domain-specific entity → domain kind (lives inside the domain that owns the scope)

Domain is a separate axis

Domains aren't pre-shipped. Propose one only when observed usage shows a separable scope — recurring artifacts that share a vertical (sales pipeline, paid ads), a rhythm (weekly review), or a workflow that wants its own settings / cron / skills, and that doesn't make sense in the global pool.

Two signals worth waiting for before proposing:

• ≥ 5 artifacts already carry the same domain: <name> value the user has been writing informally, or
• A new kind would only ever be valid inside one scope.

Domains can host kinds. Kinds can't host domains. When torn between "new kind" and "new domain that holds that kind", prefer the domain — the kind travels with it.

Examples

• "Client likes async standups" — 4-question test all fail → note.
• "Podcast appearances" — identity + typed + body shape pass → kind. Every-agent test fails → domain podcast with kinds/appearance.md.
• "Weekly investor update cadence" — not a new kind; it's a new scope → domain investors, reuses existing brief + task.

Entity-as-kind (not task) — common confusion:

• "Podcast episodes / blog posts / tweets" (the published thing, not the writing of it) — identity + queryable metrics + consistent body shape → kind post (inside social or content domain if scope separates; standalone if the mission IS publishing). The writing is a task; the published artifact is the post — link via produced.
• "Customers" — repeat reference + structured query (status, ARR, contract date) → kind customer in crm domain.
• "Orders" — identity + status machine (placed → paid → shipped) + typed fields (amount, items) → kind order in commerce domain.

Process

• Note → loopany artifact create --kind note ...
• New kind → draft kinds/<name>.md, run loopany kind propose <file>, wait for human accept
• New domain → surface the proposal with the kinds it bundles, scaffold domains/<name>/ after user agrees (flow still maturing — flag it to the user)

Anti-patterns

• ❌ "I want to track X" → propose a kind. Almost always a note first.
• ❌ Verticals (recipe, deal, experiment) as core kinds.
• ❌ A new domain when one extra field on a note would do.
• ❌ Skipping this skill and going straight to kind propose.