Propose

Turn a repeated need into a one-page proposal the user can say yes or no to.

When to use

• The user asks for a new ability: "Could you make that a skill?", "I want something that checks my numbers", "Can you connect Zotero?".
• The user picks something "available to build" from /menu (a blueprint) or a tool from the catalogue.
• Proactive mode (/propose --proactive): at the end of a session, or from /weekly-review, when the user did the same manual job again. Rules in references/proactive.md.

Nothing is built here. Building is /build, and only after a yes.

Before you start

1. Check self-build settings: node system/scripts/proposals.mjs status --json.
   • can_propose: false (mode off): say "Building new skills is switched off. Say /reconfigure if you'd like it on." Stop.
   • Proactive mode: continue only if can_suggest_proactively is true.
2. Look for something that already exists, so you don't propose a duplicate:
   • .claude/skills/*/SKILL.md descriptions (including the user's my-* skills);
   • system/blueprints/*.md titles (a ready-made plan is safer than a new design);
   • system/catalogue/mcp.json servers[] (what lines);
   • open cards in vault/00_inbox/proposals/. If one fits, say so and offer it instead ("/study already does most of this. Want me to show you?").
3. A vague idea is fine here. Write what you know; /build runs /clarify before anything is built.
4. Get today's date from the system: node system/scripts/date.mjs (local date).

Steps

1. Decide the kind (skill, agent, mcp, blueprint, automation) and the name:
   • designed for the user: my-<slug> (lowercase, hyphens, 2–4 words: my-case-summary);
   • a blueprint: the blueprint's file name without .md (zotero);
   • a catalogue tool only: the catalogue id.
2. Pick model and effort from the routing table (SPEC §6): sorting or tagging → haiku/low; drafting, notes, research → sonnet/medium; checking or critique → sonnet/high; real judgement → opus/high (rare). For a blueprint, use what it states.
3. Rate the risk:
   • low: reads and writes only inside vault/; no new accounts or keys.
   • medium: uses the web, a new tool, an API key, or school systems (read-only).
   • high: anything that could send, post, submit or delete; tools with tier: "high-risk"; always-on servers; auto sending. A blueprint's own risk wins if higher.
4. Write the card at vault/00_inbox/proposals/<YYYY-MM-DD> <Title>.md, starting from system/templates/notes/proposal.md. Frontmatter exactly as SPEC §11 (type, created, status: "open", kind, name, model, effort, risk). Body sections, in plain words a non-technical reader understands:
   • What it does: one line, then one concrete example ("You drop a case PDF in; you get a one-page summary note in your course folder.").
   • Why I'm suggesting it: the evidence ("You asked me to summarise case readings 3 times in the past 2 weeks." or "You asked for it."). For a blueprint: the user's reason.
   • What it will touch: folders it reads and writes; tools it uses; for an MCP, that config/mcp.selected.json changes. Say clearly what it will not touch.
   • Cost and risk: usage (light / moderate / heavy for their plan), money (usually free), and the risk in one sentence.
   • How to undo: "Say /remove-skill <name>. It removes everything this added; your notes stay."
5. Add the task: node system/scripts/tasks.mjs add "Approve or reject: <Title>" --tag propose --priority low --link "00_inbox/proposals/<YYYY-MM-DD> <Title>".
6. Record it: node system/scripts/proposals.mjs mark <key> suggested --card "vault/00_inbox/proposals/<file>.md" (key: the slug without my-).
7. Ask in chat (3–5 lines: what it does, why, risk, then the question). AskUserQuestion: Yes, build it now (recommended only if risk is low) / Not now (keep the card) / No thanks.
   • Yes: set the card status: "approved", tick the task (node system/scripts/tasks.mjs done "Approve or reject: <Title>"), then run /build with the card path.
   • Not now: leave it open. "It's in your proposals; say 'build <Title>' any time."
   • No thanks: set status: "rejected", tick the task, run node system/scripts/proposals.mjs mark <key> rejected. Don't suggest it again.

Outputs

• vault/00_inbox/proposals/<YYYY-MM-DD> <Title>.md (a proposal card).
• A #ab/propose task in vault/00_inbox/Tasks.md.
• state/proposals.json updated (signals and outcomes) via system/scripts/proposals.mjs.

Safety

• Never build, install or edit anything from this skill. Only the card, the task and state/proposals.json.
• Never propose changes to protected files: system/**, .claude/settings.json, system/core.md, the catalogue, or framework skills. If a need can only be met that way, say so and suggest /update-alterbrain or telling the Alterbrain maintainers.
  • One exception: the quarterly model check (.claude/skills/health-check/references/model-check.md) writes "Update model routing" cards. They may change only the model: and effort: lines of skills and agents, and /health-check applies them after approval, not /build.
• Proactive mode: at most one suggestion per session, never mid-task, never a rejected idea, never above max_open_proposals. See references/proactive.md.
• Evidence in cards and signals is described in plain words without other people's names or personal details.
• Don't oversell. If the gain is small, say so.