agentleFS
Baba01hacker666Baba01hacker666/dummyskills/skills/field-extractor/SKILL.md

field-extractor

Skill0 starsChanged 2 months agoMITView on GitHub

Extracts specific key-value fields from unstructured documents or logs with explicit missing-value handling.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when:

    line 14
  2. Very specific:

    Do not use to convert entire complex structures to validated JSON.

    line 20
  3. Very specific:

    Do not use to summarize full prose text.

    line 21
  4. Very specific:

    If source_document is missing: stop and ask: "Please provide the document to extract fields from."

    line 28
  5. Very specific:

    If target_field_names is missing: ask: "Which specific fields should be extracted?".

    line 29
  6. Very specific:

    If a field is not found in text: label as MISSING (Not present in text).

    line 30
  7. Distinctive:

    Follow these numbered actions:

    line 33
  8. Distinctive:

    Create an extraction entry for every requested field.

    line 35
  9. Very specific:

    If multiple IP addresses or dates are found and field is singular: label status as AMBIGUOUS and list each candidate with line context.

    line 46
  10. Distinctive:

    Never guess passwords, phone numbers, or emails from missing text.

    line 47
  11. Distinctive:

    Stop and ask the user when:

    line 77

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

Field Extractor

Extracts named fields from unstructured text, incident logs, or support tickets. Assigns explicit status (FOUND, MISSING, AMBIGUOUS) to every requested field with zero hallucination.

1. Purpose

Harvest targeted attributes from text. A "Field" is a specific named variable (e.g. ip_address, error_code, user_id).

2. When to Use

Use this skill when:

  • Pulling specific parameters from server logs or crash traces.
  • Extracting contact details or invoice amounts from emails.
  • User requests: "Extract [fields] from this text."

3. When Not to Use

  • Do not use to convert entire complex structures to validated JSON; use json-schema-converter.
  • Do not use to summarize full prose text; use factual-summarizer.

4. Required Inputs

  • source_document: Text or log snippet to parse.
  • target_field_names: List of specific field names to extract.

5. Missing-Input Behavior

  1. If source_document is missing: stop and ask: "Please provide the document to extract fields from."
  2. If target_field_names is missing: ask: "Which specific fields should be extracted?".
  3. If a field is not found in text: label as MISSING (Not present in text). Do not guess.

6. Procedure

Follow these numbered actions:

  1. Action 1: Enumerate Target Fields
    • Create an extraction entry for every requested field.
  2. Action 2: Scan Document for Exact or Contextual Matches
    • Locate regex patterns, key-value delimiters (:, =), or natural language mentions.
  3. Action 3: Categorize Field Status
    • FOUND: Exact value found; include quotation proof.
    • AMBIGUOUS: Multiple conflicting candidates found; list all candidates.
    • MISSING: No candidate found in text.
  4. Action 4: Emit Extraction Table
    • Format using Section 8.

7. Decision Rules

  • If multiple IP addresses or dates are found and field is singular: label status as AMBIGUOUS and list each candidate with line context.
  • Never guess passwords, phone numbers, or emails from missing text.

8. Output Format

Emit the extracted fields using this structured template:

### Extracted Fields Summary

| Field Name | Status | Extracted Value | Evidence / Context |
| :--- | :--- | :--- | :--- |
| `[field_1]` | **FOUND** | `[value]` | "[Context snippet]" |
| `[field_2]` | **MISSING** | *null* | *Not mentioned in source text.* |
| `[field_3]` | **AMBIGUOUS** | `[cand_1], [cand_2]` | Found 2 matches on lines 4 and 12 |

#### Extraction Statistics
- **Requested**: [Count] | **Found**: [Count] | **Missing**: [Count] | **Ambiguous**: [Count]

9. Verification Checklist

  • Every requested field is present in the table.
  • Missing fields are explicitly marked as null / MISSING.
  • Evidence quotes confirm each FOUND value.
  • No values were hallucinated.

10. Common Failures and Recovery

Failure SymptomCauseRecovery Action
Guessing missing valuesFilling gaps from common senseEnforce strict rule: if no quote exists, mark MISSING.
Picking arbitrary candidateAmbiguous repeated fieldsMark AMBIGUOUS and list line numbers.

11. Stop or Escalation Conditions

Stop and ask the user when:

  • Source document is unparseable binary.

12. Examples

Example 1: Successful Execution

Input:

Document: "Failed login attempt from IP 192.168.1.50 for user admin at 2026-09-10T08:14:22Z with error code ERR_INVALID_PASS."
Fields: ip_address, username, error_code, retry_count

Output:

### Extracted Fields Summary

| Field Name | Status | Extracted Value | Evidence / Context |
| :--- | :--- | :--- | :--- |
| `ip_address` | **FOUND** | `192.168.1.50` | "...from IP 192.168.1.50..." |
| `username` | **FOUND** | `admin` | "...for user admin..." |
| `error_code` | **FOUND** | `ERR_INVALID_PASS` | "...with error code ERR_INVALID_PASS." |
| `retry_count` | **MISSING** | *null* | *Not mentioned in source text.* |

#### Extraction Statistics
- **Requested**: 4 | **Found**: 3 | **Missing**: 1 | **Ambiguous**: 0

Example 2: Ambiguous or Missing Input

Input:

Document: "Invoice total is $500, with a discount of $50 leaving $450 due."
Fields: amount

Output:

### Extracted Fields Summary

| Field Name | Status | Extracted Value | Evidence / Context |
| :--- | :--- | :--- | :--- |
| `amount` | **AMBIGUOUS** | `$500, $50, $450` | Multiple dollar amounts found (total, discount, amount due). |

#### Extraction Statistics
- **Requested**: 1 | **Found**: 0 | **Missing**: 0 | **Ambiguous**: 1

Example 3: Expected Final Output

Output:

### Extracted Fields Summary

| Field Name | Status | Extracted Value | Evidence / Context |
| :--- | :--- | :--- | :--- |
| `order_id` | **FOUND** | `ORD-9901` | "Order reference ORD-9901 confirmed." |
| `tracking_number` | **MISSING** | *null* | *Shipment not yet initiated; no tracking number.* |

#### Extraction Statistics
- **Requested**: 2 | **Found**: 1 | **Missing**: 1 | **Ambiguous**: 0

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.