Repo Prep

Repo Prep

Interactively scaffold the legal, metadata, community, and compliance files a repository needs before publication — consistently, from a central author profile, with author choices respected per repo.

When to use

• Preparing a new or existing repo for GitHub / open-sourcing.
• Adding missing LICENSE, NOTICE, AUTHORSHIP, README sections, or package metadata.
• Writing a defensible AUTHORSHIP record for AI-assisted work (the wizard).
• Adding community docs or .github/ templates.
• Checking EU/Germany compliance obligations for a repo.

Operating principles

• Interactive, not assumed. Ask the user for choices (see Asking questions

below); respect the author profile's defaults but confirm per repo. Don't blindly dump templates.

• Idempotent. Detect what already exists; skip or refresh, never clobber

silently. Show a plan before writing.

• Evidence over assertion (especially authorship): mine the repo for facts.
• Confirm outward-facing actions (anything via gh, pushes) before running.
• Follow the user's git conventions — commit only when asked.

Asking questions (interview transport)

Prefer cenno when it is installed — it gives a nicer panel, progress dots, and voice input (great for the reflective authorship answers).

1. Detect cenno once per run: ToolSearch for mcp__cenno__ask_sequence. If the tools resolve, use cenno; otherwise fall back to AskUserQuestion (choices) / plain conversational prompts (free text). 2. When using cenno:

• Multi-question flows (the authorship wizard, scope selection) →

mcp__cenno__ask_sequence with flow: "question"; it auto-fills progress dots.

• Single questions → mcp__cenno__ask_user.
• Use input.kind: "choice" + choices for pick-one; "confirm" for yes/no;

"voice_text" for reflective free-text (Decisions, Judgment, Direction, Art Direction); "scale" for ratings.

• Parse the returned JSON ({answers: [...]} / {answer, ...}). Handle

{answered: false} (timeout) by retrying or falling back. 3. If cenno is wanted but not installed, mention it can be set up via the cenno skill; do not block — fall back gracefully.

Central author profile (single source of truth)

Identity, promo links ("ads"), and defaults live in ~/.config/personal-os/repo-prep/profile.toml (override with REPO_PREP_PROFILE).

1. On first run, if it doesn't exist, copy assets/templates/profile.example.toml there and walk the user through filling it (name, email, github, url, promo projects, defaults). It is pre-seeded for this author. 2. Read it at the start of every run to resolve {{author}}, {{email}}, {{github}}, the promo block, and default choices.

Workflow

1. Detect — inspect the repo: manifest/ecosystem (pyproject.toml, package.json, Cargo.toml, go.mod), existing files, git remote, default branch, whether it's already on GitHub. Read the author profile. 2. Scope — confirm which components to do via AskUserQuestion (core / community / .github / promo / compliance / gh remote). Pre-fill from profile defaults. 3. Resolve placeholders — once, per references/checklist.md. 4. Generate — for each chosen component, create files from assets/templates/ and assets/github/, filling placeholders. Use scripts/fetch_license.py for LICENSE. Edit package metadata inline. 5. Authorship — if doing AUTHORSHIP.md, run the wizard (below), don't just fill the template. 6. Compliance — if requested or the author is EU-based, run the gating questions in references/eu-germany-compliance.md and add only what applies. 7. gh remote (optional) — confirm, then create/configure the repo. 8. Verify — run the test suite (metadata edits can break builds); show the diff; commit only if asked.

Full item-by-item detail, placeholder table, and ecosystem detection: `references/checklist.md` (read it before generating).

The authorship wizard

A first-class feature. To produce a defensible AUTHORSHIP.md for AI-assisted work, read and follow `references/authorship-wizard.md`. It:

• gathers external evidence first (ADRs, git log, changelog, AI session logs,

CLAUDE.md/AGENTS.md, design tokens) and offers a draft to edit;

• asks the jurisdiction first, then interviews across five sections —

Decisions, Exercise of Judgment, Goal Setting & Direction, Art Direction, AI Implementation;

• writes a Legal & Copyright section with jurisdiction-aware framing

(US human-authorship bar, EU/Germany "own intellectual creation", UK CGW);

• always states it is not legal advice.

Output template: assets/templates/AUTHORSHIP.md.

EU / Germany compliance

references/eu-germany-compliance.md covers CRA (SBOM, vuln reporting), AI Act Art. 50 transparency, German Impressum (DDG), GDPR, the Product Liability Directive, and the EAA. Obligations are conditional — ask the gating questions and add only what applies. Not legal advice.

Resources

• assets/licenses/ — bundled MIT, BSD-3-Clause (offline); others fetched.
• assets/templates/ — AUTHORSHIP, CODE_OF_CONDUCT, CONTRIBUTING, SECURITY,

NOTICE, CHANGELOG, profile.example.toml.

• assets/github/ — PR + issue templates, dependabot, CI workflows (python/node).
• scripts/fetch_license.py — write a filled LICENSE for any SPDX id.
• references/ — checklist.md, licenses.md, authorship-wizard.md,

eu-germany-compliance.md.

Describe the bug

Steps to reproduce

1. 2. 3.

Expected behavior

Actual behavior

Environment

• OS:
• {{project}} version:

Acceptance criteria

• [ ] The bug is reproduced by an automated test or documented manual reproduction.
• [ ] The expected behavior is restored without regressing existing workflows.
• [ ] User-visible errors or recovery steps are updated if behavior changes.

Problem What problem does this solve?

Proposed solution

Alternatives considered

Acceptance criteria

• [ ] The user-facing behavior is defined clearly enough for implementation.
• [ ] Edge cases, errors, and non-goals are captured.
• [ ] Verification steps or tests are identified before work starts.

Summary

Changes

Test plan

• [ ] Tests pass ({{test_cmd}})
• [ ] Docs updated, if behavior changed
• [ ] Changelog updated, if user-visible

Authorship

Last updated: {{date}}

This file documents the human creative contribution behind {{project}}. Copyright protection for AI-assisted works depends on human authorship and jurisdiction-specific originality standards; this record distinguishes human architecture, selection, arrangement, judgment, and direction from machine-assisted implementation. See Why This File Exists.

Human Author

{{author}}{{location}} — Architecture, design, product decisions, and creative direction. Contact: {{email}}

Decisions

Significant human-made decisions and the reasoning behind them. (Evidence: ADRs, design docs, commit history.)

{{decisions}}

Exercise of Judgment

Where human judgment shaped, rejected, or refined the work — selection among alternatives, tradeoffs accepted, AI output overridden, quality bars enforced.

{{judgment}}

Goal Setting & Direction

The problem being solved, the intended users, the goals, and the non-goals that steered the project. Generated output was produced in service of these human-set goals.

{{direction}}

Art Direction

Visual identity, design system, UX patterns, tone, and aesthetic choices — human-authored selection and arrangement.

{{art_direction}}

AI Implementation

Code implementation was assisted by {{ai_tools}}. The AI generated syntax, function bodies, and boilerplate under human architectural direction and iterative review. The human author provided the specifications, constraints (CLAUDE.md / AGENTS.md, design rules), iterative review and refinement, and all debugging and integration decisions. Development session logs are retained locally as contemporaneous evidence of the creative direction process.

Legal & Copyright

Architecture and design copyright (c) {{year}}-present {{author}}.

Implementation was assisted by AI coding tools under human direction, review, and integration. Provider output terms are recorded for transparency but are not treated as a substitute for source provenance, license-compatibility review, or human authorship documentation:

{{provider_terms}}

The project does not intentionally vendor GPL, AGPL, or LGPL code, and AI-generated output is reviewed as source code — not pasted blindly — to avoid reproducing public code without compatible licensing and required notices.

Why This File Exists

Copyright protection for AI-assisted works depends on human authorship and jurisdiction-specific originality standards. This file documents the human creative process behind {{project}} so the project can distinguish human architecture, selection, arrangement, and review from machine-assisted implementation details — and so that authorship can be evidenced if ever questioned.

Changelog

All notable changes to this project will be documented in this file.

Format follows Keep a Changelog, and this project adheres to Semantic Versioning.

[Unreleased]

Added

Changed

Fixed

Code Of Conduct

{{project}} contributors are expected to keep project discussion direct, specific, and respectful.

Expected Behavior

• Focus criticism on code, design, documentation, and release risks.
• Assume maintainers and contributors are working from incomplete information.
• Make technical disagreement explicit and actionable.
• Respect privacy. Do not post private paths, API keys, tokens, logs with personal data, or unreleased material.

Unacceptable Behavior

• Harassment, threats, personal attacks, or discriminatory language.
• Publishing private contact details, private files, credentials, or user data.
• Repeatedly derailing issue or pull request discussions after a maintainer has asked to move on.

Enforcement

Maintainers may edit, hide, or remove comments; close issues or pull requests; block accounts; or restrict access when needed to keep the project workable and safe.

Report conduct issues to {{email}}.

Contributing to {{project}}

Thanks for your interest in improving {{project}}!

Ways to contribute

• Report a bug — open an issue with steps to reproduce.
• Suggest a feature — open an issue describing the use case.
• Send a pull request — for fixes and features (see below).

Development setup

git clone {{repo_url}}
cd {{project}}
{{setup_cmd}}

Run the tests before submitting:

{{test_cmd}}

Pull requests

1. Fork and branch off {{default_branch}}. 2. Keep changes focused; one logical change per PR. 3. Add or update tests for behaviour changes. 4. Ensure the test suite passes and the diff is clean. 5. Describe the why in the PR body, not just the what.

Licensing of contributions

Unless you state otherwise in writing, contributions intentionally submitted for inclusion are accepted under the project's {{license}} terms.

By contributing, you certify that you have the right to submit the work and that it does not include code copied from unlicensed, source-available, non-commercial, GPL, AGPL, LGPL, or otherwise incompatible sources.

AI-assisted contributions are allowed, but generated output must be reviewed as source code, not pasted blindly. Do not submit generated code that matches public code unless that public code has a compatible license and the required notices are preserved. When a contribution is substantially AI-assisted, mention the tool and the human review performed in the PR description.

Code of conduct

This project follows the Code of Conduct. By participating, you are expected to uphold it.

Security Policy

Reporting a vulnerability

Please report security issues privately — do not open a public issue.

Email {{email}} with:

• a description of the issue,
• steps to reproduce or a proof of concept,
• the affected version(s).

Expect an acknowledgement within a few days. Once a fix is available, a disclosure timeline will be agreed before any public details are shared.

Supported versions

The latest released version receives security fixes. Older versions are supported on a best-effort basis.

Authorship Wizard

A structured interview that produces a defensible AUTHORSHIP.md — a record of the human creative contribution behind an AI-assisted project. Its purpose is to make human authorship evidenced and explicit, because copyright protection for AI-assisted works hinges on demonstrable human authorship.

Not legal advice. This wizard surfaces general, widely-reported principles

and helps the author document facts. It is not a substitute for a qualified

lawyer in the relevant jurisdiction. Always present this disclaimer to the user.

How to run it

Fill the placeholders in assets/templates/AUTHORSHIP.md by interviewing the user and gathering external evidence. Prefer evidence over assertion: a specific decision with a commit/ADR reference is stronger than a vague claim.

Work section by section. Keep each section to a few concrete bullets — quality and specificity beat volume.

Interview transport. Prefer cenno if installed (detect per the SKILL.md Asking questions section: ToolSearch for mcp__cenno__ask_sequence). The wizard maps naturally onto mcp__cenno__ask_sequence with flow: "question":

• Jurisdiction and "which sections apply" → questions with input.kind: "choice".
• The five substance sections → questions with input.kind: "voice_text" so the

user can speak their reasoning (richer authorship evidence than terse typing).

• Run the substance questions as one ask_sequence so progress dots show; parse

{answers: [...]} in order. On {answered: false} (timeout), fall back.

If cenno is absent, use AskUserQuestion for choices and conversational prompts for free text — same questions, plainer surface.

Step 0 — Gather external evidence first

Before asking the user to recall things, mine what the repo already records, and offer the findings as a starting draft the user edits:

Summarise findings, then ask the user to confirm/correct — never invent.

Step 1 — Jurisdiction (ask first; drives the Legal section)

Ask: "Under which jurisdiction are you primarily operating / will you assert rights?" Offer the common options (see Jurisdiction notes) plus "Other / multiple". The answer selects which legal framing to write into the Legal & Copyright section and which cautions to surface.

Step 2 — The five substance sections

For each, ask 1–3 focused questions, then write tight bullets.

1. Decisions — What significant choices did you make, and why? Architecture, tech-stack selection, data models, API/interface design, build vs. buy, tradeoffs accepted. Anchor each to evidence where possible.

2. Exercise of Judgment — Where did your judgment shape or override the work? Selection among alternatives, AI output you rejected/refined, quality bars enforced, taste calls. This is often the strongest evidence of authorship in AI-assisted work — be specific about what was changed and why.

3. Goal Setting & Direction — What problem, for whom, with what goals and non-goals? Establishes that generated output served human-set objectives.

4. Art Direction — What visual identity, design system, UX patterns, and tone did you author? Selection and arrangement of expressive elements is frequently protectable even where individual components are not.

5. AI Implementation — Which AI tools assisted, and how was output reviewed? Name the tools, describe the human review loop, note where logs are retained.

Step 3 — Legal & Copyright section

Write the copyright line ((c) {{year}}-present {{author}}), the human-direction statement, and the jurisdiction-specific framing from below. Optionally record AI provider output-rights terms for transparency (see Provider terms). Re-state the not-legal-advice disclaimer in conversation (not necessarily in the file).

Jurisdiction notes

General, widely-reported positions as of 2026. Summarise the relevant one into the Legal section; flag uncertainty; recommend counsel for anything load-bearing.

United States

• The US Copyright Office position: copyright protects human-authored

contributions; purely AI-generated material lacking human creative control is not registrable. (Cf. Thaler v. Perlmutter; the Zarya of the Dawn decision; the USCO's reports on copyright and AI.)

• Human selection, arrangement, coordination, and substantial creative

modification of AI output can be protectable.

• On registration, AI-generated portions should be disclaimed; claim the

human-authored selection/arrangement and modifications.

• Practical takeaway: the Decisions/Judgment/Art-Direction sections are the

evidentiary core. Document them concretely.

European Union (incl. Germany)

• Originality standard: the work must be the **author's own intellectual

creation reflecting free and creative choices* (Infopaq, Painer*).

• AI-assisted works are protectable where a human makes such creative

choices; fully autonomous AI output without human creative input is not.

• Germany (UrhG): requires a persönliche geistige Schöpfung (personal

intellectual creation). Document the human choices that meet this bar.

United Kingdom

• The CDPA s.9(3) has an unusual computer-generated works provision: where

there is no human author, the author is the person who made the arrangements necessary for creation; protection runs ~50 years. (Under active policy review — verify current status.)

• For AI-assisted work with clear human authorship, ordinary originality

rules apply.

Other / multiple jurisdictions

• General principle everywhere: **more demonstrable human creative control =

stronger protection. When operating across jurisdictions, document to the strictest** applicable standard (typically the US human-authorship bar).

• Recommend qualified local counsel before relying on the record commercially.

Provider output terms

Optionally record, for transparency (do not rely on these in place of authorship documentation):

• OpenAI — terms state that, as between user and OpenAI and to the extent

permitted by law, the user owns the Output.

• Anthropic — commercial terms let customers retain ownership rights over

generated outputs.

Verify the current wording at the providers' published terms before quoting.

Output

Write the completed AUTHORSHIP.md to the repo root. If NOTICE exists (Apache projects), ensure it points to AUTHORSHIP.md for the authorship record.

Repo-prep checklist & per-item guidance

The full menu. Confirm which items apply (the profile defaults pre-answer most), then generate each from its template, filling placeholders. Skip items already present unless the user wants them refreshed.

Placeholders used across templates

Resolve these once, reuse everywhere:

Ecosystem detection

1. Core legal / metadata (baseline — almost always)

• [ ] LICENSE — scripts/fetch_license.py <id> --author .... See licenses.md.
• [ ] NOTICE (Apache only) — assets/templates/NOTICE.txt.
• [ ] AUTHORSHIP.md — run the authorship wizard (authorship-wizard.md).

Do not just dump the template; interview + gather evidence.

• [ ] Package metadata — set license (SPDX) + author name/email in the

manifest. Edit inline per ecosystem:

• pyproject.toml: license = "<id>", license-files = ["LICENSE"],

authors = [{ name, email }].

• package.json: "license": "<id>", "author": "Name <email>".
• Cargo.toml: license = "<id>", authors = ["Name <email>"].
• [ ] .gitignore — ensure language-appropriate ignores + local tool

artifacts. Fetch from <https://github.com/github/gitignore> if missing.

2. Community docs

• [ ] README — audit for: title + one-line description, badges, install,

usage, license section, and the promo block (below). Add a ## License section linking LICENSE (+ AUTHORSHIP).

• [ ] CONTRIBUTING.md — assets/templates/CONTRIBUTING.md (includes the

AI-assisted-contribution + license-compatibility clause).

• [ ] CODE_OF_CONDUCT.md — assets/templates/CODE_OF_CONDUCT.md.
• [ ] SECURITY.md — assets/templates/SECURITY.md (private vuln reporting).
• [ ] CHANGELOG.md — assets/templates/CHANGELOG.md (Keep a Changelog).

3. .github/ templates

• [ ] pull_request_template.md, ISSUE_TEMPLATE/ (bug + feature) — from assets/github/.
• [ ] dependabot.yml — set {{ecosystem}}.
• [ ] CI workflow — copy ci-python.yml or ci-node.yml to

.github/workflows/ci.yml; set {{default_branch}}/{{test_cmd}}.

• [ ] FUNDING.yml — only if profile has a sponsor.

4. Promo block ("ads")

From profile [promo] (skip if enabled = false). Append a README footer:

## More from {{author}}

> {{tagline}}

- **[name](url)** — blurb
- ...

Keep it to 3–6 links. Per-repo, the user may opt out.

5. EU / Germany compliance (conditional)

Run the gating questions in eu-germany-compliance.md. Add only what applies (SBOM/CI audit, AI-transparency note, IMPRESSUM.md, PRIVACY.md, non-commercial framing). For a personal non-commercial repo with no data collection, usually nothing beyond LICENSE/NOTICE/SECURITY.md.

6. GitHub remote setup (gh) — optional, confirm first

Outward-facing; confirm before running.

• [ ] Repo exists? gh repo view — else gh repo create.
• [ ] Description + topics: gh repo edit --description "…" --add-topic a,b,c.
• [ ] Default branch matches {{default_branch}}.
• [ ] Enable private vulnerability reporting (Settings → Security).

Finish

• Run the test suite to confirm metadata changes didn't break the build.
• Show the user the diff; commit only when asked (per their git conventions).

EU / Germany compliance for repos

Practical, repo-level additions for a maintainer based in Germany / operating under EU law. Scope here is what belongs in a repository; it does not cover company-level obligations.

Not legal advice. General principles as of 2026. Most obligations are

conditional — they bite only for commercial activity, personal-data

processing, AI-facing behaviour, or an operated website. Ask the gating

questions below and only add what applies. Recommend counsel for anything

load-bearing.

Gating questions (ask before adding anything)

1. Commercial? Is the software provided in the course of a business activity, for a fee, or in exchange for personal data? (Donations/sponsorship and "free but monetised" are gray — flag them.) 2. Personal data? Does the software or its website collect/process any personal data (telemetry, analytics, accounts, logs with PII)? 3. AI-facing? Does it interact with users as an AI, or generate synthetic text/image/audio/video? 4. Operated website? Is there a project site / landing page / docs site you run (not just the GitHub repo)?

Most personal/non-commercial OSS with no data collection needs none of the heavy items — just LICENSE, NOTICE, SECURITY.md, and a clear non-commercial framing.

1. Cyber Resilience Act (CRA) — Regulation (EU) 2024/2557

• In force Dec 2024. Vulnerability/incident reporting from 11 Sep 2026; full

compliance 11 Dec 2027. Penalties up to €15M / 2.5% turnover (commercial).

• Open-source carve-outs: software developed/supplied outside a commercial

activity is largely out of scope; a lighter "open-source software steward" category exists for foundations/orgs supporting projects they don't monetise. Article 64: administrative fines don't apply to OSS stewards — but vulnerability-reporting duties still start Sep 2026.

• **What to add to a repo (good practice for everyone, required for commercial

"products with digital elements"):**

• SECURITY.md with a private vulnerability-reporting channel and SLA.
• A machine-readable SBOM (SPDX or CycloneDX), covering at least direct

dependencies. Generate in CI (e.g. syft, cyclonedx, cargo-cyclonedx, npm sbom). Retain security docs ~10 years for commercial products.

• Dependency/supply-chain audit in CI (e.g. cargo-audit/cargo-deny,

npm audit, pip-audit) and Dependabot.

• Coordinated vulnerability-disclosure policy; GitHub "Private vulnerability

reporting" enabled.

2. AI Act — Regulation (EU) 2024/1689 (Article 50 transparency)

• Article 50 transparency applies 2 Aug 2026.
• Applies only if the software is AI-facing:
• Systems that interact with people must disclose they are AI (unless

obvious).

• Generators of synthetic audio/image/video/text must mark output as

artificially generated in a machine-readable format.

• Limited open-source exemption exists for some GPAI documentation duties.
• What to add (only if AI-facing): an "AI transparency" note in README/docs

stating the system is AI and how outputs are marked; implement output marking (e.g. C2PA / metadata) where you generate synthetic media.

3. Impressum — German DDG (ex-TMG)

• The Telemediengesetz was renamed Digitale-Dienste-Gesetz (DDG) (DSA

alignment, 2024). It requires an Impressum (imprint) for geschäftsmäßige (business-like) telemedia — name, postal address, email, and where applicable registry/VAT details.

• A bare GitHub repo is generally not "geschäftsmäßig"; the obligation typically

attaches to an operated project website, or when the project is commercial / monetised / donation-driven.

• What to add (if you run a project site or it's commercial): an IMPRESSUM

(in repo as IMPRESSUM.md and/or on the site) with the required identity details. Several community templates exist (search "Impressum GitHub template").

4. GDPR — Regulation (EU) 2016/679

• Applies only when personal data is processed (incl. via a website with

analytics, accounts, telemetry, or server logs with PII).

• What to add (only if data is collected):
• PRIVACY.md / privacy policy in clear language: what's collected, why, legal

basis, retention, user rights, contact.

• A data-flow description (what leaves the device, to whom).
• For local-first/no-collection software, a short explicit statement —

"collects no personal data; nothing is sent off-device" — is valuable and low-cost.

• Contributions: a DCO (Signed-off-by) or CLA is part of a clean posture.

5. Product Liability Directive — (EU) 2024/2853

• Software is now explicitly a "product." In force Nov 2024; Member-State

transposition by 9 Dec 2026.

• OSS exemption: software "developed or supplied **outside a commercial

activity" is exempt from strict liability. But* a chargeable service — or a service in exchange for personal data — revives product status, and commercial products built on your OSS are fully covered.*

• What to add: keep the non-commercial framing explicit in LICENSE/NOTICE;

for anything commercial, pair with security docs and threat modelling.

6. European Accessibility Act (EAA) — Directive (EU) 2019/882

• Applies from 28 Jun 2025 to certain consumer-facing products/services

(e-commerce, consumer apps) placed on the market commercially. Likely irrelevant to a dev tool / library; flag it only for consumer-facing commercial software and recommend an accessibility review then.

Suggested repo artifacts by trigger

Sources

• CRA: OpenSSF · Red Hat · BCLP
• SBOM/CRA: Anchore · OPSWAT
• AI Act: Linux Foundation Europe · Article 50
• Impressum/DDG: Wikipedia: Impressum · Win With Words (2024 update)
• GDPR + OSS: TermsFeed · FreePrivacyPolicy
• Product Liability: Hogan Lovells · Cycode

License selection

Help the user choose, then write the LICENSE with scripts/fetch_license.py. Default for this author: Apache-2.0 (see profile defaults.license).

Guidance:

• Permissive (Apache/MIT/BSD) maximises adoption; Apache-2.0 adds patent

protection and is this author's default.

• Copyleft (GPL/AGPL/MPL) keeps derivatives open; note GPL/AGPL are

incompatible with this author's usual permissive posture — confirm intent.

• Dual-licensing and relicensing are painful later — confirm the choice now.
• SPDX ids: <https://spdx.org/licenses/>. The script fetches any id from the

SPDX license-list-data repo when not bundled.

Writing the LICENSE

python scripts/fetch_license.py <SPDX-ID> --author "<name>" --year <year>

For Apache-2.0 also create NOTICE from assets/templates/NOTICE.txt, and set license = "Apache-2.0" + license-files in package metadata.