agentleFS
leaf76leaf76/agent-skills/deep-init/SKILL.md

deep-init

Skill0 starsChanged 3 months agoMITView on GitHub

Inspect a repository and plan or draft a project-specific AGENTS.md using evidence from manifests, commands, CI files, architecture hints, and existing guidance docs. Use when bootstrapping agent instructions for a new project, refreshing stale AGENTS.md rules after repo changes, or when a user wants repo-grounded working rules instead of a generic template.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 8 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    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:

    Default to the current working directory unless the user points to another repo.

    line 15
  2. Very specific:

    Use --format json when you need machine-readable output for follow-up processing or tests.

    line 23
  3. Distinctive:

    Treat the inventory as a map for what to inspect next, not as the final answer.

    line 24
  4. Very specific:

    Read only the files supported by those signals: root docs, manifests, CI files, lint/type/test configs, existing guidance docs, and the …

    line 25
  5. Distinctive:

    Keep rules operational and repo-specific.

    line 28
  6. Distinctive:

    Only include commands that are confirmed by manifests, scripts, or CI configuration.

    line 29
  7. Distinctive:

    Keep planning and explanations in Traditional Chinese unless the repo clearly standardizes another documentation language.

    line 57
  8. Distinctive:

    Keep generated AGENTS.md content in the repo's documentation language when obvious.

    line 58
  9. Distinctive:

    Never invent commands, owners, deployment steps, or hidden process requirements.

    line 59
  10. Distinctive:

    Never weaken existing security, validation, or change-safety rules without explicit user instruction.

    line 60
  11. Very specific:

    Use scripts/project_inventory.py to summarize manifests, languages, framework hints, commands, CI files, and AGENTS-relevant risk notes.

    line 64
  12. Very specific:

    Use references/agents-outline.md when turning repo signals into concrete AGENTS.md sections.

    line 65
  13. Very specific:

    Use scripts/test_project_inventory.py to regression-check the inventory logic after changes.

    line 66

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

Deep Init

Overview

Inspect the target repository before writing guidance. Start from repo facts, not generic policy boilerplate, and turn those facts into a concise AGENTS plan or draft.

Workflow

  1. Set the target root.
  • Default to the current working directory unless the user points to another repo.
  • Decide whether the request is:
    • planning only
    • creating a new AGENTS.md
    • updating an existing AGENTS.md
  1. Gather repo evidence first.
  • Resolve scripts/project_inventory.py relative to this skill directory, then run python3 <that-path> <repo-root> before drafting anything.
  • Use --format json when you need machine-readable output for follow-up processing or tests.
  • Treat the inventory as a map for what to inspect next, not as the final answer.
  • Read only the files supported by those signals: root docs, manifests, CI files, lint/type/test configs, existing guidance docs, and the most relevant top-level app or service directories.
  1. Convert evidence into AGENTS rules.
  • Keep rules operational and repo-specific.
  • Only include commands that are confirmed by manifests, scripts, or CI configuration.
  • Separate repo-wide policy from workspace-specific notes when monorepo signals exist.
  • Preserve stronger existing instructions instead of weakening or rewriting them.
  • Explicitly call out uncertainty when evidence is missing or contradictory.
  1. Shape the output to the request.
  • For planning-only requests, return:
    • evidence summary
    • proposed AGENTS.md sections
    • repo-specific risks or gaps
    • open questions that genuinely block a safe draft
  • For drafting requests, keep the file concise and include only the sections the repo actually needs.

Default Sections

  • Purpose and scope
  • Repo snapshot
  • Workflow policy
  • Change safety
  • Verified commands
  • Domain guardrails
  • Validation baseline
  • Repo-specific notes

Skip sections that are not supported by repo evidence. Add workspace boundaries only when the repo shows monorepo or multi-service structure.

Output Rules

  • Keep planning and explanations in Traditional Chinese unless the repo clearly standardizes another documentation language.
  • Keep generated AGENTS.md content in the repo's documentation language when obvious; otherwise default to English for compatibility with agent tooling.
  • Never invent commands, owners, deployment steps, or hidden process requirements.
  • Never weaken existing security, validation, or change-safety rules without explicit user instruction.

Resources

  • Use scripts/project_inventory.py to summarize manifests, languages, framework hints, commands, CI files, and AGENTS-relevant risk notes.
  • Use references/agents-outline.md when turning repo signals into concrete AGENTS.md sections.
  • Use scripts/test_project_inventory.py to regression-check the inventory logic after changes.

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.