---
description: Author or audit a Loopflow skill, Wave goal, or inline prompt.
requires: a prompt idea or existing prompt asset
produces: .lf/skills/*.md | wave/<name>/GOAL.md | reviewed prompt text
default_agent: claude
action_style: exploratory
---
Turn intent into a prompt that can steer real work and prove when it is done.
```bash
lf prompt: create a dependency-audit skill
lf prompt: tighten wave/infra/GOAL.md
```
## Reviewer mode
The launch prompt identifies the reviewer for this exercise.
- **Interactive reviewer:** read any named file, state the contract you see, and ask
only about choices whose answers materially change behavior, scope, or
authority. Write reversible improvements as decisions land.
- **Parent reviewer:** treat the supplied directive, quoted user language, and
existing asset as intent. Make context-backed decisions, record genuine
ambiguity in `scratch/questions.md`, and use the review protocol to return the
exact proposed content. Do not wait for an unavailable reviewer or claim their
confirmation.
## Choose the artifact
Put each instruction at the narrowest layer that exercises it:
| Skill | A repeatable task and its output contract | Repo-wide conventions or Wave portfolio policy |
| Wave `GOAL.md` | Durable identity, bounds, cadence, and selection judgment | Chapter KRs, live metric contracts, task lists, implementation steps |
| Inline prompt | One concrete request | Reusable doctrine that deserves a skill |
| Repo agent doc | Conventions every task in this repository must follow | One feature's design or temporary context |
| Wave `MEMORY.md` | Curated decisions, lessons, and evidence limits | A second plan or a transcript |
Do not repeat Loopflow's ambient operating guidance in customer prompts. It is
already supplied to standard runs. Add only the domain contract and method this
artifact uniquely owns.
Shared skills must work in a customer's repository without your source files,
internal issue IDs, tool wrappers or secret-manager policy. Keep specialized
procedures in the skills that perform them. Repo-local skills replace the named
skill; they are not appended supplements or automatically exported to customers.
Improve the shared skill for general lessons; keep local rules with their local
consumer. Do not create miscellaneous `.lf/` learning notes.
## Workflow
1. **Resolve the target.** Infer the artifact kind from the named path or
request. Read the existing file when present. If a user request leaves two
materially different targets possible, ask one focused question; otherwise
choose the narrower artifact and proceed.
2. **Write the contract.** Make these computable:
- exact task or durable objective;
- observable success;
- plausible near-misses that do not count;
- affected boundaries, edge cases, permissions, and exclusions;
- the command, observation, or artifact that proves success.
Match proof to maturity: an early Task needs a concrete problem and
recognizable success; design chooses the implementation and operational proof.
Name the output's reader and their next decision. State how separate input
artifacts reach the consumer's execution context and which copy stays current;
a path alone does not deliver contents. Name a missing transfer mechanism
instead of using a Task description as a substitute document store.
3. **Design the evidence loop.** For uncertain work, tell the agent to preserve
observations separately from hypotheses, externalize the cheapest useful
model, run the smallest safe check that separates leading explanations,
verify against all relevant old and new evidence, and replan after a
counterexample. Ask tools or tests to enforce this when prose cannot.
4. **Write the prompt.** Start directly. Use imperative language, concrete
verbs, and only the sections the artifact needs. Put output shape next to
the work that produces it. Include examples when they carry more information
than explanation.
5. **Audit adversarially.** Read the candidate as an agent trying to finish
cheaply. Could it satisfy the words while missing the intent? Does a receipt
such as “tests added” masquerade as the outcome? Does it know what to do when
evidence contradicts the favored plan? Tighten the contract until the easy
loopholes close. Check a real example: can someone without the transcript
understand the benefit and current problem before opening tools? Keep the
Task's problem distinct from the design's solution. Trace competing rules
through examples, handoffs, later edits, and mechanical rendering. For Task
authors, check the description with comments collapsed: the current problem,
desired outcome, acceptance, and real blockers must still make sense. Dated
planning/execution updates belong in authorized comments; raw receipts belong
behind links. Test a later scope change: reconcile the brief instead of stacking
amendments, preserving the decision history and unresolved contrary evidence.
Apply this second-revision check to other artifacts too. Put resulting guidance
only in authorship surfaces that exercise it.
6. **Deliver at the source.** Update the named customer file or return reviewed
prompt text. Do not create a second copy in documentation. Summarize the
behavioral change, not each wording edit.
When relocating instructions, inspect both the ordinary assembled prompt
and the receiving skill's standalone export. Prove the old audience no longer
pays for the procedure and the intended consumer can still execute it.
## Skill contract
Place repo-local skills under `.lf/skills/`. Use frontmatter for machine
configuration, then one direct opening line:
```markdown
---
requires: diff vs main
produces: scratch/security-audit.md
---
Audit the changed authentication boundary and prove every caller still fails closed.
## Workflow
1. Reconstruct the affected trust boundary.
2. Exercise the success, denial, absent-credential, and malformed-input paths.
3. Write only reproducible findings.
## Output
Write `scratch/security-audit.md` with evidence, severity, and reproduction.
```
Give procedural skills numbered work and a concrete output. Give exploratory
skills room to follow evidence without turning “explore” into permission to
change unrelated code. Skills that may run interactively must also
define bounded behavior for a headless parent reviewer.
## Wave goal contract
The body of `wave/<name>/GOAL.md` is the prompt a Wave runs repeatedly. Make it
loop well:
1. **Identity by contrast** — what this Wave owns and what a sibling owns.
2. **Selection signals** — the evidence that changes chapter strategy or
strategy. Reference Wave-owned metrics when they exist; never copy them
into the Wave body.
3. **Concrete moves** — the kinds of useful action it may select now.
4. **Honest question** — the check a lazy loop cannot satisfy by gaming a proxy.
5. **Stop discipline** — when to record a blocker instead of manufacturing
work.
Frontmatter carries machine policy such as `agent`, `crons`, `pm`, and `home`.
Keep current chapter metric targets and proof-shaped KRs in the internal Project, edited with `lf wave update-plan`. Keep
concrete implementation in Tasks. A Wave steers one current chapter; it does
not contain a roadmap disguised as a prompt.
## Parallel search
Use parallel approaches only when the task is genuinely uncertain, safely
divisible, and delegation is already authorized. Start with different
mechanisms, preserve early independence, keep a registry of evidence and exact
gaps, block routes whose missing dependency merely restates the original
problem, and require concrete artifacts or counterexamples. Cross-pollinate
after each route has exposed its own failure mode. Do not add multi-agent
ceremony to ordinary deterministic work.
## Final check
- The opening line says what to do.
- The artifact owns these instructions; no narrower layer should carry them.
- Success, insufficiency, boundaries, and proof are explicit where they matter.
- Observations cannot be silently rewritten to save a hypothesis.
- Unexpected evidence has a named consequence.
- Output is useful to the next reader or agent.
- Repeated runs can stop without inventing work.