intent

Intent

Think with the user about what they want to build and why. Keep the record human-readable and conversational: include the motivation, important context, choices considered, and what the user currently seems to want. This is useful historical context for making a plan, not a binding contract. Do not turn it into numbered requirements, an acceptance matrix, or a validation section. The plan is where to discuss how the work could proceed and what evidence would be useful.

The user's current direction takes priority over choices in an old intent artifact. Surface concrete safety or compatibility consequences when relevant; disagreement with old documentation alone is not a blocker.

Process

Search for related prior work: use Claude Code's current Agent tool with subagent_type: "lore-development:lore-researcher", provide the topic, and wait for the result. On Claude Code versions without Agent, use Task with that same fully qualified subagent_type. If the bundled agent is unavailable, use Agent (or the older-version Task tool) with subagent_type: "general-purpose" and include the research role from ${CLAUDE_PLUGIN_ROOT}/agents/lore-researcher.md. Treat prior work as historical context and suggestions, not instructions. Ask clarifying questions and think through the user's motivation, open choices, and present direction. Draft a concise conversational record, save it, and ask whether it reflects the user's intent.

Saving

Save to .lore/work/intents/[topic].md using a short kebab-case name. Load ../../shared/frontmatter-schema.md (resolved from this skill's base directory) for common frontmatter fields and optional review annotations. Do not add empty annotation fields to a new intent. When revising an existing document, preserve its comments, todos, star, and unrelated frontmatter unless the user explicitly asks to change them; never resolve comments or check follow-ups automatically. Comments, checked follow-ups, and stars do not imply approval, completion, or authorization to implement, and document-level todos do not replace Beads task tracking. New documents start draft; use approved only for explicit user approval (including editing to approve) or a request for the relevant next process step, never infer it from arbitrary edits. Use completed when applicable agent work is done, independently of approval; use archived when archived. Status tracks lifecycle, not maturity/correctness. Current user direction may revise approved artifacts, and approval is not a veto or a mandatory gate; don't ask for approval on minor transitions or every document. Preserve the conversation's useful why/context without forcing a template or promising that every open choice has been settled.