@clawhub-muthukumaran-k-1-3d30d55fab
Weekly engineering retrospective. What shipped, what broke, what to improve, with concrete action items. Works directly in OpenClaw — no Claude Code session...
--- name: ucts-retro description: > Weekly engineering retrospective. What shipped, what broke, what to improve, with concrete action items. Works directly in OpenClaw — no Claude Code session needed. tags: [ucts, retrospective, engineering, team] --- # UCTS Retro Weekly engineering retrospective. This is a structured conversation — guide the user through each section. ## Format ### 🚀 What Shipped? List everything that shipped this week: - Features, fixes, improvements - PRs merged, deployments completed - Documentation updated For each item, note: - Did it take longer than expected? Why? - Any surprises during implementation? - What would you do differently? ### 💥 What Broke? List everything that went wrong: - Bugs found in production - Incidents, outages, reverts - Build failures, flaky tests - Missed deadlines For each item: - **Root cause** (not symptoms). Use /investigate methodology if needed. - **Impact**: who was affected, for how long? - **Was it preventable?** What guard would have caught it? ### 🔧 What to Improve? Identify friction points: - Process: what takes too long, what's manual that should be automated? - Tooling: what's broken, slow, or missing? - Knowledge: what did you have to learn the hard way? - Communication: what was unclear or undocumented? ### ✅ Action Items **Maximum 3.** More than 3 means none will get done. Each action item must have: - **Owner**: one person (not "the team") - **Deadline**: specific date (not "soon") - **Definition of done**: how do you know it's complete? Bad: "Improve testing" Good: "Add integration tests for the payment flow by Friday. Done = CI passes with payment tests." Bad: "Look into performance" Good: "Profile the /api/search endpoint, identify top bottleneck, open a PR with a fix by Wednesday." ## If Actions Require Code Spawn a Claude Code session: ``` Load UCTS. Run /ucts guide <action item description> ```
Product strategy session with 6 forcing questions. Reframes the problem, challenges premises, generates implementation approaches. Works directly in OpenClaw...
--- name: ucts-office-hours description: > Product strategy session with 6 forcing questions. Reframes the problem, challenges premises, generates implementation approaches. Works directly in OpenClaw — no Claude Code session needed. tags: [ucts, planning, product-strategy, office-hours] --- # UCTS Office Hours Run a structured product strategy session. This is a conversational skill — talk directly with the user. ## The 6 Forcing Questions Ask each question. Push back on vague answers. Demand specifics. ### 1. What's the specific pain? Not hypothetical. Real examples. Who screamed? What broke? When did it last happen? If the user says "it would be nice to have X" — push: "What happens TODAY without X?" ### 2. Who experiences this most acutely? Which user persona? How often? What's the cost of the status quo (in time, money, frustration)? "Everyone" is not an answer. Find the single person who suffers most. ### 3. What's the current workaround? If there is one, it tells you the actual need. If there isn't, why not? Workarounds reveal the minimum viable solution. ### 4. What does the 10-star experience look like? Dream big. If this worked perfectly — magic wand — what would it do? Then cut: what's the 7-star version? The 5-star? The 3-star MVP? ### 5. What's the narrowest wedge? The smallest possible thing that proves the concept works. Not the full vision — the first proof. It should be buildable in one session. If it takes a week, it's too big. ### 6. What's the one metric? Single number that tells you it's working. Not three metrics. One. "Users" is not a metric. "Daily active users who complete the core flow" is. ## After the Questions 1. **Challenge the framing.** Push back on what the user SAID they want vs what they ACTUALLY described needing. 2. **Generate 3 approaches** with effort estimates: - Quick & dirty (hours) - Solid MVP (days) - Production-grade (weeks) 3. **Recommend one.** Be opinionated. "Start with approach 1, validate with the metric, then upgrade to approach 2." 4. **If a Claude Code session is needed**, generate the dispatch: `Load UCTS. Run /ucts guide <refined description>`
Root cause debugging methodology. Systematic hypothesis-driven investigation with strict rules: no fixes without investigation, stop after 3 failed attempts....
--- name: ucts-investigate description: > Root cause debugging methodology. Systematic hypothesis-driven investigation with strict rules: no fixes without investigation, stop after 3 failed attempts. Works directly in OpenClaw — no Claude Code session needed. tags: [ucts, debugging, investigation, root-cause] --- # UCTS Investigate Systematic root-cause debugging. This is a methodology skill — guide the user through the process. ## Iron Law **No fixes without investigation.** Never guess-and-check. Never "try this and see." Understand the cause FIRST, then fix. ## Process ### 1. Reproduce Get the exact: - Steps to trigger the bug - Input that causes the failure - Environment (OS, Node version, browser, etc.) - Error message (exact text, not paraphrased) - Frequency: always, sometimes, only on Tuesdays? If you can't reproduce it, you can't fix it. Stop here until you can. ### 2. Hypothesize Form **3 hypotheses** about the root cause, ranked by probability: 1. Most likely: [specific mechanism] 2. Second most likely: [specific mechanism] 3. Dark horse: [unlikely but would explain everything] Each hypothesis must be **falsifiable** — you must be able to design a test that proves it wrong. ### 3. Trace For the top hypothesis, trace the data flow: - What enters the system? - What transformations happen? - Where does the expected path diverge from the actual path? - What state is wrong and when did it become wrong? ### 4. Test Design a **minimal test** that confirms or refutes the top hypothesis: - If confirmed → you found the root cause. Proceed to fix. - If refuted → move to hypothesis #2. Repeat trace + test. ### 5. The 3-Strike Rule After **3 failed fix attempts**, STOP. Reassess from scratch: - Are your hypotheses wrong? - Is the bug actually in a different layer? - Is there a simpler explanation you missed? - "The bug is in the code you trust most." ## When to Spawn Claude Code If the investigation requires reading code, running tests, or making changes: ``` Load UCTS. Run /investigate <bug description> ``` If the user just needs to think through the problem, stay in chat.
Smart task analysis with optimal tool prescription. Analyze any coding task by complexity, domain, scope, and risk — then prescribe the best combination of U...
--- name: ucts-guide description: > Smart task analysis with optimal tool prescription. Analyze any coding task by complexity, domain, scope, and risk — then prescribe the best combination of UCTS optimization tools. Works directly in OpenClaw without a Claude Code session. tags: [ucts, token-optimization, planning, task-analysis] --- # UCTS Smart Guide Analyze the user's task and prescribe the optimal Claude Code session configuration. ## When to use When the user describes any coding task — feature, bug fix, refactor, architecture, etc. — and you need to decide HOW to approach it optimally. ## Process ### 1. Classify the task | Dimension | Options | |-----------|---------| | **Complexity** | trivial, simple, moderate, complex, massive | | **Domain** | code, debug, refactor, feature, architecture, devops, docs, security, performance, migration | | **Scope** | single-file, multi-file, module, cross-module, full-repo, multi-repo | | **Risk** | none, low, medium, high, critical | **Signals to look for:** - "todo list", "script", "hello world" → trivial - "fix bug", "add test" → simple - "authentication", "OAuth", "API endpoint" → moderate - "microservice", "payment", "distributed" → complex - "redesign", "rewrite", "migration" → massive - "payment", "stripe", "encryption" → critical risk - "security", "OWASP", "vulnerability" → high risk ### 2. Prescribe the combo | Complexity | Caveman | Tools | Model | |-----------|---------|-------|-------| | **trivial** | ultra | Cache + Monitor | haiku-only | | **simple** | full | + Pruner, Fast Transform | haiku-default | | **moderate** | full | + LLMLingua, Semantic Cache, SWE-Pruner, RouteLLM, Repo Map | auto-route | | **complex** | lite | + AgentDiet, Hierarchical Memory, Swarm, /office-hours | auto-route | | **massive** | off/lite | + Observability, SPARC, all of the above | sonnet/opus | **Risk overrides:** - critical risk → caveman off (no compression on safety-critical work) - high risk → add `/careful` (destructive command blocking) - any security domain → add `/cso` after implementation ### 3. Generate the dispatch instruction Format for spawning a Claude Code session: ``` Load UCTS. Run /ucts guide <original task description> ``` For specific known patterns: - Security audit → `Load UCTS. Run /cso` - Code review → `Load UCTS. Run /review` - QA test → `Load UCTS. Run /qa <url>` - Feature → `Load UCTS. Run /ucts guide <desc>, approve, implement, /ship` - Plan only → `Load UCTS. Run /ucts guide <desc>, /office-hours, /autoplan. Save plan, don't implement.` ### 4. Show the user ``` 📋 Task: [description] 📊 Classification: [complexity] [domain] | [scope] | risk: [risk] 🎯 Combo: caveman:[level] + [Tool1] + [Tool2] + ... 💰 Estimated savings: [X]% Spawning Claude Code with: "Load UCTS. Run /ucts guide [task]" ```