// Ambiguity-first planning — identify and resolve unknowns before committing to a plan. Use when the user wants to plan, scope, or think through work before building.
Generate a paste-ready English (U.S.) App Store Optimization metadata file (ASO.md) for an iOS app by scanning its Swift/SwiftUI codebase. Produces App Name (30), Subtitle (30), Keywords (100), Promotional Text, Description, category recommendations, screenshot caption suggestions, IAP names, and a research-notes appendix grounded in the codebase. Use this skill whenever the user mentions ASO, App Store Optimization, App Store metadata, app store listing, app name, app subtitle, keywords field, App Store Connect copy, App Store keywords, app store description, promotional text, custom product pages, or wants help writing/auditing/improving the metadata for an iOS App Store submission — even if they don't say "ASO" explicitly. Also trigger when the user asks to prepare an app for submission, audit a listing for rejection risk, pick a category, or extract keywords from a codebase.
Review code against Conor's style guide — naming, progressive disclosure, function design, error handling, agentic patterns, and token economics. Use this skill whenever the user asks for a code review, says things like "review this", "check my code", "look over this PR", "roast this", asks for feedback on a diff/branch/file, or after finishing an implementation and wants a pass before commit. Also trigger proactively after substantial code changes where a self-review would catch issues. Produces a structured findings report grouped by severity (blocker / major / minor / nit) with file:line references and concrete suggested fixes — not generic platitudes.
Decompose the current session's jobs-to-be-done into a parallelizable task plan for an agent team. Assigns each task a model tier (haiku / sonnet / opus) and a specialist subagent when one fits. Organises work into dependency waves with no shared-file edits inside a wave to avoid merge conflicts. Use this skill whenever the user says "team this up", "use a team", "use agent teams", "delegate this", "split this work", "parallelize this", "fan this out", "divide and conquer", or otherwise asks to coordinate multiple agents on work already discussed in the session. Also trigger when the user says a task is big and wants help farming it out, or when they explicitly invoke /team-work.
Control Philips Hue lights from the CLI. Use this skill whenever the user wants to control smart lights, adjust brightness or color, manage lighting scenes, or automate lighting. Examples include turning lights on/off, setting brightness levels, changing colors, controlling multiple lights/rooms at once, discovering light bridges, or configuring Hue bridge connections. Works with individual lights, entire rooms, or batch operations across multiple devices.
Control Sonos speakers from the CLI using the `sonos` command. Translates natural language requests into sonos CLI commands for playback, volume, grouping, queue management, and music search. Use this skill whenever the user mentions Sonos, asks to play music on a speaker, control volume on a room, group or ungroup speakers, manage their Sonos queue, or references speaker names like "Kitchen" or "TV". Trigger phrases: "play X on Sonos", "turn up the kitchen speaker", "pause Sonos", "what's playing on Sonos", "group my speakers", "play my Sonos favorites", "Sonos volume", "skip track on Sonos", "add to Sonos queue".
Implement iOS 26 Liquid Glass effects in SwiftUI and UIKit. Use this skill whenever the user mentions liquid glass, glass effects, glassEffect, iOS 26 UI design, translucent navigation bars, glass morphing, GlassEffectContainer, or wants to add the new Apple glass material to their app. Also use when migrating an existing app's UI to iOS 26 style, or when the user asks about glass button styles, tab bar minimization, or the new sheet presentations.
| name | and-then |
| description | Ambiguity-first planning — identify and resolve unknowns before committing to a plan. Use when the user wants to plan, scope, or think through work before building. |
No plan survives unasked questions. This skill exhausts ambiguity before committing to a plan — preventing rework, missed edge cases, and scope surprises.
Use this skill when the user wants to plan a feature, scope out work, or think through a problem before building. Trigger phrases include "what would it take to...", "let's plan", "scope this", "think this through", "what are we missing", "before we start", or when the user describes something they want to build and there are unresolved questions that would lead to rework. Also use when a request feels underspecified and jumping straight to implementation would be premature.
Gathers project context silently (CLAUDE.md, recent PRs, codebase), extracts every ambiguity categorized as blocking or refinement, resolves what it can from code, then asks the user targeted questions until blocking ambiguity hits zero. Outputs issues, epics, or plan files matched to the scope of the work.
The most expensive line of code is the one you write before understanding the problem. Developers (and AI agents) have a bias toward action — start building, figure it out along the way. That works for small tasks but fails catastrophically for anything with moving parts. This skill forces the uncomfortable but valuable pause: "What don't we know yet?"
The goal isn't to ask endless questions. It's to identify the specific unknowns that would derail implementation, resolve as many as possible from the codebase itself, and only burden the user with questions that genuinely need their input. When the blocking unknowns are resolved, produce a plan that's grounded in reality.
Before asking the user a single question, build a mental model of the project and the request. This phase is silent — no output to the user.
Project context — Read CLAUDE.md, MEMORY.md, and any domain-specific docs they reference. Understand the project's architecture, conventions, and current state.
Recent work — Understand what's been happening lately:
gh pr list --state merged --limit 10 --json title,number,mergedAt,headRefName
git log main --oneline -15
Overlapping work — Check for existing issues, plans, or in-progress branches that touch the same area:
gh issue list --state open --limit 30 --json title,number,labels,body
Also check for plan files (e.g., ~/.claude/plans/) or similar project-management artifacts.
Codebase exploration — Glob and grep the areas the request touches. Read key files — models, services, views. Understand the current state before proposing a future state.
Start shallow. Go deeper only where ambiguity concentrates. If the request touches "the technique editor," read the technique editor. Don't read every file in the project. Use Explore agents for broad investigation when a shallow scan reveals the request is more cross-cutting than it first appeared.
The point of this phase is to enter the conversation informed — so your questions are sharp and your assumptions are grounded, not generic.
Analyze the user's request against everything you gathered. Identify every point of ambiguity, categorized:
| Category | What's unclear |
|---|---|
| Requirements | What exactly should this do? Expected behavior, acceptance criteria |
| Technical | How should this be built? Patterns, services, models, data flow |
| Scope | What's in vs out? Where are the boundaries? What's v1 vs follow-up? |
| Dependencies | What else is affected? What needs to exist first? What breaks? |
| UX | What does the user see? Edge cases, empty states, error states, flows |
| Domain | Terminology, business rules, domain-specific constraints |
Tag each ambiguity as one of:
This is the skill's most important behavior. For each ambiguity, attempt to resolve it from the codebase first:
When you resolve something from code, record it transparently:
"I was going to ask about X, but I found Y in
path/to/file:42, so I'm assuming Z."
This builds trust and lets the user correct wrong assumptions without being asked a question they'd find frustrating ("you could have just looked!").
Only surface ambiguities to the user that genuinely cannot be resolved from code.
Present the ambiguity tracker to the user, then begin asking questions to resolve the remaining unknowns.
Render this at the start, and update it after each round of questions:
## Ambiguity Tracker (N resolved, N blocking, N refinement)
### Blocking
- [x] ~~Which data model handles X?~~ → Found in Position.swift:89
- [ ] What should happen when the user has no sessions?
- [ ] Does this replace the existing flow or sit alongside it?
### Refinement
- [x] ~~Preferred animation style?~~ → User: "match existing transitions"
- [ ] Empty state copy/messaging
### Resolved from Code
- ~~Does a query service exist for X?~~ → Yes, EntityListService (Services/Query/EntityListService.swift)
- ~~What's the current navigation pattern?~~ → GraphRouter with recents (Shared/Navigation/GraphRouter.swift)
The tracker is alive — items get added as new ambiguity emerges from answers, and crossed out as things get resolved. It's not locked to the initial extraction.
1-3 atomic questions per round. Never overwhelm. Group related questions from the same category.
Show your reasoning. Explain why you're asking — what you found, what you checked, what you're unsure about. Context makes questions easier to answer.
Challenge assumptions. If the user said something that conflicts with codebase reality, say so directly: "You mentioned X, but the codebase currently does Y — should we change Y, or did you mean something different?"
Surface risks proactively. Don't wait to be asked. "This touches Z which has no tests," "This would require changing a shared component used by 5 views," "This data migration would affect all existing users."
Explore edge cases. "What happens when this fails?" / "What if the list is empty?" / "What about the user's first time seeing this?"
Question scope creep. "Is X actually needed for v1, or is it a follow-up?" Prefer shipping smaller things sooner.
Be collaborative — you're on the same team. But be thorough in a way that prevents rework:
Don't block on stylistic disagreements or purely theoretical concerns. Focus on things that would actually cause rework or bugs.
The resolution loop ends when:
Infer the right output format from the scope of the work:
| Signal | Likely Output |
|---|---|
| Small — fits in 1 PR, single session of work | Single issue with DoD, affected files, risks |
| Medium — 2-3 related PRs | Plan file or small set of linked issues |
| Large — multi-PR, cross-domain | Epic with atomic child issues |
Offer your opinion on how the work should be broken up. Prefer atomic PRs and independently-deliverable tickets. The user decides the final structure.
If existing issues or plans overlap with this work:
Don't assume GitHub Issues. Check for signals:
gh CLI available? GitHub Issues is likely.When producing issues or plans:
.github/ISSUE_TEMPLATE/)gh issue list --limit 5 --json title,body)## Summary
[1-3 sentences — what and why]
## Scope
- **In**: [what this covers]
- **Out**: [what's explicitly excluded]
## Implementation
- [ ] Step 1 — description (`path/to/file`)
- [ ] Step 2 — description (`path/to/file`)
## Files Affected
- `path/to/file` — what changes and why
## Risks & Open Questions
- [Unresolved refinement ambiguities]
- [Technical risks identified during interrogation]
## Definition of Done
- [ ] Golden path works
- [ ] Edge cases handled: [list them]
- [ ] Tests pass (if applicable)
- [ ] No regressions in adjacent features
For epics, create the parent first, then atomic child issues — each independently deliverable. Each child references the parent.
For plan files, match the project's plan format if one exists (check CLAUDE.md for conventions).
You're the thoughtful colleague who asks "but what about..." before anyone starts coding. Collaborative but thorough. A little adversarial — in the constructive sense. You're not blocking progress, you're preventing rework. You'd rather spend 10 minutes asking questions now than 2 hours refactoring later.
When you challenge something, explain why. When you surface a risk, propose a mitigation. When you question scope, suggest what to defer and why.