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

re-specialize

Skill4 starsChanged 5 months agoMITView on GitHub

Incremental re-specialization — re-scans the project and updates only auto-generated zones in CLAUDE.md and agents

Reads credentials

In this repository8 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- build-featureSkill
- councilSkill
- create-prSkill
- debugSkill
- guild-specializeSkill
- qa-cycleSkill
- tddSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 11 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
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

Distinctive:
When project dependencies have changed (new framework, updated versions)
line 56
Distinctive:
When architecture has evolved (new patterns, restructured folders)
line 57
Distinctive:
When agents need refreshed context about the project
line 58
Very specific:
Read CLAUDE.md and all agent files in .claude/agents/:
line 65
Distinctive:
Check environment variable examples
line 78
Distinctive:
If CLAUDE.md has zone markers, proceed to regeneration.
line 82
Distinctive:
If CLAUDE.md does NOT have zone markers (legacy project):
line 84
Distinctive:
If user declines, abort gracefully
line 89
Distinctive:
Only replace zones where content has actually changed
line 98
Very specific:
If no agent-context zone exists, append one at the bottom
line 114
Distinctive:
Commit all changes as an atomic commit:
line 137
Distinctive:
NEVER modify content outside of zone markers
line 146
Very specific:
NEVER read real .env files -- only .env.example
line 147
Distinctive:
If a zone's content hasn't changed, skip it (no-op)
line 148

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

Re-Specialize

Incrementally updates auto-generated content in CLAUDE.md and agent files without touching user customizations. Uses protected zone markers to identify what can be safely regenerated.

When to use

When project dependencies have changed (new framework, updated versions)
When architecture has evolved (new patterns, restructured folders)
When agents need refreshed context about the project
Periodically to keep CLAUDE.md in sync with the actual codebase

Process

Step 1 -- Read current state

Read CLAUDE.md and all agent files in .claude/agents/:

Identify existing zone markers ( / )
Note which zones exist and their current content
Identify any user customizations outside of zones

Step 2 -- Explore the project

Same exploration as guild-specialize:

Scan dependency files for current stack and versions
Analyze project structure and architecture patterns
Detect code conventions from linter/formatter configs
Check environment variable examples

Step 3 -- Check zone markers

If CLAUDE.md has zone markers, proceed to regeneration.

If CLAUDE.md does NOT have zone markers (legacy project):

Offer to inject markers around the auto-generated sections
Show the user where markers would be placed
Require explicit confirmation before modifying
If user declines, abort gracefully

Step 4 -- Regenerate zone content

Invoke the Tech Lead agent using Task tool with model: "opus" (reasoning tier):

Generate fresh content for each zone based on the project scan
Compare new content with existing zone content
Present a diff for each zone to the user
Only replace zones where content has actually changed

Zones to regenerate:

Zone ID	Content
`structure`	Project folder structure with descriptions
`architecture`	Architecture patterns and design decisions
`conventions`	Code conventions from linter/formatter
`env-vars`	Environment variables from .env.example

Step 5 -- Update agent context

Invoke the Tech Lead agent using Task tool with model: "sonnet" (execution tier):

For each agent in .claude/agents/*.md, update the agent-context zone
If no agent-context zone exists, append one at the bottom
Preserve everything outside the zone (role definition, process, rules)

Step 6 -- Confirm changes

Present a summary:

Re-specialization complete for [project-name]

Zones updated:
- structure: [changed/unchanged]
- architecture: [changed/unchanged]
- conventions: [changed/unchanged]
- env-vars: [changed/unchanged]

Agents updated: [count] of [total]

Review the changes above. Confirm to commit.

Step 7 -- Commit

Commit all changes as an atomic commit:

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

Important Notes

NEVER modify content outside of zone markers
NEVER read real .env files -- only .env.example
If a zone's content hasn't changed, skip it (no-op)
Present diffs before applying changes
User confirmation is required before committing

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