--- name: kitecraft-writing description: Prepare calendar work from a Kitecraft packet or saved-input commission with one writer, a fresh independent editor and durable recovery. --- # Kitecraft writing workflow Version: 1.0.4 Start with project_context and confirm the project. For calendar work, claim the eligible item and read calendar_commission. A researched article uses its current sufficient brief_read packet and frozen instructions. A supported small_update can use the current saved-input commission and complete editable CMS baseline without buying a brief. Flag unsupported claims and material gaps; ask before paid research. The packet contains a working input and a complete research archive. Start with the working input and the applicable stage instructions. Locate and read relevant original sources by ID as the piece needs them. The structured archive repeats material for software clients; do not load that entire export into the active commission. Give the fresh editor the same working input, relevant original passages and access to the complete archive. Research proposals and observed website style remain references, not competing instructions. Before writing, read the current article materials returned alongside brief_read or retrieve them through material_list/material_read. Full transcripts are separate from the immutable research packet. Use editedTranscript when supplied, otherwise transcript; retain the original and question for attribution. Customer recollections are assertions, not independently verified facts. For a new recording, use kitecraft material upload with a local file or the scoped upload capability from material_upload, then material_transcribe. Never pass local filenames to the remote server as if it can read them, and never paste large audio blobs into chat. Interviews are optional. Before writing, understand the business, intended reader, actual task and supplied material. Decide what is worth saying, why the reader would care and how it serves the business. Keep this conception revisable as you read. Calendar work retains the exact saved commission and its commissionHash before drafting. No extra model commissioning call or rigid outline is required. A story, guide, explanation or argument can all work. Genuine author notes can supply insight without making every article a founder story. If asking optional interview questions, first explain the article, reader, purpose and how the answers will help. ## One writer Give the writer the packet evidence instruction, then its draft instruction, then the complete working input. Keep the full source archive available by source ID. Let the writer choose relevant passages rather than pasting every release note, procedural page and sample brief into its active context. Use the actual customer task and update scope. Return the complete Markdown draft. ## One independent editor Start a fresh editor context. Give it the same original working input and complete archive, plus the full draft. Assemble its instructions as evidence, frozen editorial skill, then edit instruction including the required output schema. Pass original passages discovered while drafting as evidence when useful, without writer reasoning, ratings or a lead's preferred rewrite. The editor forms its own diagnosis and implements the best article: it may change the opening, rebuild the argument, cut sections, reorder and rewrite. Work on the reader's experience and the article's contribution, not only sentence polish. Preserve strong material and meaning. A tighter complete article is preferable to a longer inventory. Return the full revised article and separate meaningful changes/gaps in the packet's EditDelivery envelope. Use host-authorized research tools when useful. This skill grants no provider spend or publishing permission. Retain the actual writer/editor requests, source reads, models/settings and both articles. Evaluate only after generation. Do not add an automatic judge or paid repair loop to this two-stage recipe. A separately authorized final-article assessment follows the optional evaluation contract below. If generation is incomplete, retain the failure rather than presenting the draft as the final edited article. ## Monthly, bulk and recurring calendar work Use calendar_month for an explicit horizon, intended slots, cadence and timezone. It saves metadata, preserving existing work. Inspect remaining slots and anticipated work, then ask before calendar_month_resume with authorizeOneBatch=true. Reuse the request and batch IDs to recover completed work. Each separately authorized batch adds at most five useful actions. Read state with authorizeOneBatch=false. Both modes use calendar_read, calendar_claim and calendar_report. Bulk mode prepares eligible work ahead of time. Recurring mode lets the customer's scheduler read due/upcoming work at the chosen frequency. Saving preferences enables no live job. Fetch tool schemas for exact inputs and the workflow guide from project_context for the complete walkthrough. Retain commission, draft and independent-review references and hashes in the customer workspace. Report them against the returned claim token and latest work revision; heartbeat during long work. After interruption, reclaim and resume retained artifacts. A fresh editor reviews the current draft and original sources. Apply the owner-selected approval and research policies before CMS work. For updates, fetch the current authoritative editable CMS source and revision, including body, structured FAQ/SEO, relations, slug and publication state. Website extraction and read-only fallback establish evidence, not CMS write readiness. Preserve live identity, canonical URL and original publication date. Keep a reviewed patch until due, or use a verified scheduled-revision capability that leaves the canonical page live. Before authorized external writes, retain one CMS intent. Use verified server-consumed idempotency with a conditional revision check, or the explicit existing-identity conditional-write/readback contract. Reconcile uncertain responses before any repeat send. Report observed receipts and the applied draft hash. On a challenge preserve drafts and report the integration blocker. On uncertainty reconcile the retained intent before sending again. A planned date, reviewed draft, approval, confirmed CMS schedule and observed publication are separate states; Kitecraft receipts remain customer-agent-reported. ## Focused inputs and honest source roles Read brief_read view=writer or view=editor for the selected stage. Read relevant saved passages with view=source and sourceId; offsets, chunk hashes and full content hashes identify the exact saved bytes. Follow nextOffset until the selected input is complete. Extent full/excerpt/snippet describes what was actually stored, not fresh verification or a hidden fetch. The immutable archive remains available without loading it into every commission. Use material provenance, question, creator, speaker, dates and revisions. editedTranscript is current; retain the original. Agent assessments and hypothetical examples are not owner testimony or personal experience. Unspecified historical material needs attribution before it supports an experience claim. A complete authorized read-only editable baseline can support small_update commission, draft and independent review while the ordinary CMS route is challenged. Retain exact artifacts through lease reclaim. Report truthful capabilities. CMS publication stays blocked until ordinary authorized access, conditional revision checks and either server-consumed idempotency or the explicit existing-identity conditional-readback contract are verified. No fresh brief purchase is required for supported edits. ## Reconcile the destination package after editing Read brief_read view=delivery. SEO title, SEO description and slug are named proposals, not approved fields. Reconcile them with the final edited text: remove examples or promises the editor removed. Apply the customer publication profile separately from the general prose recipe, including title/body H1 rules, excerpt, quick answer, FAQ, SEO, relations, image and locale decisions. Missing fields remain explicitly missing. Save one exact destination package and its validation artifact using calendar_report action=delivery. The fresh editor reviews exact article and metadata bytes and reports packageHash. Approval binds that packageHash. Changed article or metadata invalidates the old review and approval. Editorial quality, package validation, owner approval, CMS scheduling, observed publication and public SEO verification are separate checks. Do not turn a preview or local validator into a public-publication claim. Inspect whether the reader can make the promised decision using the final article. Preserve useful concrete comparisons when cutting. A passing structure check alone proves no reader payoff. Optional media, generated images and new research require their own authorization. Monthly authorization returns a durable batch ID promptly; use authorizeOneBatch=false for free reconciliation. A failed, unknown or exhausted request does not authorize another purchase. Resume retained reviewed/approved work at its returned next action, not by rewriting it. Saving preferences never enables recurrence. ## Optional Kitecraft final-article evaluation calendar_report action=review records an external editor verdict. It does not execute Kitecraft evaluation. For that separate assessment use article_evaluate. Read its schema, record the current calendar_commission, and submit the complete final article text, exact UTF-8 SHA-256, project/item, commissionHash, packetHash (or null), materialRevision, customer publicationProfile and named deliverables. Optional sourceIds select exact saved packet sources; defaults select article evidence and list omitted sources. No background source silently becomes verified. Remote services cannot open your workspace path. CLI evaluation submit --id PROJECT --file submission.json reads your local JSON and uploads its text, not the path. Submission is free and returns operationId and customer allowance impact. Read article_evaluation_status or article_evaluation_resume authorizeEvaluation=false for free. Ask before authorizeEvaluation=true: one included evaluation unit per exact input, up to two model stages, no extra charge. Current limits are 7 per trial or 30 per paid project period. Internal provider/model costs and margin receipts remain private. An exact repeated submission reuses its operation and reserved allowance. Keep that ID across interruption. A started stage with unknown outcome cannot be bought again automatically; retain completed stages and request operator reconciliation. Unstarted queued stages may resume without another reservation. Reader-only findings assess payoff, contribution, structure and clarity. Evidence-aware findings separately assess actual customer voice, material factual support, citation fidelity, firsthand provenance and applicable deliverables. Pass does not override missing sources, factual contradictions or fabricated experience. Read exact passage anchors, source IDs, quoted support, severity and corrections. Missing evidence remains needs_material. Submit corrected exact bytes with a new requestId and obtain applicable allowance authorization. A result binds article, commission, packet, material and rubric hashes; stale results remain historical. Neither Kitecraft evaluation nor external editor review grants owner approval or CMS readiness. For a supported small_update, submit complete baselineMarkdown matching the reported source.bodyHash and exact unambiguous before/after changes reproducing the final article. Evaluate the changes and their fit proportionately; do not claim unchanged legacy facts were reverified. No researched brief purchase is required. ## Complete handoff and metadata preservation Read brief_read view=delivery and view=evaluator. Proposals are named title, slug, SEO title, SEO description, summary/quick answer, internal links and source references. Reconcile every applicable field after the final edit. Reader questions guide sections; optional interview questions collect real testimony; published FAQs need supported answers and a destination requirement or reader purpose; visibility-monitoring questions are separate. Preserve the existing article FAQs, including separately stored answers. Do not add filler FAQs, an anecdote, word count or citation quota. For calendar_report action=source use preservedFields=["body","seo","faq","relations","slug","publication"], including verified explicit empty values. Descriptive phrases are not wire categories. Report omissions truthfully. A complete read-only baseline permits editorial progress with publication still blocked. Corrected transcripts take precedence; original text, speaker/creator, role, hashes and revision remain accessible. Agent assessment is never owner testimony. A proposed metadata change, such as hero alt, is separate from the original preservation baseline. When metadataHash changes supply metadataSnapshot JSON with seo, faq, relations, slug, publication, canonicalUrl and other in source, delivery and observed receipt. Include all other metadata under other. Hash the exact JSON UTF-8 bytes. Declare approvedChanges with exact JSON pointer and before/after hashes of JSON.stringify(value), for example /seo/hero_image/alt. For an absent JSON pointer hash the literal UTF-8 string undefined; explicit null hashes null. Only those changes may differ; package review/approval covers those bytes. Original canonical URL, slug and publication fields stay preserved on a live update. Body is bound separately to draftHash. A changed package needs renewed review and approval. Report truthful CMS capabilities. Conditional revision checks with server-consumed idempotency are supported. For an existing verified CMS content ID, an adapter may instead attest conditional_readback, revisionPrecondition=true, completeAuthenticatedReadback=true, ambiguousOutcomePolicy=reconcile_before_retry, targetIdentity=existing_content_id and retained capability evidence. After an uncertain response read back the complete exact draft/package, identity and revision before considering another send. Do not claim unsupported idempotency. This is a receipt contract; the customer's adapter owns CMS authentication, field mapping, locale, writes and public verification. Audio capture may happen in the customer agent or client. Reuse material_import or existing upload/transcription/correction operations for accepted formats. Capture is optional; a recorder UI or tool is not required. Preserve audio/transcript references and the exact corrected text, speaker, creator, question and revision. Visual direction follows the final article hash and customer style/crop profile. Use the delivery prompt-building instructions, factual/provenance/rights limits and an explicit generation label. A prompt, generated bytes, pixel-reviewed alt text, uploaded receipt and verified public asset are different states. Kitecraft starts no image generation or publication.