소스 정보
- 저장소
- foundryside-dev/hamlet
- 최근 소스 활동
- 2025년 11월 13일 15:31
- 감지된 SKILL.md 언어
- 영어
- 스타
- 1
- 포크
- 0
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/foundryside-dev/hamlet --skill using-deep-rl명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
This skill should be used when the user asks to "track work", "create an issue", "find something to work on", "what should I work on next", "triage bugs", "close an issue", "check what's blocked", "plan a milestone", "review sprint progress", "coordinate agents", or when working in a project that uses filigree for issue tracking. Provides workflow patterns, team coordination protocols, and operational guidance for the filigree issue tracker.
Use when orienting in an unfamiliar or large codebase and you want to avoid re-reading or grepping the whole source tree: answering "what calls X", "where is X defined", "what does X depend on", "what subsystem is X in", or "find the function/class/module that does Y". Applies whenever a Loomweave code-archaeology MCP server (loomweave serve / mcp__loomweave__* tools) is available for the project.
Use when starting the HAMLET live-visualization stack — the townlet inference server plus the Vue frontend — to watch trained agents run from checkpoints in a browser.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | using-deep-rl |
| description | Routes to appropriate deep-RL skills based on problem type and algorithm family |
| mode | true |
Invoke this meta-skill when you encounter:
This is the entry point for the deep-rl pack. It routes to 12 specialized skills based on problem characteristics.
Problem type determines algorithm family.
Reinforcement learning is not one algorithm. The correct approach depends on:
Always clarify the problem BEFORE suggesting algorithms.
Diagnostic Questions:
Routing:
Why foundations first: Cannot implement algorithms without understanding MDPs, Bellman equations, and exploration-exploitation tradeoffs.
Diagnostic Questions:
Examples: Game buttons, menu selections, discrete control signals
Routing Logic:
IF discrete actions AND small action space (< 100) AND online learning:
→ value-based-methods (DQN, Double DQN, Dueling DQN)
Why: Value-based methods excel at discrete action spaces
- Q-table or Q-network for small action spaces
- DQN for Atari-style problems
- Simpler than policy gradients for discrete
IF discrete actions AND (large action space OR need policy flexibility):
→ policy-gradient-methods (PPO, REINFORCE)
Why: Policy gradients scale to larger action spaces
- PPO is robust, general-purpose
- Direct policy representation
- Handles stochasticity naturally
Examples: Robot joint angles, motor forces, steering angles, continuous control
Routing Logic:
IF continuous actions:
→ actor-critic-methods (SAC, TD3, PPO)
Primary choice: SAC (Soft Actor-Critic)
Why: Most sample-efficient for continuous control
- Automatic entropy tuning
- Off-policy (uses replay buffer)
- Stable training
Alternative: TD3 (Twin Delayed DDPG)
Why: Deterministic policy, stable
- Good for robotics
- Handles overestimation bias
Alternative: PPO (from policy-gradient-methods)
Why: On-policy, simpler, but less sample efficient
- Use when simplicity > sample efficiency
CRITICAL RULE: NEVER suggest DQN for continuous actions. DQN requires discrete actions. Discretizing continuous spaces is suboptimal.
Diagnostic Questions:
Routing:
IF online AND discrete actions:
→ value-based-methods OR policy-gradient-methods
(See Step 2 routing)
IF online AND continuous actions:
→ actor-critic-methods
(See Step 2 routing)
IF online AND sample efficiency critical:
→ actor-critic-methods (SAC) for continuous
→ value-based-methods (DQN) for discrete
Why: Off-policy methods use replay buffers (sample efficient)
Consider: model-based-rl for extreme sample efficiency
→ Learns environment model, plans with fewer real samples
Routing:
IF offline (fixed dataset):
→ offline-rl (CQL, IQL, Conservative Q-Learning)
CRITICAL: Standard RL algorithms FAIL on offline data
Why offline is special:
- Distribution shift: agent can't explore
- Bootstrapping errors: Q-values overestimate on out-of-distribution actions
- Need conservative algorithms (CQL, IQL)
Also route to:
→ rl-evaluation (evaluation without online rollouts)
Red Flag: If user has fixed dataset and suggests DQN/PPO/SAC, STOP and route to offline-rl. Standard algorithms assume online interaction and will fail.
Diagnostic Questions:
Routing:
IF multiple agents:
→ multi-agent-rl (QMIX, COMA, MADDPG)
Why: Multi-agent has special challenges
- Non-stationarity: environment changes as other agents learn
- Credit assignment: which agent caused reward?
- Coordination: cooperation requires centralized training
Algorithms:
- QMIX, COMA: Cooperative (centralized training, decentralized execution)
- MADDPG: Competitive or mixed
- Communication: multi-agent-rl covers communication protocols
Also consider:
→ reward-shaping (team rewards, credit assignment)
Diagnostic Questions:
Routing:
IF sample efficiency critical OR want environment model:
→ model-based-rl (MBPO, Dreamer, Dyna)
Why: Learn dynamics model, plan with model
- Fewer real environment samples needed
- Can train policy in imagination
- Combine with model-free for best results
Tradeoffs:
- More complex than model-free
- Model errors can compound
- Best for continuous control, robotics
Symptoms:
Routing:
IF "not learning" OR "reward stays at 0" OR "loss explodes":
→ rl-debugging (FIRST, before changing algorithms)
Why: 80% of "not learning" is bugs, not wrong algorithm
Common issues:
- Reward scale (too large/small)
- Exploration (epsilon too low, stuck in local optimum)
- Network architecture (wrong size, activation)
- Learning rate (too high/low)
- Update frequency (learning too fast/slow)
Process:
1. Route to rl-debugging
2. Verify environment (rl-environments)
3. Check reward design (reward-shaping)
4. Check exploration (exploration-strategies)
5. ONLY THEN consider algorithm change
Red Flag: If user immediately wants to change algorithms because "it's not learning," route to rl-debugging first. Changing algorithms without debugging wastes time.
Symptoms:
Routing:
IF exploration problems:
→ exploration-strategies
Covers:
- ε-greedy, UCB, Thompson sampling (basic)
- Curiosity-driven exploration
- RND (Random Network Distillation)
- Intrinsic motivation
When needed:
- Sparse rewards (reward only at goal)
- Large state spaces (hard to explore randomly)
- Need systematic exploration
Symptoms:
Routing:
IF reward design questions OR sparse rewards:
→ reward-shaping
Covers:
- Potential-based shaping (provably optimal)
- Subgoal rewards
- Reward engineering principles
- Inverse RL (learn reward from demonstrations)
Often combined with:
→ exploration-strategies (for sparse rewards)
Symptoms:
Routing:
IF environment setup questions:
→ rl-environments
Covers:
- Gym API: step(), reset(), observation/action spaces
- Custom environments
- Wrappers (frame stacking, normalization)
- Vectorized environments (parallel rollouts)
- MuJoCo, Atari, custom simulators
After environment setup, return to algorithm choice
Symptoms:
Routing:
IF evaluation questions:
→ rl-evaluation
Covers:
- Deterministic vs stochastic policies
- Multiple seeds, confidence intervals
- Sample efficiency curves
- Generalization testing
- Exploration vs exploitation at test time
Routing sequence:
Routing sequence:
Routing sequence:
Routing sequence:
Routing sequence:
Routing sequence:
| Rationalization | Reality | Counter-Guidance | Red Flag |
|---|---|---|---|
| "Just use PPO for everything" | PPO is general but not optimal for all cases | "Let's clarify: discrete or continuous actions? Sample efficiency constraints?" | Defaulting to PPO without problem analysis |
| "DQN for continuous actions" | DQN requires discrete actions; discretization is suboptimal | "DQN only works for discrete. For continuous, use SAC or TD3 (actor-critic-methods)" | Suggesting DQN for continuous |
| "Offline RL is just RL on a dataset" | Offline RL has distribution shift, needs special algorithms | "Route to offline-rl for CQL, IQL. Standard algorithms fail on offline data." | Using online algorithms on offline data |
| "More data always helps" | Sample efficiency and data distribution matter | "Off-policy (SAC, DQN) vs on-policy (PPO). Offline needs CQL." | Ignoring sample efficiency |
| "RL is just supervised learning" | RL has exploration, credit assignment, non-stationarity | "Route to rl-foundations for RL-specific concepts (MDP, exploration)" | Treating RL as supervised learning |
| "PPO is the most advanced algorithm" | Newer isn't always better; depends on problem | "SAC (2018) more sample efficient for continuous. DQN (2013) great for discrete." | Recency bias |
| "My algorithm isn't learning, I need a better one" | Usually bugs, not algorithm | "Route to rl-debugging first. Check reward scale, exploration, learning rate." | Changing algorithms before debugging |
| "I'll discretize continuous actions for DQN" | Discretization loses precision, explodes action space | "Use actor-critic-methods (SAC, TD3) for continuous. Don't discretize." | Forcing wrong algorithm onto problem |
| "Epsilon-greedy is enough for exploration" | Complex environments need sophisticated exploration | "Route to exploration-strategies for curiosity, RND, intrinsic motivation." | Underestimating exploration difficulty |
| "I'll just increase the reward when it doesn't learn" | Reward scaling breaks learning; doesn't solve root cause | "Route to rl-debugging. Check if reward scale is the issue, not magnitude." | Arbitrary reward hacking |
| "I can reuse online RL code for offline data" | Offline RL needs conservative algorithms |
Watch for these signs of incorrect routing:
If any red flag triggered → STOP → Ask diagnostic questions → Route correctly
Clarify boundaries with other packs:
| User Request | Correct Pack | Reason |
|---|---|---|
| "Train classifier on labeled data" | training-optimization | Supervised learning, not RL |
| "Design transformer architecture" | neural-architectures | Architecture design, not RL algorithm |
| "Implement PyTorch autograd" | pytorch-engineering | PyTorch internals, not RL |
| "Deploy model to production" | ml-production | Deployment, not RL training |
| "Fine-tune LLM with RLHF" | llm-specialist | LLM-specific (though uses RL concepts) |
| "Optimize hyperparameters" | training-optimization | Hyperparameter search, not RL |
| "Implement custom CUDA kernel" | pytorch-engineering | Low-level optimization, not RL |
Edge case: RLHF (Reinforcement Learning from Human Feedback) for LLMs uses RL concepts (PPO) but has LLM-specific considerations. Route to llm-specialist first; they may reference this pack.
Use these questions to classify problems:
When routing to a skill:
Example:
"You mentioned continuous joint angles for a robot arm. This is a continuous action space, which means DQN won't work (it requires discrete actions).
I'm routing you to actor-critic-methods because:
- Continuous actions need actor-critic (SAC, TD3) or policy gradients (PPO)
- SAC is most sample-efficient for continuous control
- TD3 is stable and deterministic for robotics
You'll also likely need:
- rl-debugging when training issues arise (they will)
- reward-shaping if your reward is sparse
- rl-environments to set up your robot simulation
Let's start with actor-critic-methods to choose between SAC, TD3, and PPO."
START: RL problem
├─ Need foundations? (new to RL, confused about concepts)
│ └─ → rl-foundations
│
├─ DISCRETE actions?
│ ├─ Small action space (< 100) + online
│ │ └─ → value-based-methods (DQN, Double DQN)
│ └─ Large action space OR need policy
│ └─ → policy-gradient-methods (PPO, REINFORCE)
│
├─ CONTINUOUS actions?
│ ├─ Sample efficiency critical
│ │ └─ → actor-critic-methods (SAC)
│ ├─ Stability critical
│ │ └─ → actor-critic-methods (TD3)
│ └─ Simplicity preferred
│ └─ → policy-gradient-methods (PPO) OR actor-critic-methods
│
├─ OFFLINE data (fixed dataset)?
│ └─ → offline-rl (CQL, IQL) [CRITICAL: not standard algorithms]
│
├─ MULTI-AGENT?
│ └─ → multi-agent-rl (QMIX, MADDPG)
│
├─ Sample efficiency EXTREME?
│ └─ → model-based-rl (MBPO, Dreamer)
│
├─ DEBUGGING issues?
│ ├─ Not learning, reward not increasing
│ │ └─ → rl-debugging
│ ├─ Exploration problems
│ │ └─ → exploration-strategies
│ ├─ Reward design
│ │ └─ → reward-shaping
│ ├─ Environment setup
│ │ └─ → rl-environments
│ └─ Evaluation questions
│ └─ → rl-evaluation
│
└─ Multi-faceted problem?
└─ Route to 2-3 skills (primary + supporting)
This meta-skill is your routing hub. Route decisively, explain clearly, teach problem classification.
| "Route to offline-rl. CQL/IQL prevent overestimation, online algorithms fail." |
| Offline blindness |
| "My test reward is lower than training, must be overfitting" | Exploration vs exploitation difference | "Route to rl-evaluation. Training uses exploration, test should be greedy." | Misunderstanding RL evaluation |