Tools from the episode

# Bothsides Complete Pack

Made by Selr AI.

Read all nine documents below before taking action. This is a collection of
project-scoped instructions and guided workflows, not permission to run every
example, connect every account or install all alternative products.

Start with the operating-system edition in the authorised project, then merge
routing and autonomy instructions without duplicating or replacing existing
skills. Preserve the user's own rules and work. Keep the connection, website, application,
prompt/command and software-comparison workflows available as references; ask
which one the user wants to use next before running those workflows.

Credentials, provider usage, public deployment, real-data changes and outbound
messages follow the explicit authority in the selected workflow. Never infer
approval from this bulk copy. Stop only the blocked step and continue independent
setup work. Report which files you created or merged and what remains optional.

---
name: website-kit-public
description: Build or improve a small business website or landing page from the user's business facts and assets, through a checked preview and launch handover. Use for a first website, service page or focused website refresh; not a full application or ecommerce rebuild.
---
# Website Kit

Made by Selr AI. Public guided edition, version 2.

Help me build or improve a website for my business. Use the workflow below in
Claude Code, Codex, or another coding assistant with project-file access. Carry
routine decisions through to a checked preview. This instruction is self-contained:
no private repository, global skill installer, component subscription or paid
service is required. Optional worksheets and a fictional example in the full pack
illustrate the workflow; they are not prerequisites.

## Start in the right place

Read my request and the current project before changing files. Preserve existing
work, instructions, framework, content and working routes. Do not replace a whole
site to improve one page. Work in an isolated copy when changes could overlap.

For a new site, use the project folder I provided. If none exists, explain that a
coding workspace is needed and help me choose an empty folder through the host's
supported interface. Do not write into an unrelated folder or install software
globally. A single-page business site can use ordinary HTML, CSS and minimal
JavaScript. Keep an existing framework; choose extra tooling only for an actual
requirement. A store, membership system or authenticated app needs a separate
scope before implementing payments or personal-data storage.

If this chat cannot edit files or run a preview, produce the business brief, page
outline and clearly labelled source files it can support. State what remains to
be done in a coding workspace. Do not describe a text response as a running site.

## 1. Gather what makes this business different

Use supplied material first. Ask up to three grouped questions initially, only
for missing information that changes the result:

1. **Business and visitor:** what do you sell, to whom, in what area, and what is
   the one action visitors should take? Is this a new site or a specific refresh?
2. **Content and evidence:** existing website, services, approved prices, useful
   differences, common customer questions, and proof you are allowed to show.
3. **Look and assets:** logo, photos, colours, tone, and one or two reference
   websites with a sentence about what you like. References are optional.

If answers are incomplete, record a reasonable design assumption and continue
where possible. Missing business facts remain unknown. Never invent pricing,
customer quotes, qualifications, ratings, client logos, guarantees, availability
or results. Do not manufacture urgency. Clearly identify fictional material in
examples. Ask a focused follow-up if a consequential ambiguity remains; an
initial question limit is not a ban on necessary clarification.

Write WEBSITE-BRIEF.md with: visitor, offer, main action and destination, scope,
verified facts, available proof, assets, assumptions and unresolved launch items.
For an existing page, include what works and the specific problems to fix.

## 2. Shape the content before styling it

Write a concise page outline and draft copy in the brief. Explain the purpose of
each section in one sentence. Use only sections that help the visitor decide:
what is offered, who it is for, how it works, what makes it useful, credible proof,
practical questions and the next step. Do not force every business into pricing
cards, a logo wall, a large FAQ or a sticky sales bar.

The first screen should explain the service, its intended customer and the next
action in plain language. Replace empty claims such as “innovative solutions”
with supplied specifics. Match the CTA to its actual destination: “See services”
for an on-page section, “Email an enquiry” for an email link, or the real booking
action if booking is connected. A button must not promise a workflow it lacks.

When proof is missing, use an honest explanation of the process or relevant work
provided by the user; do not create a fake testimonial. Keep unanswered questions
out of public copy. Show the outline briefly, then continue within the supplied
brief unless the user requested an approval checkpoint or a choice changes scope.

## 3. Choose a coherent visual direction

Follow the business's existing brand. If none is provided, choose one appropriate
direction and explain why it fits the audience. Record the palette, typography,
spacing, content width, image treatment and button style in WEBSITE-BRIEF.md.
Use a small consistent set of CSS variables or the project's existing tokens.

Use references for principles such as hierarchy, density or photography, not to
copy another business's text, code, logo or distinctive artwork. Use owned or
licensed assets; record their source and usage basis. If there are no photos,
build an intentional typography-led layout. Do not fill gaps with broken images
or pretend a stock image depicts the actual business or customer.

Give the main message visual priority. Vary layout only when the content benefits,
keep body text easy to read, and use space to group related information. Avoid
arbitrary gradients, endless identical cards, tiny low-contrast captions and
animations that hide content. Decorative polish cannot repair vague copy.

Before expanding the page, implement the header, first screen and one supporting
section. Inspect that small slice when browser tools are available, then reuse
its established styles. Do not require paid fonts, component generators or an
external design skill to finish this workflow.

## 4. Build a useful preview

Implement semantic HTML, clear headings, labelled controls and real destinations.
Use responsive images with dimensions, and keep the page useful without optional
animation. Respect reduced motion. Navigation and disclosures must work with a
keyboard, with visible focus and controls large enough to operate comfortably.

Design for narrow screens and wider layouts. Let columns stack and text wrap
naturally. Avoid fixed heights
that clip copy, horizontal overflow and sticky elements that obscure controls.
An existing multi-page site keeps its routes and metadata unless the brief changes
them. Avoid duplicate dependencies and unnecessary rebuilds.

Do not make a pretend contact form. If no approved destination exists, use a real
user-supplied contact option, or clearly label the form as an unconnected preview
and list it as a launch blocker. No invented email addresses. Form UI needs labels,
validation, progress, success and recoverable failure states. Success must follow
a confirmed response, not merely a button click. Keep secrets out of client code.
Use server-side validation and appropriate spam controls when connecting a form.
Collect only necessary fields and flag relevant privacy requirements for launch.

Do not enrol contacts, send real messages, purchase services, alter DNS or publish
without authority. Preserve permission already given for a specific action. An
unconnected optional integration should not prevent the rest of the preview.

## 5. Check the result and make one useful refinement

Run the project's existing relevant checks and local preview. With supported
browser tools, inspect 375, 768 and 1440 pixel widths, plus any failing breakpoint.
Record actual checks and findings in WEBSITE-CHECKS.md:

| Check | Evidence to collect |
| --- | --- |
| Visitor understanding | First screen names the offer and visitor; primary CTA describes its real destination |
| Content | No fabricated proof, unresolved public placeholders or contradictory business facts |
| Layout | No horizontal overflow, clipped copy, overlapping controls or distorted images at inspected widths |
| Keyboard | Reach and operate navigation, CTAs and disclosures; focus stays visible and no trap occurs |
| Readability | Check text contrast with a measurement tool; review font size, line length and zoom/reflow |
| Behaviour | Exercise links, menus and validation; inspect console errors, broken requests and missing assets |
| Form receipt | Separate UI validation, authorised test-mode receipt and production receipt; never infer delivery |
| Loading | Inspect image sizes, layout shifts and avoidable blocking resources; measure performance if tools exist |
| Sharing | Accurate title and description; suitable share image if available; canonical URL when known |

Use automated accessibility checks if available, alongside keyboard and visual
inspection. Do not invent scores or claim compliance from a single scan. If a
browser, contrast tool or integration is unavailable, mark those checks unverified
and give the next check to run. A successful build is not visual acceptance.

Compare the rendered page to the stated visual direction. Identify the three most
important concrete defects, or fewer if fewer exist. Fix them, then rerun affected
checks. Do not endlessly restyle or expand the scope. If the design depends on a
missing business choice, present that choice and continue independent checks.

## 6. Hand over clearly; launch only when ready

Deliver the preview or source, WEBSITE-BRIEF.md and WEBSITE-CHECKS.md. Explain how
to open it, where to edit content and which services are connected. Give the user
one practical next step. “Prepared”, “tested locally” and “live” mean different
things; label each accurately.

For an authorised launch, verify the intended account, project and domain before
using the existing deployment route. Review costs and required credentials without
exposing secrets. Resolve public placeholders, broken contact paths and relevant
privacy requirements. Check canonical URL, staging noindex rules and intended
production indexing. Add analytics only when requested or already authorised;
do not silently add advertising pixels.

Preserve a rollback reference. After deployment read back the actual recipient URL,
expected content and assets, and exercise the main action within its authority.
For an authorised form test, use an agreed test destination and verify receipt;
otherwise say delivery remains unverified. Reconcile an uncertain deployment or
submission before retrying it. Hosting, domains and optional services are separate
from this kit; never promise that publishing is free or already complete.

<!-- Provenance marker: sk-13s376t --><!-- Provenance signature: ⁠​‌​‌​​‌‌​‌​​​‌​‌​‌​​‌‌​​​‌​‌​​‌​​​‌‌​​​‌⁠ -->


---

# Claude Code Operating System

Made by Selr AI

This is a compact operating system for an AI coding project. It gives the agent a stable way to decide, plan, remember, delegate, verify, and hand work over. It is a bounded edition for a live session: it does not create an unattended daemon, install software, change permissions, publish work, send messages, spend money, or handle secrets.

## Use it safely

Ask an AI coding host to create or merge these project-local files:

```text
CLAUDE.md or AGENTS.md (choose for the active host)
.claude/skills/<skill>/SKILL.md
.agents/skills/<skill>/SKILL.md
board/_active/README.md
board/_log.md
memory/MEMORY.md
memory/lessons.md
```

Detect the host first. Prefer `.claude/skills/` in Claude Code; otherwise use the host's documented project-local skills location, such as `.agents/skills/`. If a file or directory already exists, read it and merge compatible sections. Never replace a person's instructions, delete their board, copy a global setup into a project, or run an installer merely because it is mentioned here.

## 1. Project rulebook: `CLAUDE.md` or `AGENTS.md`

Use CLAUDE.md for Claude Code and AGENTS.md for Codex. Read and merge the host's existing instruction file rather than creating a competing rulebook. Copy this as a starting point, then edit bracketed project facts.

```md
# [Project name] agent instructions

## Start with current evidence
Before a non-trivial change, read applicable instructions, current task state, relevant source files, and `git status --short`. Treat existing working-tree changes as someone else's until proven otherwise. Use a matching project-local skill when one exists. Do not invent facts from stale notes.

## Authority
Make routine technical choices inside the request: file layout, naming, implementation shape, and proportionate tests. Pause only the step that would spend money, create a legal or business commitment, destroy or irreversibly change data, publish externally, send a message, or expose a secret. Continue independent work around that step.

Never place credentials, tokens, private contact data, or internal records in source, chat output, commits, or generated documentation. Use available native capabilities and approved project tools. Do not bypass permission prompts, attach to a personal browser, or force an external browser when the host cannot perform an action.

## Plan and build
For work with several steps, write a short checklist and observable outcome gates before editing. Read relevant code before changing it. Keep the smallest complete fix in scope. Do not reset, clean, stash, force-push, or overwrite unrelated work as recovery.

If a task has independent, bounded leaves, use `spawn-agents` only when the host supports it and each result can be checked. The parent remains responsible for scope, decisions, integration, and proof.

## Verify and close
Inspect the actual diff and run the narrowest meaningful checks. Separate local tests, configured access, and live external proof. A green command is evidence only for what it exercised. Record the result, remaining uncertainty, and next action in the project board.

## Communication
Lead with the result. State what changed, how it was checked, and material limits. Ask one plain question only when a real authority gate remains. Keep a short running task list for multi-step work.
```

## 2. Five compact supporting skills

These skills intentionally overlap. Reuse and merge an existing same-named skill; do not install a duplicate or overwrite a richer project-specific version.

### `blindspot`

```md
---
name: blindspot
description: Turn an ambiguous build request into a bounded, testable brief before implementation.
---
# blindspot
Use for a new feature, migration, integration, or design with meaningful unknowns.
1. Read the task, instructions, source files, and current state.
2. List only uncertainties that could change scope, data safety, public behaviour, or verification.
3. Resolve facts from the repository before asking anyone.
4. Write: outcome, non-goals, allowed paths, constraints, acceptance checks, and recovery point.
5. Escalate only money, legal, irreversible, publication, external-send, or genuinely opposite scope choices. Give a recommendation.
Return a short plan and gates. Do not write code until important unknowns are settled or explicitly held.
```

### `drill-me`

```md
---
name: drill-me
description: Resolve a plan's decisions one at a time, with recommendations and an auditable decision log.
---
# drill-me
Use after `blindspot` when a plan has dependency-sensitive choices.
For each decision, state the question, recommended answer, one-line reason, and practical alternative. Read the project before asking a question it can answer. Resolve low-risk technical choices and append them to `DECISIONS.md`:
## D[number]: question
- Picked: choice
- Why: reason
- Reversible: yes/no
In `auto` mode, take recommended reversible technical choices. Stop for money, legal/compliance, destructive or irreversible action, public publishing, external sends, secrets, or business commitments. Produce a locked spec when finished.

Adapted from Matt Pocock's MIT-licensed grill-me approach. Attribution retained.
```

### `spawn-agents`

```md
---
name: spawn-agents
description: Delegate independent, checkable sub-tasks without losing parent ownership of decisions or integration.
---
# spawn-agents
Use only when native delegation is available and the parent can progress in parallel. Never create a user-visible task for an internal leaf.
Each brief contains: role, one outcome, sources, settled decisions, allowed paths, forbidden actions, expected evidence, check command, and stop condition. Give concurrent writers isolated paths or worktrees. Do not delegate authority decisions, browser/account state, secret access, publishing, spending, or external communication.
On return, inspect the artifact and rerun the relevant check. A worker summary is not proof. Integrate only owned changes and record limitations.
```

### `autopilot-loop`

```md
---
name: autopilot-loop
description: Run a guarded in-session plan-build-verify loop with a fixed stop condition and durable handoff.
---
# autopilot-loop
This edition is in-session only. It is not an unattended process, shell harness, permission bypass, or background daemon.
Before each pass, write `PLAN.md` with checked tasks, scope fence, expected checks, and a maximum pass count. For every pass: pick one unchecked item; use `drill-me auto` for reversible technical choices; implement; inspect the diff; run the named check; record evidence; then continue only if progress is real.
Stop for authority gates, missing verification, repeated unchanged failure, out-of-scope work, or the pass cap. After two failed attempts at the same issue, preserve evidence and hand off. Never reset, stash, clean, commit, push, publish, send, spend, or touch secrets as part of the loop unless separately authorised.
```

### `cross-check`

```md
---
name: cross-check
description: Independently inspect a completed change against its request, failure paths, and stated evidence.
---
# cross-check
Read the request, instructions, changed files, and test output. Check scope creep, data and authority boundaries, unhappy paths, regressions, documentation accuracy, and whether each claimed result follows from evidence.
Return findings by severity with file and line references when possible. If no independent reviewer is available, say so and perform a focused self-review. Do not call a same-model review independent verification.
```

## 3. Board and memory starters

Create only missing files, or add headings to existing ones.

`board/_active/README.md`

```md
# Active work
One file per active task. Use `[ ]` open, `[~]` in progress, `[x]` checked with date.
Each task records: owner, goal, allowed paths, gates, evidence, blocker, and next action.
```

`board/_log.md`

```md
# Completed work
- YYYY-MM-DD — task — result — checks — known limit
```

`memory/MEMORY.md`

```md
# Project memory
Keep durable, verified facts as short entries with a source pointer. Do not store secrets, personal data, transient logs, or assumptions.
```

`memory/lessons.md`

```md
# Lessons
- YYYY-MM-DD — trigger — rule that prevents recurrence — evidence/source
```

## 4. First-run prompt

```text
Set up the bounded project operating system from this document. Detect the host and use project-local `.claude/skills` or `.agents/skills`. Read existing instructions and merge rather than replace them. Create only missing starter board and memory files. Do not install packages, alter global configuration, run a daemon, change permissions, touch secrets, publish, send messages, spend money, or make git changes. Show proposed files and run only structural checks.
```

## Recovery and self-check

Before considering setup complete, check that each skill has frontmatter and a `SKILL.md`, existing instructions were preserved, and no global or external action was taken. If a directory is unsupported, leave the content as a proposed project-local folder and explain the host limitation. The package remains useful without automation: the agent can follow the rulebook and playbooks directly.


---

# Agent Routing Kit

Made by Selr AI

This is a copy-paste kit for splitting suitable coding work among native agents while one parent remains accountable for the answer. It does not rank models, predict costs, invoke a billing path, install tools, or create background jobs. Use capabilities the current host actually exposes.

## What routing is for

Route work only when a leaf is independent, bounded, and checkable. Good leaves include a source inventory, focused test failure investigation, documented component change, or a review against a settled brief. Keep ambiguous design, authority decisions, cross-cutting integration, external actions, and final acceptance with the parent.

Do not delegate merely to fill capacity. Do not make a new sidebar task for internal work. Do not give two writers the same files. Do not use workers to bypass a permission denial, access a browser session, use secrets, publish, send, spend, or make a destructive change.

## Host detection and merge rule

Place this guidance in project instructions or create a local `agent-routing` skill:

```text
.claude/skills/agent-routing/SKILL.md
.agents/skills/agent-routing/SKILL.md
```

Check the host's native delegation feature first. If unavailable, work serially with the same plan and verification gates. If an existing routing skill or `AGENTS.md` defines a method, merge this kit's useful safety and evidence sections into it. Do not overwrite local policies, global configuration, model choices, or user preferences.

## Parent operating rules

```md
---
name: agent-routing
description: Plan, brief, verify, and integrate independently checkable native-agent work.
---
# agent-routing
The parent owns framing, task plan, user authority, cross-cutting decisions, final integration, and final report. Use supported agents without assuming model names, availability, quality, usage, or cost.
Before dispatch, write a routing ledger:
| Leaf | Owner | Outcome | Allowed paths | Gate | State |
|---|---|---|---|---|---|
| source audit | worker | exact findings | docs only | citations | planned |
Dispatch only a leaf with one tangible output and observable gate. Record planned, running, returned, verified, blocked, or cancelled. A worker does not delegate again unless explicitly authorised.
Never route authority decisions or action involving money, legal/compliance, irreversible data changes, secrets, external sends, publishing, account/browser state, or unrelated files. Stop that leaf and continue safe work.
```

## Match the model to the work

Use the models and effort settings actually available on this host; preserve
explicit user choices. Do not invent quality scores or assume another paid plan.

| Work | Selection rule | Acceptance evidence |
| --- | --- | --- |
| Exact extraction or formatting | Smallest capable available worker | Deterministic comparison |
| Bounded source research | Worker with the required read tools | Source pointers and uncertainties |
| Settled implementation | Capable coding worker, isolated files | Relevant success/failure tests |
| Unsettled architecture or visual direction | Keep with the parent | Decisions against brief and rendered evidence |
| Consequential review | Different model from author when available | Findings checked against actual artifacts |

A cheaper or faster option is useful only when the result can be verified.
If the chosen worker cannot complete the leaf, inspect the cause before one
revised attempt. Do not bounce the task through every model or switch accounts
to bypass a limit. Record the requested model separately from what the host can
actually confirm. No fixed savings or quota claims are part of this kit.

## Worker brief template

Give every worker a self-contained brief. Replace brackets with project facts.

```text
ROLE-LOCK
You are the [researcher / implementer / reviewer] for one bounded leaf. Do not orchestrate, delegate, or broaden scope.

OUTCOME
Deliver [one concrete artifact or answer] that lets the parent decide or integrate.

USER AUTHORITY
The user authorised [specific local/read-only/implementation scope]. They have not authorised publishing, external messages, spending, account changes, secret handling, destructive operations, commits, pushes, or unrelated edits.

SOURCES
Read: [exact files, task text, relevant instructions]. Treat other working-tree changes as owned by others.

SETTLED DECISIONS
- [decision already made]
- [interface or acceptance rule]

ALLOWED PATHS
- [path or directory]

FORBIDDEN
- Do not edit outside allowed paths.
- Do not use resets, stashes, cleans, force-pushes, permission bypasses, external browsers, installs, or global configuration.
- Do not send, publish, spend, access secrets, or touch external state.

EVIDENCE GATE
Run or provide: [specific command, diff inspection, fixture, or source citations].
Expected result: [observable result].

RETURN FORMAT
1. Changed files or findings
2. Evidence and exact limitations
3. Blocker or next action

STOP
Stop and return control if scope is unclear, a gate needs authority, files conflict, a tool is unavailable, or the check fails twice without a new diagnosis.
```

## Choosing a leaf

Use this short test before dispatch:

1. Can the result be described in one sentence?
2. Can the worker read only a small, known source set?
3. Can it own disjoint files or stay read-only?
4. Is there a meaningful check, comparison, or review criterion?
5. Can the parent do useful work while it runs?

If any answer is no, keep the work with the parent or first use `blindspot` and `drill-me` to settle the design. If the user said no agents, do not delegate.

## Example routing ledger

```md
| Leaf | Outcome | Allowed paths | Evidence gate | State |
|---|---|---|---|---|
| Source audit | List route entrypoints | `docs/` read-only | citations to exact files | verified |
| UI repair | Correct one empty state | `src/ui/EmptyState.tsx` | targeted test + render check | running |
| Review | Inspect diff for regressions | read-only | findings or explicit none | planned |
```

The example is a planning device, not a promise that three agents are needed.

## Integration protocol

When a worker returns:

1. Read the actual artifact, diff, or cited source. Do not accept a confident summary alone.
2. Confirm it stayed inside its allowed paths and authority boundary.
3. Re-run the stated check when feasible. For a review leaf, assess every finding against source.
4. Reconcile with current working-tree changes before applying an owned edit.
5. Run the narrow integration check across the combined result.
6. Update the ledger with evidence or the specific reason it is blocked.

One independent review can help on consequential changes, but an independent agent is not automatically independent verification. Say what was checked and by whom. A local test does not prove an external deployment or account configuration.

## Outcome verification

Write the expected outcome before a worker starts. Good gates make a claim falsifiable:

```text
Claim: the parser accepts the documented input and rejects malformed input.
Evidence: focused tests show both cases and exit successfully.
Limit: this does not prove production traffic or a third-party service.
```

Choose the narrowest evidence that exercises the leaf:

- Source audit: exact file citations and a conflict note.
- Mechanical edit: exact diff comparison or deterministic formatter/checker.
- Behaviour repair: focused automated test plus the relevant failure case.
- Visual change: rendered inspection at its intended size.
- Integration: a combined check covering the join between leaves.

If evidence cannot be run, return the command, why it could not run, and what remains unproven. Do not rewrite the acceptance criterion after a failure simply to close the task.

## Scope fence example

```text
IN SCOPE: `src/parser/`, tests for parser behaviour, and the related documentation.
OUT OF SCOPE: dependency upgrades, production configuration, release notes, deployment, and all external accounts.
STOP: a change outside these paths is required, a public compatibility decision appears, or current work conflicts with another edit.
```

Scope fences protect speed as well as safety: they keep a worker from solving a neighbouring problem while the requested result waits.

## Failure and recovery

On a failed worker check, require a diagnosis before one focused retry. Never repeat the same request unchanged. On a conflict, preserve both sides and return the exact files and decision needed. On tool, authentication, permission, or quota failure, do not retry blindly or switch accounts/models to work around it.

Never recover by deleting files, resetting a branch, stashing work, cleaning untracked files, or widening permissions. Keep evidence and hand off a concise blocker instead.

## First-use prompt

```text
Use the Agent Routing Kit for this project. First inspect project instructions and native delegation support. Create a short plan and routing ledger. Delegate only independent leaves with disjoint ownership and a clear evidence gate; otherwise work serially. Preserve existing files and configuration. Do not install tools, change permissions, use external browser workarounds, access secrets, commit, push, publish, send, spend, or perform destructive recovery. Verify every returned result before integrating it.
```

## Self-check

Before calling routed work complete, verify every leaf has an outcome, source set, scope fence, and evidence gate; no concurrent writers overlapped; the parent inspected returned work; and remaining uncertainty is named. If native delegation is absent, the kit still works as a serial checklist.


---

# Claude Autonomy Kit

Made by Selr AI

This edition helps an AI coding session keep moving through a bounded plan without hiding decisions or losing its place. It is deliberately in-session: no unattended daemon, loop harness, auto-commit, permission bypass, background service, package installation, or external automation is included.

The plan-and-question approach adapts the useful core of Matt Pocock's MIT-licensed `grill-me` style: surface important unknowns, recommend an answer, and record the decision. Attribution is retained; this document is not a replacement for the original project.

## Project-local installation shape

Ask the host to detect itself. Claude Code normally uses `.claude/skills/`; another compatible agent host may use `.agents/skills/`.

```text
.claude/skills/drill-me/SKILL.md
.claude/skills/autopilot-loop/SKILL.md
.agents/skills/drill-me/SKILL.md
.agents/skills/autopilot-loop/SKILL.md
PLAN.md
DECISIONS.md
HANDOFF.md
```

Read existing files first. Merge compatible instructions and preserve the project’s own setup. Do not copy these files to a home directory, run an installer, modify permissions, or replace a richer local workflow.

## 1. `drill-me`: settle the plan before the build

```md
---
name: drill-me
description: Resolve material plan decisions with recommendations, a decision log, and explicit authority gates.
---
# drill-me
Use for plans, designs, and implementation briefs with unknowns that could change the result.
First read the task, project instructions, relevant code, and existing decisions. Do not ask the user what the repository can answer. Then identify decisions in dependency order.

For each decision, write:
## D[number]: [plain-language question]
- Recommendation: [choice]
- Why: [one sentence grounded in the project]
- Alternative: [real alternative and trade-off]
- Reversible: [yes/no]
- Evidence: [file, test, or source]

Interactive mode: ask one highest-leverage question at a time, with the recommendation. Auto mode: take a reversible technical recommendation, log it, and continue.

Stop auto mode only for money, legal/compliance, destructive or irreversible data actions, publishing, external messages, secrets, account changes, or a business-scope commitment. Give a recommendation and continue unrelated work.

Finish with a locked brief: desired outcome, non-goals, allowed paths, acceptance checks, known limits, and the next safe action.
```

## 2. `autopilot-loop`: a guarded in-session rhythm

```md
---
name: autopilot-loop
description: Execute a project plan in a bounded in-session build, inspect, verify, and handoff loop.
---
# autopilot-loop
This skill runs only while the current AI session is active. It must not start a daemon, schedule itself, call an external automation service, or assume a special permission mode.

## Preflight
Before implementation, create or update `PLAN.md`:
# Plan: [goal]
- Scope: [allowed files and explicit non-goals]
- Evidence gate: [test, build, visual inspection, or source comparison]
- Maximum passes: [small fixed number, e.g. 5]
- [ ] One bounded task
- [ ] Next bounded task

Create `HANDOFF.md` if work spans a session. Record current state, changed files, checks, blockers, and next action.

## One pass
1. Select one unchecked task.
2. Read its relevant files and instructions.
3. Use `drill-me auto` only for reversible technical choices.
4. Make the smallest complete in-scope change.
5. Inspect the diff and run the named evidence gate.
6. Mark a task complete only when its evidence is present.
7. Update `DECISIONS.md` and `HANDOFF.md` before another pass.

## Stop conditions
Stop and hand off when the goal is proven, the pass cap is reached, an authority gate appears, the task leaves scope, verification is unavailable, or two attempts fail without a new diagnosis.
Never equate a passing test with live deployment, account configuration, or user acceptance. Do not reset, stash, clean, delete, force-push, commit, push, publish, send, spend, or use secrets as automatic recovery.
```

## 3. Two complementary planning skills

Create these project-local skills too, merging an existing same-named version.

### `grill-me`

```md
---
name: grill-me
description: Stress-test an idea through a focused interview before committing to a build.
---
# grill-me
Read the user's brief and existing sources. Identify the highest-impact unknown:
the user, real job, success criterion, constraint, dependency or failure mode.
Ask one clear question with a recommended answer and reason. Follow its
implications before moving to another topic. Do not ask facts the files answer.
Keep a short decision log. When the critical unknowns are resolved, return a
brief with outcome, non-goals, assumptions, risks and observable acceptance checks.
This is planning; do not start a build, spend, publish or change data during the
interview. The user may stop or request the current brief at any time.
```

### `grill-with-docs`

```md
---
name: grill-with-docs
description: Check a plan against a project's existing architecture and documented decisions.
---
# grill-with-docs
Read the named README, glossary, architecture decisions and current code relevant
to the proposed change. Cite the source for each requirement. Separate current
implementation, documented intent and unresolved contradictions.
Interview only on conflicts that affect the plan. Recommend a choice grounded in
those sources. Draft a context update and an architecture decision record:
Title / Status / Context / Options / Decision / Consequences / Evidence.
Preserve accepted decisions. Never silently rewrite project history or claim a
draft decision is approved. Finish with the revised brief and source pointers.
```

## 4. Working files

`PLAN.md`

```md
# Plan: [outcome]
## Scope
- Allowed: [paths]
- Excluded: [paths or behaviours]
## Gates
- Evidence: [exact command or inspection]
- Stop after: [N] passes
## Tasks
- [ ] [small outcome]
- [ ] [small outcome]
```

`DECISIONS.md`

```md
# Decisions
## D1: [question]
- Picked: [choice]
- Why: [reason]
- Reversible: [yes/no]
- Evidence: [source]
```

`HANDOFF.md`

```md
# Handoff: [task]
- Status: [in progress / blocked / ready for review]
- Goal: [one sentence]
- Changed: [files]
- Checks: [command and result, or not run]
- Known limit: [plain statement]
- Next safe action: [one action]
- Needs authority: [only if applicable]
```

## 5. Clarification without stalling

Most technical choices should not interrupt a build. Inspect code, choose a reversible default, log it, and proceed. Ask only where the answer changes authority or intent: a real cost, legal claim, irreversible data operation, public release, message to another person, handling of a secret, account change, or two genuinely opposite readings of the request.

Keep the question short. State the consequence, recommend an option, and name the default hold. Do not turn ordinary naming, library, formatting, or test decisions into a user interview.

```text
Decision needed: [plain question].
Recommendation: [choice], because [reason].
Holding: [the risky step only]. I can continue with [safe work].
```

## 6. Recovery rules

A loop should become more informed with every pass. If the same check fails twice, stop repeating it. Save the error, files examined, attempted fix, and smallest next experiment in `HANDOFF.md`. If a tool lacks access or permission, treat that as a boundary, not a reason to try a different account, hidden flag, browser workaround, or wider permission setting.

Preserve the working tree. Recovery means narrowing the hypothesis, not deleting work. Do not use reset, clean, stash, or automatic rollback of someone else's changes.

## 7. First-use prompt

```text
Set up this bounded autonomy kit in the current project. Detect the host and use `.claude/skills` or `.agents/skills`; merge with existing project instructions and preserve personal setup. Create `PLAN.md`, `DECISIONS.md`, and `HANDOFF.md` only if missing. Run one in-session pass at a time with explicit evidence gates and a fixed pass cap. Do not install packages, create a daemon, change permissions, use external browser workarounds, access secrets, commit, push, publish, send messages, spend money, or perform destructive recovery. Stop and hand off when an authority gate or repeated unexplained failure appears.
```

## Self-check

The kit is ready when the plan has a scope fence, observable evidence gate, and pass cap; every automatic decision is logged; an authority gate has a clear stop rule; and the handoff file can let another session continue without guessing. This bounded edition remains useful even when the host has no background-loop feature.


---

# Keeper: connect a narrowly scoped secrets folder

Made by Selr AI.

You are the AI assisting the account owner. Carry out routine supported setup steps yourself; do not hand the owner a list of terminal commands. Detect the OS and actual client before choosing commands. The shell examples below are POSIX examples for the agent; use verified platform equivalents on Windows. Owner-only authentication must use the host-supported secure flow. If no such flow is available, hold that connection step and explain the precise limitation.

This guide connects a local automation or development tool to **one deliberately selected Keeper shared folder**. It does not create records, import passwords, search the whole vault, change sharing, or expose secret values in chat, logs, or project files.

> **What this guide proves:** the documentation paths were checked on 14 September 2026. A downloaded guide is not proof that a Keeper account, plan, application, client device, or local connection has been tested.

## Before you begin

- You need a Keeper account with permission to use Secrets Manager. This capability can be controlled by your organisation and plan.
- Choose one existing shared folder containing only the records required for this connection. Create a new, purpose-specific folder in the Keeper Vault if that is safer.
- Select **read-only** access unless a specific write operation has been approved. Do not grant access to a broad team folder merely because it is convenient.
- Use your own signed-in Keeper Vault or supported secure terminal prompt. Never paste a master password, one-time access token, API key, password, recovery code, or exported configuration into an AI chat, issue, document, shell history, or log.

## The access model

Keeper Secrets Manager (KSM) uses an application and a client device. The application sees only the records or shared folders that its owner explicitly assigns. The initial device setup uses a one-time access token; after initialisation, the device holds its own encrypted configuration. See Keeper’s [one-time token guide](https://docs.keeper.io/keeperpam/secrets-manager/about/one-time-token) and [security model](https://docs.keeper.io/keeperpam/secrets-manager/about/security-encryption-model).

Do not use a personal vault, an entire team vault, an administrator’s general-purpose application, or a shared token for this guide.

## Host check: choose the right lane

Run this read-only check in a terminal:

```sh
command -v claude && echo "Claude Code available"
command -v codex && echo "Codex available"
```

If neither command is available, set up KSM for the approved local service or application instead. Do not add global agent plugins or overwrite an agent configuration just to complete this guide.

Claude Code and Codex may use a local integration only when the host offers a supported secure credential entry path. If the host cannot keep the configuration outside chat, source control, and plaintext project files, stop here. Use Keeper’s Vault manually until a supported path is available.

## Step 1: create the smallest safe scope in the Vault

1. Sign in at [Keeper Web Vault](https://keepersecurity.com/vault/) or your organisation’s regional Vault URL.
2. In the folder tree, select the approved shared folder. If needed, choose **Create New → Shared Folder** and give it a specific purpose, such as `Podcast production - read only`.
3. Use an existing owner-selected folder containing only the approved records. If a new empty folder was created, let the owner assign the records; do not move, copy or seed records yourself.
4. Review the selected scope. Do not remove other users or change existing shared-folder permissions. If the scope is too broad, ask the owner to select a narrower purpose-specific folder.
5. Record the folder name for the owner. Do not paste record titles, folder IDs, or record contents into this guide or chat.

Keeper’s [Web Vault sharing guide](https://docs.keeper.io/user-guides/web-vault) explains shared folders and permission levels.

## Step 2: create a dedicated KSM application

1. In the Keeper Vault navigation, open **Secrets Manager**.
2. Select **Create Application** and give it an unambiguous local name, such as `podcast-workstation-read-only`.
3. Attach only the selected shared folder.
4. Choose **read** permission. Enable edit permission only after a separate, explicit decision identifies the records and write action required.
5. If the option is offered and practical for your network, enable the device IP lock. It limits a client device to its first external IP address.

Keeper documents this Vault flow, including application scope, access level, device creation, and optional IP lock, in its [one-time token guide](https://docs.keeper.io/keeperpam/secrets-manager/about/one-time-token).

## Step 3: initialise one client device securely

1. In the application’s **Devices** area, create a device for this computer or service.
2. Generate its one-time access token.
3. Transfer the token only through a supported secure entry mechanism on the target machine. A password-manager secure prompt, a local terminal owned by the account holder, or an approved secrets-injection mechanism can qualify.
4. Do not paste the token into an AI conversation. Do not save it in a shell profile, `.env`, repository, screenshot, note, or command history.
5. Initialise the KSM client using the official KSM CLI instructions. The documented command is `ksm profile init` with the one-time token supplied through the secure local mechanism.

KSM client initialisation and the CLI command surface are documented in the [KSM CLI guide](https://docs.keeper.io/keeperpam/secrets-manager/secrets-manager-command-line-interface). A token is displayed only when the device is created and cannot be retrieved later, so create a new device if it is lost.

### Stop condition

If the automation host asks you to reveal a secret in chat, to place it in a project file, or to work around its secure-entry limitation, **do not continue the connection step**. Revoke the unused device if necessary and use the Vault without automation. Do not invent a token-paste workaround.

## Step 4: non-secret verification

After secure initialisation, verify the connection without retrieving a secret:

```sh
ksm version
ksm profile list
ksm folder list
```

The folder-list result should show only the selected application scope. Do not add `--list-records`, run a vault tree, export a report, or enumerate record details as a connection test.

For an agent integration, first confirm that its tool or command listing is present. Then make one read-only request for a single owner-approved record **name or metadata**, through the secure local integration. Do not print the value. A successful tool listing plus a constrained metadata/read response is sufficient evidence of connectivity.

## Recovery and safe retry limits

| Situation | Safe response |
| --- | --- |
| KSM is missing from the Vault or access is denied | Stop and ask the account owner or Keeper administrator to confirm plan and role entitlement. Do not upgrade, change roles, or use another person’s application. |
| The scoped folder is absent | Verify that the application has exactly that folder attached. Do not broaden the application scope. |
| Device is rejected after an IP change | The owner may create a new device or change the approved device policy. Make one deliberate change, then retry the non-secret verification once. |
| Token was exposed or pasted into the wrong place | Treat it as compromised: stop, revoke that device in Keeper, and create a new one. Never reuse the token. |
| A command waits for a master password | Cancel it. Use an interactive, owner-controlled Keeper login only, or return to the secure KSM path. Do not type the password into an agent-controlled prompt. |

Limit each failure diagnosis to **one configuration check and one retry**. If it still fails, stop and capture only the non-secret error class, the application name, and the owner action required.

## Remove access when the work ends

The owner can disable or remove the client device from the KSM application, then confirm that the application still exposes only its intended folder. Removing the device is preferable to leaving an unused machine authorised.

## Official references

- [Keeper Vault sharing](https://docs.keeper.io/user-guides/web-vault)
- [Keeper Secrets Manager one-time access tokens](https://docs.keeper.io/keeperpam/secrets-manager/about/one-time-token)
- [KSM command-line interface](https://docs.keeper.io/keeperpam/secrets-manager/secrets-manager-command-line-interface)
- [KSM security and encryption model](https://docs.keeper.io/keeperpam/secrets-manager/about/security-encryption-model)
- [Keeper Commander overview](https://docs.keeper.io/en/keeperpam/commander-cli/overview)


---

# Higgsfield: connect with OAuth, then create deliberately

Made by Selr AI.

You are the AI assisting the account owner. Carry out routine supported setup steps yourself; do not hand the owner a list of terminal commands. Detect the OS and actual client before choosing commands. The shell examples below are POSIX examples for the agent; use verified platform equivalents on Windows. Owner-only authentication must use the host-supported secure flow. If no such flow is available, hold that connection step and explain the precise limitation.

Higgsfield connects an AI client to its creative tools through OAuth. You sign in to your own Higgsfield account in the authorised browser flow, then the client can list available tools and create work using your account entitlements.

> **What this guide proves:** the official connection URL and install paths were checked on 14 September 2026. A downloaded guide is not evidence of a live account, subscription, tool listing, OAuth connection, or successful generation.

## What you need

- A Higgsfield account. Generations require an account.
- An AI client with an existing supported MCP or CLI integration path.
- Permission to spend any required Higgsfield credits. Generations use the same account credit system as the Higgsfield platform, with cost varying by model and resolution.

Use only Higgsfield’s official surfaces. The official MCP endpoint is `https://mcp.higgsfield.ai/mcp`; the official setup page is [higgsfield.ai/mcp](https://higgsfield.ai/mcp). Higgsfield says accounts, subscriptions, and credits are managed on [higgsfield.ai](https://higgsfield.ai/), not through resellers or lookalike services.

## Host check

Run this read-only command:

```sh
command -v claude && echo "Claude Code available"
command -v codex && echo "Codex available"
command -v higgsfield && echo "Higgsfield CLI already available"
```

Do not install a global plugin, modify a shared agent configuration, or overwrite an existing MCP entry. Choose the first available supported lane below.

## Lane A: use an existing MCP connection screen

Use this when Claude, Codex, or another MCP-capable client already provides a connection screen or project-local MCP setup.

1. Add the official server URL: `https://mcp.higgsfield.ai/mcp`.
2. Start the client’s OAuth sign-in flow.
3. Complete sign-in only in the official Higgsfield browser page opened by that flow.
4. Return to the client and confirm the connection shows as authorised.
5. Ask the client to list Higgsfield tools or models. This is a read-only connection check.

Do not paste a password, browser cookie, access token, or exported OAuth configuration into chat, a terminal transcript, source control, or a configuration file. If the client has no supported OAuth flow, stop this lane.

## Lane B: official CLI for Claude Code or Codex

Higgsfield recommends its CLI for Claude Code and Codex. Inspect the selected official installer and its destination before running it. Choose one install method for the detected platform; do not run all three:

```sh
# macOS or Linux, Homebrew
brew install higgsfield-ai/tap/higgsfield

# macOS or Linux, vendor installer
curl -fsSL https://raw.githubusercontent.com/higgsfield-ai/cli/main/install.sh | sh

# Cross-platform, including Windows, when Node.js is already available
npm install -g @higgsfield/cli
```

Then authenticate through the browser flow:

```sh
higgsfield auth login
```

The command opens the supported sign-in flow. Complete it with your own account. Do not ask an agent to handle an owner-only authentication challenge. Higgsfield’s [CLI page](https://higgsfield.ai/cli) and its [official CLI repository](https://github.com/higgsfield-ai/cli) publish these install and login commands.

The official CLI page also offers companion skills:

```sh
npx skills add higgsfield-ai/skills
```

Run that only if you want those skills and understand where your client installs them. It is optional and must not replace or alter existing global agent configuration without your approval.

## Verify without spending credits

After OAuth succeeds, list available models or workflows before any generation:

```sh
higgsfield model list
higgsfield workflow list
```

For MCP, ask the client to list Higgsfield tools, supported models, or creation history. Make one read-only request only. If the listing fails, stop and resolve authentication or account entitlement before retrying.

Do **not** generate a test image to prove that the connection works. A generation can consume credits.

## Before every generation

1. Select the exact prompt, desired aspect ratio, duration, and model.
2. Ask the client for the current cost estimate when the selected workflow supports it.
3. Confirm the planned generation and spend with the account holder unless they have already authorised that exact prompt and cost.
4. Generate once. Inspect the result before requesting another variation.

Higgsfield states that credit cost varies by selected model and resolution. Its CLI supports estimates for supported workflows, for example `higgsfield generate cost workflow reframe --duration 7.1 --resolution 1080p`. Some workflows do not expose a cost estimate, so obtain account-holder approval before submitting those jobs.

## Five starter prompts

These are briefs, not automatic actions. Replace the bracketed details, select a model after tool discovery, and approve the job before it is sent.

### 1. Founder portrait

`Editorial founder portrait of [person], [industry] context, natural window light, calm confident expression, clean [brand colour] background, waist-up composition, realistic skin texture, no text, 4:5.`

### 2. Product still

`Premium product photograph of [product] on [surface], one clear use-case cue, soft directional daylight, restrained styling, product label accurate and legible, clean negative space on the [left/right] for later copy, 4:5.`

### 3. Social explain-it clip

`Create an 8-second 9:16 video explaining [one useful idea] for [audience]. Open with “[hook]”. Use a clear visual metaphor, fast but readable captions, three short beats, and a practical final takeaway. Avoid claims that cannot be supported.`

### 4. Product demonstration

`Create a 10-second 9:16 product demonstration for [product]. Show [problem] in the first two seconds, then one believable use, one close product detail, and a simple end frame. Natural human movement, accurate product proportions, no invented features, sound off.`

### 5. Calm cinematic B-roll

`Create a 5-second 16:9 cinematic B-roll shot of [scene] at [time of day]. Single slow [camera movement], tactile detail in [foreground], soft depth of field, realistic motion, no text, no logos, no people unless specified.`

## Safe recovery

| Problem | Recovery |
| --- | --- |
| OAuth does not finish | Close the authorisation window, begin the same client’s OAuth flow once more, and verify you are signing in at an official Higgsfield domain. |
| Tools do not appear after authorisation | Restart the client if it requires it, then run one model or tool-list request. Do not add duplicate servers. |
| Tool list works but a job is unavailable | Check the model or workflow listing and account entitlement. Choose a listed option or stop. |
| Credit or cost is unclear | Do not generate. Check account billing and request approval for a named prompt and configuration. |
| A generation fails | Read the returned job status, correct one concrete input issue, then retry once. Do not launch multiple duplicate jobs. |

## Official references

- [Official Higgsfield platforms and MCP endpoint](https://higgsfield.ai/creator-hub/help-center/getting-started/official-higgsfield-platforms)
- [Higgsfield MCP and ChatGPT plugin](https://higgsfield.ai/mcp)
- [Higgsfield CLI setup](https://higgsfield.ai/cli)
- [Official Higgsfield CLI repository](https://github.com/higgsfield-ai/cli)
- [Higgsfield pricing](https://higgsfield.ai/pricing)
- [Higgsfield API documentation](https://docs.higgsfield.ai/docs)


---

# Nine Software Alternatives

Made by Selr AI.

Help me evaluate the following nine tools against the software I actually use.
These are alternatives to investigate, not guaranteed feature-equivalent or
zero-cost replacements. Project licences, hosted plans, hardware, maintenance,
AI model costs and migration effort must be checked from current official sources.

- Project management: https://github.com/makeplane/plane (replaces Jira, Asana, Monday)
- Design and prototyping: https://github.com/penpot/penpot (replaces Figma)
- Email marketing: https://github.com/knadh/listmonk (replaces Mailchimp)
- Screen recording: https://github.com/CapSoftware/Cap (replaces Loom)
- Customer support: https://github.com/chatwoot/chatwoot (replaces Intercom and Zendesk)
- E-signatures: https://github.com/documenso/documenso (replaces DocuSign)
- CRM and pipeline: https://github.com/twentyhq/twenty (replaces Salesforce and HubSpot)
- Voice and audio: https://github.com/jamiepine/voicebox (replaces ElevenLabs)
- Image generation: https://github.com/invoke-ai/InvokeAI (replaces Midjourney)

## 1. Understand the job
Ask which tools I currently use, what I pay, and the three features I cannot lose.
If my brief already supplies those facts, use them rather than asking again.
Do not assume an enterprise feature exists in a project's self-hosted edition.

## 2. Compare before installing
Visit each relevant official project README and documentation above. Record:
- Maintained release and licence; identify source-available restrictions if any.
- Required OS, hardware, local dependencies and hosting model.
- Available features versus my must-haves; integrations and export formats.
- Authentication, backups, security updates and operating responsibility.
- Hosted fees, infrastructure, usage fees and migration effort.
- Concrete limitations and a reason to keep the existing product if appropriate.

Return a short table: current job | candidate | strengths | gaps | real costs |
setup effort | recommendation. Calculate savings only from my supplied spend and
verified candidate costs; show assumptions and excluded costs separately.
Never promise that self-hosted software has no running cost.

## 3. Pick a pilot
Recommend one low-risk candidate that fits my actual job. Agree the pilot before
installation. Do not automatically install all nine or cancel subscriptions.
Read the current official installation instructions, inspect the relevant
installer, and identify writes, ports, services, accounts and costs.
Use an isolated project directory and fictional test data. Never reuse default
passwords, expose a service publicly, import customer data or alter a production
system merely to prove it starts.
Respect the host's available tools and browser lane. A missing tool is a specific
setup blocker, not permission to change unrelated global configuration.

## 4. Verify the useful workflow
Test the same representative job in the current product and the pilot. Check
import/export, access controls, backup and restore where relevant. A running
container or HTTP 200 alone is not proof of a successful replacement.
Record what worked, failed and remains unverified. Run one focused repair for a
known error, then stop that action if it still fails; do not retry paid or
irreversible actions blindly.

## 5. Handover
Write PILOT-REPORT.md with version, source links, install directory, start/stop
instructions, costs, tests, limits and removal instructions. Keep secrets out.
Recommend keep, continue pilot or reject. Migration, public exposure, messages,
real data and subscription cancellation each need their own authorised scope.

## Optional extras: MAPS and reusable commands
For a vague brief, structure it as Mission (outcome), Ask (deliverable), Parameters
(facts, limits and sources), Shape (format and checks). Ask only for missing
information that changes the outcome.
For recurring work, create a named project instruction with inputs, output shape,
source rules and acceptance checks. Draft email/follow-up/caption commands may
prepare content, but must not send or publish it without authorisation.


---

# Full Stack Builder Pack — guided build edition

Made by Selr AI.

Paste this document into your coding AI in the project you want to work on.
This edition supplies a build workflow and project templates. It does not install
or certify the older nine-skill automation stack.

## Mission
Help me turn a business process into a working, owner-controlled application.
Use the existing repository and design system when present. For a new app, start
with the smallest useful workflow and a local preview. Do not invent business
rules, commercial claims, testimonials, prices or integrations.

## 1. Establish the project
Read the existing project instructions, README, manifest and Git status first.
Preserve uncommitted work. Do not delete, reset, stash, force-push or reclone an
existing working directory. Establish which directory I authorised.
Infer the following from my brief; ask only for missing choices that materially
change the application:
- Who uses this, and what job must they finish?
- What is the input, decision and resulting output?
- What is the first workflow worth building?
- What information is sensitive, and who may access it?
- Do I need a local prototype, a team app, or a public service?

Write BUILD-BRIEF.md with these sections:
1. User and job
2. First workflow and out-of-scope work
3. Inputs and outputs
4. Business rules: confirmed / unresolved
5. Data owners and access roles
6. Acceptance checks
7. External services: required / optional / not connected

## 2. Check foundations
Keep the installed stack unless there is a concrete reason to change it. A new
Next.js/React app with Supabase is an option, not a mandatory rewrite.
Consult current official documentation before selecting commands or paid plans:
- https://nextjs.org/docs
- https://supabase.com/docs
- https://vercel.com/docs
- https://docs.github.com/
Use accounts owned by the user. No shared operator accounts or source credentials.
Do not buy subscriptions, create public repositories, alter DNS or deploy merely
because these actions appear in a reference. Preparation is not publication.
Never put server secrets in client code, browser storage, screenshots or chat.

## 3. Build the smallest vertical slice
Build input -> validation -> authorised storage/processing -> useful result.
Use fictional fixtures until a real-data connection is authorised.
Do not label mock records or placeholder integrations as live.
Keep a component map and a data-flow diagram in BUILD-BRIEF.md.
For each database entity record fields, ownership, permitted operations and
retention. If a database supports row-level policies, verify two fictional users
cannot read or change each other's records. Test server-side authorisation too.

## 4. Make it usable
Use the user's supplied brand, actual logos, type and existing components.
Check narrow and wide layouts, keyboard access, visible focus, labels, validation,
empty states, loading, errors and success confirmation.
Keep the main action obvious. Describe errors with a recovery action.
Do not send messages, create charges or write production data during UI tests.

## 5. Verify the result
Define observable checks before implementing the workflow:
| User action | Expected result | Evidence | Status |
| --- | --- | --- | --- |
| Valid submission | Saved result visible to owner | Test or readback | Pending |
| Invalid submission | Useful error, no write | Test | Pending |
| Unauthorised access | Denied without data exposure | Two-user test | Pending |
| Retry | No duplicate side effect | Test where applicable | Pending |
Run the project's relevant build/lint/tests. Inspect the actual rendered artifact
using the host's supported browser. If unavailable, state that visual inspection
is unverified. A successful build alone does not prove the workflow works.

## 6. Preview and release
Deliver a local preview and a short acceptance report first.
When deployment is explicitly authorised, verify destination account/project,
environment, domain, secrets, migrations, costs and rollback plan. Separate a
repository push from deployment. After deployment verify the named release and
user flow on the intended URL. Do not automatically retry an uncertain write.

## 7. Iterate and hand over
Create APP-STATUS.md:
- What works, with evidence
- What is mocked, configured or unverified
- How to start, stop and test locally
- Service owners and non-secret configuration names
- Last deployment and rollback reference, if one exists
- Next smallest improvement
For a failure, collect the exact failing action and relevant redacted logs.
Compare environment/configuration and deployed revision before changing code.
One focused repair, then rerun the failed check. Escalate unresolved business
choices; keep independent work moving.

## Finish
Show the working preview or the precise blocker, the checks actually run, and
where the brief and handover live. Never claim the application is production-ready
without evidence for its real data, access and operational paths.


---

# MAPS & Commands

Made by Selr AI.

Set up this prompt toolkit in the authorised project. It includes the original
MAPS framework and three reusable command definitions from Selr AI.

Read existing instructions first and preserve them. For Claude Code, use the
supported project-local command/skill location. For Codex, use its supported
project-local skills location and adapt the command input placeholder to that
host. Check the host documentation before choosing the installation format.
If neither supports custom commands, save the templates as ordinary project
Markdown files and use them directly. Do not claim unsupported slash commands
are installed. Never overwrite an existing same-named file; merge with consent
or use a distinct name. Do not modify global settings or publish anything.

First create the template files below, then show how to use them with a fictional
example. These templates draft content; they do not authorise sending emails,
posting captions, messaging people or connecting external accounts.

## MAPS template

Save as maps-template.md. Keep the brackets until the user supplies their brief.

I want a specific answer, not a generic one. I'm using the MAPS framework, so here is my prompt in four parts.

MISSION (the goal behind this request):
[What I actually want to achieve and why it matters. Not the task, the outcome. Example: win back 20 lapsed clients this month, because winter is our quiet season.]

ASK (the specific thing I need from you right now):
[One clear deliverable with a verb. Example: generate a list of 20 lead types I can call this week, with an opening line for each.]

PARAMETERS (my situation, so you don't guess):
[Everything you can't know. Who my customers are. What I sell and at what price. What has worked before, with real examples: past clients, scripts, posts, offers. What to avoid. My constraints: budget, time, tools, team. Paste real material here, it beats any description.]

SHAPE (the format I want back):
[Spreadsheet, table, bulleted list, script, one-pager. Long or short. Formal or casual. Ready to send, or a draft for me to edit.]

Before you answer: if any of my four sections is empty or too thin for a specific answer, ask me up to 3 questions to fill the most important gaps, then deliver. Where my parameters conflict with general best practice, my parameters win. If you had to assume anything, list the assumptions in one line at the end so I can correct them.

## Reusable command definitions

### email.md

```markdown
---
description: Turn rough notes into a ready-to-send email
---

Turn my notes below into a ready-to-send email.

Rules:

- Keep my meaning and my facts exactly. Never add claims, offers, or details I
  did not give you.
- Sound like a person, not a template. Short sentences. No "I hope this email
  finds you well", no "I trust you are doing well", no corporate filler.
- Get to the point in the first two lines. The reader should know what the
  email is about without scrolling.
- One ask per email. If my notes contain several asks, put the most important
  one in the email and list the rest under a "Worth mentioning" line at the
  bottom for me to decide on.
- End with a clear next step, not a vague "let me know your thoughts".
- Give me a subject line: under 7 words, says what the email is, no clickbait.
- Australian English spelling. No em dashes.

If my notes do not say who the email is to or what I want from them, ask me
those two things first, then write it. If I gave you no notes at all, do not
invent an email. Ask me what it needs to say.

My notes:

$ARGUMENTS
```

### followup.md

```markdown
---
description: Chase an unanswered message without sounding pushy or desperate
---

Write me a follow-up message for someone who has not replied.

I will paste the original message or describe the situation below. From it,
work out: who they are, what I originally asked, and how long it has been.
If you cannot tell how long it has been or what the original ask was, ask me
before writing. If I gave you nothing below at all, do not invent a
situation. Ask me who I am chasing and about what.

Rules:

- Assume they are busy, not ignoring me. The tone is easy-going and
  guilt-free: no "just checking in", no "as per my last message", no "I know
  you're busy but".
- Shorter than the original message. Two to four sentences is the target.
- Restate the ask in one line so they do not have to scroll up to remember it.
- Make it one-tap easy to reply: end with a question they can answer in a few
  words, or offer two options to pick from.
- Give them a way out. One line that lets them say no gracefully closes more
  loops than pressure ever does.
- Match the channel: if the original was a text or DM, keep it casual and
  skip the greeting; if it was an email, include a subject line starting with
  "Re:".
- Australian English spelling. No em dashes.

Then give me one alternative version with a different angle (for example,
adding one new piece of value or information rather than just nudging), so I
can pick.

The original message or situation:

$ARGUMENTS
```

### caption.md

```markdown
---
description: Turn an idea, a moment, or a rough thought into an Instagram caption
---

Turn what I give you below into an Instagram caption.

Rules:

- First line is everything: it shows before "more", so it has to earn the tap.
  Lead with the most interesting claim, number, or tension in my material.
  Never open with a question mark cliche like "Ever wondered...".
- Keep my voice and my facts. If I pasted rough words, the caption should
  sound like a cleaner version of me, not like a marketing agency.
- Short paragraphs, one or two lines each, with a blank line between them.
  A caption is read on a phone.
- One idea per caption. If my material has three ideas, use the strongest and
  list the other two at the bottom as "Other captions worth making" with a
  first line for each.
- End with one simple engagement line that fits the content: a question, a
  "tag someone who", or a "save this for later". One, not all three.
- No hashtag walls. Give me 3 to 5 relevant hashtags on a separate line at
  the end, and only ones a human would actually search.
- At most two emoji in the whole caption, and none mid-sentence.
- Australian English spelling. No em dashes.

Give me two versions: one short and punchy (under 50 words), one fuller
(100 to 150 words). Word counts exclude the hashtag line. I will pick.

If I gave you nothing below, do not invent material. Ask me what the caption
should be about, then write it.

My idea, moment, or rough thought:

$ARGUMENTS
```

## Verify and recover

Check all four template files exist and retain the source text above. Verify the
active host discovers any installed commands/skills before claiming they work.
Use fictional notes to draft one email and confirm the output preserves facts,
has one clear ask and does not send anything. For a missing input, request the
needed brief rather than inventing a customer, offer or result.
If host discovery fails, inspect the documented path and format once, correct
that specific issue and retry once. Keep the Markdown templates available even
when custom command support is unavailable. Do not reinstall the host or change
unrelated settings. Report the created files, invocation examples and limitations.