drafted 1.8.0 → 1.8.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/install-mcp.sh +54 -17
- package/package.json +4 -2
- package/plugin/commands/create-project.md +23 -0
- package/plugin/commands/create-skill.md +18 -0
- package/plugin/commands/extract.md +16 -0
- package/plugin/commands/improve-project-harness.md +16 -0
- package/plugin/commands/improve-skill.md +14 -0
- package/plugin/commands/improve-wiki.md +14 -0
- package/plugin/commands/ingest.md +20 -0
- package/plugin/commands/onboard-drafted.md +17 -0
- package/plugin/skills/drafted/SKILL.md +84 -0
package/install-mcp.sh
CHANGED
|
@@ -507,34 +507,71 @@ NODE
|
|
|
507
507
|
install_agent_instructions "$HOME/.claude/CLAUDE.md" "Claude global instructions"
|
|
508
508
|
install_agent_instructions "$HOME/.codex/CODEX.md" "Codex global instructions"
|
|
509
509
|
|
|
510
|
-
# ── Skills
|
|
510
|
+
# ── Skills & commands ─────────────────────────────────────────────
|
|
511
511
|
|
|
512
|
-
step "Installing skills"
|
|
512
|
+
step "Installing skills and commands"
|
|
513
513
|
|
|
514
|
-
#
|
|
515
|
-
|
|
514
|
+
# Resolve the plugin source: a local checkout when present (e.g. --local from this
|
|
515
|
+
# repo), otherwise the installed npm package's bundled plugin/ directory.
|
|
516
|
+
# require.resolve() misses packages under the custom global prefix
|
|
517
|
+
# ($HOME/.drafted/npm-global) when run from an arbitrary cwd (curl | bash), so
|
|
518
|
+
# prefer the already-computed global node_modules root from the install step.
|
|
519
|
+
if [ -n "${NPM_ROOT:-}" ] && [ -d "$NPM_ROOT/drafted" ]; then
|
|
520
|
+
DRAFTED_PKG_DIR="$NPM_ROOT/drafted"
|
|
521
|
+
else
|
|
522
|
+
DRAFTED_PKG_DIR="$(node -e "try { console.log(require.resolve('drafted/package.json').replace('/package.json','')) } catch { process.exit(1) }" 2>/dev/null)" || true
|
|
523
|
+
fi
|
|
524
|
+
if [ -d "$SCRIPT_DIR/plugin/skills" ] || [ -d "$SCRIPT_DIR/plugin/commands" ]; then
|
|
525
|
+
PLUGIN_SRC="$SCRIPT_DIR/plugin"
|
|
526
|
+
elif [ -n "$DRAFTED_PKG_DIR" ] && [ -d "$DRAFTED_PKG_DIR/plugin" ]; then
|
|
527
|
+
PLUGIN_SRC="$DRAFTED_PKG_DIR/plugin"
|
|
528
|
+
else
|
|
529
|
+
PLUGIN_SRC=""
|
|
530
|
+
fi
|
|
516
531
|
|
|
517
|
-
|
|
532
|
+
# Skills — Claude Code auto-loads these from ~/.claude/skills/<name>/SKILL.md
|
|
533
|
+
if [ -n "$PLUGIN_SRC" ] && [ -d "$PLUGIN_SRC/skills" ]; then
|
|
518
534
|
SKILLS_DIR="$HOME/.claude/skills"
|
|
519
535
|
mkdir -p "$SKILLS_DIR"
|
|
520
|
-
|
|
521
|
-
|
|
522
|
-
for f in "$DRAFTED_PKG_DIR/skills/"*.md; do
|
|
523
|
-
[ -f "$f" ] || continue
|
|
524
|
-
cp "$f" "$SKILLS_DIR/"
|
|
525
|
-
INSTALLED=$((INSTALLED + 1))
|
|
526
|
-
done
|
|
527
|
-
# Copy skill directories
|
|
528
|
-
for d in "$DRAFTED_PKG_DIR/skills/"*/; do
|
|
536
|
+
SKILL_COUNT=0
|
|
537
|
+
for d in "$PLUGIN_SRC/skills/"*/; do
|
|
529
538
|
[ -d "$d" ] || continue
|
|
530
539
|
DIRNAME="$(basename "$d")"
|
|
531
540
|
rm -rf "$SKILLS_DIR/$DIRNAME"
|
|
532
541
|
cp -r "$d" "$SKILLS_DIR/$DIRNAME"
|
|
533
|
-
|
|
542
|
+
SKILL_COUNT=$((SKILL_COUNT + 1))
|
|
534
543
|
done
|
|
535
|
-
ok "Installed $
|
|
544
|
+
ok "Installed $SKILL_COUNT skill(s) to $SKILLS_DIR"
|
|
545
|
+
else
|
|
546
|
+
echo -e " ${YELLOW}Skill source not found in package — skipping skills.${RESET}"
|
|
547
|
+
fi
|
|
548
|
+
|
|
549
|
+
# Commands — namespaced under drafted/ so they register as /drafted:<name>,
|
|
550
|
+
# matching the marketplace install and the commands' own cross-references.
|
|
551
|
+
if [ -n "$PLUGIN_SRC" ] && [ -d "$PLUGIN_SRC/commands" ]; then
|
|
552
|
+
CMD_COUNT=0
|
|
553
|
+
for f in "$PLUGIN_SRC/commands/"*.md; do
|
|
554
|
+
[ -f "$f" ] || continue
|
|
555
|
+
CMD_COUNT=$((CMD_COUNT + 1))
|
|
556
|
+
done
|
|
557
|
+
|
|
558
|
+
if [ "$CLIENT_CLAUDE_CODE" = true ]; then
|
|
559
|
+
CLAUDE_CMD_DIR="$HOME/.claude/commands/drafted"
|
|
560
|
+
rm -rf "$CLAUDE_CMD_DIR"
|
|
561
|
+
mkdir -p "$CLAUDE_CMD_DIR"
|
|
562
|
+
cp "$PLUGIN_SRC/commands/"*.md "$CLAUDE_CMD_DIR/" 2>/dev/null || true
|
|
563
|
+
ok "Installed $CMD_COUNT command(s) to $CLAUDE_CMD_DIR"
|
|
564
|
+
fi
|
|
565
|
+
|
|
566
|
+
if [ "$CLIENT_CODEX" = true ]; then
|
|
567
|
+
CODEX_CMD_DIR="$HOME/.codex/prompts/drafted"
|
|
568
|
+
rm -rf "$CODEX_CMD_DIR"
|
|
569
|
+
mkdir -p "$CODEX_CMD_DIR"
|
|
570
|
+
cp "$PLUGIN_SRC/commands/"*.md "$CODEX_CMD_DIR/" 2>/dev/null || true
|
|
571
|
+
ok "Installed $CMD_COUNT command(s) to $CODEX_CMD_DIR"
|
|
572
|
+
fi
|
|
536
573
|
else
|
|
537
|
-
echo -e " ${YELLOW}
|
|
574
|
+
echo -e " ${YELLOW}Command source not found in package — skipping commands.${RESET}"
|
|
538
575
|
fi
|
|
539
576
|
|
|
540
577
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "drafted",
|
|
3
|
-
"version": "1.8.
|
|
3
|
+
"version": "1.8.2",
|
|
4
4
|
"description": "Drafted — visual thinking surface for humans and AI agents. Renders HTML, markdown, images, and code as frames on a zoomable canvas, with MCP tools for AI agents and real-time sync for humans.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"files": [
|
|
@@ -9,6 +9,8 @@
|
|
|
9
9
|
"server/lib/umami.mjs",
|
|
10
10
|
"src/shared/",
|
|
11
11
|
"agent-instructions/",
|
|
12
|
+
"plugin/skills/",
|
|
13
|
+
"plugin/commands/",
|
|
12
14
|
"install-mcp.sh"
|
|
13
15
|
],
|
|
14
16
|
"bin": {
|
|
@@ -30,7 +32,7 @@
|
|
|
30
32
|
"test:watch": "vitest",
|
|
31
33
|
"version": "node scripts/sync-versions.mjs && git add plugin/.claude-plugin/plugin.json .claude-plugin/marketplace.json web-plugin/.claude-plugin/plugin.json web-plugin/.claude-plugin/marketplace.json",
|
|
32
34
|
"version:check": "node scripts/sync-versions.mjs",
|
|
33
|
-
"postpublish": "bash scripts/sync-plugin.sh \"chore: sync plugin to v$npm_package_version\"",
|
|
35
|
+
"postpublish": "bash scripts/sync-plugin.sh \"chore: sync plugin to v$npm_package_version\" && bash scripts/sync-web-plugin.sh \"chore: sync web-plugin to v$npm_package_version\"",
|
|
34
36
|
"deploy:check:google": "node scripts/check-google-drive-deploy.mjs",
|
|
35
37
|
"build:excalidraw": "node scripts/build-excalidraw-editor.mjs",
|
|
36
38
|
"prepublishOnly": "node scripts/check-npm-package.mjs"
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Start a new project — or a reusable template — with proper search of knowledge, skills, and templates first
|
|
3
|
+
argument-hint: <project name and what you want to do>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Spin up a project on the surface, or generalize one into a reusable template. Goal: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
First ask: **a new project, or a reusable template?** (This command does both.)
|
|
9
|
+
|
|
10
|
+
Search before creating (also satisfies the gates):
|
|
11
|
+
1. `wiki(action="search")` for relevant knowledge. [G1]
|
|
12
|
+
2. `skill(action="search")` for procedures that should be attached.
|
|
13
|
+
3. `template(action="list")` for an existing template to fork. [G3 — also enforced on `project(action="create")`.]
|
|
14
|
+
|
|
15
|
+
Then:
|
|
16
|
+
- If a fitting template exists → `project(action="create", templateSlug=...)` to fork it; otherwise create fresh and define the layers.
|
|
17
|
+
- `project(action="open")` the new project.
|
|
18
|
+
- `frame(action="write")` a real brief at the earliest layer (goal, audience, constraints — 6-12 lines, not a placeholder).
|
|
19
|
+
- `frame(action="anchor")` the brief so downstream work surfaces it.
|
|
20
|
+
- Attach the relevant skills you found with `skill(action="attach")`.
|
|
21
|
+
- `focus` the brief so the user watches it land.
|
|
22
|
+
|
|
23
|
+
For a **template**: build the layer structure + anchored guidance, then note how to fork it next time. Don't speculatively fill downstream frames — wait for direction.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Capture a repeatable procedure as an org skill — with proper knowledge and prior-art search
|
|
3
|
+
argument-hint: <what the procedure is for>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Turn a repeatable way of working into a Drafted skill so every future agent in the org follows it. Procedure: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
Do the searches first (they also satisfy the gates):
|
|
9
|
+
1. `wiki(action="search")` for relevant org knowledge the procedure should reference. [G1]
|
|
10
|
+
2. `skill(action="search")` for prior art — an existing skill to improve instead of duplicating. [G2 — also enforced on `skill(action="add")`.] If a close match exists, prefer `/drafted:improve-skill`.
|
|
11
|
+
|
|
12
|
+
Then define a PROPER procedure, not a vague note:
|
|
13
|
+
- a clear trigger ("when to use this"),
|
|
14
|
+
- ordered, concrete steps,
|
|
15
|
+
- success criteria / what "done right" looks like,
|
|
16
|
+
- written in the second person so any agent can follow it directly. Keep it sharp (~40 lines).
|
|
17
|
+
|
|
18
|
+
Show the draft to the user with a proposed `name` (Title Case), one-line `description`, `tags` (3-5), and `triggerPatterns`. After approval, `skill(action="add")`. Confirm with the slug and note it will auto-surface on matching tasks.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Deposit what this session produced into the harness — knowledge, a skill, and/or a template
|
|
3
|
+
argument-hint: <optional: what to capture>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Session-end deposit. Harvest what's durable from this conversation back into the harness so the next session starts smarter. Focus: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
Review the session, then **present the user options for which store(s) to deposit into** — don't auto-decide. Offer any that apply:
|
|
9
|
+
|
|
10
|
+
- **Knowledge → wiki** — durable facts, decisions, or findings worth keeping. Search first (`wiki(action="search")`) to avoid fragmenting, then `wiki(action="write")`.
|
|
11
|
+
- **Procedure → skill** — a repeatable way of working that emerged. Follow `/drafted:create-skill`.
|
|
12
|
+
- **Template → surface** — a reusable project structure that emerged. `template(action="create")` from the current project.
|
|
13
|
+
|
|
14
|
+
Show the user the candidate deposits per store, let them pick which to keep, then write the chosen ones with their approval. Confirm what landed where.
|
|
15
|
+
|
|
16
|
+
One command, all three stores — because at session end the human shouldn't have to remember which store is which.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Turn corrections you made in a project into enforced gates (anchors, attached skills, layer rules)
|
|
3
|
+
argument-hint: <optional: the correction to enforce>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
When the user had to correct the work in this project, codify the correction so future work is compelled to comply. This is the nurture → enforce bridge. Correction: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
1. Identify the recurring correction(s) or standing rule from this session.
|
|
9
|
+
2. Choose the right Drafted-side gate per correction (each counts toward the project's context budget):
|
|
10
|
+
- **Project anchor** — a brief, constraint, or style guide that must be in context project-wide: `frame(action="write")` it, then `frame(action="anchor")`. [G5]
|
|
11
|
+
- **Attached skill** — a procedure that must be loaded before work: `/drafted:create-skill` (or `skill(action="search")` for an existing one), then `skill(action="attach")`. [G4]
|
|
12
|
+
- **Layer rule** — a standing instruction for one stage: set that layer's rules via `project(action="update", layers=...)`. [G6]
|
|
13
|
+
3. Propose which mechanism for each correction, confirm with the user, then apply.
|
|
14
|
+
4. Confirm what is now enforced — the next session in this project will be gated on it automatically.
|
|
15
|
+
|
|
16
|
+
Keep within the project's context budget — if a deposit would exceed it, tighten existing gates instead of piling on.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Fix a skill you noticed is inefficient, wrong, or missing a step
|
|
3
|
+
argument-hint: <which skill, and what's off>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Improve an existing org skill when it underperformed in practice. Skill / issue: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
1. `skill(action="search")` then `skill(action="load")` the skill in question — read it fully.
|
|
9
|
+
2. Pinpoint the inefficiency: a missing step, a wrong instruction, an ambiguous trigger, or a step that wastes effort.
|
|
10
|
+
3. Propose the specific edit to the user — show before/after of the changed steps.
|
|
11
|
+
4. After approval, `skill(action="update")` (the version bumps automatically).
|
|
12
|
+
5. Confirm what changed so the next agent benefits.
|
|
13
|
+
|
|
14
|
+
Skills are the org's stable processes — every fix compounds across everyone who uses them.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Fix the wiki — reconcile stale, wrong, fragmented, or contradictory knowledge
|
|
3
|
+
argument-hint: <what's wrong, or the topic to clean up>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Improve the org wiki when knowledge has drifted. Issue/topic: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
1. `wiki(action="search")` (3-5 paraphrased queries) and `wiki(action="read")` the affected pages — don't trust titles, open them.
|
|
9
|
+
2. Diagnose: duplicate pages, a stale fact, a contradiction, or knowledge fragmented across pages.
|
|
10
|
+
3. Propose the fix to the user: consolidate duplicates, correct the fact, reconcile the contradiction, or re-link fragments.
|
|
11
|
+
4. Apply with `wiki(action="edit")` (hashline) or `wiki(action="mv")` (which rewrites inbound links). Check `wiki(action="links")` before moving or deleting.
|
|
12
|
+
5. `wiki(action="log")` what changed.
|
|
13
|
+
|
|
14
|
+
Leave the wiki more coherent than you found it — fewer, sharper, better-linked pages.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Bring knowledge into the wiki — from a research output, existing documents, or by interrogating you
|
|
3
|
+
argument-hint: <optional: what to ingest, or a source>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Feed durable knowledge into the org wiki. Source/intent: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
First decide WHAT to ingest. If it's obvious from the conversation (a research run just finished, or the user named a source), use that. Otherwise ask which of these three modes fits:
|
|
9
|
+
|
|
10
|
+
1. **A research producible** — the output of a research run (a provider-native `/deep-research` or similar). Structure it into wiki pages.
|
|
11
|
+
2. **Existing documents** — the user points at local / remote / connected folders. Scour them (spawn sub-agents if there are many) for relevant material, shortlist, confirm, then ingest the right ones. Folder scour needs file access (desktop / Cowork); on web, use connected sources.
|
|
12
|
+
3. **Interrogate the user** (grill-me) — when the knowledge is in their head. Interview relentlessly, walking ONE branch of the decision tree at a time and proposing your recommended answer at each step, until you reach shared understanding. Then structure what you captured.
|
|
13
|
+
|
|
14
|
+
Then deposit:
|
|
15
|
+
- `wiki(action="search")` first (3-5 paraphrased queries) so you don't fragment existing pages.
|
|
16
|
+
- Propose the page set to the user before writing.
|
|
17
|
+
- Write with `wiki(action="write")`, or `wiki(action="source-register")` + `wiki(action="bulk-write")` for a batch. Cross-link related pages.
|
|
18
|
+
- `wiki(action="log")` a one-line entry for the ingest.
|
|
19
|
+
|
|
20
|
+
The wiki is the org's durable knowledge — write for the next agent and teammate, not just this session.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: First-run setup — orient to Drafted and bootstrap the harness (wiki, skills, first project)
|
|
3
|
+
argument-hint: <optional: what you want to start working on>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Onboard the user to Drafted — a producibles harness that compounds across three primitives: knowledge (the wiki), procedures (skills), and the project surface. Goal/context: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
This is the over-arching prime command: orient, then seed all three stores so every later session starts smart.
|
|
9
|
+
|
|
10
|
+
1. **Orient** — in 3-4 lines explain the loop: you *prime* from the harness (the system makes you search the wiki, and auto-loads the project's attached skills, anchors, and layer rules before you work), you *build*, then you *compound* (deposit what you learned). The more it's used, the less searching and the more stable the work.
|
|
11
|
+
2. **Confirm the org** — call `get_org`. Confirm the active organization is the one to build the harness in. If unsure, ask.
|
|
12
|
+
3. **Seed knowledge** — run the `/drafted:ingest` flow: help the user point at existing business materials (folders, docs, past research) or interrogate them for tacit knowledge, and land durable pages in the wiki.
|
|
13
|
+
4. **Seed procedures** — from those materials and the conversation, surface 1-3 candidate SOPs. For the most valuable, run the `/drafted:create-skill` flow.
|
|
14
|
+
5. **Seed the surface** — run the `/drafted:create-project` flow for the user's immediate piece of work (or a reusable template).
|
|
15
|
+
6. Close by showing what now exists (wiki pages, skills, project) and restate the one-line loop: prime → build → compound.
|
|
16
|
+
|
|
17
|
+
Keep it guided and conversational — one step at a time, confirming before each deposit. Don't dump everything at once.
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: drafted
|
|
3
|
+
description: Use the Drafted producibles harness — a compounding workspace that uplifts any AI across three primitives: knowledge (the org wiki), procedures (skills), and the project surface (frames on a shared real-time canvas). Prime from the harness before working, build durable artifacts as frames instead of burying output in chat, and deposit what you learned back so the next session starts smarter. When Google Drive is connected, prefer Google Workspace frames for docs, sheets, and slides.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Drafted — a producibles harness that compounds
|
|
7
|
+
|
|
8
|
+
Drafted makes any AI more effective by giving it a memory and a workspace that get better with use. It has three primitives that layer:
|
|
9
|
+
|
|
10
|
+
- **Knowledge — the org wiki.** Durable facts, decisions, conventions. *More knowledge = less searching.*
|
|
11
|
+
- **Procedures — skills.** Reusable SOPs the org has encoded. *Better skills = more stable process.*
|
|
12
|
+
- **Surface — projects.** Reviewable work as frames on a shared zoomable canvas the user watches live at `https://drafted.live`. *Reusable projects + anchors = velocity with accuracy.*
|
|
13
|
+
|
|
14
|
+
The point is the **compounding loop**: you don't produce in a vacuum, you draw on what the org already knows and leave it richer each pass.
|
|
15
|
+
|
|
16
|
+
## The loop — prime → build → compound
|
|
17
|
+
|
|
18
|
+
- **Prime (session start).** Pull accumulated value in. The system *enforces* this: you must search the wiki before working, and a project's attached skills, anchored frames, and layer rules are auto-loaded when you open it. Don't fight the gates — they make you start smart.
|
|
19
|
+
- **Build (the work).** Produce artifacts as frames on the surface.
|
|
20
|
+
- **Compound (session end / when you notice something).** Deposit learning back: capture knowledge, distill or fix a skill, harden the project. This is *your* responsibility — the system can't force it, so do it.
|
|
21
|
+
|
|
22
|
+
## Mental model
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
Organization
|
|
26
|
+
└── Project (a bounded piece of work, e.g. "Q4 strategy memo")
|
|
27
|
+
└── Layer (a stage of thinking, e.g. research → drafts → final)
|
|
28
|
+
└── Lane (a group of related frames, e.g. one competitor per lane)
|
|
29
|
+
└── Frame (an HTML / markdown / image file)
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
**Layers are stages** — they depend on the project's template. `project(action="create")` returns the active layers; always check rather than assume. **Frames have addresses** like `/layer/lane/filename`; the canvas auto-arranges them by layer (vertical) and lane (horizontal).
|
|
33
|
+
|
|
34
|
+
## The gates you'll encounter (and how to satisfy them)
|
|
35
|
+
|
|
36
|
+
These reset every session. A gate that blocks you tells you exactly what to call next — do it, don't work around it.
|
|
37
|
+
|
|
38
|
+
- **G1 — wiki search before work.** Before you read or edit anything, `wiki(action="search")` for relevant org knowledge.
|
|
39
|
+
- **G2 — prior-art before a new skill.** `skill(action="add")` requires a `skill(action="search")` first.
|
|
40
|
+
- **G3 — prior-art before a new project.** `project(action="create")` requires wiki + skill + `template(action="list")` searches first.
|
|
41
|
+
- **G4 — attached skills** are auto-injected when you open a project. Follow them — they're how the org does this work.
|
|
42
|
+
- **G5 — the project's anchored frames** are auto-injected on open. They are required reading (briefs, constraints, style guides).
|
|
43
|
+
- **G6 — a layer's rules** are surfaced when you work in that layer. Honor them.
|
|
44
|
+
|
|
45
|
+
## The commands (when to reach for each)
|
|
46
|
+
|
|
47
|
+
These bookend the loop. Prime/feed at the start, deposit at the end.
|
|
48
|
+
|
|
49
|
+
- `/drafted:onboard-drafted` — first run: orient + bootstrap the harness (seed wiki, starter skills, first project).
|
|
50
|
+
- `/drafted:ingest` — bring knowledge into the wiki (a research output, existing documents, or by interrogating the user).
|
|
51
|
+
- `/drafted:create-skill` — capture a repeatable procedure (with knowledge + prior-art search).
|
|
52
|
+
- `/drafted:create-project` — start a project or a reusable template (with knowledge/skill/template search).
|
|
53
|
+
- `/drafted:improve-wiki` — fix stale / wrong / fragmented knowledge.
|
|
54
|
+
- `/drafted:improve-skill` — fix a skill that underperformed.
|
|
55
|
+
- `/drafted:improve-project-harness` — turn corrections into enforced gates (anchors / attached skills / layer rules).
|
|
56
|
+
- `/drafted:extract` — session-end: deposit knowledge, a skill, and/or a template (the user picks which).
|
|
57
|
+
|
|
58
|
+
## Tool surface (action-based)
|
|
59
|
+
|
|
60
|
+
`project(list|open|create|update|move)` · `frame(read|write|edit|anchor|mv|search|…)` · `ls` · `skill(search|load|list|add|update|attach|…)` · `wiki(search|read|write|edit|mv|links|log|…)` · `template(list|create|fork|…)` · `focus` · `get_org` · `asset` · `layer`.
|
|
61
|
+
|
|
62
|
+
## Sign in
|
|
63
|
+
|
|
64
|
+
If a tool returns an auth error: on a desktop/CLI agent run the `auth(action="login")` tool (it prints a one-time URL; the user opens it). On the web/Cowork connector, authorization happens via the connector's OAuth — ask the user to re-authorize the Drafted connector in their settings, then retry.
|
|
65
|
+
|
|
66
|
+
## Working on the surface
|
|
67
|
+
|
|
68
|
+
- **Always `project(action="open")` first.** Every read/write operates on the active project. Use `project(action="list")` to find one. Every response includes a `project` field — verify it matches your intent before writing.
|
|
69
|
+
- **Default to the surface for substantive artifacts.** When asked to draft, write, plan, analyze, compare, design, document, summarize, report, spec, model, or make a deck/table, create or update frames instead of leaving the durable result only in chat. One visible frame per artifact or section.
|
|
70
|
+
- **Prefer Google Workspace when Drive is connected.** Call `get_org`; if it reports `googleDrive.connected: true`, use `frame(action="write", googleType="google-doc"|"google-sheet"|"google-slide", …)` for docs, sheets, and decks; populate immediately with the native write actions.
|
|
71
|
+
- **Read before editing.** `frame(action="edit")` uses hashline addressing — every line in a `frame(action="read")` response gets a 4-char hash; pass it to edit for surgical changes.
|
|
72
|
+
- **`focus` after writing** so the user watches your work land on their surface.
|
|
73
|
+
|
|
74
|
+
## Quality conventions
|
|
75
|
+
|
|
76
|
+
- **Match format to layer intent.** Research/strategy/copy are usually markdown; visual work (wireframes, designs, dashboards) is HTML.
|
|
77
|
+
- **Respect the template's conventions.** Read a `design-system` layer before `/designs/`; read an `audience` layer before `/copy/`.
|
|
78
|
+
- **Wireframes are low-fidelity** (grayscale, placeholders); reserve color and real content for the designs/final layer.
|
|
79
|
+
- **Choose dimensions to fit content** — `autoSize: true` for HTML, or explicit `width`/`height`.
|
|
80
|
+
- **Don't re-read unchanged frames** you already have this conversation.
|
|
81
|
+
|
|
82
|
+
## Surface URL recognition
|
|
83
|
+
|
|
84
|
+
Any URL containing `/f/{uuid}` is a Drafted frame link. Use `frame(action="read", path=URL)` to get its content and `focus(target=URL)` to pan the canvas to it. Never `WebFetch` Drafted URLs — the MCP tools authenticate properly.
|