refactor: 분리되어 관리하고 있던 문서 시스템을 하나로 통일

.agents/skills/deriving-tech-log-root-tree/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: deriving-tech-log-root-tree
+description: Use when a completed or substantially completed docs project analysis must be decomposed into grounded Tech Log Topics and candidate Case, Reference, Open Question, and Decision records.
+---
+
+# Deriving Tech Log Root Tree
+
+## Core rule
+
+**Discover record candidates from evidence already present in the detailed analysis. Do not brainstorm a content calendar.**
+
+## Required sequence
+
+1. Read project `state.json`, `final/document.md`, and `source-index.md`.
+2. Read bounded analysis files when the final document's anchor is not enough to judge classification.
+3. Identify coherent Topics from shared engineering problem spaces, not merely folder/module names.
+4. Within each Topic, identify concrete incidents first (Case), then reusable rules (Reference), unresolved unknowns (Open Question), and explicit project choices (Decision).
+5. Write the human-readable PROJECT/TOPIC tree.
+6. Add a Node Specification for every title with source anchors, readiness, relations, and kind-specific metadata.
+7. Run `references/decomposition-checklist.md`.
+8. Hash the source detailed document and record the project revision so downstream generation can detect staleness.
+
+Use `.agents/skills/writing-tech-log-records/references/root-tree-contract.md` as the output contract.
+
+## Topic boundary
+
+A Topic is a stable problem/decision area whose records share terminology, evidence, and relations. It should be broad enough to connect several records when the evidence supports them, but narrow enough that its References and Decisions remain coherent.
+
+Do not create one Topic per source file. Do not force unrelated incidents into one Topic because they use the same framework.
+
+## Classification discipline
+
+- Case title names the concrete engineering problem/verification, not a generic technology lesson.
+- Reference title names a reusable criterion/distinction.
+- Open Question title states an uncertainty that is still unresolved.
+- Decision title states an actual/proposed project direction evidenced in sources.
+
+Branches may be empty. Symmetry is not a quality goal.

.agents/skills/deriving-tech-log-root-tree/references/decomposition-checklist.md

@@ -0,0 +1,43 @@
+# Root Tree Decomposition Checklist
+
+## Source integrity
+
+- [ ] The tree records the detailed document hash and project revision/snapshot.
+- [ ] Every node has at least one source anchor.
+- [ ] Source anchors actually contain the material implied by the title.
+- [ ] Runtime-dependent claims name evidence or use `NEEDS_EVIDENCE`.
+
+## Topic quality
+
+- [ ] Topic is a coherent engineering problem space rather than a directory name.
+- [ ] Two Topics do not merely split the same causal chain arbitrarily.
+- [ ] A large Topic is split when its records no longer share useful relations/criteria.
+
+## Case
+
+- [ ] There is a specific incident, experiment, failure, diagnosis, or verification sequence.
+- [ ] The title can be understood without inventing a historical story.
+- [ ] The conclusion is bounded by actual evidence.
+
+## Reference
+
+- [ ] The rule is reusable beyond the originating incident.
+- [ ] It is not the Case summary rewritten declaratively.
+- [ ] Scope and exception can be stated from sources.
+
+## Open Question
+
+- [ ] The answer is not already in the analysis.
+- [ ] Known/unknown/next verification are separable.
+- [ ] Candidate options are included only when sources really considered them.
+
+## Decision
+
+- [ ] A project choice is explicitly recorded or user-supplied.
+- [ ] `technology is present` is not being treated as rationale.
+- [ ] `NEEDS_DECISION` is used if the direction is only a recommendation.
+
+## Duplication
+
+- [ ] No two nodes have the same primary purpose.
+- [ ] Relations are used instead of copying one record's entire content into another.