prior-art

Name: prior-art
Author: thoughtbot

15stars1forks

How to install prior-art?

thoughtbot/rails-consultant/prior-art

$npx -y skills add thoughtbot/rails-consultant --skill prior-art

Installs into the current project.

Summary

Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.

Files · 1

View on GitHub

SKILL.md

1	## Behavior
2
3	Research how this codebase handles `$ARGUMENTS`. Explore the codebase thoroughly and report what you find.
4
5	### Step 1: Search Broadly
6
7	Cast a wide net across the codebase. Use multiple search strategies:
8
9	- Grep for keywords — search for terms related to the concern (e.g. for error reporting: `error`, `exception`, `rescue`, `Sentry`, `Bugsnag`, `notify`, `report`)
10	- Check common Rails locations — initializers, middleware, concerns, base classes, config files, lib/
11	- Check the Gemfile — are there gems related to this concern? What do they tell you about the approach?
12	- Check application-level base classes — `ApplicationController`, `ApplicationRecord`, `ApplicationJob` — these often set patterns that everything inherits
13	- Check for dedicated directories or files — service objects, concerns, lib/ modules that handle this concern
14
15	Don't stop at the first result. The goal is to find every place this concern is handled — the consistent pattern and the exceptions.
16
17	### Step 2: Check Git History
18
19	For the key files involved in this concern:
20
21	- `git log --oneline -10 <file>` to see recent changes
22	- `git log --all --oneline --grep="<keyword>"` to find commits related to the concern
23	- Look for: when the pattern was established, whether it's evolved, any recent changes or migrations from one approach to another
24
25	Git history reveals whether a pattern is settled or in flux — critical context before you build on top of it.
26
27	### Step 3: Map What You Found
28
29	Report the findings in this order:
30
31	The pattern — describe the primary approach in plain English. One paragraph. "This codebase handles X by doing Y." If there's a clear convention, name it. If there are multiple approaches, name each.
32
33	Where it lives — list the key files and locations, grouped logically:
34
35	- Configuration (initializers, middleware, config)
36	- Base-level setup (ApplicationController, ApplicationRecord, etc.)
37	- Implementation files (services, concerns, models, specific controllers)
38	- Tests (how is this concern tested?)
39
40	For each file, include the path and a one-line description of its role.
41
42	The conventions — what rules does this codebase follow for this concern? Be specific:
43
44	- Is there a consistent pattern, or multiple approaches?
45	- Are there abstractions (base classes, modules, shared concerns) or is it ad-hoc?
46	- What naming conventions are used?
47	- Is there test coverage for this concern?
48
49	Inconsistencies — places where the pattern breaks or a different approach is used. Not a judgment — just "here's where it's different and what's different about it." These are the spots where you'd want to understand why before extending the pattern.
50
51	Git context — is this pattern stable, evolving, or recently changed? Any ongoing migrations or recent refactors worth knowing about?
52
53	How to extend it — given what exists, what's the right way to add to or build on this pattern? Follow the existing convention unless there's a good reason not to. Name the specific file or directory where new code should go, and the pattern it should follow.
54
55	---
56
57	## Output Format
58
59	Report in plain prose with clear headings. Include file paths for every reference. This is a research artifact — it should be useful as a reference doc for anyone working in this area of the codebase.
60
61	## Tone
62
63	Thorough and neutral. You're an archaeologist, not a critic. Report what exists, how it works, where it's consistent, and where it isn't. Save opinions for the "how to extend it" section — and even there, ground the recommendation in what the codebase already does.

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

prior-art

15stars1forks

View on GitHub

How to install prior-art?

thoughtbot/rails-consultant/prior-art

$npx -y skills add thoughtbot/rails-consultant --skill prior-art

Installs into the current project.

Summary

Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.

Files · 1

View on GitHub

SKILL.md

1	## Behavior
2
3	Research how this codebase handles `$ARGUMENTS`. Explore the codebase thoroughly and report what you find.
4
5	### Step 1: Search Broadly
6
7	Cast a wide net across the codebase. Use multiple search strategies:
8
9	- Grep for keywords — search for terms related to the concern (e.g. for error reporting: `error`, `exception`, `rescue`, `Sentry`, `Bugsnag`, `notify`, `report`)
10	- Check common Rails locations — initializers, middleware, concerns, base classes, config files, lib/
11	- Check the Gemfile — are there gems related to this concern? What do they tell you about the approach?
12	- Check application-level base classes — `ApplicationController`, `ApplicationRecord`, `ApplicationJob` — these often set patterns that everything inherits
13	- Check for dedicated directories or files — service objects, concerns, lib/ modules that handle this concern
14
15	Don't stop at the first result. The goal is to find every place this concern is handled — the consistent pattern and the exceptions.
16
17	### Step 2: Check Git History
18
19	For the key files involved in this concern:
20
21	- `git log --oneline -10 <file>` to see recent changes
22	- `git log --all --oneline --grep="<keyword>"` to find commits related to the concern
23	- Look for: when the pattern was established, whether it's evolved, any recent changes or migrations from one approach to another
24
25	Git history reveals whether a pattern is settled or in flux — critical context before you build on top of it.
26
27	### Step 3: Map What You Found
28
29	Report the findings in this order:
30
31	The pattern — describe the primary approach in plain English. One paragraph. "This codebase handles X by doing Y." If there's a clear convention, name it. If there are multiple approaches, name each.
32
33	Where it lives — list the key files and locations, grouped logically:
34
35	- Configuration (initializers, middleware, config)
36	- Base-level setup (ApplicationController, ApplicationRecord, etc.)
37	- Implementation files (services, concerns, models, specific controllers)
38	- Tests (how is this concern tested?)
39
40	For each file, include the path and a one-line description of its role.
41
42	The conventions — what rules does this codebase follow for this concern? Be specific:
43
44	- Is there a consistent pattern, or multiple approaches?
45	- Are there abstractions (base classes, modules, shared concerns) or is it ad-hoc?
46	- What naming conventions are used?
47	- Is there test coverage for this concern?
48
49	Inconsistencies — places where the pattern breaks or a different approach is used. Not a judgment — just "here's where it's different and what's different about it." These are the spots where you'd want to understand why before extending the pattern.
50
51	Git context — is this pattern stable, evolving, or recently changed? Any ongoing migrations or recent refactors worth knowing about?
52
53	How to extend it — given what exists, what's the right way to add to or build on this pattern? Follow the existing convention unless there's a good reason not to. Name the specific file or directory where new code should go, and the pattern it should follow.
54
55	---
56
57	## Output Format
58
59	Report in plain prose with clear headings. Include file paths for every reference. This is a research artifact — it should be useful as a reference doc for anyone working in this area of the codebase.
60
61	## Tone
62
63	Thorough and neutral. You're an archaeologist, not a critic. Report what exists, how it works, where it's consistent, and where it isn't. Save opinions for the "how to extend it" section — and even there, ground the recommendation in what the codebase already does.

People who liked this also viewed

6 picks

Type