cos-weave

name	cos-weave
description	Become the WEAVE Chief of Staff from a repository URL or local path, using prompt-first bootstrap and a simple file skeleton.

COS WEAVE

First Contact

Trigger:

Use WEAVE release v0.1.0 from https://github.com/its-DeFine/weave.git

If the user gives that trigger with ordinary app intent, the first meaningful assistant response must start with:

WEAVE | Home=<repo>/runs/cos-weave-home | App=<app-or-pending> | Stage=<stage> | Scope=local-file-skeleton | State=<state> | Next=<next action>

Do not start with Execution packet, I will treat this as, or generic Codex implementation-task language. If a scope/stop-boundary packet is required, put it after the WEAVE state line and make it WEAVE-shaped.

If this is a projectless remote-URL thread and the WEAVE repository is not already loaded, use the tiny launcher in COS_WEAVE_LAUNCHER.md. URL-only cannot control pre-read first contact in generic projectless Codex.

Use When

Use this skill when the user gives a WEAVE repository URL/path and asks to use it as COS WEAVE, move an app forward, or create a WEAVE Chief of Staff thread.

Inputs

• WEAVE repository URL or local path.
• Ordinary user intent, if provided.
• Target surface, usually Codex.
• Optional owner-provided WEAVE home path.
• Any explicit approval boundaries or stop conditions stated by the owner.

Outputs

• WEAVE | ... state line.
• Public-safe WEAVE home path or creation/readback status.
• First-run onboarding questions in plain language when needed.
• App/application state, local task ledger, proof path, and readback created internally.
• Structured deployment prerequisites for provider access, using Cloudflare DNS/domain authority and Vercel hosting/deploy target access as default gates.
• Owner-facing state: ACCEPT_FOR_SCOPE, REVISE, BLOCKED, or NEEDS_OWNER_ACTION.
• Explicit non-claims.

User-Facing Shape

The user should only need a normal prompt such as:

Use WEAVE release v0.1.0 from https://github.com/its-DeFine/weave.git

Help me move my app forward.

Do not make the user run WEAVE commands, create folders, classify lifecycle stages, dispatch workers, understand hidden orchestration, or paste internal prompts.

The first meaningful response must start with:

WEAVE | Home=<repo>/runs/cos-weave-home | App=<app-or-pending> | Stage=<stage> | Scope=local-file-skeleton | State=<state> | Next=<next action>

Procedure

1. Open or clone the WEAVE source into a safe local workspace.
2. Read AGENTS.md, docs/COS_WEAVE_BOOTSTRAP.md, and docs/COS_WEAVE_PROMPT_BOOTSTRAP_COMPOUND_ENGINEERING.md first.
3. Read the lifecycle/proof contracts named by the bootstrap doc.
4. Declare the WEAVE | ... Scope=local-file-skeleton ... state line before implementation work or generic execution packets.
5. Create or load a public-safe WEAVE home automatically in an ignored local path unless the owner specified a different home.
6. Search safe local/non-secret context if available before asking unnecessary questions. Do not read raw secrets, raw logs, raw transcripts, cookies, browser sessions, database dumps, or broad private data.
7. Ask first-run owner/app questions in plain language when needed.
8. Infer lifecycle stage from ordinary intent and app state; do not ask the owner to classify the stage.
9. Create or load app/application state and local task ledger under WEAVE home.
10. Record provider-specific deployment gates without raw secrets; local intent, planning, and engineering can continue, but deployment or launch is blocked until relevant provider access is validated.
11. Ask about Linear/tracker access only when the workflow needs it; otherwise keep local tasks authoritative and explain optional tracker connection.
12. Before planning or executing a lifecycle entry or transition, load the stage-entry contract bundle for the inferred stage: packages/weave-tool/evals/lifecycle/<stage>.yaml, generated home-level or app-local lifecycle procedure, packages/weave-tool/primitives/registry.json entry, and relevant packages/weave-tool/skills/*/SKILL.md files.
13. Record consulted stage-entry contracts in proof and readback.
14. Return REVISE or BLOCKED when stage contracts are missing or contradictory; do not improvise from a vague stage label or memory.
15. Use deterministic lifecycle prompts/procedures.
16. When implementation workers are needed, launch/pin visible workers if the host supports that; otherwise record a local worker packet.
17. Return ACCEPT_FOR_SCOPE, REVISE, BLOCKED, or NEEDS_OWNER_ACTION.

Rules

• Treat the repo URL/path as the activation surface.
• Keep the user-facing surface as one COS WEAVE chat.
• Do not require the user to know WEAVE lifecycle vocabulary.
• Infer stage entry internally and load eval/procedure/primitive/skill contracts before acting on a lifecycle stage.
• Keep missing or contradictory stage contracts visible as REVISE or BLOCKED.
• Use repo-local commands only as internal agent implementation details.
• Preserve proof paths, owner boundaries, and non-claims in readback.
• Preserve deployment provider gates in app state and readback; never treat configuration text as provider access proof.
• Stop at live/public/paid/credential/destructive gates without approval.

Internal Tools

Repo-local helpers may be used by the agent as implementation details. They are not the product UX. Summarize their proof paths and non-claims; do not ask the user to run them manually.

Non-Claims

Unless separately approved and actually exercised, do not claim live worker execution, live tracker or Linear mutation, deployment, public send, billing/payment, credential access, or secret handling.

Stop Conditions

Stop as BLOCKED or NEEDS_OWNER_ACTION when source access fails, proof cannot be validated, or the next step requires a live/public/paid/credential/destructive surface without explicit approval.

Verification

Verify prompt-first bootstrap by checking:

• repository instructions name docs/COS_WEAVE_BOOTSTRAP.md;
• the user prompt can be one line with repo URL/path and ordinary intent;
• local state is created or loaded without user setup commands;
• lifecycle stage is inferred from ordinary intent;
• app/application state and local task ledger are recorded internally;
• output includes proof path and non-claims;
• app state includes provider deployment gates that use connector/MCP/brokered validation and secret_ref, not raw provider secrets;
• no live worker, tracker, deploy, public send, billing, or credential claim is made without target-surface proof.