Content plan

Your content plan is a short list of what to write next. It groups ideas into clusters, explains why each idea matters, and suggests dates.

The plan does not write articles. Each item links to researched briefs that your own agent writes from. See Writing briefs.

Create or update

Each item has an action.

create means write a new page. Example: you explain pricing on a call but have no pricing guide, so the plan suggests a new guide.
update means improve an existing page. Example: you have a short services page and visitors need more detail, so the plan suggests an update and points to that page.

New plans use your account time zone, detected from your browser on your first dashboard visit. Change it in Account settings if needed. Existing plans keep their saved time zone and dates. API-only accounts without a preference can supply a time zone when generating; otherwise they use UTC. The default cadence is Monday, Wednesday, and Friday. You can also choose daily or every N days, up to every 30 days.

The horizon is simple. Trial workspaces plan until your actual trial end. Paid workspaces plan 30 days ahead.

If you set a date by hand, the plan keeps it. Automatic scheduling only fills dates you did not lock.

Editing safely

When you edit an item, cluster, or cadence, include the current revision as expectedRevision. If someone else saved first, you get a 409 conflict. Reload the plan, copy your change onto the newest revision, and try again.

Tool names

API:

read: GET /api/v1/plans/:id
generate: POST /api/v1/plans/:id/generate
item: POST /api/v1/plans/:id/item
cluster: POST /api/v1/plans/:id/cluster
cadence: POST /api/v1/plans/:id/cadence

CLI:

plan read --id
plan generate --id --json
plan item --id --json
plan cluster --id --json
plan cadence --id --json

MCP:

plan_read
plan_generate
plan_item
plan_cluster
plan_cadence

Guided generation uses two model stages in one bounded planning operation and then returns the saved plan on repeat. Item, cluster, and cadence edits are free metadata changes with no provider calls.

Business outcome diagnosis

A new plan starts by identifying the customer, the business outcome and the path from a useful page to product value. It audits the saved business profile, original site excerpts, content inventory, Google report coverage and market evidence. It considers useful needs that current traffic does not capture. The saved result includes assumptions, measurement limits and questions that could change priorities. Each selected action includes a path to customer value and a success measure.

Search Console shows observed searches. Analytics sessions and key events do not establish retained customers or verified payments. Missing measurements remain unknown. Small cohorts do not establish a winning keyword. Older saved plans remain unchanged and explicitly show that they have not been reassessed.

Optional outcome evidence from your agent

Your agent can supplement saved evidence using its own authorized analytics or commerce connection. Kitecraft does not currently query PostHog or your commerce database automatically. Do not send connection credentials, people records, emails, session recordings or raw traces. Use aggregate reports scoped to this project. This is optional, and does not add a required onboarding step.

Before collecting, establish the useful product action and the business outcome from the actual offer. Then check:

Correct production project and host, reporting dates and timezone.
Event definitions, missing instrumentation, internal/demo exclusions and attribution coverage.
Eligible acquisition cohorts, signup, useful activation and return behavior. Keep people, sessions, events and accounts in separate reports. A repeat-event count must not use a people denominator.
For commercial outcomes, distinguish trial, active subscription, invoice and collected payment. An active record is insufficient payment evidence.
Product or supply limits that more traffic cannot fix. Compare business relevance, realistic competition and existing coverage before recommending articles.

Only retrieve data that can change a decision. Label proxy outcomes and unknown counts. Each report supports at most 12 metrics; supply at most six reports and 30,000 characters total. Counts use null for unknown. The result records these as customer-agent supplied, not independently verified by Kitecraft.

Send outcomeEvidence in the existing generate payload. This synthetic example illustrates the contract:

{
  "outcomeEvidence": [
    {
      "system": "posthog",
      "scope": "Production-host first-entry cohort, synthetic example",
      "startDate": "2026-09-01",
      "endDate": "2026-09-10",
      "timeZone": "UTC",
      "collectedAt": "2026-09-11T12:00:00Z",
      "grain": "people",
      "exclusions": "Exclude staff, demo and local-host activity.",
      "limitations": ["Small cohort; no person-to-search-keyword attribution."],
      "metrics": [
        {
          "segment": "Decision guide entrants",
          "outcome": "Saved a useful plan",
          "count": 3,
          "eligibleCount": 20,
          "meaning": "activation",
          "verification": "recorded"
        }
      ]
    }
  ]
}

Use the object as the body of POST /api/v1/plans/:id/generate, the JSON value of plan generate --id PROJECT_ID --json '…', or the arguments of MCP plan_generate with an additional id. In the UI, expand Customer outcome evidence (optional) and paste only the outcomeEvidence array. See the generated API schema for allowed values.

An existing saved plan is returned unchanged, even when new reports are supplied. This operation does not refresh or replace an existing strategy. New business intent also flows into the researched brief and the customer's writing packet; private analytics are not added to the writer's assignment merely to explain a conversion path.

Adaptive investigation

For a new plan, choose Adaptive investigation under Strategy research, or send "strategyMode": "adaptive" alongside optional outcomeEvidence in the same API, CLI or MCP generate payload. Omission selects adaptive; send "strategyMode": "guided" for the two-stage comparison control. Existing plans are returned unchanged, regardless of this option.

Adaptive investigation lets the model inspect supplied evidence, search this project's saved content, search the public web and open discovered pages, and refine focused keyword research when the server has authorized those providers. Saved-content searches return short leads; the agent can request a longer saved passage. Public browsing uses search/page-read providers, not a logged-in browser. It uses at most four investigation model calls and twelve tool calls, including at most two provider-research requests sharing the existing provider ceilings. The last investigation call cannot use tools. The existing final selection stage follows, so a plan uses at most five model calls. There is no automatic model retry or fallback. Denied or missing research is reported as unavailable.

This does not grant access to PostHog, billing, arbitrary databases or credentials. Supply scoped aggregate outcome evidence through the existing input when available. Tool results are untrusted evidence. A saved plan records its mode; the operation's model metadata retains per-step requests, results and usage for audit. Actual provider-reported cost can be unknown.

Adaptive is the local default for new plans. Strategy calls currently use OpenRouter openai/gpt-6-luna at high reasoning with no automatic fallback. This configuration remains experimental: the September 29 recorded-evidence comparison did not pass the usefulness threshold, and some runs failed structured-output validation. Existing plans are not regenerated. Other product generation models are unchanged.

Local owner comparison

Run bun run strategy:compare for a zero-call dry run. The manifest under .local/strategy-comparison/<timestamp>/ describes identical synthetic inputs, their hash and the review criteria. It reports quality as unmeasured.

With separately scoped model-call authorization, bun run strategy:compare --reasoning low --mode both --execute --approve-model-calls compares the two modes on those same synthetic inputs. This command can make up to seven model calls total and makes no fresh external research purchases. It requires the configured OpenRouter key. Inspect blind.json before reveal.json; full proposals, usage, reported costs and tool receipts are in each mode's artifact. A completed run means valid artifacts, not a quality win. This fixture does not measure the value of live analytics or fresh market research.

The local harness accepts --reasoning low|medium|high, --mode guided|adaptive|both and --context <sanitized-context.json>. Supplied context must use the shared PlanningContext contract and have separate scoped authorization before model calls. The harness searches only frozen inventory excerpts and buys no fresh research. It is not equivalent to the full production project inventory. Failed runs preserve completed stage artifacts. --resume .local/strategy-comparison/<run> requires identical input/model/settings and reuses recorded stages; completed comparisons cannot be overwritten. Invalid cached results fail validation instead of silently purchasing replacements.

Partial evidence and interrupted responses

An unknown source reference does not discard the whole strategy. The original generation remains in its audit record; verified citations exclude unknown IDs and the saved plan shows a limitation. A recommendation with uncertain references remains visible as Needs validation and is not automatically scheduled. Existing-page updates still need a real read target; the system does not invent the page being updated.

A plausible business pilot can be recommended with explicit validation questions even when demand, competition or overlap are uncertain. Missing data should not turn every useful idea into a rejected plan. Known adequate coverage still warrants skipping duplicate work.

The local comparison supports --project <local-project-uuid> to search the complete scoped local inventory using the same retrieval operation as the app. It is restricted to the dedicated local V2 database. Fresh public research stays disabled unless the existing configured research allowance matches that project. Dry-run does not query the project or spend. Live-project runs cannot use frozen-run resume because their inventory can change. Structured-output failures retain available text, step responses and token usage in failure.json; they are not silently accepted as complete plans. No automatic model retry is added.

Research the next batch

Once a plan is saved, choose Research next batch in the dashboard. Kitecraft investigates current evidence against your previous assignments, then adds up to five distinct recommendations. It can return fewer or none when the evidence does not support useful additions.

Previous item IDs, edits, dates, states, clusters and citations remain available. Existing researched packets stay frozen. While a batch runs, the saved plan is readable and plan edits are rejected with a clear conflict. A failed batch leaves the saved plan intact.

Use POST /api/v1/plans/:id/extend, kitecraft plan extend, or MCP plan_extend. Pass the current plan's expectedRevision and optional generation fields. This is a research write and needs an active trial/subscription and write access.

kitecraft plan read --id "$PROJECT_ID"
kitecraft plan extend --id "$PROJECT_ID" --json '{"expectedRevision":4}'

A repeat of a completed batch's admitted base revision returns the saved result without another model run. A busy or stale request returns a conflict before buying work. First-plan generate continues to return the existing plan; use extend for new opportunities. Each extension retains a lastExtension record with the admitted base revision and added IDs. Planning attempts remain bounded by the existing daily and retry limits.