create-religion 0.1.0

package/template/.agents/skills/implement/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: implement
+summary: build the current spec one reviewed step at a time
+description: "Build the feature, fix, or rollback spec'd in religion/context/current-work.md, one small reviewable step at a time. Implements each step as the smallest change that satisfies its stated outcome, shows the diff and explains it in plain language, proves the outcome with evidence, ticks the step off so progress survives a cleared context, and resumes from the first unchecked step when interrupted. Repairs open high-severity findings as extra reviewed steps and has them re-reviewed independently. Ends with a review packet; the work commit and any merge belong to $complete. Use when the user runs $implement, or asks to build, start, continue, or resume the current work item once its spec is ready."
+---
+
+# implement - build the current spec, one reviewed step at a time
+
+Where this sits:
+
+    feature, fix, or rollback  ->  [implement]  ->  complete
+    (the spec)                     (build it)       (commit, close it out)
+
+The spec was written and reviewed. This skill turns it into code without vibe coding:
+small steps, a visible diff and a plain-language explanation for each, evidence that its
+outcome is met, and iteration until it works.
+
+## Before you start
+
+**Read `religion/config.json`.** A missing file means defaults. If it exists but cannot
+be parsed, stop and point at $doctor; a skill that is about to change code must not
+guess past broken configuration.
+
+**Read the spec.** If `religion/context/current-work.md` is still the stub, or its status
+is already complete, stop and say to run $feature, $fix, or
+$rollback first.
+
+**Take the context.** Conventions from `religion/context/coding-standards.md`, the data
+model from the project overview. Code that ignores them is rework, not progress.
+
+**Resuming?** Steps already ticked (`- [x]`) mean this was started earlier and
+interrupted, usually by a cleared context. That is expected and costs nothing. Read which
+steps are done, check the working tree and recent commits to see what actually landed, and
+continue from the **first unchecked step**. Do not start over, and do not re-verify
+completed steps unless something suggests they broke.
+
+**A rollback spec** carries `Type: Rollback`. Apply it by recomputing the diff command the
+spec records, confirming it still matches, then applying it in reverse with three-way
+conflict detection and staging it. Show the staged diff and confirm no workflow-owned path
+was touched before presenting the step. Never write the reversal freehand, and never run a
+whole-commit revert: the commits being reversed also carry the archive and plan bookkeeping
+that must survive. On a conflict, stop and report the paths and the later commit involved
+rather than resolving it.
+
+## Step 1 - position the work
+
+Read `git.mode`.
+
+**`trunk`** (the default) works on the branch already checked out. Do not create a branch.
+If the current branch looks wrong for this work, say so and ask; do not switch or create
+one unprompted.
+
+**`branch-per-item`** creates and checks out a branch named from the spec using the
+configured prefix. On a resume the branch exists already, so check it out rather than
+creating a second one.
+
+Either way, if the project is not a git repository, say so and ask the user to initialize
+one. The loop needs history to be reviewable.
+
+## Step 2 - build one step
+
+Set the spec's status to `in progress` before the first code change of this run, and again
+whenever work resumes after a passing check and touches product code. That invalidates
+stale verification state.
+
+Work through the build steps **in order, one at a time**. For each:
+
+1. **Implement just that step.** The smallest change that satisfies its stated outcome.
+   Nothing from a later step, nothing nobody asked for.
+2. **Show the diff**, not whole files.
+3. **Explain it, and prove it.** What the step delivered, one line per changed file on
+   what it does and why, then the outcome shown true with evidence: command output, a
+   screenshot, a passing assertion. Keep it concrete; this is the comprehension gate, not
+   a ritual. Add a short **how to try it** line when there is a manual path.
+4. **Verify what the step touched.** Run the focused checks for this change: the relevant
+   test, the typecheck, whatever proves this diff. The full `Verify` command runs once
+   before the work is completed, so a step does not pay for the whole suite every time.
+   Run the full command earlier anyway if a step could plausibly break something far away.
+
+   With `verification.logicTests: "required"`, a logic change with no configured runner
+   stops and points at $tests. With `when-configured`, the gate applies only when a
+   test command is declared. When it is on, a step that adds in-scope logic ships a passing
+   test in the same diff. Interface and integration steps ride on running it, a screenshot,
+   and the build. With `verification.uiEvidence: "required"`, an interface outcome cannot
+   pass on build output alone.
+
+   Never install a runner mid-step unless this spec is what sets that runner up.
+5. **Iterate until it works.** If it fails, revise and re-test. After two or three
+   attempts that do not work, **stop**. Report what each attempt did and why you think it
+   is failing, and offer to hand it to $debug, which reproduces the failure and
+   tests competing hypotheses in parallel. Do not keep trying variations.
+6. **Tick the step** (`- [x]`) once its gate is satisfied, so progress survives a cleared
+   context. If the step repaired a finding, mark that finding `fixed` and note the repair
+   in its resolution line. Never mark it `closed`; see Step 3.
+7. **Then prompt, according to config.**
+
+   With `workflow.stepReview: "item"`, do not prompt. Continue to the next step and
+   collect everything into one packet at the end. Still stop early for a failed check, a
+   decision, a conflict, scope drift, or anything in the first tier of the authority rules.
+
+   With `stepReview: "every"`, offer only the options that config actually allows:
+
+   - **Continue** - move to the next step.
+   - **Commit checkpoint** - only when `git.checkpoints` is `every-step` or `squash`.
+     Choosing it is the approval that authorizes the commit. Commit just this step with a
+     conventional message describing what the change does.
+   - **Walk me through it** - a deeper, line-level explanation: why this approach, what
+     each part does, the gotchas. Then re-ask. A loop back, not a terminal choice.
+   - **Stop here** - pause. Say where things stand and how to resume.
+
+   Use the tool's short input prompt when there is one. When you have just produced a long
+   block to read, ask in plain text instead, so the prompt does not cover what is still
+   being read.
+
+Never batch the whole item into one diff. A diff too large to read means the step was too
+large; split it.
+
+## Step 3 - clear the ledger before handing off
+
+Read `religion/context/findings.md`. A P0 or P1 finding that is `open` or `fixed` will
+block completion, so close the loop now rather than discovering it later.
+
+For each `open` P0 or P1:
+
+1. **Append it to the spec's build steps** first (`- [ ] Repair F-03 - <title>`), so the
+   repair is on the record and survives a cleared context.
+2. Build it through the same loop as Step 2: smallest change, diff, explanation, evidence.
+3. Tick the step and mark the finding `fixed`.
+
+Then have the repairs re-reviewed. Run $audit over the repaired code **in a
+subagent with fresh context**, and record what it returns. The independence is the point:
+a repair is not done when the code changes, it is done when a review that did not write it
+has looked at the result, because a fix can introduce a worse defect than the one it
+removed. Reviewing your own repair in the context that produced it is not that review.
+
+A finding that a user decides not to fix is `accepted`, and only they may set it, with
+their reason recorded. A finding that looks wrong goes back to review to be marked
+`invalid` with evidence. This skill sets neither.
+
+## Step 4 - hand off
+
+When every step is built and its gate has passed, stop with a compact review packet:
+
+- where the work sits: branch, or the current branch under trunk mode
+- what changed, grouped by file or area
+- checks run, with the exact command and result for each
+- how to try it manually
+- ledger state: any findings still `open` or `fixed`, by identifier
+- known risks, skipped checks, or follow-ups
+- next action, normally $complete
+
+Set the spec's status to `verified` immediately before that packet, but only when every
+required command, outcome, and configured gate actually passed. A gate that could not run
+is a blocker, not a pass.
+
+Then say that $complete runs the full `Verify`, archives the spec, updates the
+build plan, makes the work commit, and asks separately before any merge or push.
+
+## Rules
+
+- One small step per diff, and never a commit before its review gate is satisfied.
+- Explain every change in plain language. Understanding the code is the point.
+- Build only what the spec says. If the spec is wrong or thin, stop and fix the spec
+  first. Do not improvise around it.
+- Follow the project's coding standards, including scoping user-owned queries by the
+  authenticated identity taken from the server.
+- Checkpoints are optional rollback points. The work commit, any merge, and any push
+  belong to $complete.
+- This skill does not merge, push, or complete.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/overview/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: overview
+summary: distill the two planning documents into the project's source of truth
+description: "Validate the two user-owned planning documents and generate religion/context/project-overview.md from them, the single source of truth every session loads. Proposes a normalized checkbox build plan when the plan is still loose bullets, separates what the product already does from what is queued, derives a concrete domain model and a code map, and records contradictions as open questions that can block work in the areas they affect. Also runs automatically when the plans have changed since the overview was generated. Use when the user runs $overview, has just written or edited the plans, asks to regenerate the project overview, or when another skill finds the overview stale."
+---
+
+# overview - turn the two plans into the source of truth
+
+Where this sits:
+
+    project-plan.md  +  build-plan.md  ->  [this skill]  ->  project-overview.md
+    (what and why)      (what order)                          (what everything reads)
+
+The plans are yours: long, rough, written in whatever order made sense at the time. The
+overview is the distilled version every skill reads every session. Regenerating it is
+cheap; working from a stale one is not.
+
+## When this runs
+
+**Explicitly**, when the user asks.
+
+**Automatically**, when a skill that reads the overview finds it stale. Any skill in that
+position follows the steps below first, reports what changed, and then continues with what
+it was asked to do. Nothing acts on a stale overview.
+
+## Staleness
+
+The generated file carries a hash of the two plans it was built from:
+
+    <!-- religion:source-hash <16 hex characters> -->
+
+Compute it exactly this way, so that two runs never disagree and report a false change:
+concatenate the raw bytes of `religion/project-plan.md` then `religion/build-plan.md`
+with nothing between them, take the SHA-256, and use the first 16 characters of the
+lowercase hexadecimal digest.
+
+    cat religion/project-plan.md religion/build-plan.md | shasum -a 256 | cut -c1-16
+
+Recompute it over the current plans. A mismatch means the plans moved and the overview did
+not. A missing stamp means an overview generated before this mechanism existed, or one
+hand-edited; treat both as stale.
+
+## Step 1 - read the plans
+
+Read `religion/project-plan.md` and `religion/build-plan.md` in full, plus the existing
+overview when there is one, so that a regeneration can report what changed rather than
+just replacing the file.
+
+Sections 6 through 8 of the project plan are optional. A plan that deleted them has not
+made a mistake, and the corresponding overview headings are omitted rather than filled
+with "not applicable".
+
+## Step 2 - validate, and propose fixes for approval
+
+Check both plans are usable before generating from them:
+
+- **Required sections.** Sections 1 through 5 of the project plan are answered, not left
+  as the placeholder prompts they ship with.
+- **Build plan shape.** The build plan is a checkbox list. The loop reads those boxes to
+  know what is next and what is done, so a plain bullet list breaks progress tracking.
+- **Item sizing.** Each build-plan item is a feature-sized outcome, not a whole product
+  area ("Auth, billing, and dashboard") or a loose task ("Database").
+- **Item kind.** The build plan is for features. An item that describes something broken
+  ("search ranking is bad", "the switcher does not remember") is a fix, and an item that
+  describes reviewing rather than building ("audit the hook types") is a review pass.
+  Both have their own path and their own place in the history, and neither belongs in the
+  plan. Point them at $fix and $audit, and propose removing them.
+- **Numbering.** Completed items keep their numbers, since archives refer back to them.
+
+When something is wrong, show the exact proposed replacement and ask before writing. These
+two files are the user's. Never edit them silently, and never rewrite prose that is merely
+rough: a plan can be informal and still be usable, and only shape problems that actually
+break the loop are worth proposing a change for.
+
+If the user declines a proposed fix, say what will not work as a result and generate
+anyway.
+
+## Step 3 - generate the overview
+
+Write `religion/context/project-overview.md` following
+`reference/project-overview-template.md`. Stamp the freshly computed source hash.
+
+Three sections are real work rather than distillation.
+
+**What it does** and **Roadmap** are deliberately separate. The first is the product's
+identity, taken from section 3; the second is the queue, taken from the build plan. On a
+new project they are nearly the same list. On an established one they barely overlap, and
+collapsing them produces an overview claiming the product's features are whatever three
+small things happen to be queued. Never merge them, and never fill one from the other.
+
+**Domain model** turns the plan's list of nouns into concrete shapes with fields and
+relationships. What that means depends on the project: persisted entities for something
+with a database, the shapes read and emitted for a compiler or CLI, the public types and
+their contracts for a library. A project with no database still has a domain model. Write
+what it actually works with and say what kind it is.
+
+**Code map** records where things live, derived by looking at the repository rather than
+the plans, since neither plan describes layout. For several packages, name the boundary
+each one owns. Without this, every spec re-derives the layout from scratch.
+
+Mark any shape later work will depend on as load-bearing.
+
+Derive, do not invent. If the plans do not determine something a section needs, that is an
+open question, not a gap to fill with a plausible guess. The code map is the one exception:
+it is read from the repository, because that is where the answer actually is.
+
+## Step 4 - record open questions
+
+Contradictions and gaps go in the **Open questions** section, and each one names what it
+affects:
+
+    - **Storage engine** (affects: data model, features 3 and 7) - section 5 names
+      Postgres while section 4 describes local SQLite files. Resolve in the plans and
+      regenerate.
+
+The "affects" list is load-bearing, not decoration. Work touching a named area is blocked
+while the question is open, and work elsewhere proceeds normally. Scope each one as
+narrowly as the evidence allows: a question marked as affecting everything stops the
+project, so only write that when it is true.
+
+Raise a question only for a real conflict or a real gap that later work will hit. Stylistic
+thinness is not an open question.
+
+## Step 5 - report
+
+Lead with what changed, then the questions:
+
+- **generated** or **regenerated**, and on a regeneration, what moved: sections added or
+  removed, shapes or fields that changed, items that entered or left the roadmap
+- open questions, by title, and what each blocks
+- any plan fix that was proposed, and whether it was applied
+- the next action
+
+On a first generation, say so plainly rather than reporting a diff against nothing.
+
+## Rules
+
+- The two plans belong to the user. Propose, show the exact change, and wait. Never edit
+  them without approval.
+- The overview is derived. Never hand-edit it, and never patch it to work around a plan
+  that says something different; fix the plan and regenerate.
+- Derive from the plans only. An overview that states something neither plan supports is
+  worse than one with an open question, because nothing later will question it.
+- Do not turn a rough plan into a polished one. Distil what is there.
+- Scope every open question to what it genuinely affects.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/overview/reference/project-overview-template.md

@@ -0,0 +1,101 @@
+# <Project Name> - Project Overview
+
+<!-- religion:source-hash <computed> -->
+
+> <one line on what this project is>
+
+## Problem
+
+What is broken today and why it matters, distilled from section 1 of the project plan.
+Two or three sentences.
+
+## Users
+
+Who this is for, from section 2. A short list of user kinds and what each needs. Note any
+access tiers, such as anonymous versus signed in.
+
+## What it does
+
+What this product already does, from section 3 of the plan. One line each. This is the
+product's identity, not a work queue, and on an established project most of it is already
+built. Mark the headline capability.
+
+- **<capability>** - what it gives someone.
+
+## Roadmap
+
+What is queued, in build-plan order, with its number. This is the work list, and it is a
+different thing from the section above: on an established project the two barely overlap.
+
+1. **<item>** - what it delivers.
+2. **<item>** - what it delivers.
+
+## Domain model
+
+The concrete shapes this project works with, derived from section 4 and the features that
+use them. Real types with fields and relationships, not a restatement of the vague list in
+the plan. This is usually the section a spec cannot be written without, and the one the
+plan does not directly contain.
+
+What belongs here depends on what the project is:
+
+- **Stores data** - the persisted models: entities, fields, types, relationships.
+- **Transforms input** (a compiler, a framework, a CLI, a parser) - the shapes it reads,
+  the shapes it emits, and the stages between them.
+- **Provides an interface** (a library, a design system) - the public types and the
+  contracts they promise.
+
+A project with no database is not a project with no domain model. Write the shapes it
+actually works with, and say what kind they are.
+
+### <Shape>
+
+- `field` (type) - what it holds
+- relates to <other shape> by <field>
+
+Mark anything later work depends on as load-bearing, so a change to it is understood as a
+breaking change rather than an edit.
+
+## Code map
+
+Where things live, so that work can name the files it will touch without re-deriving the
+layout every time.
+
+- `<path>` - what lives here, and when work belongs in it
+
+For a repository with several packages, list them with the boundary each one owns, so it is
+clear which one a given change belongs in.
+
+## Tech stack
+
+From section 5, one line each on what it is for.
+
+- **<technology>** - its role here
+
+## Monetization
+
+From section 6. Omit this heading entirely when the plan has no such section.
+
+## UI and UX
+
+From section 7: the look and feel, and the main routes or screens. Omit this heading
+entirely when the plan has no such section.
+
+- `/<route>` - what is there
+
+## Deployment
+
+From section 8: host, app type, build and start commands, output directory, environment
+variables by name, storage needs, background jobs, health path, domain notes. Omit this
+heading entirely when the plan has no such section.
+
+## Open questions
+
+Contradictions and gaps found between the two plans. Each one names what it affects, so
+that work touching that area can be blocked while work elsewhere continues.
+
+- **<short title>** (affects: <areas, features, or models>) - what the two plans say that
+  cannot both be true, or what is missing that later work will need. Resolve it in the
+  plans, then regenerate.
+
+Delete this heading when there are none.

package/template/.agents/skills/prototype/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: prototype
+summary: explore the look before building, as throwaway mockups or real components
+description: "Explore how a project should look before the build loop starts. Asks what feel is wanted and which screens to draft, proposes a plan, then writes static mockups sharing one theme file to prototypes/. When the project already uses a component system, offers to prototype in that system instead, so the result is real components rather than something to port. Sits outside the reviewed loop, like scaffolding. Use when the user runs $prototype, names screens to mock up, or asks to explore the layout, theme, or look and feel."
+---
+
+# prototype - lock the look before building it
+
+Exploratory work, deliberately outside the spec loop. Deciding how something should look is
+not a reviewable build step, and forcing it through one wastes both.
+
+## Step 1 - decide which kind
+
+Look at the project. If it already has a component system with tokens and primitives, offer
+to prototype **in that system**. Otherwise write **static mockups**.
+
+| | Static mockups | In the component system |
+| --- | --- | --- |
+| Output | HTML and CSS in `prototypes/` | Real components in the project |
+| Fidelity | Approximate | Exactly what ships |
+| Afterwards | Tokens ported, folder deleted | Nothing to port, nothing to delete |
+| Good for | Deciding a look from nothing | A project whose look is already decided |
+
+Static mockups are the default because they are faster to throw away, and throwing away is
+what usually happens to the first three attempts. Prototyping in the real system is better
+once the direction is settled, because the port step is where the approximation creeps back
+in.
+
+Say which you propose and why. The user decides.
+
+## Step 2 - ask what is wanted
+
+Do not start drawing. Ask:
+
+- **The feel**, in adjectives, plus anything to look at: a site, a screenshot, a product
+  whose look is close.
+- **Which screens**, and which one matters most. Draft that one first and get it right
+  before the others copy its decisions.
+- **Constraints**: dark, light, or both; density; an existing brand.
+
+Propose a short plan and get agreement before writing files.
+
+## Step 3 - static mockups
+
+Write to `prototypes/`, one file per screen, all sharing `prototypes/theme.css`.
+
+**Every colour, size, and spacing value lives in `theme.css` as a variable.** No exceptions.
+That file is the actual output of this work: the mockups are disposable, the token set is
+the decision, and a value hardcoded in one screen is a decision that will not survive.
+
+Use realistic content. Placeholder text hides every layout problem worth finding: real
+labels are longer than expected, real lists are emptier, real names break alignment.
+
+Draft the primary screen, show it, iterate until it is right, then do the others.
+
+## Step 4 - prototyping in the component system
+
+Build the screens with the project's own primitives and tokens, in the project.
+
+Add tokens where the design needs values that do not exist yet, in the token layer, never
+inline in a component. If the design fights the system repeatedly, that is a finding worth
+reporting: either the design or the system is wrong, and knowing which is worth more than
+the mockup.
+
+These are not throwaway. Say what should be kept, what was a sketch, and what a later work
+item should build on.
+
+## Step 5 - hand off
+
+Say which mockups exist and where the tokens live.
+
+For static mockups, note that the first build step of the first visual work item ports
+`theme.css` into the project's real stylesheet, and that the folder is deleted once that
+lands. For component prototypes, note there is nothing to port.
+
+Then point at $feature. Prototypes inform the plan; they are not a work item.
+
+## Rules
+
+- Ask before drawing. A mockup built from a guess wastes the round trip that would have
+  prevented it.
+- Every value is a token.
+- Real content, never placeholder text.
+- Static mockups are throwaway and are deleted once consumed. Component prototypes are not.
+- No product logic, no data layer, no routing. This is the look.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/release/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: release
+summary: prepare deployment readiness for Railway, Render, or Vercel
+description: "Prepare a project to deploy to Railway, Render, or Vercel. Reads the plans, commands, package files, and existing provider configuration; creates or updates local configuration and an environment example; runs build and start checks; and reports the environment variables, the smoke-test path, and the blockers. Stops before deploying, creating a remote service, changing a remote environment, pushing, or publishing. Use when the user runs $release, asks about deployment readiness or provider configuration, or names a provider."
+---
+
+# release - get ready to deploy, without deploying
+
+Prepares. Does not deploy. Deploying, creating a remote service, changing remote
+environment values, pushing, and publishing all need their own explicit yes, and this skill
+stops before every one of them.
+
+Run it after a completed item or a milestone, not as part of the build loop.
+
+## Step 1 - target and shape
+
+Take the provider from the argument: `$release railway`, `$release render`, `$release vercel`.
+Without one, read the deployment section of the project plan, and ask if it is not there.
+
+Then establish what is actually being deployed, because the answer changes everything: a
+static site, a server-rendered application, a service, a worker, a scheduled job, or several
+of these together.
+
+| Provider | Fits |
+| --- | --- |
+| **Railway** | Long-running services, workers, scheduled jobs, and anything wanting a managed database beside it |
+| **Render** | Similar shapes, with static sites and cron as first-class kinds |
+| **Vercel** | Front-end and edge-first applications, static output, serverless functions |
+
+If the project's shape fits the chosen provider badly, say so once, plainly, with the
+specific mismatch. Then proceed with what was asked.
+
+## Step 2 - survey
+
+- Build and start commands, and the output directory for static output.
+- The runtime version, and whether it is pinned.
+- Every environment variable the code reads, **by name**, found by searching the source
+  rather than by trusting a checked-in example file which is usually stale.
+- Data stores, caches, queues, and anything else it expects to exist.
+- Background work: workers, scheduled jobs, migrations that must run before start.
+- A health endpoint, if there is one.
+- Existing provider configuration already in the repository.
+
+## Step 3 - write local configuration
+
+Create or update only local files: the provider's configuration file, and an environment
+example listing every variable by name.
+
+**Never put a real secret in a file.** The example lists names and describes what each is
+for. A value that looks like a credential is never copied into it, and never printed.
+
+Preserve configuration that already exists. Show a diff for anything you change, and say
+why.
+
+Migrations that must run before start belong in the release or pre-deploy step the provider
+offers, not in the build. Getting that wrong deploys code against a schema that has not
+moved yet, which is the failure that takes a site down rather than failing a build.
+
+## Step 4 - check locally what can be checked
+
+Run the build. Run the start command far enough to see it come up. Hit the health path if
+there is one.
+
+A failure here is a blocker, and finding it locally is the entire point of doing this
+before deploying.
+
+## Step 5 - report
+
+- **Blockers** first: what would fail, and why.
+- **Environment variables**, by name, marking which have no local value yet.
+- **The exact next step** for that provider, as a command or a console action, so the user
+  can take it themselves.
+- **The smoke test**: what to hit after deploying and what should come back.
+- **What was not verified** and cannot be locally: the real database, real credentials,
+  cold starts, the domain.
+
+## Rules
+
+- Never deploy, create a remote service, change a remote environment, push, or publish.
+  Preparing is the whole job.
+- Never write, print, or copy a secret value.
+- Never claim a deployment will work. Report what was checked and what was not.
+- Provider tooling may be used to read state. Using it to change anything is a separate yes.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.