Agent skill

Reverse Spec For Rebuild

by BlackBeltTechnology in BlackBeltTechnology/pi-agent-dashboard

Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point…

MITAuto-check passed

Install Reverse Spec For Rebuild

skills CLI
$ npx skills add BlackBeltTechnology/pi-agent-dashboard --skill reverse-spec-for-rebuild -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install BlackBeltTechnology/pi-agent-dashboard reverse-spec-for-rebuild --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/BlackBeltTechnology/pi-agent-dashboard.git skills-src && mkdir -p .claude/skills && cp -r skills-src/packages/eng-disciplines/.pi/skills/reverse-spec-for-rebuild .claude/skills/reverse-spec-for-rebuild && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
reverse-spec-for-rebuild
GitHub stars
315
Token cost
~6.6k tokens
SKILL.md length
3,295 words
Files
77 (incl. scripts, references)
Skills in repo
70
Repo updated
First seen
Licence
MIT

At a glance

Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point…

  • Works in 12 steps: Scratch must be ignored. git… → Run id + sweep leftovers. Set RUN_ID=$(G… → Resolve the target. Confirm the path… → …
  • SKILL.md covers When to use, Inputs, Procedure and Frontend UI model (optional,…, plus 4 more sections
  • Runs TypeScript scripts from its folder; calls git, sh and node

What it does

Reverse Spec For Rebuild is an agent skill from BlackBeltTechnology/pi-agent-dashboard. Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point completeness, each claim cited file:line with confidence. Use on "reverse-engineer this for a rebuild", "extract the business rules", "reimplement X without the original code", "characterize code for a rewrite".

Its SKILL.md is about 6.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 79 other files, including scripts and reference files (for example `SKILL.md.AGENTS.md`, `eval/answer-key.json` and `eval/answer-key.json.AGENTS.md`).

The repository describes itself as: Real-time web dashboard for pi coding-agent sessions. Multi-session view, live chat mirroring, integrated terminal, diff viewer, pi-flows execution, and mobile-first remote… The licence is MIT.

Example prompts

  • “reverse-engineer this for a rebuild”
  • “extract the business rules”
  • “reimplement X without the original code”
  • “/reverse-spec-for-rebuild”

Requirements

  • Node.js

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. Scratch must be ignored. git check-ignore -q .reverse-spec-scratch/
  2. Run id + sweep leftovers. Set RUN_ID=$(G new-run) (UTC timestamp plus
  3. Resolve the target. Confirm the path exists; record
  4. Discover. One subagent with prompts/discovery.md (KB_AVAILABLE =
  5. Generate in parallel. One subagent per capability, all in a SINGLE
  6. Merge (this session — design D4; fall back to a consolidator subagent
  7. Audit in parallel. One subagent per capability in a SINGLE message,
  8. Revise loop. For each verdict: revise, re-run its generator with the
  9. Format gate. For every spec: G lint-spec PKG/capabilities//spec.md
  10. Completeness gate. One subagent with prompts/completeness.md writes
  11. Cross-cutting audit. One subagent with prompts/auditor-rebuild.md,
  12. Sweep again. G sweep --run "$RUN_ID" then G sweep; confirm git status --porcelain shows nothing

What it can do on your machine

Read from SKILL.md and the folder at commit 7a2d171. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (TypeScript, from the files we listed), which the agent can run.

    Shell commands in SKILL.md call:

    • git
    • sh
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Reverse Spec For Rebuild loads about 6.6k tokens when it runs, and up to ~14k if it reads all its reference files. Until then it costs about 106 tokens; SKILL.md has 3,295 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~106
When it runs · the whole SKILL.md, loaded when a task matches
~6.6k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~14k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from BlackBeltTechnology/pi-agent-dashboard at commit 7a2d171, republished under its MIT licence (© BlackBeltTechnology). 3,295 words, ~6,608 tokens.

Download SKILL.mdSave it as .claude/skills/reverse-spec-for-rebuild/SKILL.md (or your agent's skills folder). This skill also uses 76 other files; get the full folder from GitHub.
name
reverse-spec-for-rebuild
description
Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point completeness, each claim cited file:line with confidence. Use on "reverse-engineer this for a rebuild", "extract the business rules", "reimplement X without the original code", "characterize code for a rewrite".

reverse-spec-for-rebuild

Turn existing code into a rebuild package: enough data shapes, business rules, implicit behavior, provenance and known unknowns that a team can rebuild the same business logic and use cases without the original source. Works in any git repository; a kb tree and the OpenSpec CLI are optional accelerators.

Not the same as a kb-oriented behavioral spec generator: those strip line numbers and rule catalogs on purpose. This skill keeps them, so its output never goes under a kb-indexed root.

Methodology (provenance citations, confidence levels, state/edge/error checklists, entry-point completeness) adapted and rewritten from greenfield (Apache-2.0); see the package NOTICE.

When to use

  • A system will be rewritten (new stack, new team, vendor exit) and its business logic must survive.
  • You need a catalog of business rules, including the implicit ones that live in defaults, exception handlers and ordering.
  • You need to know what is NOT known about a system (registered gaps).

Skip for a single trivial file, or when you only want searchable docs.

Inputs

  • Target directory (default: repository root) and an optional single capability.
  • Optional previous rebuild package (for stable identifiers on re-run).
  • Optional protected roots override (default openspec docs packages .pi).

Procedure

G below is node <this skill dir>/scripts/guard.mjs (the deterministic guards in scripts/guard.mjs: check-dest, sweep, lint-spec, lint-cite), run from the repository root. PKG is .reverse-spec-scratch/<target-slug>/rebuild/ (<target-slug> = output of G slug <target>: root for the repository root, else a kebab-case form of the canonical repo-relative path plus a short hash — never ./.., never shared by two targets; it exits 2 for a target outside the repository. Never derive the slug by hand).

  1. Scratch must be ignored. git check-ignore -q .reverse-spec-scratch/ (keep the trailing slash: a dir/ ignore pattern does not match a not-yet-existing path without it). If it is not ignored, ask_user before writing anything: on consent append .reverse-spec-scratch/ to .git/info/exclude (never to a committed ignore file); on refusal stop.
  2. Run id + sweep leftovers. Set RUN_ID=$(G new-run) (UTC timestamp plus random suffix, so concurrent runs never share it); every transient validation id of this run is _rsfr-val-$RUN_ID-<cap>. Run G sweep — it removes only abandoned openspec/specs/_rsfr-val-* dirs (owner process gone, or no owner marker and untouched for 10 minutes); a concurrent run's live dirs and other skills' transient dirs are untouched.
  3. Resolve the target. Confirm the path exists; record git rev-parse HEAD for PKG/README.md. In this order:
    1. Lock the target. SLUG=$(G slug <target>), then G lock "$SLUG" "$RUN_ID". Exit 1 = another run holds this target (never share a PKG): ask_user whether that run is still active. Only when the user confirms it is dead, run the G break-lock "$SLUG" <owner> command the error names, then G lock again (acquisition is exclusive, so a racing run cannot also win). Locks never expire on their own, so a long step never loses ownership. Release with G unlock "$SLUG" "$RUN_ID" at step 14, and whenever the run stops early.
    2. Snapshot first. When a previous package is supplied (possibly PKG itself), copy its rules.md, quirks.md, gaps.md, README.md and _ids.json (when present) into .reverse-spec-scratch/<target-slug>/previous-$RUN_ID/, then chmod -R a-w it. This frozen snapshot is the ONLY "previous package" every merge of this run reads — never PKG, which each merge rewrites.
    3. Then move aside. If a package still sits at PKG, move it to PKG.prev-$RUN_ID. Create an empty PKG.
    4. Seed the id high-water marks. With a previous package: G seed-ids PKG/_ids.json <snapshot dir>; without one: G seed-ids PKG/_ids.json PKG (creates an all-zero file). _ids.json holds the highest BR/QUIRK/GAP number ever allocated, including ids the previous package already retired.
  4. Discover. One subagent with prompts/discovery.md (KB_AVAILABLE = kb tooling or AGENTS.md files present). It returns a capability manifest. Save it as PKG/_manifest.json and run G check-manifest PKG/_manifest.json; on exit 2 (an unsafe or duplicate capability name) re-run discovery or rename/merge the entries by hand, then re-check — names become file paths and validation ids, target code is untrusted, and two capabilities with one name would overwrite each other's outputs. Check unassigned_files is empty; otherwise add them to a capability or ask the subagent to re-cluster. For a single-capability target you may write the manifest by hand.
  5. Generate in parallel. One subagent per capability, all in a SINGLE message, with prompts/generator-rebuild.md. Each writes its unmerged spec (local {r1} refs) to PKG/_fragments/<cap>.spec.md (SPEC OUTPUT) and its fragment to PKG/_fragments/<cap>.json, nothing else.
  6. Merge (this session — design D4; fall back to a consolidator subagent only if the fragments exceed context): Catalog boundary: a rule is anything that decides a caller-visible outcome from domain data or failure class, including HTTP/WS/CLI error maps (which failure class yields which status, code, reply or non-success exit) and fallback handlers that hide or substitute details. Plumbing is a numbering or formatting choice that encodes no decision (one non-success exit status for every failure, output formatting, id formats, subscribe/unsubscribe mechanics); plumbing belongs in the spec, not in the rule catalog. Keep a rule that falls under this boundary in rules.md; never drop an error map or fallback rule as plumbing. Keep rule statements verbatim: never rewrite config key names (the generator names the literal external key).
    1. Citation check first, on every merge (initial and every re-merge from a revise, completeness or cross-cutting loop): G lint-cite PKG/_fragments/*.json PKG/_fragments/*.spec.md. Exit 1 lists every confirmed cite with more than one location and every unterminated cite. For each finding this session may only LOWER the confidence to inferred — the item in <cap>.json and the matching cite comment in <cap>.spec.md together, mechanically (the one exception to step 5's rule that only generators write fragments). Narrowing a cite to one location is the generator's job: route it as FINDINGS. Re-run until exit 0; never merge while it fails.
    2. Load rules.md/quirks.md/gaps.md from the frozen previous-$RUN_ID/ snapshot (step 3) when one exists — on every merge of the run, so ids the previous package retired stay retired even after this run rewrites PKG.
    3. Walk fragments in manifest order. For each rule/quirk/gap, match it BY MEANING against items already merged in this run (dedupe; add the capability to the existing item), then against the frozen snapshot (reuse its id), then against the catalogs of this run's previous merge (reuse its id). Otherwise allocate with G next-id PKG/_ids.json <BR|QUIRK|GAP> — never compute an id by hand. The mark only grows, so an id retired by the previous package or by an earlier revision of this run is never reused. _ids.json ships with the package so the next run inherits it.
    4. Render EVERY capability's PKG/capabilities/<cap>/spec.md from its unmerged PKG/_fragments/<cap>.spec.md, replacing each {r1}/{q1}/{g1} with its global id — on every merge, for all capabilities, so a re-merge that shifts ids cannot leave a stale reference in an unrevised spec. No {...} local reference may remain. Never edit the rendered spec by hand.
    5. A merged item's confidence is the LOWEST of its sources; never raise it. A merged item's cite is the union of its sources' locations; a union of more than one location caps its confidence at inferred. When a fragment rule spans several catalog rules, map its local id to the closest one and list the others in the spec text, rather than narrowing the claim.
    6. Merge entities by name into model.md; render rules.md, quirks.md, gaps.md, using references/package-templates.md. Keep a JSON origin map item id -> capability for the cross-cutting audit.
    7. At the end of EVERY merge, before step 7: G lint-cite PKG/rules.md PKG/model.md PKG/quirks.md PKG/gaps.md PKG/capabilities/*/spec.md. A finding only in merged output is a merge error: re-run the merge applying rule 4 (never hand-edit a catalog). No audit runs while it fails.
  7. Audit in parallel. One subagent per capability in a SINGLE message, prompts/auditor-rebuild.md, MODE=capability.
  8. Revise loop. For each verdict: revise, re-run its generator with the audit JSON as FINDINGS, then go back to step 6 (every revision re-merges), and re-audit every capability that was regenerated, whose rendered spec changed, or that is listed under (or contributed) a catalog item — rule, quirk, gap or entity field — whose statement, class, citation, confidence or id changed in that merge. Diff the previous merge's catalog files against the new ones to find those items. Stop after 3 rounds for a capability that still fails: report it as not promotable.
  9. Format gate. For every spec: G lint-spec PKG/capabilities/<cap>/spec.md (exit 1 lists file:line: reason). Additionally, only when the OpenSpec CLI is on PATH AND openspec/ exists, validate each spec through a transient id that is deleted in the same iteration. Run this block once per capability (it is a subshell, safe to repeat in one shell) with shell variables PKG (package dir), CAP, RUN_ID and G set; it refuses (exit 2) a CAP or RUN_ID that is not a single safe path component before touching any path; its exit status is the validation result, and it records its own pid in .owner so a concurrent sweep leaves it alone while it runs:
    bash
    (
      $G check-cap "$CAP" && $G check-run "$RUN_ID" || exit 2
      id="_rsfr-val-$RUN_ID-$CAP"; d="openspec/specs/$id"
      trap 'rm -rf "$d"' EXIT
      mkdir -p "$d" && sh -c 'echo $PPID' > "$d/.owner" &&
        cp "$PKG/capabilities/$CAP/spec.md" "$d/spec.md" && openspec validate "$id" --type spec
    )
    A failing spec is regenerated with the failures as FINDINGS (back to step 5 for that capability, then 6-9). It is never promotable while failing.
  10. Completeness gate. One subagent with prompts/completeness.md writes PKG/completeness.md, then G lint-cite PKG/completeness.md before the cross-cutting audit (a finding re-runs completeness). Any unmapped entry point = FAIL: re-run the suggested capability's generator with the unmapped list as FINDINGS — it either specs the entry point or records it as a gap (and an entry point) in its fragment. Never edit rules.md/quirks.md/gaps.md or a rendered spec directly: every merge re-renders them from fragments, so a direct edit is lost. Then loop back through steps 6-10. A package that fails is not promotable. Allow at most 3 rounds of this loop; if entry points are still unmapped, report the package as not promotable, run G unlock "$SLUG" "$RUN_ID" and stop.
  11. Cross-cutting audit. One subagent with prompts/auditor-rebuild.md, MODE=cross-cutting, ORIGINS = the origin map. Route each failing item to the capability in its origin, regenerate it with the finding, and loop back through steps 6-11. Allow at most 3 rounds of this loop; if a cross-cutting finding persists, report the package as not promotable, run G unlock "$SLUG" "$RUN_ID" and stop.
  12. Sweep again. G sweep --run "$RUN_ID" then G sweep; confirm git status --porcelain shows nothing new outside .reverse-spec-scratch/ (a change elsewhere means a subagent wrote outside its outputs — investigate before going on).
  13. Gate summary. Write PKG/README.md (template in references/package-templates.md, with the commit SHA) and report per capability: audit verdict, format gate (lint-spec, plus openspec validate when it ran), citation check (lint-cite on fragments, catalogs and completeness.md), rule counts (explicit/implicit), quirks, gaps, and the completeness verdict.
  14. Promote on confirm. Offer promotion only when every capability passed audit and format gate, completeness is PASS and the citation check (G lint-cite) is clean. ask_user for a destination; run G check-dest <dest> (add --protect <dir> per root when the user overrides the protected roots). Exit 1 = inside a protected root: say so and ask for another destination. On exit 0 MOVE (not copy) PKG to the destination. Never promote without explicit confirmation. Finally G unlock "$SLUG" "$RUN_ID" (also when the user declines promotion).
Show full SKILL.md (1,461 more words)Show less

Frontend UI model (optional, after step 13)

For a target with a user interface, after the package gate and before promotion (the UI model cites the package's BR/QUIRK/GAP ids, so the catalogs must be final). Full commands, adapter contract and rules: references/ui-extraction.md; record format: references/ui-model.md. Programs: scripts/ui-extract/ (dependency-free); stack specifics in an adapter (built-in scripts/ui-extract/adapters/angularjs.mjs, or a project adapter by path). Application knowledge (config layering, string tables, toolbar conventions, code page, template helpers) goes in a project-owned profile with parent: "<built-in>" — never into the skill.

  1. Inventory + effective config + forms (deterministic): inventory.mjs, config.mjs per customer variant, forms.mjs / screen-form.mjs.
  2. Screen records. One subagent per screen or dialog, in a SINGLE message, with prompts/ui-screen-generator.md filled by fill.mjs from a screen job; each writes only PKG/ui/screens/<ID>.json.
  3. Gate. gate.mjs APP PKG until PASS; route a failing record back to its generator with the gate lines. Never hand-edit a record to pass.
  4. Style kit + screen plans (deterministic): style-kit.mjs (kit job maps components to real selectors), then screen-plan.mjs per screen and dialog; an unlinked control (exit 1) means the record misses an action, field or unmapped reason — fix the record (step 2-3), or the adapter.
  5. Flows from code per use case: flow.mjs → layout → check-trace; compare.mjs against the prose flow, and report the differences.
  6. Behaviour models (optional): per key user action, a rebuild-package-diagrams sequence-from-ui draft deepened by one subagent with prompts/sequence-generator.md; per stateful entity field (a model.md field with allowed: values or a lock/report flag), one subagent with prompts/state-machine-generator.md. Each record is accepted only when check-sequences / check-states with --app pass; route gate lines back as findings. Candidate quirks the generators report go to the merge as findings, never straight into quirks.md.
  7. Use-case UI links (optional, before CRUD): per use-case batch one subagent with prompts/uc-linker.md links BPMN steps to UI actions with evidence (shared ref or a cite inside the action's code), or records noUi; accepted only when check-uc-links passes; finish with check-uc-links PKG --complete. Links extend each use case's screens and UI actions (CRUD columns, IFML scope, flows). 7a. Customer variability (optional, configurable apps): config-reads.mjs APP <adapter> PKG (adapter hooks configReads, variantInfo) → ui/_config-reads.json; one subagent with prompts/variability-classifier.md writes diagrams/variability/features.json; accepted only when check-variability PKG APP --complete passes. Route findings (dead everywhere, single-customer, constant) to the merge as gaps/questions. 7c. Usage evidence (optional, when the app keeps its own logs and a snapshot is available): a project job describes the log sources per customer; one subagent with prompts/usage-mapper.md maps log types to code, UI actions and use cases (diagrams/usage/mapping.json, shared); accepted only when check-usage PKG APP JOB --complete passes. Counts are aggregated locally only (usage, then the check-usage-output privacy gate) — never into the shared package. 7b. CRUD matrix (optional): per screen batch one subagent with prompts/crud-classifier.md classifies every data effect (from rebuild-package-diagrams crud-draft) as entity + C/R/U/D or unmapped; accepted only when check-crud passes; finish with check-crud PKG --complete. Route its findings (never written / never read / created never deleted / untouched) and tables with no model entity to the merge as gaps or questions.
  8. Render: the rebuild-package-diagrams skill's render.sh PKG APP (all its gates, catalog with screen plans, style kit, IFML, flows and behaviour diagrams).

Subagent routing

Rolesubagent_typePromptModelAccessParallel
discoveryrsfr-discoveryprompts/discovery.md@compactread-only1
generatorrsfr-generatorprompts/generator-rebuild.md@fastwrites its spec + fragmentone per capability, single message
auditorrsfr-auditorprompts/auditor-rebuild.md@researchread-onlyone per capability, single message; then 1 cross-cutting
completenessrsfr-completenessprompts/completeness.md@fastwrites completeness.md1
UI screen generator (optional)rsfr-ui-screen-generatorprompts/ui-screen-generator.md@fastwrites its ui/screens/<ID>.jsonone per screen/dialog, single message
sequence generator (optional)rsfr-sequence-generatorprompts/sequence-generator.md@fastwrites its diagrams/sequences/<ID>.jsonone per user action
state-machine generator (optional)rsfr-state-machine-generatorprompts/state-machine-generator.md@fastwrites its diagrams/state-machines/<ID>.jsonone per entity field
use-case linker (optional)rsfr-uc-linkerprompts/uc-linker.md@fastwrites diagrams/uc-links/<UC>.json per use caseone per use-case batch
variability classifier (optional)rsfr-variability-classifierprompts/variability-classifier.md@fastwrites diagrams/variability/features.json1
usage mapper (optional)rsfr-usage-mapperprompts/usage-mapper.md@fastwrites diagrams/usage/mapping.json (no customer data)1
CRUD classifier (optional)rsfr-crud-classifierprompts/crud-classifier.md@fastwrites diagrams/crud/<SCR>.json per screenone per screen batch (~30 effects)

Use these exact subagent_type names: the package ships matching agents/<type>.md files whose frontmatter pins the model, so an omitted model still routes correctly (an unknown type silently inherits the session model). Pass model explicitly as well; never omit it while the role is bound. No roles configured (or a role unbound) -> omit model and the subagent inherits the session model. Keep the auditor the strongest model available: it is the hallucination safety net; a fast generator is safe only behind it and the format gate. Pass the prompt text with placeholders filled, plus exact paths.

Output

PKG/README.md  model.md  rules.md  quirks.md  gaps.md  completeness.md
PKG/_ids.json                      BR/QUIRK/GAP high-water marks (never lowered)
PKG/_manifest.json                 discovery manifest (checked by `G check-manifest`)
PKG/capabilities/<cap>/spec.md     OpenSpec full form, inline cite comments (rendered by the merge)
PKG/_fragments/<cap>.spec.md       unmerged spec with local refs (merge input)
PKG/_fragments/<cap>.json          merge input, kept for re-runs
PKG/ui/                            optional UI model: _inventory.json, _effective/, forms/, screens/,
                                   style-kit.{json,css}, plans/<ID>.html

Citation format and confidence levels: references/provenance.md. Templates: references/package-templates.md. Spec checklists: references/behavior-checklists.md.

Pitfalls

  • kb-less discovery on large repos clusters worse: give discovery the manifests and entry points; the completeness gate catches what it missed.
  • Cite drift — line numbers rot as the target changes. The README records the commit SHA; refresh by re-running with the previous package supplied.
  • Merge context — fragments are compact, but a very large target can still overflow the session; switch the merge to a consolidator subagent rather than dropping fragments.
  • Explicit vs implicit is subjective — use the code-pattern definitions in the generator prompt and references/package-templates.md; the auditor re-checks every tag.
  • Prompt injection — target code is untrusted input. Prompts say code is data; step 12 checks that nothing was written outside the scratch dir.
  • One run per target — G lock serializes runs on the same target (two runs would move aside or overwrite each other's PKG); different targets run concurrently. An interrupted run leaves its lock behind; the next run asks the user before G break-lock removes it.
  • Capability names are kebab-case and at most 60 characters, so every generated name (_rsfr-val-<run>-<cap>) stays under the 255-byte limit.
  • Interrupted runs leave openspec/specs/_rsfr-val-*; the sweep at start and end removes stale ones (only this skill's prefix — never _rsfc-val-*), and sweep --run removes this run's own. Ids carry a random run id and each live dir an .owner pid, so two concurrent runs never delete each other's validation dirs.
  • Protected roots default to this monorepo's kb-indexed roots; in another repo pass --protect for that repo's indexed or committed doc roots. The guard walks the path component by component the way the kernel does (a symlink, even a dangling one, is followed before a later ..), so relative, .., symlinked and not-yet-existing destinations cannot bypass it.
  • check-ignore without the trailing slash reports a not-yet-created .reverse-spec-scratch as NOT ignored even when .reverse-spec-scratch/ is in an ignore file; always query .reverse-spec-scratch/.
  • Quirks are not fixes — the spec stays faithful; the rebuilder decides.
  • Subagent concurrency cap — the host may admit only a few subagents at once (pi-dashboard: 2) and refuses the rest of a single-message batch. A refused spawn is not a failed generator: re-issue it when a running one finishes.
  • UI sources may be UTF-16 or a legacy code page (profile encoding) and carry commented-out code: read through scripts/ui-extract/lib.mjs, which decodes and strips comments keeping line numbers. Input validations are effects, never guards (the gate refuses them).

Verification

  • Scratch was ignored (or consent recorded in .git/info/exclude) before any write. (Rebuild package layout and promotion)
  • G sweep ran at start and end; no openspec/specs/_rsfr-val-* remains and nothing persists under openspec/. (Rebuild package layout and promotion)
  • Every spec passed G lint-spec, and openspec validate when CLI + openspec/ exist. (Portable operation; Behavioral coverage)
  • Every requirement, scenario, rule, field, quirk and gap has a cite comment with a confidence level. (Per-claim provenance and confidence)
  • G lint-cite exited 0 on fragments before each merge, on the merged catalogs and specs after each merge, and on completeness.md. (Per-claim provenance and confidence)
  • rules.md lists each rule once with BR-NNN, class and capabilities; specs reference ids that resolve. (Business rule catalog; Grounding audit)
  • model.md covers every entity field with type, optionality and default. (Domain model)
  • Guarded state transitions have allowed and rejected scenarios; edge and error checklists were walked. (Behavioral coverage of state, edge cases and errors)
  • Suspected defects are in quirks.md, described faithfully in specs. (Quirk annotation)
  • Unknowns are in gaps.md; configurable values name their key. (Gap register)
  • completeness.md verdict PASS. (Entry-point completeness gate)
  • Every capability audit pass, cross-cutting audit pass, gate summary shown. (Grounding audit and revise loop)
  • Re-run with the previous package kept surviving ids and reused none. (Business rule catalog)
  • Optional UI model: gate.mjs PASS, every screen-plan.mjs run 0 unlinked, every flow from code passed check-trace. (Frontend UI-model extraction)
  • Optional behaviour models: check-sequences and check-states with --app exit 0.
  • Optional use-case links: check-uc-links PKG --complete exits 0. (use-case linking step)
  • Optional variability: check-variability PKG APP --complete exits 0. (variability step)
  • Optional usage: check-usage PKG APP JOB --complete and check-usage-output exit 0. (usage step)
  • Optional CRUD matrix: check-crud PKG --complete exits 0. (CRUD classification step) (Behaviour-model generation)
  • Promotion happened only after ask_user confirmation and G check-dest exit 0, by move. (Rebuild package layout and promotion)

© BlackBeltTechnology, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 76 other files (scripts, references) in packages/eng-disciplines/.pi/skills/reverse-spec-for-rebuild of BlackBeltTechnology/pi-agent-dashboard.

  • SKILL.md
  • SKILL.md.AGENTS.md
  • eval/answer-key.json
  • eval/answer-key.json.AGENTS.md
  • eval/fixture/package.json
  • eval/fixture/src/cli.ts
  • eval/fixture/src/config.ts
  • eval/fixture/src/errors.ts
  • eval/fixture/src/events.ts
  • eval/fixture/src/http.ts
  • eval/fixture/src/index.ts
  • eval/fixture/src/model.ts
  • eval/fixture/src/orders.ts
  • eval/fixture/src/pricing.ts
  • eval/fixture/src/tools.ts
  • eval/score.md
  • eval/score.md.AGENTS.md
  • prompts
  • … and 59 more

Open the folder on GitHubat commit 7a2d171

Compare with similar skills

Reverse Spec For Rebuild next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Reverse Spec For Rebuild compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Reverse Spec For Rebuild this skillBlackBeltTechnology/pi-agent-dashboard315—~6.6kAutomated safety check: PassMIT
Protocol Reversezhaoxuya520/reverse-skill41k2 repos~620Automated safety check: WarnMIT
macOS Reversezhaoxuya520/reverse-skill41k2 repos~366Automated safety check: PassMIT
Protocol Reversesickn33/agentic-awesome-skills47k1 repos~689Automated safety check: PassMIT
macOS Reversesickn33/agentic-awesome-skills47k1 repos~466Automated safety check: PassMIT
JS Reversesickn33/agentic-awesome-skills47k1 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Protocol Reverse

    zhaoxuya520/reverse-skill

    A skill your agent uses for authorized reverse engineering of custom binary protocols, Protobuf/gRPC, WebSocket frames, and PCAP-driven protocol recovery.

    41k GitHub starsUsed in 2 repos~620 tokens
    Backend & APIsAuto-check: warnings
  • macOS Reverse

    zhaoxuya520/reverse-skill

    A skill your agent uses for authorized macOS and Mach-O reverse engineering including codesign, Objective-C/Swift recovery, endpoint security surfaces, and Apple platform malware analysis.

    41k GitHub starsUsed in 2 repos~366 tokens
    SecurityAuto-check passed
  • Protocol Reverse

    sickn33/agentic-awesome-skills

    Authorized reverse engineering of custom binary protocols, Protobuf/gRPC schemas, WebSocket frames, and PCAP-driven protocol recovery.

    47k GitHub starsUsed in 1 repo~689 tokens
    Backend & APIsAuto-check passed
  • macOS Reverse

    sickn33/agentic-awesome-skills

    Authorized macOS and Mach-O reverse engineering: codesign inspection, Objective-C/Swift recovery, endpoint-security surfaces, and Apple-platform malware analysis.

    47k GitHub starsUsed in 1 repo~466 tokens
    SecurityAuto-check passed
  • JS Reverse

    sickn33/agentic-awesome-skills

    Front-end JavaScript reverse engineering: locate signature chains, analyze encrypted request parameters, sample runtime behavior, and reproduce logic locally in Node for evidence-based output.

    47k GitHub starsUsed in 1 repo~1.8k tokens
    SecurityAuto-check passed
  • Mobile Reverse

    sickn33/agentic-awesome-skills

    Authorized Android/iOS application reverse engineering and security testing: APK/IPA analysis, runtime instrumentation (Frida/Objection), SSL-pinning and jailbreak/root-detection bypass, per OWASP…

    47k GitHub starsUsed in 1 repo~1.5k tokens
    SecurityAuto-check passed

More from BlackBeltTechnology/pi-agent-dashboard

All 70 skills in this repo
  • Browser

    BlackBeltTechnology/pi-agent-dashboard

    Browser automation via the agent-browser CLI. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

    316 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • CI Troubleshoot

    BlackBeltTechnology/pi-agent-dashboard

    Diagnose failed GitHub Actions runs for pi-agent-dashboard: the 11-file workflow taxonomy, affected-test selection, the release pipeline, known failure modes, and how to read gh run logs and…

    316 GitHub stars~3.5k tokensUpdated today
    Auto-check passed
  • Debug Dashboard

    BlackBeltTechnology/pi-agent-dashboard

    Diagnose problems in the running pi-agent-dashboard system: server.log, /api/health, bridge WebSocket connectivity, vitest triage, known-issue FAQ entries.

    316 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Implement

    BlackBeltTechnology/pi-agent-dashboard

    Disciplined implementation in pi-agent-dashboard: the rebuild matrix (extension→reload, server→restart, client→build+restart, openspec-apply→full rebuild) plus the project's code discipline rules.

    316 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Pi Dashboard

    BlackBeltTechnology/pi-agent-dashboard

    Monitor and control the pi-dashboard server. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

    316 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Session To Guideline

    BlackBeltTechnology/pi-agent-dashboard

    Turn a pi session into a Markdown "how-we-did-it" collaboration guideline: reads the session's JSONL transcript and synthesizes a reusable playbook of which prompts worked, what had to be steered…

    316 GitHub stars~3.2k tokensUpdated today
    Auto-check passed

Questions about Reverse Spec For Rebuild

What does Reverse Spec For Rebuild do?

Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point…. Reverse Spec For Rebuild is an agent skill from BlackBeltTechnology/pi-agent-dashboard. Characterize existing code into a rebuild package a team can reimplement from without the source: behavior specs, domain model, BR-NNN rules (explicit/implicit), quirks, gaps, entry-point completeness, each claim cited file:line with confidence.

How do I install Reverse Spec For Rebuild in Claude Code?

Run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill reverse-spec-for-rebuild -a claude-code`. Or copy the skill folder (packages/eng-disciplines/.pi/skills/reverse-spec-for-rebuild in BlackBeltTechnology/pi-agent-dashboard) into .claude/skills/reverse-spec-for-rebuild in your project. Claude Code loads it when a task matches its description.

How do I install Reverse Spec For Rebuild in Codex?

Run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill reverse-spec-for-rebuild -a codex`. Or copy the skill folder (packages/eng-disciplines/.pi/skills/reverse-spec-for-rebuild in BlackBeltTechnology/pi-agent-dashboard) into .agents/skills/reverse-spec-for-rebuild in your project. Codex loads it when a task matches its description.

Can I use Reverse Spec For Rebuild in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill reverse-spec-for-rebuild -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/reverse-spec-for-rebuild, .gemini/skills/reverse-spec-for-rebuild, .github/skills/reverse-spec-for-rebuild and .opencode/skills/reverse-spec-for-rebuild in your project.

What does Reverse Spec For Rebuild need to run?

Going by SKILL.md and its folder, Reverse Spec For Rebuild needs TypeScript for the scripts in its folder and the command-line tools its instructions call (git, sh and node). Our summary lists: Node.js.

Does Reverse Spec For Rebuild access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Reverse Spec For Rebuild safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Reverse Spec For Rebuild use?

Reverse Spec For Rebuild is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Reverse Spec For Rebuild use?

About 6.6k tokens (SKILL.md is roughly 26k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 7.4k tokens, read only when the agent opens those files.

What are the alternatives to Reverse Spec For Rebuild?

Skills that share tags, products or a category with Reverse Spec For Rebuild: Protocol Reverse (zhaoxuya520/reverse-skill, 41k stars), macOS Reverse (zhaoxuya520/reverse-skill, 41k stars), Protocol Reverse (sickn33/agentic-awesome-skills, 47k stars) and macOS Reverse (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Reverse Spec For Rebuild?

BlackBeltTechnology (a GitHub organization) maintains it in BlackBeltTechnology/pi-agent-dashboard, which has 315 GitHub stars. The repository holds 70 skills in this directory. The repository was last updated on October 10, 2026.

Source: BlackBeltTechnology/pi-agent-dashboard on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.