software
Skill10 starsChanged 4 days agoMITView on GitHub
Software engineering research. Use when the user invokes /software or asks for software engineering research — technical landscape and architecture investigations, framework/library/methodology comparison, protocol or standards research, security best-practice verification, reproducibility audits of a codebase or paper-vs-code claims, API and system design prior art. Dispatches to the shared engineering-research method with the software evidence landscape.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- matheusflorindo32/apex-elite-frameworktheir own version, first seen Jul 19, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- matheusflorindo32/apex-elite-framework★ 0same 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 repository28 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- architecturalSkill
- artifact-readingSkill
- auditSkill
- civilSkill
- compareSkill
- design-alternativesSkill
- electricalSkill
- eli5Skill
- engineering-researchSkill
- evidence-rankingSkill
- fmea-brainstormSkill
- gap-analysisSkill
- habitSkill
- hypothesis-generationSkill
- mechanicalSkill
- peer-reviewSkill
- proposalSkill
- research-to-postSkill
- reviewSkill
- scholarly-researchSkill
- simplified-technical-englishSkill
- standards-lookupSkill
- summarizeSkill
- verifierSkill
- vitruvius-helpSkill
- vitruviusSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is 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.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 43
Claims about code: read the code or the official doc before describing behavior.
- Distinctive: line 57
Follow the method's artifact contract.
- Very specific: line 69
If research hits an evidence dead-end — no standard, paper, codebase, or dataset addresses the question after exhausting the discovery …
≈ “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.
Files
<!-- VITRUVIUS-COMPILED-SKILL:BEGIN v1 sha256=e2bbd775b4bd49689f0f2f4b0cf9f683bcae390a9e194eb486a00edf1f9b5e75 -->Software Engineering Research
Activate the /skill:engineering-research method and run it with this
domain payload. Do not restate the research loop here.
Evidence landscape
- Primary sources: official documentation, language/library/framework specs and RFCs, source repositories, issue trackers, release notes, vendor docs, published benchmarks with a reproducible methodology.
- Standards bodies: IETF RFCs, W3C, ISO/IEC, IEEE, NIST — cite the exact document + section when one governs.
- Prior art: public codebases (read the actual code before describing
it), architectural decision records, well-cited engineering blogs,
peer-reviewed systems literature. For papers and academic prior art, use
the
/skill:scholarly-researchdiscovery layers (OpenAlex, Semantic Scholar, arXiv). - Accept with caveats: established trade press and secondary summaries. Deprioritize undated posts, listicles, and social media without primary links.
Verification criteria
- Claims about code: read the code or the official doc before describing behavior. A repo exists ≠ a feature exists — verify in the source.
- Version specificity: claims must name the version, commit, or release
they were checked against. Unversioned claims are
inferred. - Benchmarks: a number must trace to a reproducible methodology — harness, hardware, dataset, date. "Verified faster" is not a claim.
- Security: any security claim must name the exact CVE, advisory, or standard (CWE, OWASP) and the version range it applies to.
- Paper-vs-code audits: compare claimed methods, defaults, metrics, and data handling against the actual code; call out missing code, mismatches, ambiguous defaults, and reproduction risks.
Deliverable shape
Follow the method's artifact contract. In the final artifact, end with a
Sources section of URLs (repo, doc, RFC, advisory), each annotated with
what was checked (e.g. "read §2.3 of the spec" or "verified in commit
abc1234"), and mark every claim verified, inferred, or blocked.
Invocation Flags
Accept --deep and --quick flags and pass them through to the
engineering-research method. See that skill for flag semantics.
Gap Detection
If research hits an evidence dead-end — no standard, paper, codebase, or
dataset addresses the question after exhausting the discovery layers — suggest
running /gap-analysis software <sub-topic> to formally validate and document
the gap. Do not invoke gap-analysis automatically; offer it as a next step and
wait for the user to confirm.
Scope and Boundaries
- This skill produces research — it does NOT produce final designs or implementation guidance.
- Research-only, not for final engineering sign-off. Licensed engineers must review and approve any design based on this research.
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
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.