agentleFS
Guild-AgentsGuild-Agents/guild/.claude/skills/guild-specialize/SKILL.md

guild-specialize

Skill4 starsChanged 5 months agoMITView on GitHub

Enriches CLAUDE.md by exploring the project and specializes agents to the real stack

  • Reads credentials

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 6 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a new stack is added to the project (new database, new framework)

    line 51
  2. Distinctive:

    When the project structure has changed significantly

    line 52
  3. Very specific:

    Read the Guild configuration files:

    line 58
  4. Distinctive:

    Do NOT modify content outside of zone markers (user-owned sections)

    line 116
  5. Very specific:

    If markers are missing (legacy project), replace [PENDING: guild-specialize] placeholders directly

    line 117
  6. Distinctive:

    When specializing agents, append a zone at the bottom of each agent file:

    line 130
  7. Very specific:

    Use the Task tool with model: "sonnet" to invoke each agent by reading their .claude/agents/[name].md if you need a specialized perspective …

    line 143
  8. Distinctive:

    CRITICAL: After enriching CLAUDE.md and agent files, commit the changes immediately as their own atomic commit.

    line 169
  9. Very specific:

    NEVER read real .env files — only .env.example or .env.local

    line 206
  10. Distinctive:

    If you cannot detect something with certainty, ask the user instead of assuming

    line 207
  11. Very specific:

    NEVER use git stash in automated pipelines — use wip: commits instead

    line 210

≈ “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.

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

Guild Specialize

Explores the user's real project and enriches the entire Guild configuration with concrete information about the detected stack, architecture, and conventions.

This skill runs once after guild init. It transforms generic placeholders into real project information.

When to use

  • Immediately after running guild init
  • When a new stack is added to the project (new database, new framework)
  • When the project structure has changed significantly

Process

Step 1 — Read base context

Read the Guild configuration files:

  • CLAUDE.md — current instructions (contains [PENDING: guild-specialize] placeholders)
  • PROJECT.md — identity and stack declared during init

Step 2 — Explore the real project

Investigate the real project structure looking for:

Dependencies and versions:

  • package.json (Node.js/frontend)
  • pom.xml or build.gradle (Java)
  • requirements.txt or pyproject.toml (Python)
  • Gemfile (Ruby)
  • go.mod (Go)
  • Cargo.toml (Rust)

Architecture and structure:

  • Folders src/, app/, lib/, pkg/, internal/
  • Organization pattern: by layers, by features, by domain
  • Project entry points

Configuration and conventions:

  • tsconfig.json, eslint.config.*, .prettierrc
  • .env.example, .env.local (environment variables — do NOT read real .env)
  • Dockerfile, docker-compose.yml
  • CI/CD: .github/workflows/, .gitlab-ci.yml

Database and migrations:

  • Folder migrations/, db/, prisma/, drizzle/
  • Configured ORM or query builder
  • Existing schema

Existing documentation:

  • README.md — project overview
  • Internal documentation in docs/

Step 3 — Enrich CLAUDE.md

Invoke the Tech Lead agent using Task tool with model: "opus" (reasoning tier) to replace all [PENDING: guild-specialize] placeholders in CLAUDE.md with real information:

  • Stack with exact versions: extracted from dependency files
  • Folder structure explained: what each main folder does
  • Detected code conventions: linter, formatter, import style
  • Identified architecture patterns: MVC, hexagonal, modular, etc.
  • Known environment variables: listed from .env.example
  • Visible limitations and technical debt: outdated dependencies, TODOs found
  • Useful project commands: detected npm/make/cargo scripts

CLAUDE.md now uses zone markers (<!-- guild:auto-start:ID --> / <!-- guild:auto-end:ID -->) to delimit auto-generated sections. When enriching:

  • Replace content BETWEEN the markers, preserving the markers themselves
  • The following zones exist: structure, architecture, conventions, env-vars
  • Do NOT modify content outside of zone markers (user-owned sections)
  • If markers are missing (legacy project), replace [PENDING: guild-specialize] placeholders directly

Step 4 — Specialize agents

Invoke the Tech Lead agent using Task tool with model: "sonnet" (execution tier) to add project-specific context for each agent in .claude/agents/*.md:

  • advisor.md: real project domain, target users
  • tech-lead.md: specific stack, detected patterns, architecture decisions
  • developer.md: code conventions, main framework, file structure
  • code-reviewer.md: lint rules, project patterns, anti-patterns to watch
  • qa.md: testing framework, commands to run tests, current coverage
  • bugfix.md: debugging stack, logs, available tools

When specializing agents, append a zone at the bottom of each agent file:

<!-- guild:auto-start:agent-context -->
## Project-Specific Context
- Stack: [detected stack]
- Architecture: [detected patterns]
- Conventions: [detected conventions]
<!-- guild:auto-end:agent-context -->

This zone allows guild-re-specialize to update agent context later without touching the agent's core role definition.

Use the Task tool with model: "sonnet" to invoke each agent by reading their .claude/agents/[name].md if you need a specialized perspective to enrich their configuration.

The model parameter is resolved from the step's model-tier: reasoning→"opus", execution→"sonnet". System/gate steps run inline (no Task tool).

Step 5 — Confirm

Present a summary of what was detected:

Guild v1 specialized for [project-name]

Detected stack:
- [list of technologies with versions]

Architecture:
- [identified pattern]
- [main structure]

Updated agents:
- [list of agents with their applied specialization]

Use /resume or /build-feature to continue work.

Step 6 — Commit enrichment immediately

CRITICAL: After enriching CLAUDE.md and agent files, commit the changes immediately as their own atomic commit. Do NOT leave them as unstaged changes — they are vulnerable to git stash and other operations.

git add CLAUDE.md .claude/agents/*.md
git commit -m "chore: enrich CLAUDE.md and agents via guild-specialize"

This ensures enrichment survives any subsequent git operations (stash, checkout, rebase).

Example Session

User: /guild-specialize

Guild Specialize analyzing project...

Tech Lead (opus) — Enriching CLAUDE.md...
Stack detected:
- Node.js 20.11.0, TypeScript 5.3.3
- React 18.2.0, Next.js 14.1.0
- PostgreSQL via Prisma 5.9.0

Architecture:
- Next.js App Router (src/app/)
- API routes in src/app/api/
- Shared components in src/components/

Tech Lead (sonnet) — Specializing agents...
Agents updated:
- developer.md: Specialized for Next.js + TypeScript
- qa.md: Configured for Vitest + Playwright

Use /resume or /build-feature to continue work.

Important Notes

  • NEVER read real .env files — only .env.example or .env.local
  • If you cannot detect something with certainty, ask the user instead of assuming
  • Prioritize accuracy over completeness — it is better to say "not detected" than to fabricate
  • Agents should be specialized to the real stack, not generic
  • NEVER use git stash in automated pipelines — use wip: commits instead
  • CLAUDE.md changes must always be committed separately from feature code

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.