Prompt Library

# Prompt Library

[← Back to README](../README.md) · [Docs index](README.md) · [Architecture](architecture.md) · [Prompt evolution and governance](prompt-evolution.md)

This repository includes a public-facing description of the **Gemini CLI prompt library** behind AutoFACS CLI Automation.

The important design idea is simple: the system does not rely on one giant agent prompt for every job. Instead, it uses a small set of reusable prompt artifacts with different scopes, permissions, and output expectations.

## 1. Why a prompt library exists

The uploaded prompt artifacts show a clear goal: reduce prompt drift, keep sessions narrow, and prevent the CLI from mixing incompatible kinds of work in the same run.

At a public-facing level, the prompt library exists to enforce:

- single-mode execution
- named-file scope where possible
- evidence-first reasoning
- diagnosis/implementation separation
- bounded command behavior
- safe halting when proof or scope is insufficient

## 2. Core artifact types

### Shared forward

A shared front-matter layer establishes the rules common to all sessions, such as:

- choose one mode only
- do not mix audit and implementation casually
- prefer named-file scope over recursive discovery when exact files are already known
- halt safely when the evidence surface is insufficient

### Task-class templates

The prompt library is then split into reusable task classes.

#### Audit / evidence
Used for read-only inspection and factual reporting.

#### Corrective documentation / tracker
Used for wording corrections, certainty downgrades, or historical correction notes.

#### Implementation
Used for one narrow change after the evidence surface is already established.

#### Refactor
Used for structural cleanup that should not change behavior.

#### Governance probe
Used for read-only checks that verify whether the runtime is actually using the intended governance surfaces.

### Support artifacts

The uploaded artifacts also show support materials such as checklists and historical-reference prompts. These help operators keep runs consistent without turning every session into a one-off improvisation.

## 3. Public-safe design principles extracted from the prompt set

The following ideas are repeatedly visible across the prompt artifacts and are safe to describe publicly:

- **Mode separation** — different jobs have different permissions.
- **Task-local narrowing** — the session-local prompt may be narrower than the global runtime rules.
- **Command-budget discipline** — commands are whitelisted by task class rather than assumed by convenience.
- **Output-schema discipline** — each task class returns only the sections relevant to that job.
- **Evidence labeling** — claims should distinguish between direct proof, inference, and uncertainty.
- **Safe halt behavior** — stopping without edits is a valid outcome when the evidence surface is incomplete.

## 4. Why this matters in practice

This prompt structure helps keep Gemini CLI useful for engineering work without letting it become a high-variance, overreaching operator.

Instead of one conversational prompt doing everything at once, the prompt library encourages:

- reviewable runs
- narrower diffs
- fewer scope jumps
- clearer audit trails
- easier human supervision

## 5. What this public doc does not reproduce

This page describes the structure of the prompt system, not every private runtime detail.

It deliberately does not reproduce:

- exact internal sentinel strings
- repo-specific governance anchors
- private source-of-truth file layouts
- full verbatim operational prompts that are only meaningful inside the original repository

## See also

- [Prompt evolution and governance](prompt-evolution.md)
- [Architecture](architecture.md)
- [Workflow patterns](example-workflows.md)
- [Public-facing boundaries](public-safe-boundaries.md)