agentleFS
axisvelaaxisvela/ea-harness/.claude/skills/arch-req-from-doc/SKILL.md

arch-req-from-doc

Skill15 starsChanged 51 days agoMITView on GitHub

Extract architecture requirements from documents (PDF, DOCX, MD, TXT). Uses LLM to identify physical locations, tech stack, integration points, authentication, and security requirements from unstructured text. Outputs a partial requirements YAML in the req/v2 entity model (infra / systems / components / deployments / flows / network_links / auth). Medium confidence — always verify. Use before arch-req-merge to collect the business context layer.

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always flag missing auth mechanisms — documents almost never specify them.

    line 38
  2. Distinctive:

    If the user uploads or pastes document content in the conversation, extract requirements directly.

    line 57

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

Locating shared resources. References in this file to standards/, tools/, config.yaml, and templates/ are relative to the ArchHarness resource root. Determine the root, in order: (1) the ARCHHARNESS_HOME environment variable, (2) the output of python -m archharness root (the pip-installed package bundles these resources under its data directory), (3) the current working directory when it already contains config.yaml and tools/ (the repository checkout). Prefix shared paths with that root whenever the working directory is not the resource root.

You are an architecture requirements analyst reading documents. Your job is to extract precise, physical architecture information from text documents — not to evaluate or critique the content.

What documents typically contain (and don't)

What documents usually haveWhat documents usually lack
Business purpose and scopeSpecific port numbers
Application namesAuth mechanism details
Vague deployment location ("cloud", "China DC")Exact subnet/zone placement
Ownership and departmentProtocol-level auth
High-level tech stackCredential storage solution
Data sensitivity classificationCross-border compliance details

Extraction from documents is MEDIUM confidence at best. Always flag missing auth mechanisms — documents almost never specify them.

How to invoke the Python tool

cd tools/arch-req-readers

# PDF document
ANTHROPIC_API_KEY=... python from_document.py -i requirements.pdf -o partial-doc.yaml

# Word document
ANTHROPIC_API_KEY=... python from_document.py -i design.docx -o partial-doc.yaml

# Markdown or text
ANTHROPIC_API_KEY=... python from_document.py -i brief.md -o partial-doc.yaml

When a document is uploaded directly in chat

If the user uploads or pastes document content in the conversation, extract requirements directly. Focus on finding:

  1. Project name and purpose (1-2 sentences)
  2. Application names — any system, service, or platform mentioned
  3. Physical location clues — country names, DC names, cloud provider mentions
  4. Technical stack — language, framework, runtime mentions
  5. Integration points — "connects to", "calls", "sends data to" statements
  6. User types — who uses the system
  7. Compliance/security mentions — GDPR, data residency, encryption

Output a partial req/v2 document. The partial model references other entities by name (the merger resolves names to typed IDs). See standards/requirements-model-v2.yaml for the full field list.

project_name: {value: "[extracted]", confidence: medium, source: "document:x.md", note: ""}
infra:            # hosting + network nodes (INF-nn after merge)
  - name: {value: "Hohhot DC"}
    node_kind: {value: "data_center"}
    infra_type: {value: "private_cloud"}
systems:          # applications (APP-nn)
  - name: {value: "[app name from document]"}
    type: {value: "existing"}
components:       # application artefacts only — NEVER an appliance (CMP-nn)
  - system: {value: "[app name]"}
    name: {value: "[component name]"}
    component_role: {value: "backend_service"}
deployments:      # component -> infra (DEP-nn)
  - component: {value: "[component name]"}
    environment: {value: "prod"}
    infra: {value: "Hohhot DC"}
flows:            # directed, component -> component (FLOW-nn)
  - from: {value: "[initiator]"}
    to: {value: "[provider]"}
    protocol: {value: "[if mentioned]"}
    auth_method: {value: "none", note: "Auth mechanism not stated — CRITICAL gap"}
auth:             # user/entry authentication only (AUTH-nn)
  - subject: {value: "user"}
    applies_to: {value: "[entry point]"}
    protocol: {value: "[if mentioned]"}

Remember: firewalls, WAFs, load balancers and identity providers are infra, not components.

Gap flags to always add after document extraction

  • "Auth mechanisms between components not specified in document — CRITICAL"
  • "Physical DC/Zone placement may be vague — verify exact location"
  • "Tech stack versions may be outdated if document is old"

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.