ask-gabriel
Skill0 starsChanged 5 days agoMITView on GitHub
Use when the user asks which skill to run or is unsure what to do next, or when the agent is unsure which skill, rule, or path applies. Points to the matching journey instead of doing the work.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Gabriel-Lafrance/Skillsword for word, first seen Nov 6, 2026
Other versions1 project uses a version of this.
Word for word · 1
- Gabriel-Lafrance/Skills★ 0100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- analyzeSkill
- babysit-prSkill
- councilSkill
- gabriel-modeSkill
- grill-meSkill
- hillclimbSkill
- howSkill
- review-loopSkill
- reviewSkill
- rulesSkill
- setup-gabriel-skillsSkill
- takeover-prSkill
- taskSkill
- test-auditSkill
- verificationSkill
- whySkill
- write-ticketSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 64
Prefer /analyze then /task for a build.
- Distinctive: line 74
If the ask is unclear, ask for one sentence of intent.
- Distinctive: line 76
Run that skill only when the user says to (or said “just pick and go”).
- Very specific: line 78
When recommending /task, /analyze, /how, or /why, say they apply code-quality.md and code-structure.md.
- Very specific: line 84
No journey matches: use the On-ramps table, then the Skills table in AGENTS.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 when buildable |
| Fix a bug | /task |
| Audit or assess existing code or a whole repo, with no diff | /analyze |
| Build until X is true | /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 (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 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 |
| Ask for a council or a panel of models to review, compare alternatives, or give feedback | /council, independent judgments from multiple providers; the current owner adjudicates and keeps the shared budget |
| 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 (it applies user-experience.md and docs/design.md) |
| Raise a UI journey, slow path, or evaluation target to a score or goal over rated rounds | /hillclimb, with or without the slash; it picks UI, performance, or evaluation from the goal; a requested council fills the reviewer slot. Ordinary edits keep their existing route |
| Write or add tests | /verification proposes "Tests worth keeping" in its report; reply tests 1, or say yes when /review recommends a test. It 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 (prunes one evidenced batch and reports how to restore it; 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 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 by /verification, and only when the user asked for it or named it in the report or accepted a /review recommendation (testing.md). Ordinary edits do not get tests.
Process
The user asked which skill to run
- If the ask is unclear, ask for one sentence of intent.
- Recommend one next skill and the next one or two steps. Link the matching journey when there is one.
- Run that skill only when the user says to (or said “just pick and go”).
- Talk in ordinary words and spell out abbreviations. Skip chatbot closings and puffery.
- When recommending
/task,/analyze,/how, or/why, say they apply code-quality.md and code-structure.md.
The agent is unsure mid-work
- Match the work to a journey. Open it.
- Find the step you are on, and follow it: the skill to run, the rule to open, and the next move.
- 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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.