github-project-setup
Skill0 starsChanged 6 months agoMITView on GitHub
Scaffold a new GitHub repo as a project workspace — labels, milestones, baseline issues for vision, PRD, UX, architecture, traceability, P3.express kickoff. Triggers "prepare new repo", "scaffold project setup", "GitHub project setup".
1 other project uses a version of this.
Adopted by
Most recently taken up by
- nek1987/auto-agent-harnesstheir own version, first seen Oct 11, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- nek1987/auto-agent-harness★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- plugin-v2/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- plugin-v2/CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/agents.mdcCursor rule
- agentic-security-reviewSkill
- arc42-baselineSkill
- caveman-commitSkill
- caveman-helpSkill
- caveman-reviewSkill
- cavemanSkill
- create-goalSkill
- design-twiceSkill
- discovery-sprintSkill
- domain-contextSkill
- grillSkill
- improve-codebase-architectureSkill
- issue-breakdownSkill
- issue-draftSkill
- issue-pr-syncSkill
- new-adrSkill
- new-glossary-entrySkill
- orchestrateSkill
- portfolio-trackSkill
- product-pageSkill
- project-reviewSkill
- project-runSkill
- project-scaffoldingSkill
- quality-assuranceSkill
- quality-metricsSkill
- record-decisionSkill
- review-fixSkill
- roadmap-managementSkill
- sales-cycleSkill
- specorator-designSkill
- specorator-improvementSkill
- specorator-onboardSkill
- stock-takingSkill
- tackle-issueSkill
- tdd-cycleSkill
- token-budget-reviewSkill
- tracer-bulletSkill
- ubiquitous-languageSkill
- verifySkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 7 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use this skill to turn a blank or early GitHub repository into a manageable product/project workspace.
- Distinctive: line 23
If the repo already has issues, list them first and avoid duplicating obvious existing setup work.
- Distinctive: line 31
Use P3 when the project needs explicit sponsor/PM roles, kickoff, follow-up registers, risks, go/no-go gates, or stakeholder communication.
- Very specific: line 32
Use --no-p3 only for very small internal experiments where the user explicitly does not want governance.
- Distinctive: line 46
Read back created issues from GitHub:
- Very specific: line 78
Do not run --execute against the wrong repository.
- Distinctive: line 79
Do not create duplicate planning issues if the target repo already has equivalent issues.
- Distinctive: line 80
Do not claim GitHub Projects fields/views were configured by the script.
- Distinctive: line 81
Keep the setup backlog focused on readiness and product setup.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GitHub Project Setup
Use this skill to turn a blank or early GitHub repository into a manageable product/project workspace.
It creates a repeatable backlog baseline, not implementation code. The default setup includes:
- GitHub/repo environment readiness.
- Product setup:
PRODUCT_VISION.md, PRDs, use cases, UX/design brief, architecture input, traceability. - P3.express initiation through kickoff.
- Optional plugin-shell preparation for plugin products.
Preconditions
- Resolve the target repository as
owner/name. - Confirm
gh auth statusworks. - Confirm the user expects GitHub writes. Label/milestone/issue creation is shared state.
- If the repo already has issues, list them first and avoid duplicating obvious existing setup work.
Procedure
- Classify the project profile:
generic-product: default for apps, libraries, SaaS, services, and internal tools.obsidian-plugin: use for Obsidian plugin work or similar plugin-shell setup where isolated UI, marketplace readiness, and host bridge concerns matter.
- Decide whether P3.express initiation applies:
- Use P3 when the project needs explicit sponsor/PM roles, kickoff, follow-up registers, risks, go/no-go gates, or stakeholder communication.
- Use
--no-p3only for very small internal experiments where the user explicitly does not want governance.
Dry-run the plan:
npm run project:setup:github -- --project-name "<Project Name>" --profile <generic-product|obsidian-plugin> --dry-run- Review the plan with the user when the target repo is not empty or when there is any risk of duplicate public issues.
Execute only after the plan is suitable:
npm run project:setup:github -- --repo <owner/name> --project-name "<Project Name>" --profile <generic-product|obsidian-plugin> --executeRead back created issues from GitHub:
gh issue list --repo <owner/name> --state open --limit 100 --json number,title,milestone,labels,url- Summarize the created milestone structure and the recommended first issue to work.
What The Tool Creates
The tool creates:
- Labels for setup, product, PRD, use cases, UX, architecture, traceability, CI, release, docs, and pages.
- Milestones:
v1 repo setupv1 product setupv1 plugin shellforobsidian-pluginP3 project initiationunless--no-p3
- Issues covering:
- README/license/docs and GitHub workflow.
- CI, release, dependency, and branch-protection readiness.
- GitHub Pages product page.
PRODUCT_VISION.md.- v1 PRD.
- use case catalog.
- UX/design and architecture handoff briefs.
- traceability index.
- plugin shell architecture when applicable.
- P3 A01-A10 initiation and focused communication when enabled.
Guardrails
- Do not run
--executeagainst the wrong repository. - Do not create duplicate planning issues if the target repo already has equivalent issues; update existing issues or create a smaller gap-filling set instead.
- Do not claim GitHub Projects fields/views were configured by the script. The tool creates labels, milestones, and issues. GitHub Project boards/views should be configured manually or by a future extension.
- Keep the setup backlog focused on readiness and product setup. Feature implementation issues come after the product baseline.
References
- Tool:
scripts/github-project-setup.ts - Project management methodology:
docs/project-track.md - Existing local project track skill:
.claude/skills/project-run/SKILL.md
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
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.