메뉴
Compile a structured context file for HLD generation by merging decisions (from hld-discuss), research (from arch-research), and ADR constraints with gap-fill questions. Can also run standalone with direct Q&A when no decisions file exists.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | hld-gather |
| description | Compile a structured context file for HLD generation by merging decisions (from hld-discuss), research (from arch-research), and ADR constraints with gap-fill questions. Can also run standalone with direct Q&A when no decisions file exists. |
| version | 3.0.0 |
| context | fork |
| argument-hint | [decisions-file-path] [--adr path-to-adr] [--research path-to-research] |
| allowed-tools | Read, Glob, Grep, Skill, Task, AskUserQuestion, WebSearch, WebFetch |
| model | opus |
Compile all context needed to write a High Level Design document. In the full pipeline, this skill receives a decisions file (from hld-discuss), a research file (from arch-research), and an ADR reference, then merges them with gap-fill questions to produce the final context file.
Can also run standalone — if no decisions file is provided, falls back to direct Q&A mode.
$ARGUMENTS — path to a decisions file, and optionally flags.
Parse for:
docs/context/hld/<name>-decisions.md--adr <path>--research <path>If invoked with --adr or text like "based on ADR at ", read the ADR as primary input.
Every factual claim in the context file must be traceable to research performed in this session.
Human-in-the-loop: Never proceed past a decision point without user approval.
Check if $ARGUMENTS points to a decisions file:
--adr provided, read the ADR. Extract decision, drivers, chosen option, rationale, consequences, confirmation.--research provided, read the RESEARCH.md. If not provided, check for <name>-RESEARCH.md at same location.docs/hld/ for existing HLDs to understand the landscape.Compare decisions + research + ADR against what an HLD context file needs:
| Required Section | Source | Gap-Fill Needed? |
|---|---|---|
| Problem Statement | ADR or decisions topic | Usually covered |
| Goals / Non-Goals | Decisions file (D-XX scope) | Ask if non-goals unclear |
| Scope Boundaries | Decisions file | Usually covered |
| Consumers & Expectations | May not be in decisions | Ask if missing |
| Data Entities | May be partially covered | Ask for detail if needed |
| External Systems | Decisions file (integration D-XX) | Usually covered |
| NFRs | Decisions file or gaps | Ask if specific numbers missing |
| Deployment & Rollout | May not be in decisions | Ask if not mentioned |
Only ask about genuine gaps. Present compilation plan:
"I have decisions, research, and ADR context. Here's what I'll compile. Any gaps?"
# HLD Context: [Feature/Change Title]
**Gathered:** [today's date]
**Description:** [what is being built/changed]
**ADR Reference:** [path to ADR]
**Decisions file:** [path]
**Research file:** [path, if used]
## Problem Statement
[From ADR or decisions topic]
## Goals and Non-Goals
### Goals
- [Specific, measurable outcomes — from decisions + ADR]
### Non-Goals
- [Explicitly out of scope — from decisions Deferred Ideas]
## Implementation Decisions
[Preserved from decisions file — D-XX numbering intact]
### [Category]
- **D-01:** [decision] (User Decision)
- Rationale: [rationale]
- Code context: [file:line]
- Affects: [downstream impact]
### Claude's Discretion
- **D-03:** [area]
## ADR Context
[Extracted from ADR — decision, drivers, chosen option, rationale, consequences]
## User Answers
[Gap-fill answers organized by question area — only sections where gaps existed]
## Research Summary
### Decision Impact Analysis
[From RESEARCH.md]
### Approach Comparison
[From RESEARCH.md — preserved as table]
| Approach | Pros | Cons | Adoption | Risk |
|----------|------|------|----------|------|
### Don't Hand-Roll
[From RESEARCH.md — preserved as table]
| Problem | Don't Build | Use Instead | Why |
|---------|------------|-------------|-----|
### Codebase Findings
[From RESEARCH.md — with file:line citations]
| Pattern | Location (file:line) | Reusable? | Adaptation Needed |
|---------|---------------------|-----------|-------------------|
### Gap Analysis
[From RESEARCH.md]
| Expected | Actual | Severity | Impact |
|----------|--------|----------|--------|
### Common Pitfalls
[From RESEARCH.md]
| Pitfall | What Goes Wrong | How to Avoid |
|---------|----------------|--------------|
## Change Map
### Files to Modify
| File/Module | Change Description |
|---|---|
| `path/to/file` | [what changes] |
### New Files
| File/Module | Purpose |
|---|---|
| `path/to/new` | [what it does] |
### Files to Remove/Deprecate
| File/Module | Reason |
|---|---|
### Configuration Changes
- [env vars, feature flags, build changes]
### Database/Schema Changes
- [tables, columns, indexes, migrations]
## Implementation Phases
| Phase | Scope Summary | Depends On | Deliverable |
|-------|---------------|------------|-------------|
| 1 | [scope] | — | [deliverable] |
| 2 | [scope] | Phase 1 | [deliverable] |
## Deferred Ideas
[From decisions file]
## Open Questions
[Merged from decisions + research + gap-fill]
## Template
The HLD must follow the template at `${CLAUDE_SKILL_DIR}/../hld-generate/references/template.md`.
Key sections: Problem Statement, Goals/Non-Goals, Proposed Solution (Overview, Architecture, Data Model, API Design, Key Design Decisions), Alternatives Considered (≥2), Codebase Impact, Security, Performance, Reliability, Observability, Migration, Testing, Open Questions, Implementation Phases, References.
docs/context/hld/ if needed.docs/context/hld/<name>-context.md<path>. Run /architecture-docs:hld-generate <path> to generate the HLD."Falls back to direct interactive gathering when no decisions file is provided.
Question areas: Scope Boundaries, Consumers & Expectations, Data Entities, External Systems, NFRs, Deployment & Rollout.
Dispatch parallel code + web research Tasks.
CHECKPOINT — Present findings.
Produce change map: files to modify/create/delete, config changes, schema changes.
CHECKPOINT — Present and organize into implementation phases.
Same template as Compiler Mode Phase 3, but without D-XX numbering.
Same as Compiler Mode Phase 4.
Interface with Blender (3D modeling, animation, rendering) through its Python API (bpy). Use whenever the user mentions Blender, .blend files, bpy, bmesh, geometry nodes, shader nodes, Cycles, EEVEE, Workbench, scene/object/material manipulation, mesh editing, armatures/rigging, keyframe animation, F-curves, drivers, NLA, importing/exporting 3D formats (GLTF/glb, FBX, OBJ, USD, STL, Alembic, Collada), batch rendering, headless render farms, CLI invocation (`blender --background --python`), authoring add-ons, custom operators/panels/menus, modal operators, PropertyGroups, Geometry Nodes trees, baking, simulation (cloth/fluid/rigid body), grease pencil, compositor nodes, or hooking Blender up to MCP / live AI control. Trigger even on vague asks like 'script Blender', 'automate Blender', 'render this from a script', or any 3D-graphics task where Blender is implied. Also trigger when the user asks to install bpy as a pip module or run Blender headless on a server.
Diagnose and fix Unraid (Lime Technology NAS OS) issues — array start/stop hangs, parity errors, disabled or emulated disks (red ball/red X), New Config and trust-parity, Docker macvlan/ipvlan call traces and custom networks, VM problems (KVM, libvirt, QEMU), GPU/USB/PCIe passthrough (IOMMU groups, VFIO, ACS override), BTRFS scrub/balance and ZFS pool degraded/corruption, mover and share allocation policies (high-water/most-free/fill-up), user shares vs disk shares, /mnt/user vs /mnt/cache vs /mnt/disk*, SMB/NFS permissions and newperms, Community Applications (CA) plugin and .plg install, /boot/config persistence, USB boot and GUID/license issues, syslog and diagnostics bundle interpretation, Fix Common Problems plugin, and version-aware release-notes lookup against docs.unraid.net. Use this whenever the user mentions Unraid, unRAID, Lime Tech NAS, or describes any symptom on an Unraid box — array won't stop, won't start, disk dropped, parity sync errors, container has no network, VM black screen, cache pool
Diagnose and fix Linux desktop issues — graphics drivers (Nvidia, AMD/Mesa, Intel), display servers (Wayland, X11, XWayland), audio (PipeWire, PulseAudio, Bluetooth), boot failures, systemd unit errors, suspend/hibernate, NetworkManager/Wi-Fi, kernel module problems, Flatpak/Snap sandbox breakage, and general desktop environment failures. Use this whenever the user reports ANY Linux desktop symptom — black screen, login loop, no audio, screen tearing, frozen cursor, GPU hangs, crashes after kernel update, broken external monitor, suspend doesn't work, app won't launch under Wayland, screen recording missing, Bluetooth pairing fails, or anything else where their Linux machine isn't behaving. Trigger even when the user just says 'my Linux is broken' or describes a vague desktop problem without naming the subsystem. Also use for proactive triage of dmesg/journalctl logs the user pastes, even if no explicit fix is requested.
Find every flaw in the overall approach and strategy of the code. Challenges whether the right problem is being solved, whether the algorithm is appropriate, whether assumptions are validated, and whether better alternatives exist. Produces severity-ranked issues with file:line references. Use when you want a dedicated approach review of code changes, files, or directories.
Find every flaw in the structural soundness, component design, and system organization of the code. Challenges whether boundaries are clean, coupling is minimized, dependencies flow correctly, and the module structure scales. Produces severity-ranked issues with file:line references. Use when you want a dedicated architecture review of code changes, files, or directories.
Find every violation of language and framework conventions, established patterns, and anti-patterns in the code. Challenges whether idioms are followed, APIs are designed correctly, and deprecated patterns are avoided. Produces severity-ranked issues with file:line references. Use when you want a dedicated best-practices review of code changes, files, or directories.