postplus-workspace

PostPlus Workspace

Turn one resolved project folder into the durable context and control surface for repeated PostPlus work. Reuse confirmed brand, product, persona, and campaign facts; do not require workspace setup for a one-off task. Read only task-relevant facts, keep approved claims distinct from ideas, and change them only in scope. This skill owns workspace orchestration. Specialist PostPlus skills own domain judgment. The current PostPlus CLI and server own schemas, validation, cost, permissions, and provider execution.

Core Contract

1. Read the workspace before acting.
2. Keep confirmed facts, approved claims, research findings, hypotheses, defaults, unknowns, and forbidden content distinct.
3. Never invent product facts, prices, offers, identities, references, permissions, approvals, or results.
4. Ask only when missing or conflicting information changes truth, strategy, identity, execution, compliance, spend, or publishing.
5. Make reversible low-risk production choices without asking.
6. Discover current PostPlus capabilities by catalog and CLI schema instead of maintaining a hard-coded skill inventory.
7. Require explicit approval before changing approved truth, approving a test plan, spending credits, launching, publishing, or changing live ads.
8. Return durable results and decisions to the workspace.

Route

Initialize Workspace

1. Resolve the exact target folder and inspect existing files.
2. Run postplus doctor --skill postplus-workspace --json. Follow its concrete action if Python 3 is missing; if no executable action is supplied, report the dependency and affected task and stop. Do not guess a package manager, install command, or administrator permission.
3. Resolve this installed skill directory and run:

<python-3-command> <skill-directory>/scripts/workspace.py init \
  --target <folder> --project "<project name>" \
  [--brand "<brand>"] [--product "<product>"] \
  [--market "<market>"] [--platform "<platform>"] \
  --output <folder>/.postplus/workspace-init.json

Pass only user-supplied or reliably sourced values. The entrypoint creates missing files only and rejects filesystem roots, the user home directory, and installed skill directories.

Read existing source materials, fill only confirmed information, preserve UNKNOWN, then run the onboarding check.

Initialize Campaign

Run:

<python-3-command> <skill-directory>/scripts/workspace.py new-campaign \
  --target <workspace> --name "<campaign name>" [--slug <campaign-slug>] \
  --output <workspace>/.postplus/campaign-init.json

Fill the objective, market, platform, offer, CTA, KPI, constraints, and approval state. Set current_campaign in project.yaml only after confirming the intended campaign.

Resume And Execute

1. Find the nearest project.yaml at or above the working directory.
2. Read the nearest applicable AGENTS.md, then project.yaml.
3. Read only the stage context listed in context-schema.md.
4. Run the workspace stage check before high-impact execution.
5. Read the selected specialist skill completely.
6. Read current CLI help or schema only when the selected skill leaves a required argument unclear.
7. Continue from recorded state instead of recreating prior work.

If no workspace exists, offer initialization. Do not scatter project files into an unrelated folder.

Stage Rules

Follow stage-gates.md for onboarding, research, strategy, test, production, launch, and learning requirements. The bundled checker validates workspace files only; current quotes, provider validation, permissions, accounts, and live state remain authoritative at the CLI or server boundary.

Read uncertainty-policy.md when information is missing, conflicting, or a repair could change meaning.

Check Workspace

Treat BLOCKED as a stop for the affected stage. A local READY result does not replace current CLI validation, quote confirmation, or launch approval.

Status

End substantive tasks with:

Workspace and campaign templates are in assets/project-template/. The commands above use the non-destructive scripts/workspace.py entrypoint.