Draft Agent Loop

Enforce a Human-in-the-Right-Loop (HITRL) lifecycle for remote agents. Use this skill when the user wants structured oversight over an agent task: plan appro...

Security Scan

The skill appears internally consistent with its stated purpose (it uses the draft CLI to implement a human-in-the-loop workflow), but pay attention to publishing Task Journals to an external Draft service and the npm install step before you install or use it.

Purpose & Capability

The name/description match the requested artifacts: the skill is built around the 'draft' CLI and the SKILL.md exclusively instructs the agent to run draft commands (start-server, status, page create/append/publish). The declared install (npm @innosage/draft-cli) and required binary ('draft') are proportionate to the stated purpose.

Instruction Scope

Instructions are narrowly scoped to draft CLI operations and human approval gates, which fits the purpose. However, the skill instructs starting a daemon (draft start-server) and publishing pages to the Draft service; those actions can create local processes/state and will store content on an external service. The SKILL.md explicitly says 'does not write to local disk or agent memory,' which could be misleading if the draft daemon or CLI persists state locally. Also, publishing Journals may expose context that unintentionally contains sensitive data despite the 'do not include secrets' guidance.

Install Mechanism

Install is via an npm package (@innosage/draft-cli) that provides the 'draft' binary. This is a common, expected mechanism for a CLI; it is medium-risk compared to instruction-only skills because it pulls executable code from the npm registry. No obscure download URLs or archive extraction are used.

Credentials

No required environment variables or credentials are declared. There is one optional env var (GLOBAL_INVITE_CODE) used for publishing; this is reasonable and scoped to the Draft publish flow. The skill does not ask for unrelated secrets or cloud credentials.

Persistence & Privilege

The skill does not request always:true and is user-invocable (normal). It does instruct starting a draft daemon which may run in the background and persist session state — this is a legitimate runtime need for the draft CLI but is a form of persistence the user should be aware of.

Assessment

This skill is coherent for enforcing a human-in-the-loop process, but before installing or using it: 1) Review the npm package '@innosage/draft-cli' (source, maintainers, and recent releases) to ensure you trust the binary being installed. 2) Be cautious about what you put into Task Journals — publishing a plan or logs to an external Draft service can leak sensitive context if you include secrets, PII, or proprietary material. 3) Understand that 'draft start-server' runs a background daemon; check whether it writes local state or opens network endpoints in your environment. 4) If you have strict data-handling requirements, test the workflow in an isolated environment and confirm the invite/publish settings (GLOBAL_INVITE_CODE) before sharing pages externally.

Draft Agent Loop Skill (HITRL)

Use this skill to implement a rigorous human-agent collaboration loop. This is the "Human-in-the-Right-Loop" (HITRL) method, designed to eliminate "blind box" agent outcomes by forcing plan approval and result verification.

Scope: This skill orchestrates remote agent workflows using the draft CLI. All persistence is through Draft pages (via the canonical draft-cli dependency). It does not write to local disk or agent memory.

Trigger Guidance

Trigger this skill when:

• "Work on this task and check with me before and after."
• "I want to review your plan first before you do anything."
• "Use HITRL / use draft-agent-loop for this."
• "Apply structured oversight to this task."
• New task received where the user's intent is high-stakes or complex enough to warrant human gates.
• A new iteration is requested after a Phase 3 sign-off.

Do NOT trigger this skill when:

• The user asks to do a task directly with no mention of approval or review gates.
• The user only asks about raw Draft commands or page automation without approval gates (use draft-cli).
• The user wants a local-file authoring workflow (authorship in local markdown).

Core Rules

• Source of Truth: The "Task Journal" Draft page. All plans, logs, and results live there.
• Environment: Always use headless page mode through draft ... --runtime v2.
• Runtime dependency: Follow the startup and page-operation rules from draft-cli.
• Handoff Mode: Blocking. STOP and wait for human approval/sign-off in the chat before proceeding to the next phase.
• No Sensitive Data in Logs: Do NOT include credentials, secrets, tokens, or PII in execution log entries or plan documents. Limit evidence to status indicators and non-sensitive file names.

Phase 0: Setup & Connection

Before doing anything, establish a stable Draft connection:

# 1. Start the daemon in headless runtime v2
draft start-server

# 2. Confirm the session is READY before proceeding
draft status --json

If draft status does not show a healthy v2 headless session, follow the draft-cli recovery pattern:

• DAEMON_OFFLINE → re-run draft start-server
• wrong runtime selected → stop and correct runtime before writing
• Only proceed once draft status --json shows a healthy headless v2 session

Phase 1: Plan (Proposal & Approval)

Before executing any code or changes:

1. Create Journal: Create a new Draft page titled <Task Name> - Task Journal.

   draft page create "<Task Name> - Task Journal" --json
   

2. Submit Plan: Author a detailed Task Journal using the mandatory template. Append it to the Journal.

   cat << 'EOF' | draft page append <id> --json
   # 📋 Task: [Title]
   
   ## Context
   [Detailed background and motivation]
   
   ## Problem / Goal
   [Specific issue being solved or feature being added]
   
   ## Acceptance Criteria (Outcome-Focused)
   - [ ] [Criterion 1]
   - [ ] [Criterion 2]
   
   ## Implementation Notes
   [Current state analysis, relevant files, suggested approach, technical considerations]
   
   ## Test Coverage
   [Test strategy, scenarios to test, existing tests to reference]
   EOF
   

3. Confirm Before Publishing: Before publishing, explicitly confirm with the user: "I am about to publish the Task Journal for external review. Please confirm."

4. Handoff: On confirmation, publish the page and ask for approval.

   draft page publish <id> --invite-code "${GLOBAL_INVITE_CODE:-innosage}" --json
   

   Handoff Phrase: "I have initialized the Task Journal with the plan and requirements: [URL]. Please review the context and acceptance criteria. Once you are ready for me to proceed, please reply with APPROVED or LGTM here in the chat."

5. Wait: STOP. Do not proceed until the user explicitly tells you to continue in the chat. Note: Do not rely on Draft page comments for approval on remote/public pages.

Phase 2: Execute (Action & Logging)

Once approved:

1. Verify Approval: Confirm the user has provided approval in the chat.
2. Execute: Perform the tasks outlined in the plan.
3. Log Evidence: For every significant action, append a concise, non-sensitive log entry to the Journal under a # 📜 Execution Log section. Do NOT include raw command output, file contents, or credentials.

   cat << 'EOF' | draft page append <id> --json
   ### [Timestamp] Action: [Description]
   - **Status**: Success/Failure
   - **Evidence**: [e.g., "Modified src/components/Button.tsx — added reveal prop"]
   EOF
   

Phase 3: Verify (Result & Sign-off)

Once the execution is complete:

1. Submit Results: Append a # ✅ Final Results summary to the Journal. Include links to artifacts (e.g., PR URL, Draft page URL). Do not include raw file dumps.

2. Confirm Before Publishing: Explicitly confirm with the user before re-publishing.

3. Handoff: On confirmation, re-publish the page.

   draft page publish <id> --invite-code "${GLOBAL_INVITE_CODE:-innosage}" --json
   

   Handoff Phrase: "I have completed the task. Please verify the results in the Task Journal: [URL]. If satisfied, reply with DONE or ✅ here in the chat."

4. Wait: STOP. If the user provides sign-off (DONE / ✅), proceed to Phase 4. If feedback is received, enter the Iteration Loop.

Phase 4: Archive (Draft Page Only)

After sign-off, append a final summary to the existing Task Journal page. This keeps all persistence within Draft — no local filesystem writes.

cat << 'EOF' | draft page append <id> --json
# 🗂 Task Complete — Summary
- **Outcome**: [Brief description of what was achieved]
- **Key Decisions**: [Any notable trade-offs or design choices]
- **Artifacts**: [Links to PR, relevant files, or external references]
EOF

The Draft page itself (with its page ID and URL) is the durable record. No additional writes to TASK_LOG.md, knowledge/, or other filesystem locations are required or expected.

Iteration Loop

If the user provides feedback or requests changes after Phase 3:

1. Acknowledge: Acknowledge the feedback in the chat.
2. Start New Iteration: Enter Phase 1 again to propose how you will address the feedback.
3. Append to Same Page: Do NOT create a new page. Append the new plan to the existing Task Journal under a new heading: # 📋 Iteration [N]: Addressing Feedback.
4. Template: Use the mandatory Phase 1 template for each new iteration to maintain context and traceability.

Non-Goals

• Do NOT use browser-backed v1 or --mode workspace.
• Do NOT skip the plan approval gate.
• Do NOT execute multiple un-logged steps.
• Do NOT write to local agent filesystem (no TASK_LOG.md, no knowledge/ writes).
• Do NOT include credentials, PII, or sensitive command outputs in Draft page content.