agentleFS
Sign inStart free
mblaubergmblauberg/provenant/skills/setup-repo/SKILL.md

setup-repo

Skill1 starsChanged 5 days agoMITView on GitHub

Use when asked to set up or scaffold a repository's process: tracker, issue forms, labels, branch ruleset, templates, routes, autonomy level, docs layout or work-item runbook. Not for a repo's day-to-day GitHub mechanics; use its runbook.

12 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Put project templates under .provenant/templates/.

    line 34
  2. Distinctive:

    Only with tracker GitHub issues and a confirmed host:

    line 44
  3. Very specific:

    Ruleset: add the ci-status aggregate, then create a ruleset requiring that one exact-head check, per ruleset guidance.

    line 53
  4. Very specific:

    Stop for an unnamed target, unconfirmed write permission or host, replacement of an existing ruleset or labels file, a semantic conflict, …

    line 64

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Setup

Scaffold the process a repository needs so agents can run it with the human near or out of the loop. Setup is the one place that sets how much autonomy a repo grants.

Gate and classify

Name the target; never infer it from the working directory. Read the target's Repository process declaration, MAINTAINING.md, .github/**, .provenant/** and its runbook before proposing anything. Ask only what the repo has not already settled.

Show one diff and get one approval. Mark each action keep (exact match), create (absent), adapt (compatible, propose the merge) or conflict (semantic mismatch: stop and ask). Never overwrite. A re-run on a set-up repo must produce no diff. Confirm the remote host before any gh command.

Declare the process

Amend the Repository process block in MAINTAINING.md from templates/repo-declarations.md: tracker, scope home (issue-tracker or project-docs), workflow-state owner, docs layout, merge policy and runbook pointers. Pointers only; never copy policy. With tracker none, both homes are project-docs and the GitHub steps are skipped. Ask where specs, runbooks and ADRs live, and apply engineering-docs' default homes.

Autonomy

Record the chosen autonomy and landing gates in the repository runbook. Put project templates under .provenant/templates/; a leaf holds a brief, tier, access and outputs, while a composite holds nodes. Use plan for open shape, batch for disjoint slices and deliver through landing. Keep write scopes and decision authority explicit; a template grants no new authority.

Inspect with provenant templates NAME and provenant run --use NAME --file BRIEF --explain; run provenant config check.

GitHub steps

Only with tracker GitHub issues and a confirmed host:

  1. Labels: copy labels.yml and workflows-labels.yml. The sync prunes any undeclared label, so warn before the first run. Labels signal handling only, never type or status.
  2. Issue forms: copy ISSUE_TEMPLATE/: Epic, Feature, Task and Bug. The spec fields sit on Feature and Task. Confirm private vulnerability reporting works, then copy SECURITY.md.
  3. Ruleset: add the ci-status aggregate, then create a ruleset requiring that one exact-head check, per ruleset guidance. Ask which jobs it should needs:.
  4. PR template: copy pull_request_template.md and adapt the evidence rows.
  5. Runbook: seed the declared work-item runbook from the runbook seed and add the project's mechanics.
  6. Dependabot and CODEOWNERS: adapt dependabot.yml.

Stop

Stop for an unnamed target, unconfirmed write permission or host, replacement of an existing ruleset or labels file, a semantic conflict, or ambiguous ci-status dependencies.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free