本文へ移動
cccskills
無料GitHub で公開

spec-mining

Apply this opinionated workflow when reverse-engineering legacy or undocumented systems: scope, explore the code, trace data flows, document in EARS format, flag uncertainties. For code archaeology, onboarding, and requirements extraction.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md3.0 KB
  • references/specification-template.md2.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Spec Mining

Extract a specification from a system that has no usable documentation, by reading the code that actually runs.

The discipline that makes the output trustworthy: separate what you observed from what you inferred. A reader will act on this document — rebuilding a service, planning a migration, onboarding — and a confident-sounding guess is worse than an acknowledged gap, because nobody goes back to check it.

Approach

Work outside-in: entry points, then routes, then the services behind them, then the data layer. Following an actual request path teaches you the system's real structure, which is often not the structure its directory names advertise.

Read the tests too. They document intended behaviour and edge cases someone hit in production, and they are usually more honest than any comment or README in the repo.

Read the migration history as well. Migrations are dated and ordered, so they show how the schema arrived at its current shape — which columns were added under pressure, what was backfilled, what was renamed but never dropped. That sequence is often the only surviving record of why the data model looks the way it does.

Every observation cites its evidence — src/auth/jwt.strategy.ts:42. Without a location the reader can't verify a claim, and unverifiable claims are what make reverse-engineered specs rot.

Writing observed requirements — EARS

EARS keeps requirements unambiguous by forcing the trigger and the state into the sentence, so "the system validates the token" can't hide when.

PatternForm
UbiquitousThe system shall [action].
EventWhen [trigger], the system shall [action].
StateWhile [state], the system shall [action].
ConditionalWhile [state], when [trigger], shall …
OptionalWhere [feature enabled], shall …

Number them by area so they can be referenced later — OBS-AUTH-001, OBS-USER-002:

OBS-AUTH-001
While credentials are valid, when POST /auth/login is called, the system
shall return a JWT access token (15m) and a refresh token (7d).
Evidence: src/auth/auth.controller.ts:31, src/auth/auth.service.ts:88

Uncertainties are a deliverable

Anything you could not determine from the code goes in its own section as a question, not a guess: what triggers a status transition, whether a delete is soft, which external system owns a field. This section is often the most valuable part of the document — it is the list of things a maintainer must be asked before anyone relies on the rest.

Output

Save to specs/{project_name}_reverse_spec.md. Structure and section order: references/specification-template.md.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

csharp

無料

Apply these opinionated C# conventions whenever writing or reviewing C# 12 / .NET 8+ code: nullable enabled with warnings as errors, records and primary constructors, pattern matching over cast chains, the Result pattern for expected failures, async all the way with CancellationToken, IOptions config, IHttpClientFactory, and never returning EF entities from an API.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

ALWAYS invoke for any task involving docstrings, JSDoc/TSDoc, or REST API documentation — even when the request seems handleable without it. Enforces Microsoft contract-first conventions and a bare-minimum rule that Claude won't apply by default: never restate the signature, drop @param/@returns that only echo names and types, always document @throws, and document data shapes as WHAT not WHY. Covers Python docstring styles (Google/NumPy/Sphinx), TSDoc tags and @inheritDoc, and API doc patterns for NestJS/Express/FastAPI/Django. Trigger on: adding or auditing docstrings, redundant or missing tags, deleting comment rot, or producing a documentation-health report. Do not skip for documentation tasks — consistent conventions are the whole point.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

Apply these opinionated .NET 8 architecture conventions whenever structuring or reviewing a backend service: clean architecture layering and which direction dependencies point, when CQRS with MediatR is worth it, cross-cutting concerns as pipeline behaviours, minimal APIs grouped by feature, keeping DbContext in Infrastructure, health checks and structured logging, WebApplicationFactory integration tests, and when AOT pays off.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

Remove signs of AI-generated writing from text. Use after drafting to make copy sound more natural and human-written. Based on Wikipedia's "Signs of AI writing" guide.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

Apply these opinionated JavaScript conventions whenever writing or reviewing JS or Node: ESM-first packaging, choosing between Promise combinators, error handling that doesn't swallow failures, AbortController for cancellation, keeping the event loop unblocked, and reaching for platform APIs before dependencies.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

Turn the git commits for a Jira ticket into a short, business-friendly implementation report and save it as local markdown. Use when the user wants to report finished work on a Jira ticket: a Jira report, update, or comment, a summary of their commits or changes for the ticket, or a note telling PM/QA what shipped.

日本語の概要は準備中です。原文の説明を表示しています。

alexander-danilenko/cortex-ai-skills162026年9月28日 更新

alexander-danilenko のスキルをすべて見る

このスキルの問題を報告する