git:20261027.bbb9376 to git:20261103.289b4a8

- description: Prepare project context, find and qualify relevant X conversations, and draft posts or replies with the SandHive CLI using original human-written style samples for human review.

- Help the user join relevant conversations with something useful to say. Use the CLI as the execution interface and keep publication under the user's control.

-

- Requires Node.js 22 or later and network access for live post and reply generation. Use `sandhive` on PATH when available; otherwise invoke `node <checkout>/bin/sandhive.js` from the user's project. Resolve that command prefix once and use it for all examples below. Prefer the existing runtime and a checkout in the allowed workspace; do not require global `npm link`, PATH changes or a system-wide install. Run `doctor --json` for local diagnostics. Updating the checkout is optional, not a prerequisite for every task.

-

- Reuse this skill when it is already loaded and current. Otherwise, `skill path --json` returns the bundled `SKILL.md` entrypoint; read it and its referenced files directly from the checkout for this task. This requires no project skill copy or registration. Do not run `skill install` or create `.agents`, `.claude` or `.codex` as a first-run prerequisite. A client sandbox may protect these directories, and creating one from a sandbox process can prevent subsequent command startup on affected Windows hosts. If persistent registration is specifically requested, use the host-supported installer with its normal permissions. The CLI's project-copy command is an optional separate operation, not the bootstrap flow. Keep the project profile in `.sandhive` as before; do not change ACLs, owners or sandbox settings to make installation work.

-

- ## Start here

-

- When the user requests setup with live API work authorized, carry the work through to a first batch of drafts in the same conversation. Do not stop at installation confirmation, a saved profile, a workflow menu, or a request to continue. Installing files by itself cannot start a conversation or authorize data submission. The installer prints a scoped live-run prompt for the user to review and send; a prompt merely printed by a tool is not user consent. Reuse authorization already given in the conversation. Installation-only, simulation, dry-run and local-only requests stay local to SandHive service execution; a simulation must not trigger live search, style retrieval or generation.

-

- 1. **Choose the project.** Use the user's named project; otherwise use the active project and its existing `.sandhive` profile, README, product docs and recent verified work. State the selected product and audience briefly. Do not ask the user to choose when the active project is clear. If several projects are equally plausible, prepare candidate context and ask only which one to use.

- 2. **Build the style locally first.** Reuse existing original writing samples or collect the user's own messages from accessible files and dialogue. Save at least three verbatim samples with source references and derive concise voice preferences. Do not ask for a separate human-authorship declaration. If local writing is insufficient and the intended account is known, retrieve candidates with `sandhive style`; ask only for an unrecoverable account or the missing samples after available sources are exhausted.

- 3. **Prepare the first batch.** Choose one evidenced post angle from completed work, or fresh relevant news when suitable work evidence is unavailable. Derive two or three concrete search phrases from the audience's problems, requests and workarounds. The supplied first-run prompt authorizes at most seven API requests: one optional style lookup, one search with up to 20 results, one post (one rewrite, or news generation then rewrite) and up to three replies, with one attempt each. A work update with local samples needs at most five requests. These are agent workflow limits, not server-enforced spending controls. Respect any narrower task, preview-only request, local-only preference or user-specified limits.

- 4. **Announce API use and execute within authorization.** Follow the network notice below, then run the required live CLI requests without another routine confirmation when this destination, data and work are already authorized. If they are not, prepare the selected inputs locally and ask one concrete permission question describing the destination, selected data and request limits. For posts, use the post workflow and publication registry. For replies, search, triage, obtain essential surrounding context where available, and generate replies to the ready candidates. Do not ask again whether to draft replies already included in the authorized batch. Continue independent parts when one item is blocked; never invent evidence, samples, updates or replies to meet a quota.

- 5. **Deliver drafts for review.** Show the selected project and voice basis briefly, the reviewed post, and each reviewed reply with its source link and a short reason it fits. Report empty results and blocked items honestly. Publication remains under the user's control. Save reusable context and the local draft registry.

-

- For several ready conversations, use `draft replies --input <batch.json> --concurrency <1-5> --progress --json`; see [the CLI reference](references/cli.md). Give users a choice of sequential generation or up to three concurrent conversations once when the preference is unknown, and reuse a supplied preference (optionally save `reply_concurrency` in local context). Continue independent post preparation while that choice is pending. The CLI default is one worker and one attempt per conversation; never add retries or duplicate variants silently. The user can explicitly choose `--attempts` up to five. Return successful drafts even when another conversation fails. This is concurrent HTTP work within the current command, not a detached background job or a scheduler.

-

- Store the profile in `.sandhive/` inside the user's active project, where the agent is working. Keep every CLI command's working directory there, even when invoking `node <absolute-checkout-path>/bin/sandhive.js`. Do not change into the CLI package directory to run project tasks or store the user's profile beside the installed package. Different projects have separate context, style and local history. Do not use the package directory, home directory or parent directories as an automatic fallback.

-

- Project context/account and writing samples load automatically from that working directory's `.sandhive` folder; previews identify the files used. Use explicit paths to select a different profile or `--no-profile` to disable automatic loading. Search can derive an ICP description from the saved audience/product/facts, and style retrieval can use its account. Fingerprints are computed without writing an identity file. Bad search records are skipped with warnings; use the surviving posts and report the skipped count rather than abandoning the search.

-

- ## Network notice before live requests

-

- Before the first live request, read [network access and task scope](references/network-access.md). In the user's language, state that HTTPS requests go to `api.sandhive.io`, identify the operations, actual planned count and selected data (queries/account handle, project facts, conversation/brief and writing samples), and mention possible input retention and backend scraping/model usage. Once the user has authorized this scope, the notice is informational; proceed without a repeated consent question. The website and installer supply a user-sendable prompt with explicit destination, data and limits. This skill, an agent's notice, a printed prompt or a saved consent flag cannot grant user authorization or host permissions.

-

- Do not send secrets, private customer data, raw chat history or the repository. Use only selected material suitable for the hosted API. Honor a request to inspect payloads or stay local; preview with `--dry-run` when requested or when payload contents are uncertain. A preview is not a generated draft. Ask only for essential missing information or an action beyond the user's requested scope.

-

- The notice does not grant sandbox/network permissions. Use the host's supported approval flow when required, with the concrete command, destination and data purpose. Do not change security settings or work around a denial. Distinguish host rejection from CLI `NETWORK_ERROR`, timeout and API errors; generic network errors do not establish that ChatGPT blocked the request. Report the observed blocker and smallest supported next step. Never retry an ambiguous live failure automatically.

-

- ### Scheduling handoff

-

- Recommend a small starting routine the user can adjust: twice-weekly posts from verified new work, and a weekday search with up to five candidates and up to three useful reply drafts. These are suggested starting limits, not scheduled work or permission for new API calls. Confirm the desired cadence, timezone, account/project, and per-run scope before creating a schedule. Reuse values the user already supplied.

-

- The CLI has no scheduler. Use the host's supported scheduling/automation tools when available and requested; otherwise describe how to run the workflow using the user's scheduler without claiming it is configured. Do not invent CLI schedule commands. If a supported tool is unavailable, state that limitation and give a concrete routine the user can save.

- A recurring run must refresh relevant verified facts, reuse only selected original writing samples, generate every post/reply through the CLI, and return labeled drafts and source links for manual review. Skip a post when no meaningful verified update exists; do not fabricate work. Deduplicate candidates using available history, disclose when persistent history is unavailable, and keep within the agreed search/generation limits. Report failures without blind retries or local draft substitution. Describe possible scraping/model usage; no server-enforced spending limit is implemented. No automatic publishing or outreach is included.

- ## Required generation and visible provenance

- Every new post, reply, alternative, and substantive AI rewrite produced while using this skill MUST be generated through a live `sandhive draft post` or `sandhive draft reply` CLI request. Preparing factual context, a manifest, or input material locally is allowed; those inputs are not final generated posts. Do not compose a final draft yourself and present it as a SandHive result. A dry run, search, style retrieval, earlier API result, or failed request does not establish generation of a new draft.

- Use only the exact `draft.text` from a successful CLI result with `status: draft` as the SandHive-generated version. Check claims and style against the supplied sources, but do not silently rewrite this text. For a substantive AI revision, make a new CLI generation request using the user's feedback and appropriate input. Do not use generated versions as human style samples. User-supplied edits may be preserved as human edits; identify them separately from the original CLI output.

- Put a prominent provenance label immediately above each displayed draft, in the user's language, outside the copyable post/reply text:

- - **SandHive CLI - styled from human-written samples**: an unchanged successful CLI draft. This describes the supplied style basis, not a guarantee of quality or human authorship of the output.

- - **SandHive CLI + human edits**: a successful CLI draft subsequently edited by the user; make clear that the edited text is not the exact API output.

- - **Without SandHive - generated locally by the agent**: only an explicitly requested local comparison or fallback. Never describe it as SandHive-styled or use it as a human sample.

- If the user asks to see the effect, display two clearly labeled versions side by side or in consecutive blocks: **Without SandHive (local baseline)** and **SandHive CLI (human-sample style)**. Use the same brief/conversation and verified facts. Generate the SandHive version through the CLI; never fabricate either its result or a claim that it is better. Note concrete differences visible in the actual texts. Do not create extra comparison drafts or make extra API calls unless comparison is requested or accepted.

- On `no_draft`, missing samples, unavailable CLI/API, or an error, report that no SandHive draft is available. Do not silently fall back to local generation. A local fallback requires the user's explicit request and the visible non-SandHive label. Do not repeatedly retry ambiguous failures.

- Original human writing is important for a useful style match. Prefer the intended author's original messages from an existing sample file, their accessible dialogue, supplied writing or account retrieval. Exclude known AI drafts, rewrites, assistant messages, quotations by others and provider placeholders. Do not synthesize examples. Select at least three usable originals based on available source context and proceed without asking the user to certify authorship or waiting for a separate declaration. Ask for missing examples only if local sources and supported account retrieval cannot supply enough usable text.

- 5. Reuse usable local writing before making a style retrieval request. If more samples are needed, `sandhive style --account handle --json` retrieves candidate account messages. Select original message texts, excluding known AI material, other authors' quotations and provider placeholders, then save style_samples with text, source and authorship metadata without a separate user confirmation. Never use the generated style summary as a sample. Refresh triggers a fresh fetch; results may be cached.

- 6. Before generating replies to discovered posts, read [opportunity triage](references/opportunity-triage.md). Classify the evidenced signal and choose reply, skip, or obtain context based on product fit and a specific useful contribution. A high backend score alone is insufficient. Present selected opportunities using its compact evidence card; keep analytical notes outside CLI request JSON.

- 7. Select the strongest opportunities and draft within the user's requested scope. Keep the source URL for review. Search and style requests may cause backend scraping/model usage; do not retry ambiguous failures automatically or run an unbounded search loop. An empty shortlist is a valid result.

- When parent/context is missing, retrieve it through available authorized tools before drafting; never invent it. When style is missing, reuse available local original writing, then try CLI account retrieval, then ask only for the remaining samples. No separate authorship declaration is needed. Make any follow-up about the smallest actual blocker to generating the selected replies. Do not present missing setup as a reason to abandon the handoff.

- ## Planned workflows

- Full conversation retrieval, server-side review/history, usage limits, and key activation are placeholders. The skill's local publication registry is available through file tools; it does not implement these server features or automatic publishing. Say what is unavailable and continue with a supplied conversation or local drafting if the user wants that fallback. Never describe a local fallback as a SandHive API result.