メニュー
Extract rewrite-ready knowledge from general Rust codebases — functionality, design, engineering, Rust patterns. Use when given Rust source and asked to consolidate for recreation or rewrite.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Documents the Blooming Blockery CLI contract and teaches context-first tree authoring for design specifications and documentation.
Extract rewrite-ready knowledge from Rust/iced GUI codebases — functionality, design, engineering, iced patterns. Use when given iced Rust source and asked to consolidate for recreation or rewrite.
SOC 職業分類に基づく
| name | project-consolidation-rust-general |
| description | Extract rewrite-ready knowledge from general Rust codebases — functionality, design, engineering, Rust patterns. Use when given Rust source and asked to consolidate for recreation or rewrite. |
Extract rewrite-ready knowledge from a Rust codebase across four domains:
Use when given Rust source files and asked to consolidate knowledge for recreation, rewrite, or deep understanding.
Before writing any output, work through every question below. Do not skip questions because the answer seems absent — absence is itself informative and must be noted. Cite the specific file, line, or pattern that provides each answer.
todo!(), unimplemented!(), TODOs)main, lib.rs, workspace root)? What does it do?build.rs scripts or proc macros? What do they do?mod declarationpub vs pub(crate) vs private at each boundary, and why?// TODO, // FIXME, // HACK, // NOTE comments — quote verbatimArc, Rc, Cell, RefCell, Mutex usage — what does each wrap and why?clone() — intentional or borrow checker workaround?unwrap()/expect() — justified by what invariant?dyn Trait vs impl Trait usage — where and why?Display, From, Iterator, Drop, etc.)thiserror, anyhow, custom?Result alias?async fns and what they awaitArc<Mutex<>> / channels — what do they protect and why?unsafe blocks — quote and justify eachCow, Box<dyn>, impl Trait in return position — where and why?Cargo.toml dependencies — why each non-obvious one was chosenThis phase must be completed first. It answers: what does this software actually do?
One-paragraph summary of what this project is and what problem it solves.
An exhaustive list of every capability. For each:
Feature: [name]
Description: [what it does]
Entry point: [function, CLI flag, API call, etc.]
Status: [fully implemented / partial / stubbed / abandoned]
Notes: [limitations, TODOs, known issues]
Mode: [name]
Trigger: [how entered]
Behavior differences:
Algorithm/Logic: [name or description]
Location: [file/function]
Purpose:
Complexity/notes:
todo!(), unimplemented!(), // TODO — quoted verbatimbuild.rs and proc macro effectsDecision:
Alternatives:
Reason:
Impact:
Name:
Kind:
Purpose:
Fields/Variants:
Derives: [with reasons]
Ownership notes:
Invariants:
Lifetime params:
Lifecycle:
Signature:
Purpose:
Trait bounds:
Requires:
Ensures:
Behavior:
Panics:
⚠️ Gotchas:
Trait:
Purpose:
Implementors:
Key methods:
Design intent:
Macro:
Source:
Purpose:
⚠️ Non-obvious:
FUNCTIONALITY.md ← produced first
# [Project] — Functionality Inventory
## Purpose
## Feature & Capability List
## Operational Modes
## Data & I/O
## Implemented Algorithms
## Unimplemented / Abandoned
DESIGN_KNOWLEDGE.md
# [Project] — Design Knowledge
## Architecture
## Public API Surface
## Design Decision Log
ENGINEERING_KNOWLEDGE.md
# [Project] — Engineering Knowledge
## Data Structures
## Function Contracts
## Trait Architecture
## Error Handling
## Concurrency & Async
## Rust Patterns
FUNCTIONALITY.md first — it frames everything elseunwrap(), unsafe, Arc<Mutex<>> with a documented justification