init-project

Project Initialization

Responsible for: project analysis, domain identification, writing the plan, running the review loop, generating artifacts (following ralph protocol directly), and final reporting. Not responsible for: reviewing the plan (architect/critic do that).

Autonomy: Execute all phases (1→2→3→4→5→6) end-to-end without pausing for user confirmation. Evidence gates are self-checks, not user approval points. Do not ask "shall I continue?" between phases. <Execution_Discipline> Work conventions that guard failure modes which recur in this protocol. They bind across all phases — treat each as a precondition, not advice. Governing principle: setup work is verified to the same bar as feature code — confirm against the authoritative source (the templates), never declare "sufficient" from memory or a partial scan.

1. Full-tree discovery before any "missing" conclusion. Never decide a template or reference is absent from a depth-limited or filtered listing. Run find {skill_base_dir}/templates -type f (no -maxdepth, no grep pre-filter) once and treat that inventory as authoritative. The "template not found" fallback may fire only after a full listing confirms absence.

2. Fixed artifacts are copied, never authored from memory. Every artifact the protocol calls fixed — templates/skills/tier-review/SKILL.md, templates/agents/{code,doc,test,ux}-critic.md — is produced by: read the template file → copy it → graft only project-specific hooks. Do not reconstruct it from another repo's output or recollection; you will drop required sections.

3. Read every template in full; obey directives in its body. Templates contain instructions, not only {placeholders} (e.g. tier-review's "add coral:architect to the list with tier 1 by default"). Read the whole file before instantiating and treat its imperative sentences as requirements.

4. Diff-against-template is part of Phase 4. Verification asserts each generated fixed artifact contains every section and directive its template has — a structural diff, not a frontmatter-key existence check. "name: present" does not catch a dropped section.

5. Enumerate concerns before writing agents; one agent per concern; justify omissions. In the Tier-2 fallback, first produce an explicit concern → severity → agent table for the domain. Give each distinct failure mode its own agent — do not bundle several into one guardian — and record in agents.md why any plausible agent was deliberately NOT created (covered-by-X), so the roster is a justified decision, not an accident.

6. Tier discipline is explicit. Tier-1/2 safety guardians are binary gates (PASS / NEEDS WORK on BLOCKING findings, no rubric); Tier-3 quality agents are rubric-scored. A guardian without a score and a critic with one are both correct — do not "fix" either toward the other. </Execution_Discipline>

Phase 1: Gather Context

1a. Detect Scenario

Check the working directory for source files:

Existing project indicators (any of these):

• package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, build.gradle
• src/, lib/, app/, csrc/, cmd/
• Makefile, CMakeLists.txt, Dockerfile
• README.md with project description

New project: Working directory is empty or has only basic scaffolding (e.g., .git/ only).

If ambiguous, treat as existing (safer).

1b. Extract Context

Parse the command argument for:

Field	Examples
Project description	"a CLI tool for...", "REST API that..."
Tech stack	"React + FastAPI", "Rust", "Next.js"
Architectural concerns	"must be serverless", "multi-tenant"
Reference material	"ref/codes", "github.com/...", "docs/spec.md"