agentleFS
scholayscholay/skills/source-intake/SKILL.md

source-intake

Skill141 starsChanged 5 months agoMITView on GitHub

Organize, classify, and register raw research materials into a stable, trackable source layer. Use when processing newly collected PDFs, archives, image folders, or mixed downloads; assigning stable IDs; maintaining intake manifests; or deciding what type of object each material is before any processing begins.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. Arch1eSUN/Arcgentic★ 286same name
    2. Sunnyshinnny776/pm-agentic-cookbook★ 2same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository4 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 12 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    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
  1. Distinctive:

    Before assigning an ID to anything, classify it:

    line 16
  2. Distinctive:

    Before doing anything else, list what you have and where it came from.

    line 32
  3. Distinctive:

    Update these manifests after expansion:

    line 38
  4. Distinctive:

    Before assigning a new ID, check whether this item is already registered.

    line 45
  5. Distinctive:

    Keep both IDs in your manifest so the chain from raw to processed is always traceable.

    line 54
  6. Distinctive:

    Create one clean, stable copy of each source object:

    line 58
  7. Distinctive:

    Image group: document the group strategy before doing anything else (will this become a derived PDF, or stay as individual images?)

    line 60
  8. Distinctive:

    If you generate page images, OCR text, or other derivatives from a source object, record them in a separate manifest — not in the raw …

    line 66
  9. Distinctive:

    Never rename or overwrite files in the raw layer.

    line 70
  10. Distinctive:

    Do not register a source object before checking for duplicates.

    line 71
  11. Distinctive:

    Do not force image groups into PDF form by default — decide the handling strategy first.

    line 72
  12. Distinctive:

    Do not force datasets, license files, or ambiguous objects into PDF form.

    line 73
  13. Very specific:

    If a source is ambiguous, mark it status: pending_decision rather than guessing.

    line 76
  14. Very specific:

    Read references/naming-conventions.md for ID formats, filename patterns, and status vocabulary.

    line 92
  15. Very specific:

    Read references/archive-first.md for why archive expansion must come before registration, and common mistakes when skipping it.

    line 93

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

Source Intake

The core problem

Research materials accumulate in chaotic ways: some arrive as standalone PDFs, some inside zip archives, some as image folders, some as web pages saved to disk. Processing them without first understanding what you have creates a false baseline — you think you've ingested everything when the most important items are still locked inside a zip file.

Rule zero: expand all archives before claiming anything is ingested.

Object types

Before assigning an ID to anything, classify it:

TypeDescription
source_pdfA PDF that can be processed directly
derived_pdfA PDF you generate from images, scans, or web pages
image_groupA folder of images that form a logical unit (scanned pages, figures)
datasetStructured data files (CSV, XLSX, JSON, GIS)
reference_fileRights, permissions, licenses, or metadata files
archiveZIP, RAR, or other compressed container — expand first, then classify contents
ambiguousNeeds a decision before it can be registered

Workflow

1. Inventory before touching

Before doing anything else, list what you have and where it came from. Keep a raw inventory file. Do not rename or move anything in the raw layer.

2. Expand all archives

Expand every archive into a staging area. Note the parent archive ID for each extracted file so you can trace it back later.

Update these manifests after expansion:

  • expanded_inventory — what came out of which archive
  • pending_pdf_candidates — PDFs waiting for registration
  • pending_image_groups — image folders waiting for a handling decision

3. Check for duplicates

Before assigning a new ID, check whether this item is already registered. Match on: DOI or URL first → title + year → manual review.

4. Assign stable IDs

Once an item is confirmed unique and classified, assign a stable ID. Recommended format:

  • Raw objects: RAW-#### (source as received, untouched)
  • Processed source objects: SRC-#### (stable, normalized copy)

Keep both IDs in your manifest so the chain from raw to processed is always traceable.

5. Normalize

Create one clean, stable copy of each source object:

  • PDF: copy with a stable filename into your normalized folder
  • Image group: document the group strategy before doing anything else (will this become a derived PDF, or stay as individual images?)
  • Dataset: register and note the format; do not force into PDF
  • Web page: preserve the URL and access date; create a PDF capture if needed

6. Record derivatives separately

If you generate page images, OCR text, or other derivatives from a source object, record them in a separate manifest — not in the raw inventory. Keep the chain: raw → normalized → derivative.

Rules

  • Never rename or overwrite files in the raw layer. All transformations happen in a separate staging or working layer.
  • Do not register a source object before checking for duplicates.
  • Do not force image groups into PDF form by default — decide the handling strategy first.
  • Do not force datasets, license files, or ambiguous objects into PDF form.
  • Manifests must make parent–child relationships explicit (which archive did this PDF come from?).
  • Record the source before generating any derivatives.
  • If a source is ambiguous, mark it status: pending_decision rather than guessing.

Manifest minimum fields

For each registered source object, record at minimum:

  • stable ID (SRC-####)
  • object type (from the type table above)
  • original raw path
  • normalized/working path
  • parent raw ID (if from an archive)
  • language
  • status
  • notes

References

  • Read references/naming-conventions.md for ID formats, filename patterns, and status vocabulary.
  • Read references/archive-first.md for why archive expansion must come before registration, and common mistakes when skipping it.

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.