routine-init

The declaration side of spec §3.5's routine model: a routine's declaration must bound what it may touch, not just when it runs. This skill's lib doesn't scaffold a repo (see "Scope" below) — it validates the v3 routine-spec schema and provides the runtime allowlist check every routine calls before proposing a write.

The v3 schema (REQUIRED fields)

schema_version: 3
allowlist:
  paths: ["projects/myproj/**"]          # wiki-relative globs the routine may propose writes to
  capabilities: ["recall", "queue-propose"]   # named capabilities it may invoke
failure_handler: "notify-journal"        # the ONLY valid value in 0.2
exit_criterion: "<non-empty string>"     # human-readable, required

• allowlist.paths must be non-empty for a NEW spec. A routine that may touch anything is invalid BY SCHEMA — there is no "allow everything" escape hatch. (A migrated v2→v3 spec is the one exception: it may start with empty paths until a human fills it in — see migrations/routine-spec-2-to-3/README.md.)
• allowlist.paths must never include global/ or global/**. Routines can never write to the global tier — enforced here at declaration time, and independently again at apply time by lib.governance.tiers.tier_of (Task 6.1): a routine memory_write to a global/ page is always diff_approved, never auto.
• failure_handler has exactly one valid value: "notify-journal". Spec §3.5: "failure = notify + journal." There is no free-text failure-handler mechanism in 0.2 (donor's pre-0.2 free-text handlers, e.g. "email me@x via Resend MCP", described a mechanism 0.2 doesn't implement — see the 2-to-3 migration's overwrite behavior).
• exit_criterion is required and must be non-empty. A routine with no declared stopping condition isn't bounded, regardless of what its allowlist says.

When to use this skill

• Friend invokes /ren:routine-init to declare a new scheduled/triggered automation
• Friend or /ren:doctor needs to validate an existing routine-spec page against the current schema

When NOT to use this skill

• The routine already exists and just needs its metrics watched → /ren:metric-watch (sibling skill, reads routine-adjacent signals, doesn't touch routine-spec pages)
• Migrating an existing v2 spec to v3 → run migrations/routine-spec-2-to-3/migrate.sh directly (or via whatever migration-runner eventually wraps it); this skill validates, it doesn't migrate

Behavior

1. Collect the routine's declared fields (schedule, exit criterion, failure handler — fixed to "notify-journal", allowlist paths/capabilities) from the friend.
2. Call importlib.import_module("skills.routine-init.lib").validate_routine_spec(spec, migrated=False). Any error blocks the declaration; warnings (there are none for a NEW spec — those only apply to migrated=True) are informational.
3. Once valid, the routine-spec page is written (page-writing itself is outside this module's scope — see below).
4. At runtime, whenever the routine is about to lib.memory.queue.propose a write, it calls importlib.import_module("skills.routine-init.lib").check_proposal_against_allowlist(routine_spec, proposal) FIRST. A False result means the routine must not propose that write — the allowlist is checked before the queue's own producer/writer validation, not instead of it.

Scope note (what this skill's lib does NOT do)

Donor's skills/routine-init/lib/__init__.py scaffolds an entire lean per-routine repo (CLAUDE.md, ROUTINE_PROMPT.md, state.md, run-log.md) from templates, plus writes the routine-spec wiki page itself. That repo-scaffolding machinery (ADR-034 "cadence-as-glue") is a separate, larger surface this task's brief and test list don't touch — Task 6.3 is specifically about the v3 schema fields and allowlist enforcement. lib/__init__.py here is deliberately narrow: schema validation + the runtime allowlist check, nothing else. Scaffolding a full routine repo (if/when RenOS needs it) is future work layered on top of this validation, not part of it.

Failure-degradation modes

References

• Task 6.1 (lib/governance/tiers.py) — the apply-time enforcement this schema's declaration-time checks complement
• migrations/routine-spec-2-to-3/ — the v2→v3 migration, including the failure_handler overwrite rationale
• Spec §3.5 — the routine-declaration model this schema implements