Skip to main content
Glama
fbwndrud

vibelore

by fbwndrud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

lore_arc_plan

Destructive

Generates a next arc's promise and 3–20 episode beats, validates structure and quality, and saves the plan for approval before chapter drafting.

Instructions

다음 아크의 약속과 3~20개 얇은 회차 비트(사건·압력·전환·다음 상태)를 생성하고 구조·품질 검증을 거쳐 .vibelore/arc-plan.json에 저장한다(아크별 사본은 .vibelore/arcs/). lore_write 전에 lore_arc_status로 활성 아크가 없음을 확인했을 때, 또는 아크가 끝났을 때 호출한다. 기반과 승인된 StoryProfile·StorySpine·WriterSkill이 필요하다. pending 계획은 같은 번호로 교체한다. 활성 아크는 ARC_IN_PROGRESS로 거부한다. 사용자가 교체를 명시적으로 요청한 경우에만 replaceActive=true로 다음 번호의 아크로 교체한다. 생성·품질 판정·언어 검증에 status=needs_model이 약 3회 나온다. 반환은 {plan(episodes, quality), needsApproval, instruction}.

Input Schema

NameRequiredDescriptionDefault
modeNoreview(기본)=사용자 승인 전까지 pending이며 집필할 수 없다. auto=검증 통과 즉시 활성화. 사용자가 "알아서·묻지 말고"라고 한 경우만 auto.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
episodesNo아크 화수 3~20 정수. 기본 8. 범위 밖과 소수는 거부한다.
feedbackNo거절한 계획을 다시 만들 때 반영할 피드백. 이전 계획은 모델에 다시 보내지 않으므로 피드백만으로 이해되게 쓴다.
directionNo사용자가 원하는 아크 방향. 비우면 작품 브리프와 StorySpine에서 자율 설계.
replaceActiveNo사용자가 활성 아크 교체를 명시적으로 요청한 경우만 true. 기본은 ARC_IN_PROGRESS로 거부하며, true는 활성 계획을 다음 번호의 아크로 교체한다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.4.8
    • addedInput schema / properties / episodes / default
      Added value: +8
    • changedInput schema / properties / episodes / description
      Previous value: -"아크 화수 3~20(범위 밖은 잘라낸다). 기본 8."New value: +"아크 화수 3~20 정수. 기본 8. 범위 밖과 소수는 거부한다."
    • addedInput schema / properties / episodes / maximum
      Added value: +20
    • addedInput schema / properties / episodes / minimum
      Added value: +3
    • changedInput schema / properties / episodes / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / replaceActive
      Added value: +{
+  "default": false,
+  "description": "사용자가 활성 아크 교체를 명시적으로 요청한 경우만 true. 기본은 ARC_IN_PROGRESS로 거부하며, true는 활성 계획을 다음 번호의 아크로 교체한다.",
+  "type": "boolean"
+}
  2. Changed5 schema fields changedv0.4.4
    • changedInput schema / properties / direction / description
      Previous value: -"사용자가 원하는 아크 방향. 비우면 자율 설계."New value: +"사용자가 원하는 아크 방향. 비우면 작품 브리프와 StorySpine에서 자율 설계."
    • changedInput schema / properties / episodes / description
      Previous value: -"아크 화수 3~20"New value: +"아크 화수 3~20(범위 밖은 잘라낸다). 기본 8."
    • changedInput schema / properties / feedback / description
      Previous value: -"거절한 계획을 다시 만들 때 반영할 피드백."New value: +"거절한 계획을 다시 만들 때 반영할 피드백. 이전 계획은 모델에 다시 보내지 않으므로 피드백만으로 이해되게 쓴다."
    • changedInput schema / properties / mode / description
      Previous value: -"review=사용자 검토, auto=자동 승인"New value: +"review(기본)=사용자 승인 전까지 pending이며 집필할 수 없다. auto=검증 통과 즉시 활성화. 사용자가 \"알아서·묻지 말고\"라고 한 경우만 auto."
    • changedInput schema / properties / workId / description
      Previous value: -"작품 식별자 ([A-Za-z0-9_-])."New value: +"작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a non-read-only, destructive, non-idempotent write, and the description adds materially: files written, that pending plans are replaced in place at the same number, the ARC_IN_PROGRESS rejection, the needs_model approval loop appearing ~3 times, and the return shape. This is behavioral detail well beyond what structured fields supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by when-to-call, prerequisites, edge cases, and return value in a logical order with no filler prose. It is dense and repetitive in places (replaceActive semantics echoed from the schema), which keeps it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description states the return object, the approval gate, the file side effects, the error condition, and the mandatory prerequisites. For a multi-step generative tool with 7 parameters, nothing an agent needs to invoke it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so mode, workId, project, episodes, feedback, direction and replaceActive are all documented in the schema itself. The description restates the replaceActive and episodes semantics rather than adding format or constraint detail beyond them, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource — generating the next arc's promise plus 3–20 thin episode beats — and states the concrete artifact (.vibelore/arc-plan.json with per-arc copies). An agent can distinguish this from lore_arc_status/lore_arc_review/lore_arc_decide without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions (before lore_write, once lore_arc_status confirms no active arc, or when an arc has ended), prerequisites (foundation plus approved StoryProfile/StorySpine/WriterSkill), and an exclusion (active arcs rejected with ARC_IN_PROGRESS). The replaceActive escape hatch is scoped to explicit user requests only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools