drafted 1.16.0 → 1.17.0

package/agent-instructions/global.md

@@ -1,52 +1,3 @@
 <drafted>
-Drafted is the shared workspace for agent-produced consulting artifacts. Claude Code and Codex agents should use it proactively when the task benefits from persistent visual work, client-facing documents, reusable skills, or organization knowledge.
-
-Drafted terminology:
-- Wiki: durable organization knowledge. It may also be called the knowledge base or database. Save, compound, curate, and retrieve knowledge here when it should benefit the business, teammates, other agents, or future work by the same person.
-- Skills: reusable operating knowledge. Users may call them skills, procedures, SOPs, standard operating procedures, checklists, methods, protocols, playbooks, or templates for repeatable work. Use them actively before repeatable work, follow them while working, and maintain them when better methods emerge.
-- Projects: client-facing or reviewable work products, organized as frames on a shared surface. Use projects when work should be seen, reviewed, reused, or developed over time rather than left only in chat.
-
-Operating principle:
-- Do not treat Drafted as passive storage. Actively use and maintain the wiki, skills, and projects when they fit the work.
-- Default to creating or updating Drafted project frames for substantive outputs instead of leaving artifacts only in chat. If the user asks you to draft, write, plan, analyze, compare, design, document, summarize, report, spec, model, or make a deck/table, put the durable result on the Drafted surface unless the user explicitly wants chat-only output.
-- Put durable knowledge in the wiki, reusable methods in skills, and producible artifacts in projects.
-- Do not save reusable procedures, SOPs, checklists, methods, protocols, or repeatable work instructions to the wiki/knowledge base. Save them as Drafted skills.
-
-Before working:
-- Check whether Drafted MCP tools are available. If not authenticated, use auth(action="get_link") or auth(action="login") and give the user the sign-in link.
-- Identify the correct organization and project first. Use get_org(action="get") and project(action="list"). Opening a project binds the agent session's context — the org derives from the project. There is no org switching: address existing resources by UUID (pageId/skillId/projectId — org self-derives), and pass org=... on creates and searches that name no resource (wiki write, skill add, project create, template actions).
-- Check get_org(action="get") for googleDrive.connected. When Google Drive is connected for the org you are working in, Google Workspace frames are available and should be the strong default for documents, spreadsheets, and presentations.
-- Never assume the current Drafted project or org context is correct. Verify the project/org echoed in each response before writing.
-
-Wiki rules:
-- Search the org wiki before substantive work: wiki(action="search") with relevant keywords.
-- Read relevant pages before creating or changing artifacts.
-- Maintain the wiki when you discover durable knowledge, decisions, client constraints, project context, research notes, or facts that should compound for the business or future agents.
-- When creating or editing wiki pages, return a browser link the user can click.
-
-Skill rules:
-- Treat skill, procedure, SOP, checklist, method, protocol, playbook, and repeatable-work template as the same user intent.
-- Search skills before starting repeatable work: skill(action="search") or skill(action="list").
-- Load and follow relevant skills with skill(action="load"). Read supporting skill files when needed.
-- When the user asks to record, distill, create, save, install, or update a skill/procedure/SOP/checklist/method/protocol/playbook, create or update a Drafted skill for the org with skill tools.
-- Every skill has a portable part — its method, SKILL.md, and any script source — and that part always belongs in Drafted, not only in a local repo. When you build a runnable skill, push the source to Drafted (skill action="push", or skill action="add" for prose) and declare how to rebuild it in the skill's `setup:` frontmatter (e.g. ["npm ci"]) so any machine or agent can regenerate it. Do not leave a reusable skill authored only as local files when Drafted is connected.
-- Machine-specific build output (node_modules, downloaded browsers, compiled binaries) is never portable: build it into a `.skillinstall/` directory inside the skill. Drafted always strips `.skillinstall/` from a pushed bundle and skill push auto-gitignores it, so the rebuildable bundle stays local while the method and recipe stay in Drafted.
-- Improve skills when you find a better checklist, standard, or operating method.
-
-Project/producible rules:
-- For client-facing, durable, or reviewable artifacts, produce the work inside the appropriate Drafted project instead of leaving it only in chat.
-- Prefer one visible frame per artifact or artifact section so the user can review, compare, and refine work on the surface.
-- Use project(action="open") before frame/asset/connector/layout changes. For every write/edit, confirm the response project matches the intended project.
-- Read anchored frames and existing neighboring frames before editing a layer.
-- After creating frames, documents, diagrams, or other producibles, use focus when available and return the clickable Drafted frame or project link.
-
-Google Workspace rules:
-- If get_org reports googleDrive.connected, strongly prefer Google Workspace frames for business artifacts: google-doc for memos, reports, briefs, SOPs, proposals, and long-form documents; google-sheet for tables, trackers, budgets, research matrices, and models; google-slide for decks and presentation outlines.
-- Create Google Workspace frames with frame(action="write", googleType="google-doc" | "google-sheet" | "google-slide", path="/{layer}/{lane}/{filename}", title="...") after opening the project.
-- For flowcharts, process maps, architecture diagrams, system diagrams, data-flow diagrams, visual maps, or other editable diagrams, load and follow the system skill `excalidraw-drafted` (Drafted Excalidraw Diagram) and create native Drafted Excalidraw frames. Use normal Drafted HTML/markdown frames for web/UI mockups, rich visual layouts, or non-editable presentation artifacts.
-- Use breadcrumbs in code or docs where useful: drafted:<frameId> for frames and drafted-project:<projectId> for projects.
-
-Collaboration rules:
-- Parallel agents must each open and verify their own Drafted project/org context.
-- If there is any doubt about the correct org, project, wiki location, or skill, ask a short clarifying question before writing.
+You have Drafted MCP tools — a shared surface for durable, reviewable work: produce substantive output as frames on the surface (not only in chat), put knowledge in the org wiki, and encode repeatable methods as skills. The full operating manual is the `drafted` skill installed with the plugin — follow it when working with Drafted. Address orgs by path: `fs(ls, path="/")` lists them, and `/o/<org>/<root>/...` (root ∈ wiki, skills, projects) is the canonical path form — the org is part of the path, never a separate switch. Before writing, verify the org/project echoed in the response is the one you intend.
 </drafted>

package/install-mcp.sh

@@ -480,56 +480,7 @@ load_global_agent_instructions() {
   fi
   cat <<'DRAFTED_GLOBAL_INSTRUCTIONS'
 <drafted>
-Drafted is the shared workspace for agent-produced consulting artifacts. Claude Code and Codex agents should use it proactively when the task benefits from persistent visual work, client-facing documents, reusable skills, or organization knowledge.
-
-Drafted terminology:
-- Wiki: durable organization knowledge. It may also be called the knowledge base or database. Save, compound, curate, and retrieve knowledge here when it should benefit the business, teammates, other agents, or future work by the same person.
-- Skills: reusable operating knowledge. Users may call them skills, procedures, SOPs, standard operating procedures, checklists, methods, protocols, playbooks, or templates for repeatable work. Use them actively before repeatable work, follow them while working, and maintain them when better methods emerge.
-- Projects: client-facing or reviewable work products, organized as frames on a shared surface. Use projects when work should be seen, reviewed, reused, or developed over time rather than left only in chat.
-
-Operating principle:
-- Do not treat Drafted as passive storage. Actively use and maintain the wiki, skills, and projects when they fit the work.
-- Default to creating or updating Drafted project frames for substantive outputs instead of leaving artifacts only in chat. If the user asks you to draft, write, plan, analyze, compare, design, document, summarize, report, spec, model, or make a deck/table, put the durable result on the Drafted surface unless the user explicitly wants chat-only output.
-- Put durable knowledge in the wiki, reusable methods in skills, and producible artifacts in projects.
-- Do not save reusable procedures, SOPs, checklists, methods, protocols, or repeatable work instructions to the wiki/knowledge base. Save them as Drafted skills.
-
-Before working:
-- Check whether Drafted MCP tools are available. If not authenticated, use auth(action="get_link") or auth(action="login") and give the user the sign-in link.
-- Select the correct organization first. Use get_org(action="get") and project(action="list") to identify the target org/project. Opening a project switches org context automatically; for wiki/skill-only work, use get_org(action="switch", orgId=...).
-- Check get_org(action="get") for googleDrive.connected. When Google Drive is connected for the active org, Google Workspace frames are available and should be the strong default for documents, spreadsheets, and presentations.
-- Never assume the current active Drafted project or organization is correct. Verify the returned project/org before writing.
-
-Wiki rules:
-- Search the org wiki before substantive work: wiki(action="search") with relevant keywords.
-- Read relevant pages before creating or changing artifacts.
-- Maintain the wiki when you discover durable knowledge, decisions, client constraints, project context, research notes, or facts that should compound for the business or future agents.
-- When creating or editing wiki pages, return a browser link the user can click.
-
-Skill rules:
-- Treat skill, procedure, SOP, checklist, method, protocol, playbook, and repeatable-work template as the same user intent.
-- Search skills before starting repeatable work: skill(action="search") or skill(action="list").
-- Load and follow relevant skills with skill(action="load"). Read supporting skill files when needed.
-- When the user asks to record, distill, create, save, install, or update a skill/procedure/SOP/checklist/method/protocol/playbook, create or update a Drafted skill for the org with skill tools.
-- Every skill has a portable part — its method, SKILL.md, and any script source — and that part always belongs in Drafted, not only in a local repo. When you build a runnable skill, push the source to Drafted (skill action="push", or skill action="add" for prose) and declare how to rebuild it in the skill's `setup:` frontmatter (e.g. ["npm ci"]) so any machine or agent can regenerate it. Do not leave a reusable skill authored only as local files when Drafted is connected.
-- Machine-specific build output (node_modules, downloaded browsers, compiled binaries) is never portable: build it into a `.skillinstall/` directory inside the skill. Drafted always strips `.skillinstall/` from a pushed bundle and skill push auto-gitignores it, so the rebuildable bundle stays local while the method and recipe stay in Drafted.
-- Improve skills when you find a better checklist, standard, or operating method.
-
-Project/producible rules:
-- For client-facing, durable, or reviewable artifacts, produce the work inside the appropriate Drafted project instead of leaving it only in chat.
-- Prefer one visible frame per artifact or artifact section so the user can review, compare, and refine work on the surface.
-- Use project(action="open") before frame/asset/connector/layout changes. For every write/edit, confirm the response project matches the intended project.
-- Read anchored frames and existing neighboring frames before editing a layer.
-- After creating frames, documents, diagrams, or other producibles, use focus when available and return the clickable Drafted frame or project link.
-
-Google Workspace rules:
-- If get_org reports googleDrive.connected, strongly prefer Google Workspace frames for business artifacts: google-doc for memos, reports, briefs, SOPs, proposals, and long-form documents; google-sheet for tables, trackers, budgets, research matrices, and models; google-slide for decks and presentation outlines.
-- Create Google Workspace frames with frame(action="write", googleType="google-doc" | "google-sheet" | "google-slide", path="/{layer}/{lane}/{filename}", title="...") after opening the project.
-- For flowcharts, process maps, architecture diagrams, system diagrams, data-flow diagrams, visual maps, or other editable diagrams, load and follow the system skill `excalidraw-drafted` (Drafted Excalidraw Diagram) and create native Drafted Excalidraw frames. Use normal Drafted HTML/markdown frames for web/UI mockups, rich visual layouts, or non-editable presentation artifacts.
-- Use breadcrumbs in code or docs where useful: drafted:<frameId> for frames and drafted-project:<projectId> for projects.
-
-Collaboration rules:
-- Parallel agents must each open and verify their own Drafted project/org context.
-- If there is any doubt about the correct org, project, wiki location, or skill, ask a short clarifying question before writing.
+You have Drafted MCP tools — a shared surface for durable, reviewable work: produce substantive output as frames on the surface (not only in chat), put knowledge in the org wiki, and encode repeatable methods as skills. The full operating manual is the `drafted` skill installed with the plugin — follow it when working with Drafted. Before writing, verify the org/project echoed in the response is the one you intend.
 </drafted>
 DRAFTED_GLOBAL_INSTRUCTIONS
 }

package/mcp/gates.mjs

@@ -33,7 +33,7 @@ export function g1Block(gateState, wikiIndex) {
   if (gateState.wikiSearched) return null;
   let msg =
     'G1: search the org wiki before reading or editing anything. ' +
-    'Call wiki(action="search", query="<relevant terms>") first, then retry. ' +
+    'Call fs(search, path="/wiki", query="<relevant terms>") first, then retry. ' +
     'More knowledge = less searching — start by drawing on what the org already knows.';
   if (wikiIndex) msg += `\n\nWiki index (what exists to search):\n${wikiIndex}`;
   return msg;
@@ -43,16 +43,16 @@ export function g2Block(gateState) {
   if (gateState.skillSearched) return null;
   return (
     'G2: search for prior-art skills before creating one. ' +
-    'Call skill(action="search", query="<topic>") first — if a close match exists, improve it ' +
+    'Call fs(search, path="/skills", query="<topic>") first — if a close match exists, improve it ' +
     '(/drafted:improve-skill) instead of duplicating — then retry skill(action="add").'
   );
 }
 
 export function g3Block(gateState) {
   const missing = [];
-  if (!gateState.wikiSearched) missing.push('wiki(action="search")');
-  if (!gateState.skillSearched) missing.push('skill(action="search")');
-  if (!gateState.templateSearched) missing.push('template(action="list")');
+  if (!gateState.wikiSearched) missing.push('fs(search, path="/wiki")');
+  if (!gateState.skillSearched) missing.push('fs(search, path="/skills")');
+  if (!gateState.templateSearched) missing.push('fs(ls, path="/skills")');
   if (missing.length === 0) return null;
   return (
     `G3: search before creating a project. Run ${missing.join(', ')} first ` +