Prompt Author

---
description: Author new best-practice prompt(s) for a feature by reading the codebase context, then propose them (with correct architecture placement, call params, and a starter eval) for approval.
argument-hint: "<feature or capability the prompt is for>"
allowed-tools: Read, Glob, Grep, Agent
---

You are orchestrating prompt authoring for: **$ARGUMENTS**

## Step 0 — Locate or create the feature brief

Determine the feature name. If `$ARGUMENTS` is empty, ask the user what feature the
prompt is for before proceeding.

Derive a slug from the feature name (lowercase, hyphens, no spaces): e.g. "User
Onboarding" → `user-onboarding`.

**Case A — workspace initialised** (`docs/prompt-engineering/features/` exists):

  - If `docs/prompt-engineering/features/<slug>.md` **already exists**: read it with
    the Read tool and use its contents as the feature brief. Echo a one-sentence
    summary of the feature intent to the user and confirm you are using that file.
    Skip to Step 1.
  - If the file does **not** exist: create it from the plugin template
    (`templates/feature-brief-template.md`) at
    `docs/prompt-engineering/features/<slug>.md` — replacing `<Feature Name>` in the
    frontmatter and title with the actual feature name. Tell the user:

    > I created `docs/prompt-engineering/features/<slug>.md`. Please fill it in from
    > the product point of view (what it does, the user story, the expected output
    > contract, constraints, and acceptance criteria), then tell me when you're done.

    Wait for confirmation, then read the file. Do NOT proceed until the brief is
    available.

**Case B — workspace not initialised** (`docs/prompt-engineering/` does not exist):

  Tell the user:

  > To author a prompt that fits this feature, please fill out a product brief — a
  > short markdown written from the **product point of view** (not technical). A
  > template is at `templates/feature-brief-template.md` in this plugin.
  >
  > You can run `/prompt-init` first to set up a persistent workspace (recommended),
  > or create the brief at any path and paste the path here, or paste the content
  > directly into the chat.

  Wait for the user to provide the brief (file path or pasted markdown), then read it.
  Confirm receipt by echoing a one-sentence summary of the feature intent.

## Step 1 — Gather codebase context

Delegate to the `context-gatherer` subagent. Pass it:
- The full text of the feature brief from Step 0 (as a `feature_brief` block).
- The feature name from `$ARGUMENTS`.

The subagent produces a project brief: architecture style, prompt-placement layer,
domain terms, target model(s), and any remaining open questions.

## Step 2 — Confirm understanding

Show the user:
- The one-sentence **intent** (from the product brief).
- The proposed **output contract** (schema/format the code will consume).
- The proposed **placement path** in the codebase.
- Any **open questions** the subagent flagged that are not answerable from the brief or
  codebase.

Incorporate any answers the user gives before authoring.

## Step 3 — Author

Delegate to the `prompt-writer` subagent with the merged brief (product requirements +
codebase context + any answers from Step 2). It returns:
- The proposed prompt template(s).
- The architecture placement (port interface for clean-architecture repos).
- Recommended call parameters.
- A starter eval.
- A self-review against the rubric.

## Step 4 — Present for approval

Show the proposed files/diffs in the terminal. Do NOT write them unless the user
approves. On approval:
1. Create the prompt template files at the recommended paths.
2. If the feature brief lives at `docs/prompt-engineering/features/<slug>.md`, update
   its frontmatter from `status: draft` to `status: implemented`.

Load the `prompt-best-practices` skill so authored prompts and any later review use
the same standard.