ext-develop

Extension Development

Use this skill to guide the workflow, not as a second API manual. The online references below own the detailed contracts, examples, and reload behavior. The local engineering checks below remain mandatory even when those references cannot be fetched.

Before designing or editing

1. Identify what the user wants and the smallest capability set that can provide it. Check existing host services and shared panels before building a replacement.
2. For behavior-only discussion, apply Engineering checks without enumerating APIs. Before specifying or implementing an interface, choose its one matching capability reference below; read the overview when container/scaffold/reload behavior is relevant. Reuse verified text still in context. For a named interface, obey the system prompt's strict lookup budget and stop as unverified when it is exhausted. Use the article's contract/examples, not the documentation site's navigation, styles, or scripts. If the user declined a fallback, request only the missing source and never ask again.
3. Confirm the proposed behavior, affected files, and visible result with the user before scaffolding or editing. Do not publish, restart, or add privileged behavior merely because implementation was approved.

Documentation fallback

1. Fetch the relevant official URL directly; a web search is not required. For truncated output, read the returned temp_file for the needed section. For HTML pages, web_fetch saves extracted text with whitespace collapsed, not original HTML: line-based reading may still return one long line. One targeted text extraction is enough to check a detail. Do not write helper scripts or try to reconstruct code formatting from that text; lost newlines can change the meaning of code comments and examples. A no-file-change task includes temporary files such as /tmp/*.py: only read the tool-returned cache, do not create a script or reformatted copy elsewhere.
2. If the needed contract is still missing, truncated, or ambiguous, stop this lookup. Report it as unverified; no match on a page does not prove the method or its namespace absent, private, or unsupported. Do not inventory other APIs to infer an answer. Do not retry extraction or probe other extensions/the running host to fill the gap. Ask permission to open the official documentation in a new browser tab. If already authorized for this task's documentation lookup, do not ask again for each page.
3. After consent, use the available browser tool to read only the relevant official documentation. Do not navigate, inspect, or close unrelated tabs. Read beyond truncated snapshots as needed; opening a page alone does not verify its contents. If browser setup is required, ask whether the user wants to use browser-setup; never enable it silently or bypass a disabled browser. If the tool is unavailable, do not invent another browser control mechanism or install one without approval.
4. If the user declines or the browser cannot retrieve the reference, ask the user to supply the documentation or designate a separate source checkout matching the running version and permit read-only inspection. Do not search installed OpenClacky gem source. Reading a checkout does not authorize modifying it to make an extension work.
5. If still blocked, end with only Unverified detail, Reference checked, and Evidence or permission needed next. For example: "I could not verify this method from this page; please provide its source." Do not turn that into "the object does not exist" followed by a disclaimer. Clarifying the user's goal may continue, but implementation against that contract must wait. Resolve version differences before relying on a contract; version metadata is allowed, installed implementation source is not.