@arthai/agents 1.0.0

package/skills/wizard/SKILL.md

@@ -0,0 +1,411 @@
+---
+name: wizard
+description: "Guided step-by-step workflows for non-engineers. Role-based flows that walk you through common tasks. Usage: /wizard <role> <step>"
+user-invocable: true
+arguments: "<role> <step>"
+---
+
+Guided workflows that walk non-engineers through multi-step processes. Each workflow is designed
+for a specific role and breaks complex tasks into manageable steps, bringing in the right
+specialist at each stage.
+
+## Argument Parsing
+
+| Input | Action |
+|---|---|
+| `/wizard` | Detect role or ask, then show available workflows |
+| `/wizard pm` | Show PM workflow steps |
+| `/wizard pm 1` | Jump to PM workflow step 1 |
+| `/wizard pm next` | Continue to next incomplete step |
+| `/wizard founder` | Show Founder workflow steps |
+| `/wizard designer` | Show Designer workflow steps |
+| `/wizard marketer` | Show Marketer workflow steps |
+| `/wizard status` | Show progress across all workflows |
+| `/wizard resume` | Resume where you left off |
+| `/wizard reset` | Clear saved progress and start fresh |
+
+## Role Detection
+
+Check `.claude/.claude-agents.conf` for `USER_ROLE`. If not set, present this menu using AskUserQuestion:
+
+```
+What best describes your role?
+  1. Product Manager — I plan features and prioritize what to build
+  2. Founder — I oversee everything from vision to shipping
+  3. Designer — I design experiences and visual interfaces
+  4. Marketer — I position products and drive awareness
+
+Pick the one closest to your work.
+```
+
+## State Management
+
+Progress is saved in `.claude/.wizard-state.json` so you can resume across sessions.
+
+**State schema:**
+```json
+{
+  "role": "pm",
+  "active_workflow": "plan-and-ship",
+  "current_step": 2,
+  "steps_completed": [1],
+  "step_outputs": {
+    "1": {
+      "summary": "Feature brief for user notifications",
+      "file": ".claude/plans/notifications-brief.md"
+    }
+  },
+  "started_at": "2026-03-23T10:00:00Z",
+  "last_active": "2026-03-23T14:30:00Z"
+}
+```
+
+**State operations:**
+- Read state at the start of every `/wizard` invocation
+- Write state after every step completion
+- On `/wizard resume`: read state, show summary, continue from `current_step`
+- On `/wizard reset`: delete `.claude/.wizard-state.json`
+- On `/wizard status`: read state, show progress table
+
+---
+
+## Workflow 1: Product Manager — "Plan and Ship a Feature"
+
+Present this overview when the PM role is selected:
+
+```
+Plan and Ship a Feature
+═══════════════════════
+
+This workflow walks you through taking an idea from concept to launch:
+
+  Step 1: Describe Your Idea          ← Tell us what you want to build
+  Step 2: Understand Your Users       ← Learn who needs this and why
+  Step 3: Write the Plan              ← Create a detailed plan for the team
+  Step 4: Create a Launch Plan        ← Figure out how to tell people about it
+  Step 5: Track Progress              ← See how things are going
+
+You can do these in order, skip ahead, or come back later.
+Which step would you like to start with?
+```
+
+### Step 1: Describe Your Idea
+
+**What happens:** You describe the feature or product idea in your own words. A specialist helps turn it into a structured brief.
+
+**Execution:**
+1. Ask the user: "What do you want to build? Describe it in a few sentences — who it helps and what problem it solves."
+2. Read CLAUDE.md for project context
+3. Spawn the `product-manager` agent with:
+   > Write a product brief for: {user's description}
+   > Project context: {CLAUDE.md content}
+   > Structure with: Problem statement, Target user, Desired outcome, Success metrics, Scope, Open questions.
+   > Write in plain language. Under 500 words.
+4. Save the brief output to `.claude/plans/{topic}-brief.md`
+5. Update state: step 1 complete, save file reference
+
+**After completion:**
+```
+Your feature brief is ready!
+
+Here's a quick summary: [2-sentence summary of the brief]
+
+What would you like to do?
+  - "next" to move on to understanding your users
+  - "revise" to change something in the brief
+  - "share this" to send the brief to your team
+  - "save and stop" to come back later
+```
+
+### Step 2: Understand Your Users
+
+**What happens:** A research specialist analyzes who needs this feature and what they struggle with, using your brief from Step 1 as context.
+
+**Execution:**
+1. Read Step 1 output (brief) for context
+2. Spawn the `user-researcher` agent with:
+   > Based on this product brief: {brief content}
+   > Generate 2-3 behavior-based user personas who would benefit from this feature.
+   > For each persona: behavior pattern, motivation (functional/emotional/social jobs), current pain, trigger, and what success looks like.
+   > Also identify the top 3 assumptions we should validate before building.
+3. Save output to state
+
+**After completion:**
+```
+User research is ready! Here's what we found:
+
+[1-sentence summary of key personas and insights]
+
+What would you like to do?
+  - "next" to write the full plan
+  - "revise" to adjust the research
+  - "share this" to send to your team
+  - "save and stop" to come back later
+```
+
+### Step 3: Write the Plan
+
+**What happens:** A planning team creates a detailed implementation plan using your brief and user research.
+
+**Execution:**
+1. Read Step 1 (brief) and Step 2 (research) outputs
+2. Invoke `/planning {topic}` with context from previous steps injected
+3. The planning skill spawns its own team (PM + Architect) to create the plan
+4. Save plan output to state
+
+**After completion:**
+```
+Your implementation plan is ready!
+
+The team created: [brief summary — scope, timeline, key decisions]
+
+What would you like to do?
+  - "next" to plan how to launch this
+  - "revise" to change the plan
+  - "share this" to send to your team
+  - "save and stop" to come back later
+```
+
+### Step 4: Create a Launch Plan
+
+**What happens:** A go-to-market specialist creates a launch plan for your feature.
+
+**Execution:**
+1. Read Step 1 (brief) and Step 2 (research) for context
+2. Spawn the `gtm-expert` agent with:
+   > Create a launch plan for: {topic}
+   > Product brief: {brief content}
+   > Target users: {persona summaries from step 2}
+   > Structure with: What's launching, Who it's for, Positioning, Channels, Timeline (4 weeks), Success metrics, Risks.
+   > Write in plain language. Under 600 words.
+3. Save output to state
+
+### Step 5: Track Progress
+
+**What happens:** A status specialist reads the project's actual data and generates a progress report.
+
+**Execution:**
+1. Spawn the `stakeholder-reporter` agent with:
+   > Generate a project status report focused on: {topic from step 1}
+   > Context: we planned this feature in [date]. Here's what the plan included: {brief summary}
+   > Read git history, PRs, and issues to report on progress.
+2. Save output to state
+
+**After completion:**
+```
+Here's your project status! [summary]
+
+You've completed all 5 steps of the Plan and Ship workflow.
+
+What would you like to do?
+  - "share this" to send the status to your team
+  - "start over" to plan a new feature
+  - "run step 5 again" to get a fresh status update later
+```
+
+---
+
+## Workflow 2: Founder — "Build and Ship"
+
+```
+Build and Ship
+══════════════
+
+This workflow takes you from vision to launched product:
+
+  Step 1: Describe Your Vision        ← What are you building and why?
+  Step 2: Research the Market          ← Who else is doing this? What's your edge?
+  Step 3: Plan the Build              ← Turn vision into a concrete plan
+  Step 4: Build It                    ← Get the team building
+  Step 5: Ship and Learn              ← Launch and see what happens
+
+Which step would you like to start with?
+```
+
+### Step 1: Describe Your Vision
+- Ask: "What are you building? Who is it for? Why does the world need it?"
+- Spawn `product-manager` with product vision template prompt
+- Save vision document to state
+
+### Step 2: Research the Market
+- Read Step 1 (vision) for context
+- Spawn `competitive-analyst` with:
+  > Research the competitive landscape for: {vision summary}
+  > Identify direct competitors, indirect competitors, and potential entrants.
+  > Run a Strategy Canvas and 7 Powers analysis on the top 3 competitors.
+  > What is the blue ocean opportunity?
+- Save competitive intelligence to state
+
+### Step 3: Plan the Build
+- Read Steps 1-2 for context
+- Invoke `/planning {topic}` with vision + competitive context
+- Save plan to state
+
+### Step 4: Build It
+- Read Step 3 (plan) for context
+- Invoke `/implement {topic}` with plan context
+- Save implementation progress to state
+
+### Step 5: Ship and Learn
+- Read Steps 1-2 for context
+- Spawn `gtm-expert` for launch plan based on competitive intelligence
+- Spawn `stakeholder-reporter` for current project status
+- Present both outputs together
+
+---
+
+## Workflow 3: Designer — "Design, Validate, Ship"
+
+```
+Design, Validate, Ship
+══════════════════════
+
+This workflow guides you through a complete design cycle:
+
+  Step 1: Define the Challenge         ← What problem is this design solving?
+  Step 2: Get Expert Critique          ← Honest feedback from design principles
+  Step 3: Iterate                      ← Refine based on feedback
+  Step 4: Plan Implementation          ← Turn the design into a build plan
+  Step 5: Review Final Result          ← Check the build against the original intent
+
+Which step would you like to start with?
+```
+
+### Step 1: Define the Challenge
+- Ask: "What design problem are you trying to solve? Who is the user and what should they be able to do?"
+- Spawn `design-studio-think` with design thinking prompt
+- Save design brief to state
+
+### Step 2: Get Expert Critique
+- Ask for the design to critique (URL, screenshot path, or description)
+- Spawn `design-studio-critique` with design brief context from Step 1
+- Save critique to state
+
+### Step 3: Iterate
+- Read Steps 1-2 (brief + critique) for context
+- Spawn `design-studio-create` with:
+  > Based on this design challenge: {brief}
+  > And this critique feedback: {critique summary}
+  > Create an improved design that addresses the top recommendations.
+- Save iteration output to state
+
+### Step 4: Plan Implementation
+- Read Steps 1-3 for context
+- Invoke `/planning --design {topic}` with design brief and iteration context
+- Save plan to state
+
+### Step 5: Review Final Result
+- Ask: "Has the design been implemented? Point me to what to review."
+- Spawn `design-studio-critique` for final review against original brief from Step 1
+- Compare: does the implementation match the design intent?
+
+---
+
+## Workflow 4: Marketer — "Research, Position, Launch"
+
+```
+Research, Position, Launch
+═════════════════════════
+
+This workflow guides you from market research to launch execution:
+
+  Step 1: Understand the Landscape     ← Who are the competitors and what's our edge?
+  Step 2: Define Positioning           ← How do we describe what we do and for whom?
+  Step 3: Create Content               ← Blog posts, copy, and marketing materials
+  Step 4: Plan the Launch              ← Week-by-week launch execution plan
+  Step 5: Measure Results              ← How did it go? What's next?
+
+Which step would you like to start with?
+```
+
+### Step 1: Understand the Landscape
+- Ask: "What product or feature are we marketing? Who do you think the competitors are?"
+- Spawn `competitive-analyst` with competitive intelligence gathering protocol
+- Save landscape analysis to state
+
+### Step 2: Define Positioning
+- Read Step 1 (landscape) for context
+- Spawn `gtm-expert` with:
+  > Based on this competitive landscape: {landscape summary}
+  > Complete a Positioning Canvas for: {product}
+  > Identify: competitive alternatives, unique attributes, value, target customers, market category.
+  > Write the positioning statement.
+- Save positioning to state
+
+### Step 3: Create Content
+- Read Steps 1-2 (landscape + positioning) for context
+- Spawn `content-strategist` with:
+  > Based on this positioning: {positioning statement}
+  > And this competitive landscape: {key findings}
+  > Create: 1 blog post draft, 3 social media posts (Twitter/LinkedIn), and 1 product announcement.
+  > Ground all content in real product capabilities (read CLAUDE.md and codebase).
+  > Use the PAS framework for the blog post and AIDA for social.
+- Save content drafts to state
+
+### Step 4: Plan the Launch
+- Read Steps 1-3 for full context
+- Spawn `gtm-expert` for a full launch plan with GACC brief
+- Save launch plan to state
+
+### Step 5: Measure Results
+- Spawn `stakeholder-reporter` for project status
+- Present status alongside launch plan metrics from Step 4
+- Suggest: what to double down on, what to adjust
+
+---
+
+## Step Execution Protocol
+
+For every step in every workflow, follow this protocol:
+
+1. **Read state** from `.claude/.wizard-state.json`
+2. **Check prerequisites** — if previous steps have outputs, load them as context
+3. **Present what this step does** in plain language before executing
+4. **Confirm** — "Ready to start? Or would you like to skip this step?"
+5. **Execute** — spawn the appropriate agent/skill with full context
+6. **Save output** to state (summary + file reference if applicable)
+7. **Present results** with a brief summary
+8. **Offer next actions:**
+   ```
+   What would you like to do?
+     - "next" to continue to [next step name]
+     - "revise" to redo this step with changes
+     - "share this" to format for your team
+     - "save and stop" to come back later
+     - "skip to step [N]" to jump ahead
+   ```
+
+## Resume Protocol
+
+On `/wizard resume`:
+1. Read `.claude/.wizard-state.json`
+2. If no state exists: "No workflow in progress. Type /wizard to start one."
+3. If state exists, present:
+   ```
+   Welcome back! You're working on: [workflow name]
+   Role: [role]
+   Started: [date]
+
+   Progress:
+     ✓ Step 1: [name] — [summary]
+     ✓ Step 2: [name] — [summary]
+     → Step 3: [name] — not started yet
+       Step 4: [name]
+       Step 5: [name]
+
+   Ready to continue with Step 3: [name]?
+   ```
+
+## Rules
+
+- Never show agent names — say "bringing in a specialist" or "running analysis"
+- Never show model names or cost tiers
+- Never show slash command syntax — all interaction is natural language
+- All text must be in everyday language — no jargon, no technical terms
+- Always save state before spawning agents (crash recovery)
+- Always offer "save and stop" at every checkpoint — respect the user's time
+- Pass context from previous steps to every agent invocation — continuity is critical
+- If a step fails, explain what happened in plain English and offer to retry
+- Keep step summaries under 2 sentences — the full output is always available
+- The user can do steps out of order — warn but don't block
+- Each step should complete in under 60 seconds

package/templates/CLAUDE.md.managed-block

@@ -0,0 +1,123 @@
+## Engineering Principles (MANDATORY — applies to ALL work)
+
+### Research Before Fixing
+- **Never guess.** Before changing code, read the relevant source files, docs, and configs.
+- Understand WHY something is broken before attempting a fix.
+- If your first fix doesn't work, STOP. Don't try another guess. Re-read the code.
+- Use explore-light (Haiku, 1x cost) to scan the codebase before expensive agents investigate.
+
+### No Over-Engineering
+- **Do exactly what's needed.** Don't add abstractions, utilities, or frameworks unless the code already uses them.
+- Match existing patterns — run explore-light to find how similar code is structured before writing new code.
+- A bug fix touches the minimum files possible. A feature matches the existing architecture.
+- If you're creating a new class/helper/utility that nothing else in the codebase uses, you're over-engineering.
+
+### Test Before Shipping
+- **Run tests locally before pushing.** Never push untested code.
+- If the project has `/precheck`, run it. If it has `/qa`, run it in commit mode.
+- After fixing a bug, verify the fix AND verify nothing else broke (differential testing).
+- If 3+ consecutive fix attempts fail, STOP. Step back and reassess the root cause from scratch.
+
+### Deployment Safety
+- **Never modify production systems without explicit confirmation.**
+- Don't change deploy targets, CI pipeline structure, or infrastructure config silently.
+- Don't overwrite existing files during deployment without asking.
+- If a deployment breaks something, investigate before attempting to fix. Don't cascade.
+
+## Toolkit Awareness (MANDATORY — READ THIS FIRST)
+
+You have a **claude-agents toolkit** installed in this project. It provides specialized
+agents, skills, and hooks that handle domain-specific work better and cheaper.
+
+**You are the ORCHESTRATOR.** The triage router fires on every message with a routing
+table and SPEED score. Use it to decide: toolkit or you?
+
+### When to use the toolkit (SPEED score 2+):
+- **Multi-step workflows**: `/pr`, `/deploy`, `/planning`, `/implement`, `/qa`, `/ci-fix`
+  encode battle-tested sequences you'd otherwise do manually and forget steps
+- **Domain expertise**: SRE, QA, frontend, backend agents have project context baked in
+- **Cost savings**: Haiku/Sonnet agents handle 80% of tasks at 1/60th the cost of Opus
+- **Parallelism**: Team skills spawn multiple agents working simultaneously
+
+### When to use YOU directly (SPEED score 0-1):
+- **Quick lookups**: Read/Grep/Glob for finding a file, checking a value, reading code
+- **Small targeted edits**: 1-2 file changes where you already know what to do
+- **Complex reasoning**: Architecture decisions, debugging novel problems, nuanced tradeoffs
+- **Conversation flow**: Follow-up questions, clarifications, explaining code
+- **Creative problem-solving**: When the task doesn't fit any existing pattern
+- **Judgment calls**: Security reviews, design decisions, "should we even do this?"
+
+### The balance:
+The toolkit handles **process** (repeatable workflows, domain-specific checks, multi-step
+sequences). You handle **judgment** (reasoning, creativity, novel problems, architecture).
+
+A senior engineer doesn't do everything themselves — they delegate routine work and focus
+their expertise where it matters most. That's you. The toolkit is your team.
+
+**Don't over-delegate**: If it's faster to just Read a file and answer, do it.
+**Don't under-delegate**: If it's a 5-step workflow the toolkit has a skill for, use it.
+
+### Project Knowledge System
+
+If this project has been calibrated (`/calibrate`), deep context is available:
+
+- **`.claude/project-profile.md`** — Architecture patterns, coding conventions, domain model,
+  testing style. Read this before writing any code to match the project's patterns.
+- **`.claude/knowledge/`** — The toolkit's long-term memory for this project:
+  - `shared/conventions.md` — Coding rules learned from corrections. **Read before writing code.**
+  - `shared/domain.md` — Business rules beyond what's in the code. **Read before domain decisions.**
+  - `shared/vocabulary.md` — What the team calls things. **Use these terms.**
+  - `shared/patterns.md` — Architecture patterns. **Follow these when adding new code.**
+  - `agents/{your-name}.md` — Your past learning. **Read on session start.**
+  - **Write back** when you learn something new — corrections, discoveries, decisions.
+  - See `knowledge/README.md` for the full protocol.
+- **`.claude/knowledge/external/sources.md`** — Where team knowledge lives outside code
+  (Notion, Linear, Figma, etc.). Check before making decisions that might already be documented.
+
+## Session Start Behavior (MANDATORY)
+
+On your FIRST response in every new session, ALWAYS start with a brief status line
+using context from the SessionStart hook. Include:
+- Current branch + uncommitted file count
+- Docker/infra status (if problems detected)
+- Open PRs or assigned issues (if any)
+- Any red flags (pending migrations, expired tokens)
+
+Format: 1-3 compact lines before addressing the user's request. Example:
+```
+📋 project — main | 5 uncommitted | Docker: postgres ✓ redis ✓ | 2 open PRs
+```
+Then proceed with the user's actual request.
+
+**CRITICAL — Greetings and vague first messages**: If the user's first message is a
+greeting ("hey", "hi", "hello", "yo", "sup") or vague ("help", "what's up",
+"what should I work on") or ANY message under 5 words with no specific task —
+**ALWAYS use the `/onboard` skill**. Never respond to greetings yourself. The
+bootstrap hook status line is a quick snapshot — `/onboard` gives the real briefing
+with open PRs, issues, priorities, and actionable next steps.
+
+## Routing Trace (MANDATORY)
+
+On EVERY response, show a compact routing trace so the user understands the decision
+path. Place it at the end of your response in a dimmed block:
+
+```
+🔀 Routing: [what triage decided] → [agent/skill/tool used] ([cost tier])
+   Why: [1-line reason for this routing choice]
+```
+
+Examples:
+```
+🔀 Routing: backend bug fix → python-backend agent (Sonnet, 10x)
+   Why: touches backend/app/services/, needs CLAUDE.md context, SPEED=4
+```
+```
+🔀 Routing: file lookup → Grep (built-in, 0x)
+   Why: single-file search, no project context needed, SPEED=0
+```
+
+Rules:
+- Always show the SPEED score breakdown if score >= 2
+- Show which hook provided the context (triage-router, bootstrap, etc.)
+- If you chose NOT to use the triage router's suggestion, explain why
+- Skip the trace only for simple follow-up messages in an ongoing conversation

package/templates/CLAUDE.md.template

@@ -0,0 +1,111 @@
+# CLAUDE.md — {{PROJECT_NAME}}
+
+<!-- Generated by claude-agents install.sh --init -->
+<!-- TODO: Replace {{placeholders}} with your project details -->
+
+## Project Overview
+
+{{PROJECT_NAME}} is a {{DESCRIPTION}}.
+
+## Tech Stack
+
+- **Frontend**: <!-- TODO: e.g., Next.js 14, React 18, TypeScript, Tailwind -->
+- **Backend**: <!-- TODO: e.g., FastAPI, SQLAlchemy, PostgreSQL -->
+- **Auth**: <!-- TODO: e.g., Stytch, Auth0, Clerk -->
+- **Deploy**: <!-- TODO: e.g., Railway, Vercel, AWS -->
+
+## Project Structure
+
+```
+{{PROJECT_NAME}}/
+├── frontend/          <!-- TODO: Frontend directory -->
+├── backend/           <!-- TODO: Backend directory -->
+└── ...
+```
+
+## Key Architecture
+
+<!-- TODO: Describe your auth flow, API patterns, database schema, etc. -->
+
+## Local Dev Services
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Service  | Port | Directory | Start Command |
+|----------|------|-----------|---------------|
+| Frontend | <!-- TODO --> | frontend/ | <!-- TODO: e.g., npm run dev --> |
+| Backend  | <!-- TODO --> | backend/  | <!-- TODO: e.g., uvicorn app.main:app --reload --> |
+
+## Test Commands
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| What | Command | Directory |
+|------|---------|-----------|
+| Backend tests | <!-- TODO: e.g., pytest --> | backend/ |
+| Backend lint | <!-- TODO: e.g., ruff check . --> | backend/ |
+| Frontend tests | <!-- TODO: e.g., npm test --> | frontend/ |
+| Frontend lint | <!-- TODO: e.g., npm run lint --> | frontend/ |
+| Type check | <!-- TODO: e.g., npx tsc --noEmit --> | frontend/ |
+| E2E tests | <!-- TODO: e.g., npx playwright test --> | frontend/ |
+
+## Infrastructure
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Platform | Service | Domain |
+|----------|---------|--------|
+| <!-- TODO: e.g., Railway --> | <!-- TODO --> | <!-- TODO --> |
+
+Health endpoints: <!-- TODO: e.g., /health, /api/health -->
+
+## Environments
+
+<!-- TODO: Auto-populated by /scan environments or /calibrate -->
+
+| Name | Type | URL | Health | Deploy | Branch |
+|------|------|-----|--------|--------|--------|
+| local | development | <!-- TODO --> | <!-- TODO: e.g., /health --> | manual | — |
+| <!-- TODO --> | <!-- TODO: staging/production/preview/canary --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> |
+
+Access notes: <!-- TODO: e.g., Railway MCP for staging/prod. Env vars: .env.local, .env.staging -->
+
+## Domain
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+<!-- Describe what this app does, its core entities, and business rules. -->
+<!-- Used by qa-domain agent for domain-aware testing. -->
+
+## Running Locally
+
+```bash
+# TODO: Add your local development commands
+# Frontend
+cd frontend && npm run dev
+
+# Backend
+cd backend && source .venv/bin/activate && uvicorn app.main:app --reload
+```
+
+## Critical Rules
+
+<!-- TODO: Add project-specific rules, e.g.: -->
+- Never push to main directly — always create a PR
+- Secrets in .env.local only — never committed
+
+## Agent Customization
+
+The following agents/skills are managed by `claude-agents` (symlinked):
+- Run `~/.claude-agents/install.sh --status` to see what's linked
+- To override any portable file, replace the symlink with a regular file
+- Your override won't be touched by future syncs
+
+### Project-Specific Agents
+
+Add project-specific agents as regular files in `.claude/agents/`:
+- See `~/.claude-agents/examples/agents/` for templates (frontend, backend, ops, sre, qa)
+
+### Project-Specific Skills
+
+Add project-specific skills as regular directories in `.claude/skills/`:
+- See `~/.claude-agents/examples/skills/` for templates (ci-fix, qa, restart)