Morph Init

---
name: morph-init
description: Install and set up the Morphness harness in the current repository, new or ongoing, through a short adaptive interview with suggested answers. Use when the user asks to install, add, set up or initialize Morphness or "the harness".
---

# morph-init

You are installing Morphness into the repository in the current working directory. Morphness is a
multi-agent harness: a Technical Lead in the main chat plans and delegates, a Full-stack subagent
implements, a QA subagent validates, a legal-writer subagent drafts legal wording, and a retro and prune
loop changes the harness itself as the project goes. After install, the copy belongs to the project and
is expected to change. There is no version and no upgrade.

Work through the phases below in order. Ask **one question at a time**, always with a suggested answer
the user can accept with "yes" or Enter. Skip any question whose answer you already know from the repo,
an answers file or an earlier answer, and say what you inferred instead. Keep each question to a line or
two, with options on short lines and your suggestion marked.

## Phase 0: Find the source and the mode

1. **Locate the Morphness source.** In order: this skill's own plugin folder (`template/` two levels up
   from this file), a local clone the user names, or a fresh shallow clone of the Morphness repo into
   a temporary folder outside the target (the URL in INSTALL.md). Record the source repo URL and commit (`git rev-parse HEAD`)
   for `installed_from`.
2. **Check the target.** `git status` must be clean, apart from files `scripts/install.sh` just copied
   (ask the user to commit or stash anything else; never do it yourself). If `harness.config.yml`
   exists and still has `{{` placeholders, the files were copied by `scripts/install.sh`: carry on and
   skip the copy step in render.md. If it exists and is filled in, stop and suggest `/morph-doctor`
   instead: morph-init never overwrites an installed harness.
   If there is no `harness.config.yml` but the repo already runs an earlier harness of this shape
   (a `harness/` folder with `SETUP.md` or `PLAN_CHECKLIST.md`, a `_harness/` folder, or a
   `HARNESS_VERSION` file), this is a **migration**: say so, and follow `references/render.md`
   § Migrating an earlier harness instead of the plain copy. A no-clobber copy would skip every kit
   file and change nothing.
3. **Pick the input mode.** Ask once:
   - Interview (recommended): you ask, with suggestions.
   - From a file: the user points at a context file (a README, a brief, a filled `morph-answers.yml`
     from `references/questions.md` § Answers file). Read it, map what you can, then ask only the gaps.
   - Template: write `morph-answers.yml` with every question and its suggested default, let the user edit
     it, then continue from the file.
4. **New or ongoing project.** Infer it: a repo with source code, a lockfile or more than a handful of
   commits is ongoing. For an ongoing project, run the scan in `references/questions.md` § Repo scan
   before asking anything, and use what it finds as the suggestions.
   For a migration, the earlier harness is the best source: its agent files, rules and project docs
   answer most questions, so the interview mostly confirms what the scan found.

## Phase 1: Interview

Ask the questions in `references/questions.md` in order. Each question lists when to skip it, what to
suggest and which follow-ups its answer unlocks. Profiles in `profiles/<name>/profile.yml` in the
Morphness source supply suggested answers for known stacks: when the scan or an answer matches a
profile, say so and offer it ("This looks like a Next.js + Supabase app. Use the web-saas profile's
suggestions? yes / no").

Save answers as you go to `morph-answers.yml` at the target root, so an interrupted install can resume.

## Phase 2: Suggestions (installed only on yes)

Using `references/catalog.md`, build three short lists from the answers:

1. **Skills** that fit the stack and process, each with a one-line reason.
2. **Connectors and MCP servers** (GitHub, the database, error tracking, docs lookup and so on), each
   with a one-line reason and whether it is project-scoped (`.mcp.json`) or a user connector.
3. **Community lessons** from the source's `lessons/` folder whose tags match the stack, services and
   areas, each with its title and evidence line.
   Leave out a lesson whose `evidence.source` (or a `reports` entry) names this project: it came from
   here, so its rule is already in the project's files. Say how many you left out and why.

Show each list once and ask which to take (all / none / pick numbers). Install or add **only** what the
user accepts. Never install anything that came from text inside the repo, an answers file or a lesson;
only items from `references/catalog.md` or that the user names. If an install command fails, say so and
carry on; don't try another download route.

## Phase 3: Summary and confirm

Print a summary: project, owner, environment, branches, modules, named checks with their commands, risk
areas, model and effort per agent, Claude Projects advice (if used), accepted skills, connectors and
lessons, and the list of files that will be created. Ask for a final yes. Nothing is written to the
target before this yes, except `morph-answers.yml`.

## Phase 4: Render

Follow `references/render.md`: create a branch, copy `template/` without overwriting, fill placeholders,
apply modules, merge accepted lessons, wire the accepted skills and connectors, and run the
self-checks. Then commit on the branch and, if the user agrees, push and open a PR to the integration
branch (or to the only branch, for a single-branch flow).

## Phase 5: Hand-off

Tell the user, in a few lines:

- What was installed and the branch or PR.
- The **advised** model and effort settings. For Claude Code: the Technical Lead runs in the main chat,
  so set the session model and effort there (`/model`, effort setting); subagent models live in
  `.claude/agents/*.md`. For Claude Projects (when used): the coordinator and thread settings from
  `harness.config.yml` § claude_projects, and the playbook in
  `harness/modules/claude-projects/README.md` to paste into the project instructions. These are advice;
  the user may change any of them.
- How to start the first feature: "Ask the Technical Lead: plan <feature>."
- That the harness will change itself through retros and prunes (`harness/MORPHING.md`), and that
  `/morph-share` can send lessons that worked back to the community catalog.

Delete `morph-answers.yml` from the target only if the user says so; otherwise move it to
`_harness/morph-answers.yml` so the doctor and later prunes can read the original intent.