Eighteen source types feed 22 output targets
Skill Seekers accepts 18 kinds of input, including documentation sites, GitHub repositories, local code, PDFs, office documents, notebooks, videos, wikis, and exported chats. It organizes the extracted material and can package it for 22 destinations. Those destinations include assistant skills, RAG frameworks, and vector databases. The useful idea is reuse: a team can prepare a source once, then emit formats for Claude, OpenAI, LangChain, Qdrant, or another listed target without writing a converter for every pairing.
The breadth comes with a large surface. The README lists 19 installable coding agents and an MCP server with 40 tools. Optional extras cover browsers, video processing, several document types, cloud storage, and vector databases. Core commands also scan project manifests and sampled imports, enhance generated material through an API or local agent, score output, package archives, and upload them. Buyers should start from one exact workflow, because installing every extra turns a document utility into a sizeable Python application.
The 44-second install is only the entry price
Our sandbox installed 148 packages in 44 seconds and occupied 328 MB. The source checkout already contained 3,192 files, about 190,706 lines, and 38.9 MB at commit f3972ef. Building took another 9 seconds. That is acceptable for a development tool, although it is far more machinery than MarkItDown if the task is simply turning a PDF or presentation into Markdown. Skill Seekers earns the extra weight only when its packaging and repeated-source workflows save custom glue code.
Python 3.10 or newer and Git cover the base route, while many advertised inputs need their own extras. The full video path brings transcription, scene detection, OCR, and a GPU-aware setup step. Confluence, Notion, Slack, cloud storage, browser rendering, and vector stores each add packages or remote services. AI editing needs a provider credential or a supported local agent command. A GitHub token is optional for public repositories, but the environment guide says it raises API limits and enables private access.
What happened when we ran it
Our run built successfully in 9 seconds after the 44-second install. Pytest then ran for 837 seconds and exited with code 1. Its summary reported 4,058 passed, 14 failed, 125 skipped, and 16 collection or setup errors out of 4,088 tests. This was a substantial amount of passing coverage, yet the checkout did not produce a clean test result in the stated fresh Debian container. Calling the suite healthy would erase the failures that a maintainer would have to investigate.
The final log lines repeatedly showed KeyError: getpwuid(): uid not found: 1000. Those errors appeared in git-source end-to-end cases, MCP tool cases, and marketplace-publisher tests. We measured the project in an unprivileged container with 3 CPUs, 8 GB of RAM, no secrets, and the Python 3.12 Bookworm uv image. The log supports the missing UID lookup as the immediate error and nothing further. Pip-audit also reported 37 known vulnerabilities in the installed environment.
Unified PDF output can succeed while losing references
Open issue 453 describes a v3.9.1 unified build containing 19 PDFs and 20 EPUB files. The command reportedly exited successfully, while the final PDF reference directory held only an index and none of the extracted document files. The reporter found the PDF text in the cache and traced the loss to the final assembly stage. That is especially risky here because a polished generated skill can hide missing evidence. Teams should compare source counts, reference files, and citations before accepting an archive.
The report is narrow enough to act on. It concerns unified multi-source assembly, while single-source extraction reportedly retained the expected text. The supplied workaround copied cached references into a hand-built tree. A prospective user can therefore test the same boundary with a small fixture: mix two source types, inspect the packaged reference folders, and check that generated prose points back to real material. Exit code 0 alone did not protect the reported v3.9.1 workflow from incomplete output.
The 40-tool MCP server should stay behind trusted access
Open issue 462 reports path traversal in the git URL mode of the MCP fetch_config tool. The report says a crafted config name can escape the cache path and affect directories allowed by the server process. Pull request 464 proposes name validation, but both the issue and fix were still open when fetched. Anyone running the HTTP transport should verify the code they deploy, bind it deliberately, and add network access controls instead of treating the documented health endpoint as a security boundary.
The release history shows maintainers do respond to operational breakage. Version 3.9.1 fixed an MCP image that had begun installing an incompatible 2.x SDK and added a readiness loop with log output. The same release repaired 92 relative documentation links and corrected several stale command and target counts. That work is useful evidence of maintenance. It also shows why pinning a release and testing the exact MCP image matters more than copying a command from an older guide.
September activity is healthy, while the open queue still matters
GitHub recorded the last push on September 6, 2026, and an open pull request was updated on September 7. The repository had 14,939 stars and 56 combined issues and pull requests when fetched. The latest release, v3.9.1, arrived on August 3 and was described as documentation and infrastructure work with no runtime-code change. Taken together, those dates show current development rather than a dormant tag, while the security and output-integrity reports remain part of an adoption review.
Skill Seekers makes sense when several source formats must become several AI-ready outputs and one team owns the verification step. The 4,058 passing tests show serious coverage, but the 14 failures, 16 setup errors, and 37 audit findings keep it out of the install-and-forget category. Trial it on representative private copies, inspect every produced reference tree, pin provider and package choices, and expose the MCP server only after the open path-handling question is settled in your deployed revision.