Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/ai-protocol-kit/llms.txt

Use this file to discover all available pages before exploring further.

The GitHub Repository Publication Preparation Protocol v2 is a structured, phase-gated working contract for preparing any GitHub repository for clean public release. It prevents the most common AI-assisted publication failure modes: rushing straight to file generation, pushing without a risk audit, enabling GitHub features by default, and optimising for file count rather than publication readiness. Use it whenever you are about to publish, re-publish, or materially restructure a repository for public consumption.

​
Core Rule

Build the smallest publication package that correctly represents the project, its risks, and its intended public surface.
Do not assume the project is a standard open-source software repository. Do not assume every repository needs the same files, workflows, or GitHub features.

​
Operating Rules

#Rule
1Follow the phases in order.
2Do not skip directly to file generation, git initialisation, commit creation, remote creation, or push.
3Before acting, identify the environment, understand what the operation requires, anticipate likely failure points, choose the method that avoids them, and then act.
4If a meaningful ambiguity remains and could change licensing, visibility, deployment, or repository structure, stop and ask before modifying anything.
5Do not generate files, workflows, community templates, or Pages unless they are justified by the actual project and publication intent.
6Do not optimise for completeness by default. Optimise for correctness, minimality, and publication readiness.

​
Phases

1
Phase 1 — Classify the Project
2
Determine and report the project’s name, type, primary purpose, target audience, current status, maintenance model, intended visibility, and primary published unit. Use real evidence from the workspace. Stop and ask if classification remains materially ambiguous.
3
Project type taxonomy
4
TypeDescriptionapplicationA runnable software applicationlibraryImportable or linkable code intended for reusetoolA utility or CLI that performs a specific taskdocumentationA repository whose primary output is written documentationcontent repositoryWritten, media, or mixed content (not primarily code)template or kitA starting point, scaffold, or reusable kitresearch repositoryExperimental work, studies, or findingsmixed repositoryMore than one of the above in meaningful proportioninternal operational repositoryTooling, configs, or scripts not intended for public use
5
Primary published unit taxonomy
6
UnitExamplessource repositoryThe repo itself is the artefactpackagenpm, PyPI, RubyGems, etc.deployable applicationA runnable build or containerstatic siteGitHub Pages or similardocumentationRendered docs surfacetemplate kitStarter files, scaffoldrelease artefactTagged release asset or binary
7
Phase 2 — Analyse the Workspace
8
Inspect the workspace enough to make sound publication decisions. Determine and report the high-level structure, stack or tooling, entry points, generated outputs already present, environment-variable usage, whether .env.example exists, GitHub-relevant files already present, licensing signals, deployment signals, whether the workspace is already a git repository, whether remotes already exist, and whether any Pages, docs, or site surfaces already exist.
9
Do not generate files in this phase. Read only enough to close the publication decision perimeter.
10
Phase 3 — Run the Publication Risk Audit
11
Check and report sensitive data in current files, sensitive data in git history (if history exists), secrets, tokens, credentials, private keys, or personal data, local-only or generated material that should not be published, tracked artefacts (build output, caches, installed dependencies, editor folders, temp files, backups), large binary or media files, third-party assets that may create licence obligations, commit hygiene, compatibility between the intended licence and dependencies or bundled assets, naming risks, and deployment risks.
12
If publication-blocking issues are found, stop and provide remediation steps before continuing. If the workspace is not yet a git repository, explicitly state that history audit cannot be performed.
13
Phase 4 — Design the Publication Model
14
Before generating any file, decide and report the recommended repository visibility, recommended licence, whether GitHub Pages is appropriate (and if so: whether it should exist now or later, where its source should live, whether it should be isolated), which GitHub features should be enabled or disabled (Issues, Discussions, Wiki, Projects, Actions, Releases), whether CI is justified, whether community-health files are justified, whether documentation beyond the README is justified, and whether .nojekyll, LFS, or similar mechanisms are justified.
15
Do not generate GitHub Pages, CI, community files, or docs by default. Only add them when the real project and publication model justify them. Prefer the smallest correct publication package.
16
Phase 5 — Generate the Publication Package
17
Generate only the files justified by the publication model. Possible files include .gitignore, .gitattributes, .env.example, LICENSE, README.md, CONTRIBUTING.md, CHANGELOG.md, CODE_OF_CONDUCT.md, SECURITY.md, CODEOWNERS, issue templates, pull-request templates, workflow files, docs/, and static site files for GitHub Pages.
18
Generation rules
19
  • Infer from the actual workspace and project intent.
  • Extend existing files when appropriate instead of replacing them.
  • Do not generate placeholder bureaucracy.
  • Do not create files only because they are common on GitHub.
  • If a file is skipped, state why.
  • If a file requires unresolved policy input, stop and ask before generating it.
    • 20
    Phase 6 — Review Before Any Git or GitHub Action
    21
    Before initialising git, creating commits, creating a remote, or pushing, produce a concise review stating: what will be published, what will not be published, which files were added or modified, which repository features are expected to be enabled or disabled, which decisions are now frozen, which decisions still require confirmation, and which risks remain.
    22
    Do not initialise git, commit, create a remote, or push until this review is complete and the publication package is confirmed.
    23
    Phase 7 — Execute Publication
    24
    After confirmation, perform the minimum clean publication sequence required by the environment. Possible actions include: initialise git if absent, set the default branch name, stage files intentionally, create the first commit, create the remote repository, connect the remote, push the default branch, configure Pages, set description and homepage, and configure repository features if automation is available.
    25
    Publication also includes repository identity, licensing clarity, feature surface, and deployment behaviour — not only pushing files.
    26
    Phase 8 — Final Post-Publication Checklist
    27
    After publication, produce a checklist of only the relevant remaining manual tasks. Possible items: verify repository visibility, verify README rendering, verify licence recognition, verify Pages deployment, set description and topics, set homepage URL, verify Actions permissions, configure branch protection if needed, create a first release or tag if appropriate, and confirm that no unintended files became public.

    ​
    What NOT to Generate

    No default Pages

    Never generate GitHub Pages unless the publication model explicitly justifies it. Never assume GitHub Pages belongs in the main branch.

    No default CI

    Never generate CI workflows unless there is a meaningful build or test surface that makes automation useful.

    No community boilerplate

    Do not generate CONTRIBUTING.md, CODE_OF_CONDUCT.md, issue templates, or PR templates just because they appear in popular repositories.

    No maximum file count

    Do not optimise for a larger publication package. Every generated file must be justified by the real project and the real publication model.

    ​
    Final Safeguards

    • Never assume every repository is open-source software.
    • Never assume every public repository needs all standard GitHub files.
    • Never assume GitHub Pages belongs in the main branch.
    • Never assume CI is useful if there is no meaningful build or test surface.
    • Never optimise for maximum file count.
    • Always optimise for a clean, justified, publication-ready result.

    Build docs developers (and LLMs) love

    Get started for freeTalk to us