@phren/cli 0.0.1

package/skills/sync/SKILL.md

@@ -0,0 +1,261 @@
+---
+name: sync
+description: Sync your Claude skills and project config across machines using profiles.
+dependencies:
+  - git
+---
+# phren-sync - Profile-aware sync
+
+> Sync your Claude skills and project config across machines using profiles that control what goes where.
+
+Phren carries your skills and project config between machines. Profile-aware: he only syncs what belongs on this machine.
+
+## Prerequisites
+
+This skill requires a phren repository. If you don't have one yet, see "New machine setup" at the bottom.
+
+**Expected structure:**
+```
+~/.phren/               # or wherever your phren repo lives
+  global/               # skills and config for all projects
+    skills/             # global skill files (.md)
+    CLAUDE.md           # global Claude instructions
+  <project>/            # per-project config
+    CLAUDE.md
+    skills/
+    summary.md
+  profiles/             # machine profile definitions
+    work.yaml
+    personal.yaml
+  machines.yaml         # maps machine names to profiles
+```
+
+If any of these are missing, the skill will tell you what to create and how.
+
+## How it works
+
+Phren uses profiles to decide what goes where. A profile is a list of projects. A machine is mapped to a profile. When you sync, phren only brings over the projects in your machine's profile.
+
+## Sync down (pull to this machine)
+
+When the user says "get my skills", "sync my config", "pull from phren", or just "phren-sync":
+
+### 1. Find the phren directory
+
+```bash
+PHREN_DIR="${PHREN_DIR:-$HOME/.phren}"
+ls "$PHREN_DIR" 2>/dev/null
+```
+
+If the directory doesn't exist, tell the user:
+> "No phren repo found at ~/.phren. Clone yours with `git clone <your-repo-url> ~/.phren`, or set `PHREN_DIR` to point to a different location."
+
+### 2. Figure out which machine this is
+
+```bash
+cat ~/.phren/.machine-id 2>/dev/null || hostname
+```
+
+If `~/.phren/.machine-id` doesn't exist, ask the user to pick a name:
+> "I need a machine name to look up your profile. What should I call this machine? (e.g. 'work-laptop', 'home-desktop')"
+
+Then save it:
+```bash
+mkdir -p ~/.phren && echo "work-laptop" > ~/.phren/.machine-id
+```
+
+### 3. Look up the profile
+
+```bash
+cat "$PHREN_DIR/machines.yaml"
+```
+
+If the machine name isn't in `machines.yaml`, tell the user:
+> "Machine 'work-laptop' isn't in machines.yaml yet. Which profile should it use?"
+> Then show available profiles: `ls "$PHREN_DIR/profiles/"*.yaml`
+
+```bash
+cat "$PHREN_DIR/profiles/<profile-name>.yaml"
+```
+
+The profile YAML has:
+```yaml
+name: work
+description: Work laptop setup
+projects:
+  - myapp
+  - api-server
+```
+
+If no profiles exist yet, offer to create one with `phren-init`.
+
+### 4. Pull latest
+
+```bash
+cd "$PHREN_DIR" && git pull
+```
+
+If this fails (not a git repo, no remote), tell the user. Don't silently skip.
+
+### 5. Refresh the machine with the supported flow
+
+Run init against the pulled phren repo so hooks, MCP registration, and machine/profile wiring are refreshed:
+
+```bash
+PHREN_PATH="$PHREN_DIR" npx phren init -y
+```
+
+If the user is in an untracked repo afterward, tell them to open a session there and let the agent ask, or run `phren add` from that directory.
+
+Only mention `phren link` if the user is explicitly repairing an older pre-init install.
+
+### 6. Build the context file
+
+Write `~/.phren-context.md` with a summary of what's active on this machine:
+
+```markdown
+# Phren context: <machine-name> (<profile-name>)
+
+Machine: <machine-name>
+Profile: <profile-name>
+Last synced: <date>
+
+## Active projects
+- myapp: Description from summary.md
+- api-server: Description from summary.md
+
+## Global skills
+phren-sync, phren-init, phren-consolidate, phren-discover
+```
+
+Pull project descriptions from each project's `summary.md` if it exists.
+
+### 7. Rebuild MEMORY.md
+
+Regenerate `~/.claude/projects/*/memory/MEMORY.md` with cross-project awareness from the active profile. Pull key facts from each project's `summary.md`.
+
+### 8. Check project health
+
+After syncing, check each active project in the phren directory for missing files. Print a one-line status per project. Informational only, does not block the sync.
+
+**Required files** (warn if missing):
+- `summary.md`: project description used by context file and memory
+- `CLAUDE.md`: project-level Claude instructions
+
+**Recommended files** (note if missing, don't warn):
+- `tasks.md`: persistent task queue
+- `FINDINGS.md`: captured session findings
+
+For each project in the profile, check `$PHREN_DIR/<project>/` for these files and print:
+
+```
+Project health:
+  + my-app: all files present
+  ~ backend: missing recommended: FINDINGS.md
+  ! new-project: missing required: summary.md, CLAUDE.md
+```
+
+Legend: `+` all good, `~` missing recommended files, `!` missing required files.
+
+Skip the "global" entry since it has a different structure. Only check actual project directories.
+
+### 9. Report
+
+```
+phren-sync down: <machine-name> (<profile-name>)
+
+Synced:
+  - myapp (CLAUDE.md + 3 skills)
+  - api-server (CLAUDE.md + 1 skill)
+  - global (CLAUDE.md + 11 skills)
+
+Skipped (not in profile):
+  - old-project
+
+Project health:
+  + myapp: all files present
+  ~ api-server: missing recommended: FINDINGS.md
+
+Context: ~/.phren-context.md updated
+```
+
+## Sync up (push changes back)
+
+When the user says "sync this back", "push to phren", "save this to my phren":
+
+### 1. Find what changed
+
+```bash
+diff "$PHREN_DIR/<project>/CLAUDE.md" ./<project-path>/CLAUDE.md
+diff -r "$PHREN_DIR/<project>/skills/" ./<project-path>/.claude/skills/
+
+Remember: `.claude/skills/` is a generated mirror. The source-of-truth lives in phren `skills/`, and the project mirror also includes inherited global skills after resolution.
+```
+
+If files are symlinked (same inode), they're already in sync. Just commit from the phren directory.
+
+If files are regular copies that differ, copy them back:
+```bash
+cp <changed-file> "$PHREN_DIR/<project>/<corresponding-path>"
+```
+
+### 2. Commit and push
+
+```bash
+cd "$PHREN_DIR"
+git add -A
+git commit -m "<project> updates from <machine-name>"
+git push
+```
+
+## Conversational shortcuts
+
+These should work naturally in conversation:
+
+| User says | What to do |
+|-----------|-----------|
+| "add myapp to my work profile" | Edit the profile YAML, add to projects list, commit |
+| "show me my personal profile" | Read and display the profile YAML |
+| "what's on this machine?" | Read and display `~/.phren-context.md` |
+| "remove old-project from work" | Edit the profile YAML, commit |
+| "switch to personal profile" | Update the machine mapping in `machines.yaml`, re-run sync down |
+| "create a new profile called travel" | Create a new profile YAML with empty projects list, ask what to include |
+
+## New machine setup
+
+First time on a new machine:
+
+```bash
+# 1. Clone your phren repo
+git clone <your-repo-url> ~/.phren
+
+# 2. Name this machine
+mkdir -p ~/.phren && echo "my-machine-name" > ~/.phren/.machine-id
+
+# 3. Map it to a profile in machines.yaml
+#    Add a line: my-machine-name: work
+
+# 4. Run phren-sync
+```
+
+If you don't have a phren repo yet, start with `phren-init` to create one from scratch.
+
+## Conflict resolution
+
+When two machines edit the same phren file before syncing, `git pull` will hit a merge conflict. Here's how to handle each file type:
+
+**tasks.md**: Take both changes. Task items from both machines are valid. Concat them, deduplicate if needed, commit.
+
+**FINDINGS.md**: Take both changes. Keep entries in chronological order. If both machines added entries on the same date, interleave or group them under the same date heading.
+
+**CLAUDE.md**: Manual merge. Ask the user which version they want, or show both and let them pick. These files contain preferences and instructions where intent matters, so don't auto-resolve.
+
+**skills/ files**: If the same skill was edited on both machines, show the user a diff and let them choose. If different skills were edited, git handles this automatically (no conflict).
+
+**General approach**: Run `git pull --rebase` during sync. If conflicts appear, tell the user which files conflict and apply the rules above. Don't silently drop changes from either side.
+
+## Related skills
+
+- `phren-init`: create a new project or set up phren from scratch
+- `add_finding()`: capture findings via MCP (synced across machines by `push_changes()`)
+- `phren-consolidate`: synthesize findings across projects

package/starter/README.md

@@ -0,0 +1,74 @@
+# My Phren
+
+Your personal project store for [phren](https://github.com/alaarab/phren). Phren is your project's memory keeper — he holds what your agents learn and surfaces it when it matters, across sessions and machines.
+
+## Structure
+
+Each subdirectory is a project. Add one for every codebase you work on.
+
+```
+~/.phren/
+├── global/          # context that applies to every project
+│   ├── CLAUDE.md
+│   └── skills/      # personal workflow skills
+├── my-project/
+│   ├── CLAUDE.md    # architecture, commands, key patterns
+│   ├── summary.md   # five-line project card
+│   ├── FINDINGS.md  # fragments accumulated over time
+│   ├── tasks.md     # task queue that persists across sessions
+│   └── .claude/
+│       └── skills/  # project-specific skills
+├── profiles/        # YAML files mapping project sets to machine roles
+└── machines.yaml    # maps machine hostnames to profiles
+```
+
+## Guided tour
+
+New to phren? Here's what each file does and when it matters.
+
+**summary.md** is the elevator pitch. Phren shows this to Claude first so it knows what project it's working on. Keep it to 5 lines: what, stack, status, run command, biggest insight.
+
+**CLAUDE.md** is the project bible. Commands, architecture, key patterns, things to never do. Claude reads this before making changes. The better this file is, the fewer mistakes Claude makes.
+
+**FINDINGS.md** fills itself. As Claude discovers insights, patterns, and decisions during your sessions, it tells phren and entries land here grouped by date. Old entries fade from retrieval over time. Wrong entries can be removed with `remove_finding()`.
+
+**tasks.md** is your task board file. It keeps Active (working now), Queue (up next), and Done (finished) in one place so the work history stays with the project. You can also manage it from `npx phren shell`.
+
+**global/CLAUDE.md** applies everywhere. Your style preferences, tool choices, things Claude should always know regardless of which project you're in.
+
+**profiles/** and **machines.yaml** handle multi-machine setups. Map hostnames to profiles, and profiles to project lists. Your work laptop sees work projects, your home machine sees personal ones.
+
+## Getting started
+
+If you got here via `npx phren init`, you're already set up. Restart Claude Code and you're good.
+
+If you cloned manually:
+
+1. Add the MCP server: `claude mcp add phren -- npx phren ~/.phren`
+2. Install skills: `/plugin marketplace add alaarab/phren` then `/plugin install phren@phren`
+3. Restart Claude Code
+4. Add a project: run `/phren-init my-project` or scaffold one with a template such as `npx phren init --template python-project`
+5. Push to a private GitHub repo to sync across machines
+
+## Day-to-day workflow
+
+1. **Start a session**: phren pulls the latest and feeds relevant context to your agent
+2. **Work normally**: Claude reads your project docs and builds on what phren remembers
+3. **Fragments accumulate**: tell phren what you learned, or he picks up insights automatically
+4. **Session ends**: phren commits and pushes what he collected
+5. **Review occasionally**: run `npx phren shell` to triage what phren queued, manage tasks, and check health
+
+## Syncing across machines
+
+Edit `machines.yaml` to map each machine's hostname to a profile:
+
+```yaml
+work-desktop: work
+home-laptop: personal
+```
+
+Each profile in `profiles/` lists which projects that machine should see. After cloning on a new machine, run `/phren-sync` to pull everything in.
+
+## Troubleshooting
+
+Run `npx phren doctor --fix` to check and repair your setup.

package/starter/global/CLAUDE.md

@@ -0,0 +1,89 @@
+# User-level instructions
+
+<!-- Copy this file to your personal phren instance's global/CLAUDE.md and fill in your own preferences. -->
+<!-- This becomes ~/.claude/CLAUDE.md after syncing. Claude reads it at the start of every session. -->
+
+## How I Work
+
+<!-- Your non-negotiable rules. Examples: -->
+<!-- "Write human from the start. No em dashes. No double hyphens. No AI buzzwords." -->
+<!-- "Think visually. If it looks like a template, it's not done." -->
+<!-- "Finish the job. Changelog, README, tests. Don't wait to be asked." -->
+
+## Skills
+
+These skills are available as a full set via phren, or individually from the Claude skills marketplace. You don't need the full phren setup to use skills marked with (standalone).
+
+### Phren skills (manage your project store)
+
+| Skill | What it does |
+|-------|-------------|
+| `/phren-sync` | Pull phren to a new machine or push config changes back to the repo |
+| `/phren-init` | Scaffold a new project with summary, CLAUDE.md, task |
+| `/phren-discover` | Research what's missing in a project and surface gaps and opportunities |
+| `/phren-consolidate` | Find patterns across all project FINDINGS.md files |
+
+### Your own skills
+
+Put personal workflow skills in `~/.phren/global/skills/` and list them here. See [phren](https://github.com/alaarab/phren) for examples.
+
+<!-- Example:
+| `/humanize` | Strip AI language from writing and code |
+| `/release`  | Version bump, changelog, tag, publish |
+-->
+
+## Agent coordination
+
+<!-- If you use team agents, document your coordination pattern here. Example: -->
+<!-- "Never use fire-and-forget background agents. Always use TeamCreate/TaskCreate/SendMessage." -->
+
+- Team agents follow the same phren rules as the primary agent.
+- Before handing work back or stopping, tell phren about non-obvious bugs, patterns, tradeoffs, or decisions with `add_finding(...)`.
+- Do not wait for the user to explicitly say "save this as a finding" if the insight will matter next session.
+
+## Project store
+
+In shared mode, skills and project config live in `~/.phren` (or wherever `PHREN_DIR` points). This is a git repo that syncs across machines using profiles.
+
+If you're using `phren init --mode project-local`, the root is `<repo>/.phren` instead. Project-local mode does not use profiles, machine mappings, or global hooks.
+
+- `~/.phren/global/`: skills and config that apply everywhere
+- `~/.phren/<project>/`: per-project CLAUDE.md, skills, task, findings
+- `~/.phren/profiles/`: YAML files mapping project sets to machine roles
+- `~/.phren/machines.yaml`: maps machine hostnames to profiles
+
+Run `/phren-sync` to pull everything down or push changes back.
+
+## MCP tools
+
+The phren MCP server is running. Phren already knows a lot — ask him before asking the user to repeat themselves.
+
+- **At session start:** ask phren what's active: `list_projects()`, then `get_project_summary(name)` for the relevant project
+- **When the user mentions a project, codebase, or task:** ask phren first: `search_knowledge(query)` before asking questions
+- **When the user asks about commands, architecture, conventions, or past decisions:** check with phren: `search_knowledge(query)`
+- **When the user mentions a task or todo:** ask phren what's tracked: `get_tasks(project)`
+- **When you discover a non-obvious pattern, bug, or workaround:** tell phren immediately: `add_finding(project, insight)`
+- **When the user says they want to do something later:** tell phren to remember it: `add_task(project, item)` instead of listing it in chat
+- **When a task is finished:** tell phren it's done: `complete_task(project, item)` without being asked
+
+**What NOT to tell phren:**
+- Credentials, API keys, tokens, passwords, or anything that looks like a secret
+- Personal or sensitive data: SSNs, financial info, health info, PII of any kind
+- One-off facts that won't apply next session ("the server was down today")
+- Narration of what happened ("fixed the login bug"): only save the actual insight
+- Things obvious from reading the code or docs
+
+If you're unsure whether something is worth telling phren, skip it. High-signal entries beat volume.
+
+The goal: phren should already have the context before the user has to explain it. Tasks stay in files, not buried in chat history.
+
+## Machine context
+
+<!-- Claude reads this at session start to know what's active on this machine. -->
+<!-- Auto-generated by /phren-sync. Don't edit manually. -->
+
+Read `~/.phren-context.md` at the start of every session for machine-specific context: which profile is active, which projects are linked, and when the last sync happened.
+
+## Without MCP server
+
+If the MCP server isn't available, phren still helps. Claude reads `~/.phren-context.md` and per-project memory files from `~/.claude/projects/` for context, then fetches details directly from `~/.phren/project-name/` as needed. No MCP required — phren just works a bit more quietly.

package/starter/global/skills/humanize.md

@@ -0,0 +1,30 @@
+---
+name: humanize
+description: Strip AI language from writing and code. Kill the AI voice.
+---
+# /humanize - Kill the AI voice
+
+Strip out artificial language and make your writing sound like you actually talk.
+
+## Rules
+
+- No em dashes. Use a colon, comma, or rewrite. "AI wrote this, badly" or "AI wrote this: poorly."
+- No double hyphens used as dashes: "hard--won" should be "hard-won" or rewritten.
+- Banned words: robust, seamless, leverage, comprehensive, utilize, synergize, perplexing, meticulous. Don't use them.
+- No filler comments that restate code: bad: `// increment i`, good: `// only count non-zero`, or just delete it.
+- No "Note that...", "It's worth mentioning...", "One thing to consider..." Just say it.
+- No "arguably", "arguably one of the most". Be direct.
+
+## Self-audit
+
+Read your output back. If it sounds like AI wrote it, rewrite it. Check:
+- Any sentence feel stiff or overly formal?
+- Any words you wouldn't say in a conversation?
+- Any phrase that sounds like it's trying too hard?
+
+## Customize
+
+These rules are a starting point. Adjust them to match your actual voice:
+- Add words you hate hearing from AI.
+- Document patterns from your own writing (short sentences, specific cadence, humor style).
+- Share examples of "bad" vs "good" versions so Claude knows your voice.

package/starter/global/skills/pipeline.md

@@ -0,0 +1,35 @@
+---
+name: pipeline
+description: Tell Claude which stage of development you're in and get guidance on what to focus on next.
+---
+# /pipeline - Where am I in the workflow
+
+Tell Claude which stage of development you're in, and get guidance on what to focus on next.
+
+## Stages
+
+1. **planning** - sketching ideas, designing, deciding what to build
+2. **coding** - writing implementation, building features
+3. **testing** - running tests, verifying behavior, catching bugs
+4. **review** - code review, feedback, making sure it's ready
+5. **shipped** - released, deployed, users have it
+
+## What to do
+
+1. Look at recent git commits to understand what's been done recently.
+2. Check open files in the editor to see what's actively being worked on.
+3. Ask the user: "What stage are you in?" if unclear.
+4. Tell the user:
+   - **Current stage**: e.g. "You're in the coding stage"
+   - **What to focus on next**: e.g. "Once you finish this component, write tests for it. Don't move to review until tests pass."
+
+## Examples
+
+- "You've got 10 failing tests. You're in testing. Run tests again after each fix, don't batch them."
+- "You've got code ready but no CHANGELOG entry. That's review stage. Update the changelog, then you're ready to ship."
+- "You've got 3 open PRs awaiting feedback. You're in review. Respond to comments or start something new while you wait."
+
+## Customize
+
+- Adjust the stages to match your workflow (you might have a "documentation" or "deployment" stage)
+- Add what "done" means for each stage in your project

package/starter/global/skills/release.md

@@ -0,0 +1,35 @@
+---
+name: release
+description: Get from "code is ready" to "users have it" with a version bump, changelog, tag, and publish checklist.
+---
+# /release - Ship a version
+
+Get from "code is ready" to "users have it" with a checklist.
+
+## Steps
+
+1. **Confirm version bump**: Ask for patch, minor, or major (if not specified). Auto-detect from git history or ask the user.
+2. **Update CHANGELOG.md**: List what changed in this release. Format varies (keep-changelog, conventional commits, etc).
+3. **Bump version**: Update package.json, Cargo.toml, pyproject.toml, or whatever your project uses.
+4. **Git tag**: Create a git tag: `git tag vX.Y.Z` and push it.
+5. **Publish**: Run your publish command (`npm publish`, `cargo publish`, `poetry publish`, etc).
+
+## Example flow
+
+```
+You: "/release"
+Claude: "What version bump? (patch/minor/major)"
+You: "minor"
+Claude: "Got it. You're going from 1.2.3 to 1.3.0.
+  - Updated CHANGELOG.md with new features
+  - Bumped version in package.json
+  - Created tag v1.3.0
+  - Published to npm
+  Ready to verify it's live?"
+```
+
+## Customize
+
+- Update the publish command for your stack (e.g. `cargo publish` for Rust, `twine upload` for Python)
+- Adjust changelog format to match your conventions
+- Add any pre-publish checks you need (tests, linting, etc)

package/starter/machines.yaml

@@ -0,0 +1,8 @@
+# Maps machine hostnames to profiles.
+# Run `hostname` to find your machine's name, then add it here.
+#
+# Examples: replace with your actual hostnames:
+#   work-laptop: work
+#   home-desktop: personal
+#
+# After adding a line, run: npx phren init

package/starter/my-api/.claude/skills/README.md

@@ -0,0 +1,7 @@
+# my-api skills
+
+| Skill | What it does |
+|-------|-------------|
+| `/verify` | Pre-commit gate |
+
+Add project-specific skills here.

package/starter/my-api/CLAUDE.md

@@ -0,0 +1,33 @@
+# CLAUDE.md
+
+## Project overview
+
+**Purpose**: Backend API. Replace this with a real description of what the service does.
+**Stack**: Node.js, Express, PostgreSQL (or whatever you're using)
+**Status**: active
+**Version**: 0.0.0
+
+## Commands
+
+```bash
+# Install:   npm install
+# Run:       npm run dev
+# Test:      npm test
+# Build:     npm run build
+```
+
+## Project skills
+
+Source skills live in the phren project `skills/` directory. Phren resolves global + project-local skills and mirrors the effective set into repo-local `.claude/skills/`.
+
+## Architecture
+
+<!-- How routes, middleware, and services are organized -->
+
+## Key patterns
+
+<!-- Naming rules, error handling patterns, things to never do -->
+
+<!-- Tip: If this file grows past ~100 lines, split it using @import directives.
+     Example: @CLAUDE-architecture.md, @CLAUDE-commands.md, @CLAUDE-conventions.md
+     See phren README for details. -->

package/starter/my-api/FINDINGS.md

@@ -0,0 +1,9 @@
+# my-api findings
+
+Findings accumulated over time. Captured automatically during sessions and committed on exit.
+
+<!-- Example entry:
+## 2026-03-04
+- The auth middleware runs before rate limiting: order matters in middleware stack
+- `npm run dev` needs PORT set or it defaults to 3001, not 3000
+-->

package/starter/my-api/summary.md

@@ -0,0 +1,7 @@
+# my-api
+
+**What:** REST API backend: replace with what yours actually does
+**Stack:** Node.js, Express, PostgreSQL (or whatever you're using)
+**Status:** active
+**Run:** npm run dev
+**Watch out:** .env not committed: copy .env.example and fill in secrets before first run

package/starter/my-api/tasks.md

@@ -0,0 +1,7 @@
+# my-api tasks
+
+## Active
+
+## Queue
+
+- [ ] Add your tasks here

package/starter/my-first-project/.claude/skills/README.md

@@ -0,0 +1,7 @@
+# my-first-project skills
+
+| Skill | What it does |
+|-------|-------------|
+| `/verify` | Pre-commit gate |
+
+Add project-specific skills here.

package/starter/my-first-project/CLAUDE.md

@@ -0,0 +1,49 @@
+# CLAUDE.md
+
+## Project overview
+
+**Purpose**: One paragraph about what this project is and what it does
+**Stack**: Replace with your tech stack
+**Status**: active
+**Version**: 0.0.0
+
+## Commands
+
+```bash
+# Install:
+# Run:
+# Test:
+# Build:
+```
+
+## Project skills
+
+Source skills live in the phren project `skills/` directory. Phren resolves global + project-local skills and mirrors the effective set into repo-local `.claude/skills/`.
+
+## Architecture
+
+<!-- How the codebase is structured. Example:
+
+src/
+  routes/     - Express route handlers
+  services/   - Business logic, one file per domain
+  models/     - Database models (Prisma)
+  middleware/ - Auth, rate-limiting, error handling
+  utils/      - Shared helpers
+
+-->
+
+## Key patterns
+
+<!-- Project-specific patterns, naming rules, things to never do. Example:
+
+- All API responses use `{ ok: boolean, data?, error? }` shape
+- Service functions throw, route handlers catch and format
+- Never import from `src/models` directly in routes, go through services
+- Tests live next to source files as `*.test.ts`
+
+-->
+
+<!-- Tip: If this file grows past ~100 lines, split it using @import directives.
+     Example: @CLAUDE-architecture.md, @CLAUDE-commands.md, @CLAUDE-conventions.md
+     See phren README for details. -->