skills.rest
mathiasbourgoin
mathiasbourgoinCOMMUNITY
Explore all skills by this author →
GitHub

roster-spec-infer

Infer behavioral specifications from codebases by mining tests, source, and git history.

2|2|Updated Mar 17, 2026
Search Tags:#code analysis#functional requirements#documentation drift#gap detection#evidence tiering#spec inference#legacy code analysis
One-click install
npx skills add https://github.com/mathiasbourgoin/roster --skill roster-spec-infer
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: roster-spec-infer
Source: https://github.com/mathiasbourgoin/roster/tree/main/.opencode/skills/roster-spec-infer
Command: npx skills add https://github.com/mathiasbourgoin/roster --skill roster-spec-infer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Undocumented legacy code and mismatched documentation create development risk by hiding actual system behavior, leaving untested public surfaces unmarked, and allowing doc drift to lead to incorrect implementation assumptions.

Core Features & Use Cases

  • Evidence-Tiered Claim Labeling: Every behavioral claim is tagged [E1] (test-proven), [E2] (code-inferred), or [E3] (doc-only) to clearly communicate confidence levels.
  • Conflict & Gap Detection: Automatically surfaces mismatches between code and documentation (doc drift) and identifies untested public API symbols that lack test coverage.
  • Formal Requirements Generation: Converts verified claims into structured functional requirements (FR-NNN) with clear MUST/SHOULD language tied to source evidence.
  • Use Case: Use this skill when onboarding to a legacy codebase with no up-to-date specs, or when auditing an existing system to verify that documentation matches actual implementation.

Quick Start

Use the roster-spec-infer skill to generate a complete evidence-tiered inferred spec for the legacy project located at the path you provide.

Frequently Asked Questions about roster-spec-infer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reverse-engineer functional requirements from legacy code with no documentation?▼

Reverse-engineering functional requirements from legacy code involves mining test suites, implementation source code, and git commit history to generate evidence-tiered behavioral specifications. This process produces formal requirements with verifiable source evidence, making undocumented modules safe to onboard and maintain.

What is documentation drift and how do I detect conflicts between code and specs?▼

Documentation drift occurs when actual code behavior diverges from written specs or comments. You can detect these conflicts by automatically surfacing mismatches between implementation source code and existing documentation during a legacy system audit, ensuring implementation assumptions match reality.

How to generate inferred specs from source code and test suites for an undocumented module?▼

To generate inferred specs, analyze the legacy project path to mine test suites and implementation source code. The system produces evidence-tiered, confidence-labeled behavioral claims, identifying untested public API gaps and generating formal functional requirements tied directly to verifiable source evidence.

Can I identify untested public API gaps in a legacy codebase during an audit?▼

Yes, identifying untested public API gaps is a core part of legacy code analysis. By mining the codebase and test suites, the analysis automatically surfaces public API symbols that lack test coverage, reducing development risk and highlighting areas needing immediate verification.

What's the best way to verify post-integration behavior matches the original implementation?▼

The best way to verify post-integration behavior is through behavioral verification workflows that generate evidence-tiered claims. By tagging claims as test-proven, code-inferred, or doc-only, you clearly communicate confidence levels and ensure formal requirements match the actual implementation.

What do evidence tiering labels like E1, E2, and E3 mean in spec inference?▼

Evidence tiering labels communicate the confidence level of behavioral claims: E1 means test-proven, E2 means code-inferred, and E3 means doc-only. This labeling ensures generated functional requirements are tied to verifiable source evidence for accurate legacy system audits.

Related Skills

Explore More Software Engineering Skills→
leogodin217leogodin217
60

review-sprint

Audit code changes for dead code, test naming, and spec drift.

Community
Advanced
trotsky1997trotsky1997
6

cursor-ide-browser-skills

Automate browser interactions in Cursor IDE via MCP protocol.

Community
Basic
gkganesh12gkganesh12
1

gk-review

Audit source code against documentation and test suites for architectural drift.

Community
Advanced
sequenziasequenzia
2

inverted-spec

Reverse-engineer codebases into provenance-annotated SDD pipeline specifications.

Community
Advanced