Opensourcefaq
Answer open-source product questions by combining local source-code and documentation...
Install
npx skills add digoal/blog --skill opensourcefaq -g -a claude-code -y- Repository
- digoal/blog8.6k
- Category
- Writing
- Updated
- 3d ago
- License
- GPL-2.0
- Context cost
- Mediumabout 1,946 tokens
- Runs scripts
- No, instructions only
What it does
Answer open-source product questions by combining local source-code and documentation research, project framework notes generated by init, DeepWiki repository knowledge, and current web evidence, then save a sourced, diagram-rich Markdown answer to the current project's markdown directory. Use when the user asks about behavior, architecture, internals, configuration, APIs, troubleshooting, performance, operations, extension points, practical reproduction, or version-specific details of one or more open-source projects and provides the question, all relevant local source directories, and DeepWiki repoName values.
Opensourcefaq
Overview
Use this skill to produce a verified, source-backed, diagram-rich Markdown answer for questions about open-source products. Require the user to provide the question, every relevant project source directory, and the corresponding DeepWiki repoName values; remind them to clone the source first and run init to generate project framework notes before using the skill.
Inputs
Confirm these inputs before writing the final article:
question: the exact technical question to answer.source_dirs: absolute paths to all open-source project checkouts involved.deepwiki_repo_names: DeepWiki repoName values such asowner/repofor each relevant project.version_context: branch, tag, commit, release, or product version if the answer depends on version-specific behavior.
If any required input is missing, ask for it. If only the version context is missing, inspect the local checkout with git -C <dir> rev-parse --abbrev-ref HEAD, git -C <dir> rev-parse HEAD, and release files when useful, then state the inferred version and its limits.
Workflow
-
Restate the question and scope.
- Identify the involved projects, versions, modules, configuration, and runtime assumptions.
- Split broad questions into concrete subquestions that can be checked against source code.
-
Analyze the problem.
- Form hypotheses from the user's wording, known architecture, and likely code paths.
- Name ambiguity early instead of silently choosing one interpretation.
- Prefer the simplest explanation that source code and docs support.
