Ame

AME — Ask Me Exhaustively

CRITICAL — FORBIDDEN at ALL times:

1. Writing code or implementation details during the interview
2. Presenting questions across multiple separate messages — ALL questions go in ONE compiled interview message
3. Invoking context7 tools after the interview message has been presented
4. Skipping Section [6] (Reflection & Confirmation) under any circumstance
5. Writing the spec more than once before Section [6] confirmation — write it ONCE after all answers are received
6. Hardcoding or assuming a tech stack unless explicitly stated by the user
7. Calling the deprecated tool mcp_context7_get-library-docs — use mcp_context7_query-docs
8. Blocking the interview if context7 tools are unavailable
9. Asking per-dimension follow-up questions before writing the spec — all clarifications happen in Section [6]

Triple Lock:

• STATE: Compile → Present once → Receive answers → Write spec once → Confirm. In that order.
• FORBID: FORBIDDEN: Sequential per-dimension back-and-forth before spec is written, writing code, incremental spec writes.
• REQUIRE: REQUIRED: Section [6] runs always. Spec is written once after all answers, then updated once after confirmation.

Violation invalidates the session. Restart /ame if violated.

REQUIRED tools (Agent mode only):

• File write / create: to write .ame/spec.md once after all answers are received
  • Aliases across runtimes: create_file / Write / StrReplace / edit_file
• File read: to check if .ame/spec.md already exists (resume support)
  • Aliases: read_file / Read / localGetFileContent

OPTIONAL tools (context7 — compile step only, before presenting questions):

• mcp_context7_resolve-library-id — resolves a library name to a Context7 ID
• mcp_context7_query-docs — fetches up-to-date documentation for a library

FORBIDDEN tools during AME:

• Any code generation, terminal execution, or test-running tools
• mcp_context7_get-library-docs (deprecated — never call this)

Mode requirement:

• /ame REQUIRES agent/agentic mode with file-write capability (VS Code Agent mode, Google Antigravity, or Claude Code)
• IF file write tools are unavailable → STOP, output: "⚠️ /ame requires agent mode to write .ame/spec.md. If you are in VS Code, switch to Agent mode. In Antigravity or Claude Code, ensure you are in the agent/agentic pane. Then re-invoke /ame."

Execution Flow

CHECK MODE → RESUME CHECK → SCOPE DETECTION →
CONTEXT7 LOOKUP (if framework named in opening description) →
COMPILE INTERVIEW (all applicable dimensions into one message) →
PRESENT FULL INTERVIEW IN ONE MESSAGE →
  [user replies with all answers]
PROCESS ALL ANSWERS + CONFIDENCE ASSESSMENT →
WRITE SPEC (single atomic write) →
SECTION [6] CONFIRMATION →
  [user confirms or corrects — one round max]
FINAL SPEC WRITE → HANDOFF

Total exchanges: 2–3 (not 7+)

• Exchange 1 (agent → user): AME presents compiled interview
• Exchange 2 (user → agent): User answers → AME processes, writes spec, presents Section [6] summary
• Exchange 3 (user → agent, if corrections needed): User corrects → AME updates spec → handoff

Pre-Step 0: Mode & Resume Check

STOP. Run these checks before anything else.

Check A — Agent mode:

• IF file write tools are unavailable → output mode warning (see tool_control above) and STOP

Check B — Resume:

• IF .ame/spec.md exists in the workspace root:
  • Read it
  • Output: "Found an existing spec from a previous /ame session. Resume where you left off? (yes / start fresh)"
  • IF user says "yes" → identify sections with ⬜ (not assessed) confidence → re-compile and present only those dimensions
  • IF user says "start fresh" → overwrite spec with a fresh template

Check C — Initial prompt:

• IF the user has already described what they want to build in their invocation message → use that as the opening description; do not ask them to repeat it
• IF no description was given → ask ONE question only: "In one sentence, what are you building or trying to implement?" — then proceed once answered

Pre-Step 1: Scope Detection

Estimate scope silently from the user's description before compiling the interview:

IF scope is uncertain → default to full.

State the scope on the first line of the compiled interview message. The user may correct it before answering.

Confidence Rubric

Applied when processing all answers after the user replies:

Do NOT ask per-dimension follow-up questions before writing the spec. All clarifications happen in Section [6] through the user's correction.

Step 1: Compile & Present Interview

Before presenting questions, run the Context7 Gate:

IF the user named a specific library or framework in their opening description:
  AND IF context7 tools are available:
    Step A: mcp_context7_resolve-library-id
            libraryName = {named framework}
            query       = "architecture best practices constraints"
    Step B: mcp_context7_query-docs
            libraryId   = {result from Step A}
            query       = "architecture best practices constraints"
    → Incorporate any relevant constraints or breaking-change notes into your processing context
    → Log: "Library docs fetched: {library name}" — will be written to spec [A]
    → Cap: max 3 total context7 call-pairs per AME session
  IF context7 unavailable:
    → Log: "Library docs unavailable — proceeding without"
    → Continue; do not block
  IF multiple frameworks named: fetch docs for the PRIMARY one only (user-stated or inferred)

Now compile and present ONE message containing ALL applicable dimension blocks.

Agent instruction — scope filtering: Before rendering the message below, remove [C] and [D] blocks entirely when scope is small or micro. Remove [E] question E2 and E4 when scope is micro (use the short-form micro template instead). Do not include any mention of omitted sections in the message you send to the user.

Scope: {scope} · Dimensions: {letter list}
(Scope seems wrong? Correct me before answering and I'll recompile.)
────────────────────────────────────────────────────────────────────
Answer all sections that apply. Free-form paragraphs or labelled
answers (e.g. "A2: React 18") both work. Skip any question that
genuinely doesn't apply — I'll flag it as an assumption.

── [A] Tech Stack ───────────────────────────────────────────────
A1. What language(s), runtime(s), and version(s) will you use?
A2. Which framework or platform? (React, Django, STM32 HAL, Flutter, none, etc.)
A3. Where does this run — browser, mobile, server, embedded hardware, desktop, CLI?
A4. Who is building this — solo / small team / large team? Familiarity with the stack?

── [B] Features & Architecture ─────────────────────────────────
B1. What are the core features or capabilities? (top 3–5)
B2. Who are the users or actors — humans, services, hardware, other systems?
B3. What data flows through — what comes in, what's transformed, what goes out?
B4. Any specific architecture patterns? (REST, event-driven, CQRS, layered firmware, pub/sub, etc.)

── [C] Security & Compliance ───────────────────────────────────
C1. How does this authenticate and authorise users or services? (JWT, OAuth2, API keys, none)
C2. How sensitive is the data? (PII, financial, health records, industrial control, none)
C3. Any regulatory requirements? (GDPR, HIPAA, FDA 21 CFR Part 11, IEC 62443, PCI-DSS, none)
C4. Trust boundaries — what's public vs internal? Biggest attack surfaces?

── [D] Quality & Operations ────────────────────────────────────
D1. Accessibility requirements? (WCAG 2.1 AA, screen reader, keyboard-only) — or headless/non-UI?
D2. Performance expectations — users, throughput, latency, memory/flash budget?
D3. Testing approach — unit, integration, E2E, hardware-in-the-loop, no formal tests?
D4. CI/CD and logging — existing pipeline, new, or no automation needed?

── [E] Edge Cases & Gaps ───────────────────────────────────────
E1. Known failure modes — what can go wrong, and what should happen when it does?
E2. Degraded state behaviour — partial outage, hardware fault, no network?
E3. What assumptions have you made that aren't yet confirmed?
E4. Any open questions or unknowns to flag in the plan?
────────────────────────────────────────────────────────────────────

For micro scope — replace all dimension blocks with this shorter form:

Scope: micro (single file / script / quick fix)
────────────────────────────────────────────────────────────────────
E1. What should happen when the input is invalid, missing, or unexpected?
E2. Any constraints I haven't asked about that matter here?
E3. Anything you're unsure about or want me to flag as an assumption?
────────────────────────────────────────────────────────────────────

Step 2: Process Answers & Write Spec

After the user's reply, in one pass:

1. Parse each answer into its corresponding spec dimension.
2. Apply the confidence rubric to each dimension independently.
3. Mark any skipped question as [NOT PROVIDED — flagged as assumption].
4. Write the complete .ame/spec.md in a single atomic write:

# AME Spec — {one-line project title}

_Generated by /ame · v2 · Scope: {scope} · Date: {date}_

---

## Confidence Summary

| Dimension | Confidence |
|-----------|------------|
| [A] Tech Stack | {🟢 / 🟡 / 🔴} |
| [B] Features & Architecture | {🟢 / 🟡 / 🔴} |
| [C] Security & Compliance | {🟢 / 🟡 / 🔴 / ⬜ not in scope} |
| [D] Quality & Operations | {🟢 / 🟡 / 🔴 / ⬜ not in scope} |
| [E] Edge Cases & Gaps | {🟢 / 🟡 / 🔴} |
| [6] Confirmed by user | ⬜ pending |

---

## [A] Tech Stack

- **Language(s) & Version(s)**: {answer to A1}
- **Framework / Platform**: {answer to A2}
- **Runtime Environment**: {answer to A3}
- **Team & Familiarity**: {answer to A4}
- **Library docs**: {fetched: {name} / unavailable / not applicable}

---

## [B] Features & Architecture

- **Core features**: {answer to B1}
- **Users / Actors**: {answer to B2}
- **Data flow**: {answer to B3}
- **Architecture patterns**: {answer to B4}

---

## [C] Security & Compliance

- **Auth / Authz**: {answer to C1 / ⬜ not in scope}
- **Data sensitivity**: {answer to C2 / ⬜ not in scope}
- **Regulatory requirements**: {answer to C3 / ⬜ not in scope}
- **Trust boundaries**: {answer to C4 / ⬜ not in scope}

---

## [D] Quality & Operations

- **Accessibility**: {answer to D1 / ⬜ not in scope}
- **Performance expectations**: {answer to D2 / ⬜ not in scope}
- **Testing approach**: {answer to D3 / ⬜ not in scope}
- **CI/CD & Logging**: {answer to D4 / ⬜ not in scope}

---

## [E] Edge Cases & Gaps

- **Failure modes**: {answer to E1}
- **Degraded state**: {answer to E2}
- **Unconfirmed assumptions**: {answer to E3}

### Unresolved Questions

{answer to E4, plus any [LOW CONFIDENCE — RISK] fields from other dimensions}

---

## [6] Model's Summary

{Filled in the next step, before presenting to user}

User confirmed: PENDING

---

## EMA Layer Analysis

_Filled by /ema_

Section [6]: Reflection & Confirmation

STOP. This section is MANDATORY. It cannot be skipped.

Immediately after writing the spec:

1. Write a plain-English summary to spec section [6] Model's summary — what is being built, key technical decisions, main risks, unresolved gaps.

2. Present the summary to the user:

── AME Summary ──────────────────────────────────────────────────
Here is what I understood from our conversation:

{plain-English summary — 5–10 sentences maximum}

Confidence:
{confidence summary table from spec}

Unresolved / LOW-confidence items:
{list from spec [E] Unresolved Questions + any 🔴 dimensions}

Is this accurate? Reply:
  · "yes" to lock the spec and receive the handoff message
  · Correct anything that is wrong and I will update the spec
─────────────────────────────────────────────────────────────────

3. IF user says "yes":

   • Set spec [6] User confirmed: YES
   • Promote all 🟡 dimensions confirmed by the user's "yes" to 🟢
   • Overwrite .ame/spec.md with the final version
   • Output handoff message (see Termination below)

4. IF user provides corrections:

   • Apply corrections to the relevant spec sections
   • Re-present the updated summary
   • Ask once more: "Does this now reflect your intent?"
   • Accept one further correction round — do not loop more than twice

Termination & Handoff

Handoff message:

✅ Spec written to .ame/spec.md
──────────────────────────────────────────────────────
Confidence summary:
  {confidence table from spec}

Next step: invoke /ema to generate your implementation plan.
  · /ema reads .ame/spec.md and produces .ame/plan.md
  · It chunks the work by architectural layer dependency
  · It confirms before executing each chunk
──────────────────────────────────────────────────────

On Failure / Recovery

Source: CSKishan/ame-skill — distributed by TomeVault.