메뉴
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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
| 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