create

name	create
description	Initialize or resume Cadre in a greenfield or brownfield repository using MCP-provided templates and human-approved product, engineering, workflow, styleguide, pattern, and project-state artifacts. Use for Cadre setup, project onboarding, or the create command; classify the repository first and do not overwrite an initialized project.

Cadre Create

Use the Cadre MCP as the authoritative runtime and template provider. Do not copy runtime code or templates into the project. Treat every rendered artifact and state mutation as a proposal until the human approves it. If required Cadre MCP tools are unavailable, stop and report that the plugin runtime is unavailable; never reconstruct templates from memory.

At every required clarification or approval boundary, show a concise summary or focused diff. Inspect the active host policy before calling workflow_elicit: if the task context reports approval policy never, including Codex Full Access, skip the form and ask the same short question once in chat. Otherwise prefer workflow_elicit, using clarification for at most three questions and approval bound to the current proposal digest. Treat only an approved result as approval. If it returns fallback_required, or immediately returns declined while the task explicitly reports policy never, ask the same short question once in chat; the latter is policy rejection, not a human decline. Never request secrets or retry the form.

Procedure

1. Resolve the exact project root. Inspect its manifests, source layout, tests, agent guidance, Git status, and recent history. Run git rev-parse --show-toplevel: if it succeeds, never initialize a nested repository; if it fails, record that the approved root requires git init. Ask which root to use if the boundary is materially ambiguous. Read every existing file before proposing an edit.
2. Explicitly classify the context as greenfield or brownfield, with evidence. A substantive implementation, behavior, user/data/interface contract, or delivery history is brownfield. If a scaffold, prototype, migration, or incomplete evidence makes the classification unclear, ask a blocking question before drafting or mutating anything.
3. Call project_status when .cadre/project.json exists and use its embedded structured validation; do not repeat state_validate at command entry. Reconcile its setup journal, worktree, and recent commits. Resume the recorded checkpoint exactly; do not restart or overwrite setup. Offer $refresh or $status only after completed setup.
4. Call template_get_many once for project/product, project/guidelines, project/tech-stack, project/workflow, and project/styleguides/general. Retain that versioned bundle across approval turns and do not refetch it unless its version or content hash changes. patterns/index.md, .gitignore, project.json, tracks.md, and the empty lifecycle directories are initialization outputs derived by the MCP; do not render or pass them as caller-supplied files. For greenfield work, use explicit user intent and ask about missing material product/stack choices. For brownfield work, distinguish evidenced current reality from desired change and preserve deliberate conventions.
5. Draft product.md, guidelines.md, and tech-stack.md. Resolve any material ambiguity through targeted questions; do not invent product behavior, constraints, or stack decisions.
6. Identify the proposed workflow.md by template ID, template-set version, content hash, and a concise summary of its material rules and consequences. Do not print the complete unchanged bundled workflow unless the human asks. If changes are requested, show a focused diff and summarize the resulting behavior; show the complete revised workflow only on request. Do not create a standalone workflow approval.
7. Call styleguide_resolve with the proposed technologies. Always include the general guide and resolve the applicable language, framework, markup, and build-tool guides as one set. Preserve evidenced brownfield conventions. Ask only when a material convention choice cannot be resolved from the request and repository; do not ask the human to accept each default guide or the final set separately.
8. Call project_init_preview with only the proposed caller-supplied files and metadata. Do not pass patterns/index.md or any other MCP-derived output. Expected human decision count is one when root, classification, and material configuration choices are clear. Present one complete initialization envelope containing concise product/engineering/stack summaries, workflow identity and summary, styleguide set and amendments, the complete target-path and SHA-256 manifest, generated-state summary, context classification, project root, Git disposition, and consequences. After explicit confirmation, pass only its opaque proposal token to project_init_apply. This one approval authorizes unchanged Git initialization, validation, setup commits, derived tracks.md, and provenance bookkeeping; do not add later approval prompts for those deterministic consequences. The apply atomically creates mutable .cadre state and approved context only; it never installs a runtime or template copies there.
9. If Git disposition is initialize, run git init only at the approved root, verify git rev-parse --show-toplevel equals that root, then call setup_record_git_initialized. If Git is unavailable, initialization fails, or a different repository appears, stop with the setup journal intact. For an existing repository, verify its root again.
10. Call state_validate and report the result. Commit the authorized setup as cadre(create): initialize project harness only when validation is clean and checkpoint is commit-pending; validation failure is a blocker, not a request to approve an exception implicitly.
11. Call setup_record_commit; it records the actual current HEAD. If the index needs regeneration, call tracks_render_preview and pass only its proposal token to apply. Commit the bookkeeping as cadre(create): record setup commit without another prompt and report the concise final result.

Resume protocol

• git-pending: initialize Git only when the journal says initialize; verify the exact approved root and record the checkpoint.
• commit-pending plus matching dirty artifacts: validate and create the expected artifact commit.
• Clean worktree plus matching expected HEAD/base relationship: treat the artifact commit as successful and record that SHA; never repeat it.
• Recorded setup SHA plus dirty bookkeeping: finish only the follow-up state commit.
• Journal, files, digest, worktree, or HEAD mismatch: stop and show the mismatch. Never guess, discard, or restart.

All later commands must read .cadre/workflow.md. Every file is rendered from a versioned MCP template, every multi-step mutation is resumable, and human approval gates artifacts and state changes.