setup-repo
Setup Repo
This skill sets up or repairs a repository. The same rules apply whether the project is new or already initialized — inspect first, then apply each step.
Scope
This skill delivers repo scaffolding only: git initialization, .gitignore, .gitattributes, AGENTS.md, hooks, and skill installation. The summary in Step 9 is the final deliverable. Once it is delivered, this skill's work is complete — what happens next is the user's decision.
Step 1: Interview the user
Collect before touching any files:
- Project goal — one sentence: what is this project for?
- Tech stack — languages, frameworks, runtimes
- Skills — any specific agentic skills to add (optional)
If the project has tool constraints, also collect:
- Runtime targets — which runtimes need enforcement hooks (
GitHub Copilot CLI,OpenCode)
More from yldgio/vibe-grimoire
pre-mortem
>-
13create-prd
Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue, Azure DevOps work item, or local file. Use when the user wants to create or write a PRD, create a product requirements document, design a new feature, or capture requirements.
11prd-slice
Break a PRD into independently-deliverable work items (vertical slices / tracer bullets) and create them in Azure DevOps, GitHub Issues, or Jira. Use when a user wants to convert a PRD into implementation tickets, decompose a product spec into trackable slices, create work items from requirements, or break down a PRD for any issue tracker — even if they don't say "vertical slice" or "tracer bullet".
11plan-from-prd
Turn a PRD into a multi-phase, local Markdown implementation plan using tracer-bullet vertical slices, saved to ./plans/. Use when the user wants to create an implementation plan from a PRD, plan phases from a PRD, break a PRD into development phases, or mentions "tracer bullets" or "implementation phases". For creating tracker work items (GitHub Issues, Azure DevOps, Jira) use the prd-slice skill instead.
11tdd
>-
9adr
Create an Architectural Decision Record (ADR) to formally document a significant technical or architectural choice. Use whenever a user says "write an ADR", "document this decision", "record why we chose X", "capture this architecture choice", "explain why we went with Y", "document the trade-offs", "write up this tech decision", or makes any significant architectural choice that future teammates will need to understand. Also use proactively when you observe a meaningful decision being made during a session — even if the user hasn't explicitly asked for an ADR. ADRs prevent teams from re-debating settled choices and preserve context that would otherwise become tribal knowledge lost to future maintainers.
7