# Public Showcase Repo Prompt

Use this prompt when turning a private/local project into a standalone public GitHub showcase repository.

```text
Create a standalone public GitHub showcase repo for this project:

Project:
- Name: <project name>
- Suggested repo: mcxl/<repo-name>
- Local context path: <private/local project path>
- Public positioning: <one-sentence audience and purpose>

Important privacy and history rules:
- Create a fresh standalone repo with its own clean `.git` history.
- Do not make `agentic-os-workspace` or any private monorepo public.
- Do not preserve private git history.
- Do not publish production source code unless I explicitly approve it.
- Do not publish real client records, site addresses, phone numbers, emails, report outputs, photos, PDFs, DOCX/XLSX files, logs, `.env` files, API keys, Supabase details, service-role keys, or production deployment config.
- Use sanitized/demo/synthetic material only.
- Scan every new repo before publishing and scan again before each push.

For the project:
- Inspect the local project context to understand what it does.
- Identify privacy-sensitive folders, generated outputs, credentials, logs, deployment files, and real records.
- Create a fresh standalone public showcase repo under `mcxl`.
- Include:
  - `README.md`
  - `docs/architecture.md`
  - `docs/demo-scenario.md`
  - `docs/public-showcase-repo-prompt.md` if useful as a reusable pattern
  - `SECURITY.md`
  - `LICENSE.md`
  - `.gitignore`
  - `.nojekyll`
  - root `index.html`
  - `public/index.html`
  - safe synthetic/demo images or diagrams

Position the repo clearly as a public showcase:
- what it does
- who it is for
- why it exists
- workflow
- outputs
- agent/tool/skill framing
- privacy boundary
- current status
- GitHub repo link
- GitHub Pages link

Visual requirements:
- Add a workflow diagram using only synthetic/public-safe labels.
- Add an anti-hallucination / anti-slop control-loop diagram showing:
  - unverified AI draft or generic output;
  - quarantine of unknowns/placeholders;
  - source/evidence gate;
  - validator gate;
  - read-only review agents;
  - human release decision;
  - route-back-to-intake when evidence is missing.
- Do not use real client names, site names, addresses, screenshots, generated reports, or source documents in visuals.

GitHub publishing:
- Commit the sanitized contents.
- Create the public GitHub repo.
- Push `main`.
- Enable GitHub Pages from `main` root.
- Set repo homepage to the Pages URL.
- Add useful topics.
- Add visible links from the Pages site to the GitHub repo and from the README to both URLs.

Final verification:
- Confirm the working tree is clean.
- Confirm the repo is public and default branch is `main`.
- Confirm GitHub Pages returns HTTP 200.
- Confirm the live page includes the GitHub repo link.
- Confirm scans found no private terms, address-like strings, credential patterns, private paths, or blocked output file types.

At the end, report:
- GitHub repo link
- GitHub Pages link
- commit hash
- what was included
- what was deliberately excluded
- scans/checks performed
- any publishing risks or follow-up checks
```

## Recommended Scan Patterns

Use text and file-type scans appropriate to the project before publishing. At minimum, check for:

- private/client names;
- real addresses and contact details;
- email and phone patterns;
- credential/token patterns;
- private filesystem paths;
- `.env`, logs, data exports, generated reports, PDFs, DOCX/XLSX files, images, and archives.

Treat hits in privacy-policy wording as expected only when they describe exclusions, not real values.