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 first, then group them into the fewest agents that keep each one sharp. Every agent is a separate spawn that re-reads the diff and its context on every review, so an agent that could have been merged is a cost the user pays forever. Before writing any agent, produce one concern table for the whole project (all domains together): concern → severity → invariant → trigger (which diffs invoke it) → already proven by a gate? Then form the roster from it:

   • Exclude a concern a deterministic checked-in gate already proves (build, CI, a release or check script). Name that gate; no agent duplicates it.
   • Merge concerns whose triggers coincide — they would read the same diff at the same lines. The merged agent fixes its concerns as ordered stages in its protocol, so merging never drops a perspective.
   • Never split one invariant by language, directory, or crate; it has one owner.
   • Keep agents apart only when their triggers differ, so each is invoked without the other, or when their invariants differ enough that one prompt would blur both.

   Beyond three domain agents (fixed critics not counted), each additional one needs a written reason it cannot merge — its trigger or invariant differs from every other agent's. Record every merge and exclusion in agents.md ## Excluded Agents (covered-by-X, or proven-by-gate), 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. Documentation reviewers are the separate doc tier — rubric-scored like Tier 3, and run last, after the code fixes, under tier-review --gated. Never put a documentation reviewer in tiers 1–3. 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