ask-gabriel

Ask Gabriel

The map of this pack. Recommend the next skill, or point to the journey that shows the whole path. Stay thin: load another skill's body only after the path is chosen.

Read when

• Nothing up front. Keep the rules in code-quality.md and code-structure.md out of this router: they already apply, and the next skill loads them.
• About to reply? Open the Plain language and Unslop sections of writing-style.md. Skip them and the recommendation reads like pack jargon.
• Unsure what the whole path looks like? Open the matching journey below. Skip it and you take the first step right and the third one wrong.

Journeys

Each journey follows one piece of work through the skills and rules, step by step, with the rule opened at each moment and the next move. They share one example domain (billing) and chain into each other. Their path and shapes beat the app's existing code, which is usually messy. An app sibling is copied only when it matches an example (cite a sibling).

The work	Journey
A new Feature, from ticket to ship, built on a strong foundation	new-feature.md
A follow-up that fits an existing seam, a named extension point where a new variant plugs in ("add PayPal")	follow-up-fits-the-seam.md
A follow-up that needs a seam first (Refactor, then Feature)	follow-up-needs-a-seam.md
A bug report, from investigation to fix	bug.md
A quick note to keep for later	quick-note.md

What one rule means in code (a Before/After, a pattern's folder tree): code-quality-examples.md and code-structure-examples.md.

On-ramps

Situation	Start with
Merge main into a branch, update a branch, or otherwise sync Git without requesting behavior changes	Git sync only: Git safety, conflicts, and incorporation; stop after a clean sync
A precise ticket with Gabriel's worker self-review and main-agent check loop	/gabriel-mode
Unsure which skill	Stay here and answer below
How something works, a walkthrough, ownership, or layering	/how
Why it was built this way, or the design rationale	/why
Fuzzy idea / research before a build	/analyze
Bug to investigate before anyone asks for a fix	/analyze → /task-with-tests when buildable
Fix a bug	/task-with-tests
Audit or assess existing code or a whole repo, with no diff	/analyze
Build until X is true	/task-with-tests (the default build; the user may refuse every test)
Build with no tests at all	/task
Coding style / is this diff clean?	/review (it applies code-quality.md; snippets in code-quality-examples.md). The steering list is principles.md, not a skill
Structure / folders / services / data shape	/analyze, then /task-with-tests (both apply code-structure.md; shapes in code-structure-examples.md)
Need a final implementation-ready Linear/GitHub ticket	/write-ticket
Ship a branch or pull request	shipping.md
Linear ticket → build	/task-with-tests with the ticket. Ship with those same rules
Pressure a decision, direction, or structure	/grill-me
Review local branch vs main, or an open GitHub PR	/review
Watch a PR until checks/reviews change	/babysit-pr, parent-owned watch and latest-head report
Repeat review and authorized fixes within a finite budget	/review-loop
Assess or revive an old PR against current intent	/takeover-pr
Choose browser or other tools	Harness-first discovery
Build a screen / frontend, or update the app UX source of truth	/task-with-tests (it applies user-experience.md and docs/design.md)
Explicitly invoke a bounded review-and-improve loop on a UI journey or a slow path	/hillclimb, only when named by the user; it picks the UI or performance variant from the goal. Ordinary UI or speed-up work keeps its existing route
Lock complex behavior with tests	/task-with-tests proposes tests after the grill and you can refuse every one. Ask for a test directly, or say yes when /review recommends a lock. Either way the agent follows testing.md
Verify changed behavior, or explicitly run all existing tests and QA the running app, a migration, an endpoint, or a job	/verification, scoped by behavior and risk; an explicit full-verification request runs all configured suites
Audit, prune, or clean up existing tests	/test-audit (reports evidence and waits for approval before deleting; campaign mode covers a whole subsystem)
Install this pack from skills.sh	/setup-gabriel-skills (asks where the skills and AGENTS.md go; manual copy only if install fails)

Prefer /analyze then /task-with-tests for a build. /how and /why stop after the mechanics or the rationale. Recommend only the skill names in this map; nested vs one-off is a fork inside that skill’s SKILL.md.

Git sync alone starts no build, review, or verification pipeline. Meaningful conflict resolutions need checks for affected behavior; selecting those checks is not permission to expand the task. Required repository checks and explicit user verification requests still apply.

/task splits the work and builds every slice itself. A test is written only when the user asked for it or accepted a /task behavior-lock brief or a /review recommendation (testing.md). Ordinary edits do not get tests.

Process

The user asked which skill to run

1. If the ask is unclear, ask for one sentence of intent.
2. Recommend one next skill and the next one or two steps. Link the matching journey when there is one.
3. Run that skill only when the user says to (or said “just pick and go”).
4. Talk in ordinary words and spell out abbreviations. Skip chatbot closings and puffery.
5. When recommending /task, /task-with-tests, /analyze, /how, or /why, say they apply code-quality.md and code-structure.md.

The agent is unsure mid-work

1. Match the work to a journey. Open it.
2. Find the step you are on, and follow it: the skill to run, the rule to open, and the next move.
3. No journey matches: use the On-ramps table, then the Skills table in AGENTS.md. Still unsure: ask the user one question with a recommended answer.

Anti-patterns

• Copying billing vendor names into an app that does not use them