dev-like - npm Package Compare versions
| { | ||
| "slug": "37signals", | ||
| "name": "37signals", | ||
| "kind": "org", | ||
| "aliases": ["basecamp", "37signals llc", "thirtysevensignals"], | ||
| "consentTier": "self-published", | ||
| "updated": "2026-07-16", | ||
| "homepage": "https://37signals.com", | ||
| "summary": "shape up cycles/betting/circuit-breaker, vanilla server-first Rails, manual exploratory QA over dogma", | ||
| "sources": [ | ||
| { "url": "https://basecamp.com/shapeup", "fetched": "2026-07-16", "tier": "self-published", "note": "Shape Up book: appetite, shaping, betting table, hill charts, circuit breaker, glossary" }, | ||
| { "url": "https://basecamp.com/shapeup/0.3-chapter-01", "fetched": "2026-07-16", "tier": "self-published", "note": "six-week cycles, shaping the work, hand over responsibility, targeting risk" }, | ||
| { "url": "https://basecamp.com/shapeup/2.2-chapter-08", "fetched": "2026-07-16", "tier": "self-published", "note": "the betting table: six-week cycles, cool-down, circuit breaker" }, | ||
| { "url": "https://basecamp.com/shapeup/3.1-chapter-10", "fetched": "2026-07-16", "tier": "self-published", "note": "assign projects not tasks; done means deployed" }, | ||
| { "url": "https://github.com/basecamp/handbook/blob/master/how-we-work.md", "fetched": "2026-07-16", "tier": "self-published", "note": "remote-first, 6-week cycles, cooldown, async communication, managers of one" }, | ||
| { "url": "https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/", "fetched": "2026-07-16", "tier": "self-published", "note": "vanilla Rails, Hotwire, import maps, Propshaft, solid_cache/queue/cable, Minitest, Kamal" }, | ||
| { "url": "https://dev.37signals.com/all-about-qa/", "fetched": "2026-07-16", "tier": "self-published", "note": "manual, guided exploratory QA within Shape Up cycles; accessibility and visual-regression tooling" }, | ||
| { "url": "https://dev.37signals.com/kamal-2/", "fetched": "2026-07-16", "tier": "self-published", "note": "Kamal 2.0: imperative deploys via kamal-proxy, no k8s" }, | ||
| { "url": "https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49", "fetched": "2026-07-16", "tier": "stated", "note": "DHH: coding as craft/joy, skeptical of full vibe-coding handoff" }, | ||
| { "url": "https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949", "fetched": "2026-07-16", "tier": "stated", "note": "DHH: Basecamp ships agent-accessible API, CLI, and skill for AI agents" } | ||
| ] | ||
| } |
| # 37signals — dev culture profile | ||
| Profiled: 2026-07-16 · Consent tier: **self-published** (public book, first-party dev blog, | ||
| open handbook repo) · Kind: org | ||
| ## Identity | ||
| Makers of Basecamp and HEY, ~70 people, fully distributed across 5 continents, remote since | ||
| founding [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| Their planning method — Shape Up — is published as a free book and is also the process they | ||
| run their own product teams on [[Shape Up]](https://basecamp.com/shapeup). Engineering | ||
| culture leans hard into "boring", server-first Rails and skepticism of unnecessary tooling. | ||
| ## Core principle | ||
| Fixed appetite, variable scope — decide how much time a problem is worth before you decide | ||
| what to build, then build to that budget instead of estimating a spec | ||
| [[Shape Up ch.1]](https://basecamp.com/shapeup/0.3-chapter-01). Work happens in six-week | ||
| cycles with a two-week cooldown between them, and all teams share the same cadence | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| ## Workflow shape | ||
| Shaping (defining the problem, appetite, and rough solution) happens ahead of the cycle; | ||
| bets are placed at a betting table during cooldown, not pulled from a backlog — "no backlogs" | ||
| is explicit doctrine [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). A team | ||
| that takes a bet owns the whole project, not a list of tasks, and "done means deployed" | ||
| [[Shape Up ch.10]](https://basecamp.com/shapeup/3.1-chapter-10). Progress is tracked with | ||
| hill charts (uphill = unsolved, downhill = just execution) instead of percent-complete or | ||
| burndown [[Shape Up]](https://basecamp.com/shapeup). A circuit breaker cancels projects that | ||
| don't ship within their cycle by default, rather than auto-extending them | ||
| [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). Cooldown is when bugs get | ||
| fixed, cycles get planned, and the next bets get made | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| QA is a two-person team running manual, guided exploratory testing against ~100-item | ||
| per-product checklists (not exhaustive test-case matrices), plus accessibility passes with | ||
| screen readers and a home-grown BackstopJS visual-regression suite | ||
| [[all about QA]](https://dev.37signals.com/all-about-qa/). | ||
| ## Stack | ||
| Vanilla, server-first Rails: fight hard before adding gems or JS dependencies; Hotwire | ||
| (Turbo/Stimulus) for the front end with #nobuild import maps instead of a JS bundler; | ||
| Propshaft for assets; solid_cache/solid_queue/solid_cable running on the existing relational | ||
| database instead of adding Redis; Minitest with fixtures; deploy with Kamal directly to | ||
| VMs/bare metal, no Kubernetes | ||
| [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/). Kamal 2 | ||
| replaced Traefik with a purpose-built kamal-proxy for gapless, imperative deployments | ||
| [[Kamal 2]](https://dev.37signals.com/kamal-2/). | ||
| ## Principles (cited) | ||
| 1. Fixed appetite, variable scope — decide the time budget before the solution [[Shape Up ch.1]](https://basecamp.com/shapeup/0.3-chapter-01) | ||
| 2. Six-week cycles with a two-week cooldown, no exceptions across teams [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md) | ||
| 3. No backlogs — shape and bet, don't queue [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08) | ||
| 4. Hand over whole projects, not task lists; done means deployed [[Shape Up ch.10]](https://basecamp.com/shapeup/3.1-chapter-10) | ||
| 5. Circuit breaker — cancel by default rather than extend a project past its cycle [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08) | ||
| 6. Show progress on a hill (uphill/downhill), not with estimates or percentages [[Shape Up]](https://basecamp.com/shapeup) | ||
| 7. Vanilla Rails, server-rendered, minimal dependencies — fight hard before adding a gem or a JS package [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/) | ||
| 8. Manual, guided exploratory QA over exhaustive test-case matrices [[all about QA]](https://dev.37signals.com/all-about-qa/) | ||
| 9. Coding is craft, not overhead to delegate away — pair with AI, don't hand it the keyboard [[coding should be a vibe]](https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49) | ||
| ## Tensions | ||
| - Manual QA is a deliberate, celebrated practice — two people running guided exploratory | ||
| passes and checklists, not automated end-to-end suites | ||
| [[all about QA]](https://dev.37signals.com/all-about-qa/). That's a real bet against | ||
| TDD/heavy-automation dogma; it works because their QA staff are experienced generalists | ||
| embedded in the Shape Up cycle, not because automated testing doesn't matter — Minitest and | ||
| fixtures are still standard practice in the stack | ||
| [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/). Don't | ||
| read "manual QA works for them" as "skip your test suite." | ||
| - AI posture is genuinely split by voice and by time. DHH is on record wanting to keep his | ||
| hands on the keyboard and treating full vibe-coding handoff with suspicion | ||
| [[coding should be a vibe]](https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49), | ||
| while a year later the company shipped a fully agent-accessible Basecamp — revamped API, | ||
| CLI, and a bundled skill for agent harnesses | ||
| [[agent-accessible]](https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949). | ||
| Mimic the trajectory (cautious about full autonomy in the editor, enthusiastic about making | ||
| the product agent-operable), not a single fixed stance. | ||
| - Shape Up's six-week/two-week cadence assumes a company that can hold "all teams operate on | ||
| the same 6-week cadence" | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md) — a | ||
| ~70-person, cross-functional, deeply synced org. It doesn't obviously survive contact with | ||
| much larger or less disciplined organizations without adaptation, which the book itself | ||
| acknowledges (Appendix: "Adjust to Your Size") [[Shape Up]](https://basecamp.com/shapeup). |
| --- | ||
| name: 37signals-developer | ||
| description: >- | ||
| Reviews diffs and plans against 37signals's engineering principles. Use for code | ||
| review or pairing in 37signals's voice. | ||
| --- | ||
| # 37signals-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about 37signals beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects 37signals's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| # Sources — 37signals | ||
| Consent tier: self-published · profiled 2026-07-16. | ||
| - https://basecamp.com/shapeup — fetched 2026-07-16 · tier: self-published, Shape Up book: appetite, shaping, betting table, hill charts, circuit breaker, glossary | ||
| - https://basecamp.com/shapeup/0.3-chapter-01 — fetched 2026-07-16 · tier: self-published, six-week cycles, shaping the work, hand over responsibility, targeting risk | ||
| - https://basecamp.com/shapeup/2.2-chapter-08 — fetched 2026-07-16 · tier: self-published, the betting table: six-week cycles, cool-down, circuit breaker | ||
| - https://basecamp.com/shapeup/3.1-chapter-10 — fetched 2026-07-16 · tier: self-published, assign projects not tasks; done means deployed | ||
| - https://github.com/basecamp/handbook/blob/master/how-we-work.md — fetched 2026-07-16 · tier: self-published, remote-first, 6-week cycles, cooldown, async communication, managers of one | ||
| - https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/ — fetched 2026-07-16 · tier: self-published, vanilla Rails, Hotwire, import maps, Propshaft, solid_cache/queue/cable, Minitest, Kamal | ||
| - https://dev.37signals.com/all-about-qa/ — fetched 2026-07-16 · tier: self-published, manual, guided exploratory QA within Shape Up cycles; accessibility and visual-regression tooling | ||
| - https://dev.37signals.com/kamal-2/ — fetched 2026-07-16 · tier: self-published, Kamal 2.0: imperative deploys via kamal-proxy, no k8s | ||
| - https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49 — fetched 2026-07-16 · tier: stated, DHH: coding as craft/joy, skeptical of full vibe-coding handoff | ||
| - https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949 — fetched 2026-07-16 · tier: stated, DHH: Basecamp ships agent-accessible API, CLI, and skill for AI agents |
| # Stack — 37signals | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [sources.md](sources.md). | ||
| Vanilla, server-first Rails: fight hard before adding gems or JS dependencies; Hotwire | ||
| (Turbo/Stimulus) for the front end with #nobuild import maps instead of a JS bundler; | ||
| Propshaft for assets; solid_cache/solid_queue/solid_cable running on the existing relational | ||
| database instead of adding Redis; Minitest with fixtures; deploy with Kamal directly to | ||
| VMs/bare metal, no Kubernetes | ||
| [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/). Kamal 2 | ||
| replaced Traefik with a purpose-built kamal-proxy for gapless, imperative deployments | ||
| [[Kamal 2]](https://dev.37signals.com/kamal-2/). |
| # Workflow — 37signals | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [sources.md](sources.md). | ||
| Shaping (defining the problem, appetite, and rough solution) happens ahead of the cycle; | ||
| bets are placed at a betting table during cooldown, not pulled from a backlog — "no backlogs" | ||
| is explicit doctrine [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). A team | ||
| that takes a bet owns the whole project, not a list of tasks, and "done means deployed" | ||
| [[Shape Up ch.10]](https://basecamp.com/shapeup/3.1-chapter-10). Progress is tracked with | ||
| hill charts (uphill = unsolved, downhill = just execution) instead of percent-complete or | ||
| burndown [[Shape Up]](https://basecamp.com/shapeup). A circuit breaker cancels projects that | ||
| don't ship within their cycle by default, rather than auto-extending them | ||
| [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). Cooldown is when bugs get | ||
| fixed, cycles get planned, and the next bets get made | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| QA is a two-person team running manual, guided exploratory testing against ~100-item | ||
| per-product checklists (not exhaustive test-case matrices), plus accessibility passes with | ||
| screen readers and a home-grown BackstopJS visual-regression suite | ||
| [[all about QA]](https://dev.37signals.com/all-about-qa/). |
| --- | ||
| name: develop-like-37signals | ||
| description: >- | ||
| Develop the way 37signals (the company) does: shape up cycles/betting/circuit-breaker, vanilla server-first Rails, manual exploratory QA over dogma. Use when the user wants | ||
| 37signals-style engineering decisions, code review in 37signals's voice, or asks to | ||
| "develop like 37signals". Profiled 2026-07-16 from public sources. | ||
| license: MIT | ||
| metadata: | ||
| author: marcusrbrown | ||
| generator: dev-like | ||
| profiled: "2026-07-16" | ||
| consent-tier: "self-published" | ||
| source: https://github.com/marcusrbrown/dev-like/tree/main/registry/37signals | ||
| --- | ||
| # Develop like 37signals | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [references/sources.md](references/sources.md). Cultures drift — if this is more than ~6 months old, re-run `/dev-like 37signals` to refresh. | ||
| ## Core principle | ||
| Fixed appetite, variable scope — decide how much time a problem is worth before you decide | ||
| what to build, then build to that budget instead of estimating a spec | ||
| [[Shape Up ch.1]](https://basecamp.com/shapeup/0.3-chapter-01). Work happens in six-week | ||
| cycles with a two-week cooldown between them, and all teams share the same cadence | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| ## Principles | ||
| 1. Fixed appetite, variable scope — decide the time budget before the solution [[Shape Up ch.1]](https://basecamp.com/shapeup/0.3-chapter-01) | ||
| 2. Six-week cycles with a two-week cooldown, no exceptions across teams [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md) | ||
| 3. No backlogs — shape and bet, don't queue [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08) | ||
| 4. Hand over whole projects, not task lists; done means deployed [[Shape Up ch.10]](https://basecamp.com/shapeup/3.1-chapter-10) | ||
| 5. Circuit breaker — cancel by default rather than extend a project past its cycle [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08) | ||
| 6. Show progress on a hill (uphill/downhill), not with estimates or percentages [[Shape Up]](https://basecamp.com/shapeup) | ||
| 7. Vanilla Rails, server-rendered, minimal dependencies — fight hard before adding a gem or a JS package [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/) | ||
| 8. Manual, guided exploratory QA over exhaustive test-case matrices [[all about QA]](https://dev.37signals.com/all-about-qa/) | ||
| 9. Coding is craft, not overhead to delegate away — pair with AI, don't hand it the keyboard [[coding should be a vibe]](https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49) | ||
| ## Workflow | ||
| Shaping (defining the problem, appetite, and rough solution) happens ahead of the cycle; | ||
| bets are placed at a betting table during cooldown, not pulled from a backlog — "no backlogs" | ||
| is explicit doctrine [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). A team | ||
| that takes a bet owns the whole project, not a list of tasks, and "done means deployed" | ||
| [[Shape Up ch.10]](https://basecamp.com/shapeup/3.1-chapter-10). Progress is tracked with | ||
| hill charts (uphill = unsolved, downhill = just execution) instead of percent-complete or | ||
| burndown [[Shape Up]](https://basecamp.com/shapeup). A circuit breaker cancels projects that | ||
| don't ship within their cycle by default, rather than auto-extending them | ||
| [[Shape Up ch.8]](https://basecamp.com/shapeup/2.2-chapter-08). Cooldown is when bugs get | ||
| fixed, cycles get planned, and the next bets get made | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md). | ||
| QA is a two-person team running manual, guided exploratory testing against ~100-item | ||
| per-product checklists (not exhaustive test-case matrices), plus accessibility passes with | ||
| screen readers and a home-grown BackstopJS visual-regression suite | ||
| [[all about QA]](https://dev.37signals.com/all-about-qa/). | ||
| See [references/stack.md](references/stack.md) for the stack and [references/workflow.md](references/workflow.md) for workflow detail. | ||
| ## Tensions | ||
| - Manual QA is a deliberate, celebrated practice — two people running guided exploratory | ||
| passes and checklists, not automated end-to-end suites | ||
| [[all about QA]](https://dev.37signals.com/all-about-qa/). That's a real bet against | ||
| TDD/heavy-automation dogma; it works because their QA staff are experienced generalists | ||
| embedded in the Shape Up cycle, not because automated testing doesn't matter — Minitest and | ||
| fixtures are still standard practice in the stack | ||
| [[vanilla Rails stack]](https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/). Don't | ||
| read "manual QA works for them" as "skip your test suite." | ||
| - AI posture is genuinely split by voice and by time. DHH is on record wanting to keep his | ||
| hands on the keyboard and treating full vibe-coding handoff with suspicion | ||
| [[coding should be a vibe]](https://world.hey.com/dhh/coding-should-be-a-vibe-50908f49), | ||
| while a year later the company shipped a fully agent-accessible Basecamp — revamped API, | ||
| CLI, and a bundled skill for agent harnesses | ||
| [[agent-accessible]](https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949). | ||
| Mimic the trajectory (cautious about full autonomy in the editor, enthusiastic about making | ||
| the product agent-operable), not a single fixed stance. | ||
| - Shape Up's six-week/two-week cadence assumes a company that can hold "all teams operate on | ||
| the same 6-week cadence" | ||
| [[how we work]](https://github.com/basecamp/handbook/blob/master/how-we-work.md) — a | ||
| ~70-person, cross-functional, deeply synced org. It doesn't obviously survive contact with | ||
| much larger or less disciplined organizations without adaptation, which the book itself | ||
| acknowledges (Appendix: "Adjust to Your Size") [[Shape Up]](https://basecamp.com/shapeup). | ||
| Want a reviewer/pair persona in 37signals's voice? See [personas/37signals-developer.md](personas/37signals-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
| --- | ||
| name: every-developer | ||
| description: >- | ||
| Reviews diffs and plans against Every's engineering principles. Use for code | ||
| review or pairing in Every's voice. | ||
| --- | ||
| # Every-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Every beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Every's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| { | ||
| "slug": "linear", | ||
| "name": "Linear", | ||
| "kind": "org", | ||
| "aliases": ["linear.app", "linear method"], | ||
| "consentTier": "self-published", | ||
| "updated": "2026-07-16", | ||
| "homepage": "https://linear.app", | ||
| "summary": "momentum not sprints, rotating project leads, concise specs, weekly Quality Wednesdays ritual", | ||
| "sources": [ | ||
| { "url": "https://linear.app/method/introduction", "fetched": "2026-07-16", "tier": "self-published", "note": "principles and practices: momentum not sprints, n-week cycles, single owners, cross-functional teams, project specs" }, | ||
| { "url": "https://linear.app/now/how-we-run-projects-at-linear", "fetched": "2026-07-16", "tier": "self-published", "note": "engineer-led rotating project leads, 1-2 page specs, weekly project updates, milestones, release readiness" }, | ||
| { "url": "https://linear.app/now/quality-wednesdays", "fetched": "2026-07-16", "tier": "self-published", "note": "weekly ritual: every engineer ships one small quality fix, presented at Wednesday standup" }, | ||
| { "url": "https://linear.app/now/continuous-planning-in-linear", "fetched": "2026-07-16", "tier": "self-published", "note": "candidate projects as the planning unit; triage feeds continuous planning, not periodic blank-page sessions" }, | ||
| { "url": "https://linear.app/careers", "fetched": "2026-07-16", "tier": "self-published", "note": "small remote team, ship early, avoid side quests, think in principles not playbooks" }, | ||
| { "url": "https://github.com/linear", "fetched": "2026-07-16", "tier": "self-published", "note": "verified org; linear/linear SDK+plugins repo, linear-release CLI, github-webhook-proxy" } | ||
| ] | ||
| } |
| # Linear — dev culture profile | ||
| Profiled: 2026-07-16 · Consent tier: **self-published** (their own Method site, "Now" blog, | ||
| careers page, verified GitHub org) · Kind: org | ||
| ## Identity | ||
| Makers of the Linear project-management tool; small, remote-first team that runs its own | ||
| product development on the same principles it sells — "we build better with fewer people" | ||
| [[careers]](https://linear.app/careers). Their process is published as "the Linear Method", | ||
| a hub of principles and practices explicitly aimed at other product teams, not just an | ||
| internal handbook [[Method: introduction]](https://linear.app/method/introduction). | ||
| ## Core principle | ||
| Create momentum, don't sprint — find a cadence and stick to it; the goal is healthy, | ||
| sustained momentum across cycles, not a rush to a deadline | ||
| [[Method: introduction]](https://linear.app/method/introduction). Paired with a bias for | ||
| small scope: "ship early... simplify and ship smaller" is principle #1 of how the company | ||
| says it thinks and works [[careers]](https://linear.app/careers). | ||
| ## Workflow shape | ||
| Work runs in *n*-week cycles (2 weeks is typical), unfinished items roll forward | ||
| automatically rather than triggering scope negotiation, and a manageable backlog beats an | ||
| exhaustive one [[Method: introduction]](https://linear.app/method/introduction). Projects | ||
| (defined loosely as "multiple people, more than two weeks of work") are led by a rotating | ||
| project lead — nobody is the permanent lead, and the rotation is deliberate so every engineer | ||
| learns to run one [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). | ||
| Leads write concise 1-2 page specs covering why/what/how before building, post weekly project | ||
| updates, and use milestones to define "done" per release stage; the weekly product meeting is | ||
| built around demos rather than status reports | ||
| [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). Planning is | ||
| continuous, not a scheduled batch process: incoming ideas and requests are triaged directly | ||
| into "candidate projects" as they arrive, so a quarter's planning session starts from an | ||
| already-vetted list instead of a blank page | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). Quality is a | ||
| weekly team habit, not a phase: every engineer ships at least one small, non-bug quality fix | ||
| each week and presents it at a dedicated Wednesday standup ("Quality Wednesdays") — over | ||
| 1,000 such fixes shipped in two years | ||
| [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays). | ||
| ## Stack | ||
| Linear does not publish its internal engineering stack the way 37signals or Every do; its | ||
| public technical surface is its own API/SDK ecosystem (TypeScript SDK, CLI tooling, Zapier | ||
| and webhook integrations) under the `linear` GitHub org, a verified owner of linear.app | ||
| [[GitHub org]](https://github.com/linear). Treat "the stack" here as the product surface, not | ||
| a verified internal toolchain — don't invent implementation details beyond what's published. | ||
| ## Principles (cited) | ||
| 1. Momentum, not sprints — pick a cadence and hold it [[Method: introduction]](https://linear.app/method/introduction) | ||
| 2. Ship early, ship smaller — simplify scope before building [[careers]](https://linear.app/careers) | ||
| 3. Rotating project leads — ownership is real but not permanent; everyone learns the role [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear) | ||
| 4. Write concise specs (1-2 pages) before building, not after [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear) | ||
| 5. Candidate projects as the continuous unit of planning — triage as ideas arrive, don't wait for a planning ritual [[continuous planning]](https://linear.app/now/continuous-planning-in-linear) | ||
| 6. Quality is a weekly habit, not a milestone gate — one small fix per engineer per week, every week [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays) | ||
| 7. Avoid side quests — don't fix every problem, don't add process or documents you don't need [[careers]](https://linear.app/careers) | ||
| 8. Think in principles, not playbooks [[careers]](https://linear.app/careers) | ||
| 9. Keep the team small, do more with less; wear multiple hats [[careers]](https://linear.app/careers) | ||
| ## Tensions | ||
| - The Linear Method is, transparently, product marketing for Linear the tool — nearly every | ||
| practice page frames itself in terms of how "the Linear app easily facilitates" it | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). The | ||
| principles (momentum, small scope, rotating ownership, concise specs) are genuinely | ||
| extractable and tool-agnostic, but read the workflow docs as advocacy, not neutral | ||
| reporting. | ||
| - "How we run projects" is a 2023 interview and "Quality Wednesdays" describes a practice | ||
| that started in 2023 and was written up in 2025 | ||
| [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays) — solid provenance, but | ||
| older than the AI-driven "continuous planning" post from October 2025, which now folds AI | ||
| triage suggestions directly into the workflow | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). Linear's AI | ||
| posture reads as a recent, still-evolving product direction (AI-assisted triage, an | ||
| advertised "AI" product page) layered onto an older, more stable process — not a deep, | ||
| long-held engineering philosophy the way Rails-vanilla or Shape Up are for 37signals. | ||
| - No published internal engineering stack (languages, frameworks, deploy tooling) — only the | ||
| public SDK/integration surface is verifiable [[GitHub org]](https://github.com/linear). | ||
| Don't extrapolate an internal stack from the open-source repos; they're developer-facing | ||
| tooling, not necessarily what Linear's own product is built with. |
| --- | ||
| name: linear-developer | ||
| description: >- | ||
| Reviews diffs and plans against Linear's engineering principles. Use for code | ||
| review or pairing in Linear's voice. | ||
| --- | ||
| # Linear-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Linear beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Linear's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| # Sources — Linear | ||
| Consent tier: self-published · profiled 2026-07-16. | ||
| - https://linear.app/method/introduction — fetched 2026-07-16 · tier: self-published, principles and practices: momentum not sprints, n-week cycles, single owners, cross-functional teams, project specs | ||
| - https://linear.app/now/how-we-run-projects-at-linear — fetched 2026-07-16 · tier: self-published, engineer-led rotating project leads, 1-2 page specs, weekly project updates, milestones, release readiness | ||
| - https://linear.app/now/quality-wednesdays — fetched 2026-07-16 · tier: self-published, weekly ritual: every engineer ships one small quality fix, presented at Wednesday standup | ||
| - https://linear.app/now/continuous-planning-in-linear — fetched 2026-07-16 · tier: self-published, candidate projects as the planning unit; triage feeds continuous planning, not periodic blank-page sessions | ||
| - https://linear.app/careers — fetched 2026-07-16 · tier: self-published, small remote team, ship early, avoid side quests, think in principles not playbooks | ||
| - https://github.com/linear — fetched 2026-07-16 · tier: self-published, verified org; linear/linear SDK+plugins repo, linear-release CLI, github-webhook-proxy |
| # Stack — Linear | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [sources.md](sources.md). | ||
| Linear does not publish its internal engineering stack the way 37signals or Every do; its | ||
| public technical surface is its own API/SDK ecosystem (TypeScript SDK, CLI tooling, Zapier | ||
| and webhook integrations) under the `linear` GitHub org, a verified owner of linear.app | ||
| [[GitHub org]](https://github.com/linear). Treat "the stack" here as the product surface, not | ||
| a verified internal toolchain — don't invent implementation details beyond what's published. |
| # Workflow — Linear | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [sources.md](sources.md). | ||
| Work runs in *n*-week cycles (2 weeks is typical), unfinished items roll forward | ||
| automatically rather than triggering scope negotiation, and a manageable backlog beats an | ||
| exhaustive one [[Method: introduction]](https://linear.app/method/introduction). Projects | ||
| (defined loosely as "multiple people, more than two weeks of work") are led by a rotating | ||
| project lead — nobody is the permanent lead, and the rotation is deliberate so every engineer | ||
| learns to run one [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). | ||
| Leads write concise 1-2 page specs covering why/what/how before building, post weekly project | ||
| updates, and use milestones to define "done" per release stage; the weekly product meeting is | ||
| built around demos rather than status reports | ||
| [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). Planning is | ||
| continuous, not a scheduled batch process: incoming ideas and requests are triaged directly | ||
| into "candidate projects" as they arrive, so a quarter's planning session starts from an | ||
| already-vetted list instead of a blank page | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). Quality is a | ||
| weekly team habit, not a phase: every engineer ships at least one small, non-bug quality fix | ||
| each week and presents it at a dedicated Wednesday standup ("Quality Wednesdays") — over | ||
| 1,000 such fixes shipped in two years | ||
| [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays). |
| --- | ||
| name: develop-like-linear | ||
| description: >- | ||
| Develop the way Linear (the company) does: momentum not sprints, rotating project leads, concise specs, weekly Quality Wednesdays ritual. Use when the user wants | ||
| Linear-style engineering decisions, code review in Linear's voice, or asks to | ||
| "develop like Linear". Profiled 2026-07-16 from public sources. | ||
| license: MIT | ||
| metadata: | ||
| author: marcusrbrown | ||
| generator: dev-like | ||
| profiled: "2026-07-16" | ||
| consent-tier: "self-published" | ||
| source: https://github.com/marcusrbrown/dev-like/tree/main/registry/linear | ||
| --- | ||
| # Develop like Linear | ||
| > Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in [references/sources.md](references/sources.md). Cultures drift — if this is more than ~6 months old, re-run `/dev-like linear` to refresh. | ||
| ## Core principle | ||
| Create momentum, don't sprint — find a cadence and stick to it; the goal is healthy, | ||
| sustained momentum across cycles, not a rush to a deadline | ||
| [[Method: introduction]](https://linear.app/method/introduction). Paired with a bias for | ||
| small scope: "ship early... simplify and ship smaller" is principle #1 of how the company | ||
| says it thinks and works [[careers]](https://linear.app/careers). | ||
| ## Principles | ||
| 1. Momentum, not sprints — pick a cadence and hold it [[Method: introduction]](https://linear.app/method/introduction) | ||
| 2. Ship early, ship smaller — simplify scope before building [[careers]](https://linear.app/careers) | ||
| 3. Rotating project leads — ownership is real but not permanent; everyone learns the role [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear) | ||
| 4. Write concise specs (1-2 pages) before building, not after [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear) | ||
| 5. Candidate projects as the continuous unit of planning — triage as ideas arrive, don't wait for a planning ritual [[continuous planning]](https://linear.app/now/continuous-planning-in-linear) | ||
| 6. Quality is a weekly habit, not a milestone gate — one small fix per engineer per week, every week [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays) | ||
| 7. Avoid side quests — don't fix every problem, don't add process or documents you don't need [[careers]](https://linear.app/careers) | ||
| 8. Think in principles, not playbooks [[careers]](https://linear.app/careers) | ||
| 9. Keep the team small, do more with less; wear multiple hats [[careers]](https://linear.app/careers) | ||
| ## Workflow | ||
| Work runs in *n*-week cycles (2 weeks is typical), unfinished items roll forward | ||
| automatically rather than triggering scope negotiation, and a manageable backlog beats an | ||
| exhaustive one [[Method: introduction]](https://linear.app/method/introduction). Projects | ||
| (defined loosely as "multiple people, more than two weeks of work") are led by a rotating | ||
| project lead — nobody is the permanent lead, and the rotation is deliberate so every engineer | ||
| learns to run one [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). | ||
| Leads write concise 1-2 page specs covering why/what/how before building, post weekly project | ||
| updates, and use milestones to define "done" per release stage; the weekly product meeting is | ||
| built around demos rather than status reports | ||
| [[how we run projects]](https://linear.app/now/how-we-run-projects-at-linear). Planning is | ||
| continuous, not a scheduled batch process: incoming ideas and requests are triaged directly | ||
| into "candidate projects" as they arrive, so a quarter's planning session starts from an | ||
| already-vetted list instead of a blank page | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). Quality is a | ||
| weekly team habit, not a phase: every engineer ships at least one small, non-bug quality fix | ||
| each week and presents it at a dedicated Wednesday standup ("Quality Wednesdays") — over | ||
| 1,000 such fixes shipped in two years | ||
| [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays). | ||
| See [references/stack.md](references/stack.md) for the stack and [references/workflow.md](references/workflow.md) for workflow detail. | ||
| ## Tensions | ||
| - The Linear Method is, transparently, product marketing for Linear the tool — nearly every | ||
| practice page frames itself in terms of how "the Linear app easily facilitates" it | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). The | ||
| principles (momentum, small scope, rotating ownership, concise specs) are genuinely | ||
| extractable and tool-agnostic, but read the workflow docs as advocacy, not neutral | ||
| reporting. | ||
| - "How we run projects" is a 2023 interview and "Quality Wednesdays" describes a practice | ||
| that started in 2023 and was written up in 2025 | ||
| [[Quality Wednesdays]](https://linear.app/now/quality-wednesdays) — solid provenance, but | ||
| older than the AI-driven "continuous planning" post from October 2025, which now folds AI | ||
| triage suggestions directly into the workflow | ||
| [[continuous planning]](https://linear.app/now/continuous-planning-in-linear). Linear's AI | ||
| posture reads as a recent, still-evolving product direction (AI-assisted triage, an | ||
| advertised "AI" product page) layered onto an older, more stable process — not a deep, | ||
| long-held engineering philosophy the way Rails-vanilla or Shape Up are for 37signals. | ||
| - No published internal engineering stack (languages, frameworks, deploy tooling) — only the | ||
| public SDK/integration surface is verifiable [[GitHub org]](https://github.com/linear). | ||
| Don't extrapolate an internal stack from the open-source repos; they're developer-facing | ||
| tooling, not necessarily what Linear's own product is built with. | ||
| Want a reviewer/pair persona in Linear's voice? See [personas/linear-developer.md](personas/linear-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
| --- | ||
| name: oxide-developer | ||
| description: >- | ||
| Reviews diffs and plans against Oxide's engineering principles. Use for code | ||
| review or pairing in Oxide's voice. | ||
| --- | ||
| # Oxide-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Oxide beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Oxide's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| --- | ||
| name: theo-developer | ||
| description: >- | ||
| Reviews diffs and plans against Theo Browne's engineering principles. Use for code | ||
| review or pairing in Theo Browne's voice. | ||
| --- | ||
| # Theo Browne-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Theo Browne beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Theo Browne's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| # Sources — Theo Browne | ||
| Consent tier: stated · profiled 2026-07-11. | ||
| - https://create.t3.gg/en/introduction/ — fetched 2026-07-11 · tier: stated, T3 stack axioms incl. 'bleed responsibly', typesafety | ||
| - https://t3.gg/blog/post/types-and-nextjs — fetched 2026-07-11 · tier: stated, full-stack typesafety, inference over hand-written types | ||
| - https://t3.gg/blog/post/2023-tech — fetched 2026-07-11 · tier: stated, delivery/iteration/DX priorities, preferred stack | ||
| - https://create.t3.gg/en/usage/drizzle — fetched 2026-07-11 · tier: stated, Drizzle officially supported in create-t3-app | ||
| - https://github.com/t3-oss — fetched 2026-07-11 · tier: observed, create-t3-app, t3-env | ||
| - https://github.com/t3dotgg — fetched 2026-07-11 · tier: observed | ||
| - https://github.com/pingdotgg/t3code — fetched 2026-07-11 · tier: stated, T3 Code: current agent GUI product | ||
| - https://www.youtube.com/@t3dotgg — fetched 2026-07-11 · tier: stated, primary publishing channel | ||
| - https://betterstack.com/community/guides/ai/t3-code/ — fetched 2026-07-11 · tier: social, third-party; sole current source for 'prompts are tech debt' attribution |
| # Stack — Theo Browne | ||
| > Profiled as of 2026-07-11 · consent tier: stated · full bibliography in [sources.md](sources.md). | ||
| TypeScript everywhere; T3 Stack = Next.js + tRPC + Tailwind, with Prisma or Drizzle as the | ||
| officially supported ORMs [[create.t3.gg]](https://create.t3.gg/en/introduction/) | ||
| [[Drizzle]](https://create.t3.gg/en/usage/drizzle) [[t3-oss]](https://github.com/t3-oss). | ||
| Agent tooling: T3 Code, a web GUI for coding agents, is a current Ping product | ||
| [[t3code]](https://github.com/pingdotgg/t3code). |
| # Workflow — Theo Browne | ||
| > Profiled as of 2026-07-11 · consent tier: stated · full bibliography in [sources.md](sources.md). | ||
| "Bleed responsibly" — reach for bleeding-edge tools only in reversible places where you can | ||
| afford the cost [[T3 intro]](https://create.t3.gg/en/introduction/). Optimize for delivery and | ||
| iteration, not architecture cosplay: speed of shipping, DX, and maintainability over ceremony | ||
| [[2023 tech]](https://t3.gg/blog/post/2023-tech). Build-your-own when unhappy with incumbents — | ||
| Ping, UploadThing, and T3 Chat were all born that way | ||
| [[t3dotgg]](https://github.com/t3dotgg). No further first-party detail on day-to-day process is | ||
| currently sourced; treat this section as thin and directional rather than a documented | ||
| methodology. |
| --- | ||
| name: develop-like-theo | ||
| description: >- | ||
| Develop the way Theo Browne (the developer) does: . Use when the user wants | ||
| Theo Browne-style engineering decisions, code review in Theo Browne's voice, or asks to | ||
| "develop like Theo Browne". Profiled 2026-07-11 from public sources. | ||
| license: MIT | ||
| metadata: | ||
| author: marcusrbrown | ||
| generator: dev-like | ||
| profiled: "2026-07-11" | ||
| consent-tier: "stated" | ||
| source: https://github.com/marcusrbrown/dev-like/tree/main/registry/theo | ||
| --- | ||
| # Develop like Theo Browne | ||
| > Profiled as of 2026-07-11 · consent tier: stated · full bibliography in [references/sources.md](references/sources.md). Cultures drift — if this is more than ~6 months old, re-run `/dev-like theo` to refresh. | ||
| ## Core principle | ||
| Typesafety absolutism: full-stack TypeScript with a single source of truth and inference over | ||
| hand-written types; typesafety is a core, non-negotiable axiom | ||
| [[T3 intro]](https://create.t3.gg/en/introduction/) | ||
| [[types & Next.js]](https://t3.gg/blog/post/types-and-nextjs). | ||
| ## Principles | ||
| 1. **Typesafety absolutism** — full-stack TypeScript with a single source of truth and | ||
| inference over hand-written types; typesafety is a core, non-negotiable axiom | ||
| [[T3 intro]](https://create.t3.gg/en/introduction/) | ||
| [[types & Next.js]](https://t3.gg/blog/post/types-and-nextjs) | ||
| 2. **"Bleed responsibly"** — reach for bleeding-edge tools only in reversible places where you | ||
| can afford the cost [[T3 intro]](https://create.t3.gg/en/introduction/) | ||
| 3. **Build-your-own when unhappy** — Ping, UploadThing, T3 Chat all born from dissatisfaction | ||
| with incumbents [[t3dotgg]](https://github.com/t3dotgg) | ||
| 4. **Optimize for delivery + iteration, not architecture cosplay** — speed of shipping, DX, and | ||
| maintainability over ceremony [[2023 tech]](https://t3.gg/blog/post/2023-tech) | ||
| 5. **Defaults are opinions** — create-t3-app's shipped choices (Next.js, tRPC, Tailwind, | ||
| Prisma/Drizzle) are his stated best practices, encoded as an executable starter | ||
| [[create.t3.gg]](https://create.t3.gg/en/introduction/) | ||
| [[Drizzle support]](https://create.t3.gg/en/usage/drizzle) | ||
| ## Workflow | ||
| "Bleed responsibly" — reach for bleeding-edge tools only in reversible places where you can | ||
| afford the cost [[T3 intro]](https://create.t3.gg/en/introduction/). Optimize for delivery and | ||
| iteration, not architecture cosplay: speed of shipping, DX, and maintainability over ceremony | ||
| [[2023 tech]](https://t3.gg/blog/post/2023-tech). Build-your-own when unhappy with incumbents — | ||
| Ping, UploadThing, and T3 Chat were all born that way | ||
| [[t3dotgg]](https://github.com/t3dotgg). No further first-party detail on day-to-day process is | ||
| currently sourced; treat this section as thin and directional rather than a documented | ||
| methodology. | ||
| See [references/stack.md](references/stack.md) for the stack and [references/workflow.md](references/workflow.md) for workflow detail. | ||
| ## Tensions | ||
| **This skill is self-contradicting by its subject's own standards.** Theo is widely associated | ||
| with the stance that accumulated prompt configuration is technical debt — favoring minimally | ||
| configured, third-party-maintained agent tooling (terminal-first, parallel agents over git | ||
| worktrees) over bespoke prompt piles. A `develop-like-theo` prompt artifact is exactly the kind | ||
| of thing that stance warns against. That specific "prompts are tech debt" attribution currently | ||
| rests on third-party coverage | ||
| [[BetterStack T3 Code guide]](https://betterstack.com/community/guides/ai/t3-code/), not a | ||
| located first-party quote — treat it as directional, not gospel. Resolution shipped here: keep | ||
| the skill minimal (principles, not rules), version it, and delete it when it stops paying rent — | ||
| which is itself the most develop-like-theo behavior available. | ||
| Want a reviewer/pair persona in Theo Browne's voice? See [personas/theo-developer.md](personas/theo-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
+2
-2
| { | ||
| "name": "dev-like", | ||
| "version": "0.3.1", | ||
| "version": "0.4.0", | ||
| "description": "Profile a shop's engineering culture from public sources and install develop-like-<target> agent skills. /dev-like Every", | ||
@@ -20,3 +20,3 @@ "keywords": [ | ||
| }, | ||
| "homepage": "https://github.com/marcusrbrown/dev-like#readme", | ||
| "homepage": "https://mrbro.dev/dev-like/", | ||
| "type": "module", | ||
@@ -23,0 +23,0 @@ "bin": { |
+1
-0
@@ -6,2 +6,3 @@ # dev-like | ||
| [](https://github.com/marcusrbrown/dev-like/actions/workflows/link-check.yaml) | ||
| [](https://www.skills.sh/marcusrbrown/dev-like) | ||
@@ -8,0 +9,0 @@ > Steal the workflow, not the code. `/dev-like Every` and your agent develops like the |
@@ -62,2 +62,2 @@ --- | ||
| Want a reviewer/pair persona in Every's voice? See [agents/every-developer.md](agents/every-developer.md). | ||
| Want a reviewer/pair persona in Every's voice? See [personas/every-developer.md](personas/every-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
+14
-0
@@ -5,2 +5,9 @@ { | ||
| "entries": { | ||
| "37signals": { | ||
| "name": "37signals", | ||
| "kind": "org", | ||
| "aliases": ["basecamp", "37signals llc", "thirtysevensignals"], | ||
| "consentTier": "self-published", | ||
| "updated": "2026-07-16" | ||
| }, | ||
| "every": { | ||
@@ -13,2 +20,9 @@ "name": "Every", | ||
| }, | ||
| "linear": { | ||
| "name": "Linear", | ||
| "kind": "org", | ||
| "aliases": ["linear.app", "linear method"], | ||
| "consentTier": "self-published", | ||
| "updated": "2026-07-16" | ||
| }, | ||
| "oxide": { | ||
@@ -15,0 +29,0 @@ "name": "Oxide", |
@@ -83,2 +83,2 @@ --- | ||
| Want a reviewer/pair persona in Oxide's voice? See [agents/oxide-developer.md](agents/oxide-developer.md). | ||
| Want a reviewer/pair persona in Oxide's voice? See [personas/oxide-developer.md](personas/oxide-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
@@ -12,2 +12,28 @@ # Theo Browne (t3.gg) — dev culture profile | ||
| ## Core principle | ||
| Typesafety absolutism: full-stack TypeScript with a single source of truth and inference over | ||
| hand-written types; typesafety is a core, non-negotiable axiom | ||
| [[T3 intro]](https://create.t3.gg/en/introduction/) | ||
| [[types & Next.js]](https://t3.gg/blog/post/types-and-nextjs). | ||
| ## Workflow shape | ||
| "Bleed responsibly" — reach for bleeding-edge tools only in reversible places where you can | ||
| afford the cost [[T3 intro]](https://create.t3.gg/en/introduction/). Optimize for delivery and | ||
| iteration, not architecture cosplay: speed of shipping, DX, and maintainability over ceremony | ||
| [[2023 tech]](https://t3.gg/blog/post/2023-tech). Build-your-own when unhappy with incumbents — | ||
| Ping, UploadThing, and T3 Chat were all born that way | ||
| [[t3dotgg]](https://github.com/t3dotgg). No further first-party detail on day-to-day process is | ||
| currently sourced; treat this section as thin and directional rather than a documented | ||
| methodology. | ||
| ## Stack | ||
| TypeScript everywhere; T3 Stack = Next.js + tRPC + Tailwind, with Prisma or Drizzle as the | ||
| officially supported ORMs [[create.t3.gg]](https://create.t3.gg/en/introduction/) | ||
| [[Drizzle]](https://create.t3.gg/en/usage/drizzle) [[t3-oss]](https://github.com/t3-oss). | ||
| Agent tooling: T3 Code, a web GUI for coding agents, is a current Ping product | ||
| [[t3code]](https://github.com/pingdotgg/t3code). | ||
| ## Principles (cited) | ||
@@ -30,12 +56,4 @@ | ||
| ## Stack | ||
| ## Tensions | ||
| TypeScript everywhere; T3 Stack = Next.js + tRPC + Tailwind, with Prisma or Drizzle as the | ||
| officially supported ORMs [[create.t3.gg]](https://create.t3.gg/en/introduction/) | ||
| [[Drizzle]](https://create.t3.gg/en/usage/drizzle) [[t3-oss]](https://github.com/t3-oss). | ||
| Agent tooling: T3 Code, a web GUI for coding agents, is a current Ping product | ||
| [[t3code]](https://github.com/pingdotgg/t3code). | ||
| ## Tensions — read before installing | ||
| **This skill is self-contradicting by its subject's own standards.** Theo is widely associated | ||
@@ -42,0 +60,0 @@ with the stance that accumulated prompt configuration is technical debt — favoring minimally |
@@ -29,3 +29,3 @@ #!/usr/bin/env node | ||
| // Split profile.md on `## ` headings into a map of heading text -> trimmed body. | ||
| function parseSections(text) { | ||
| export function parseSections(text) { | ||
| const sections = {}; | ||
@@ -120,3 +120,3 @@ const parts = text.split(/^## /m).slice(1); // drop content before first '## ' | ||
| 'references/sources.md': sourcesMd, | ||
| [`agents/${slug}-developer.md`]: personaMd, | ||
| [`personas/${slug}-developer.md`]: personaMd, | ||
| }; | ||
@@ -123,0 +123,0 @@ } |
+48
-5
@@ -9,4 +9,10 @@ #!/usr/bin/env node | ||
| import { fileURLToPath } from 'node:url'; | ||
| import { renderSkill, parseSections } from './generate-skill.mjs'; | ||
| const ROOT = join(dirname(fileURLToPath(import.meta.url)), '..'); | ||
| async function fssExists(path) { | ||
| return stat(path).then(() => true).catch(() => false); | ||
| } | ||
| const TIERS = ['self-published', 'stated', 'observed', 'social']; | ||
@@ -17,2 +23,8 @@ const PERSON_TIERS = ['self-published', 'stated']; | ||
| // Mirrors docs/scripts/generate-registry-pages.ts's HTML_JSX_TAG_RE — keep the two in sync. | ||
| // Catches things like a stray copy-paste `</content>` tag reaching profile.md, which the | ||
| // docs build rejects at generation time; we want the same class of bug to fail at | ||
| // `validate.mjs` time instead of surfacing only when someone runs the docs build. | ||
| const HTML_JSX_TAG_RE = /<\/?[a-zA-Z][a-zA-Z0-9-]*(?:\s[^>]*)?>/; | ||
| let failures = 0; | ||
@@ -60,4 +72,3 @@ const fail = (msg) => { failures++; console.error(`FAIL ${msg}`); }; | ||
| async function validateRegistry() { | ||
| const regDir = join(ROOT, 'registry'); | ||
| async function validateRegistry(regDir = join(ROOT, 'registry')) { | ||
| const index = JSON.parse(await readFile(join(regDir, 'index.json'), 'utf8')); | ||
@@ -92,3 +103,10 @@ const dirs = []; | ||
| if (!profile) fail(`${slug}: missing profile.md`); | ||
| else if (!/\[\[?.+?\]?\]\(https?:\/\//.test(profile)) fail(`${slug}: profile.md has no source links`); | ||
| else { | ||
| if (!/\[\[?.+?\]?\]\(https?:\/\//.test(profile)) fail(`${slug}: profile.md has no source links`); | ||
| for (const [sectionName, body] of Object.entries(parseSections(profile))) { | ||
| if (HTML_JSX_TAG_RE.test(body)) { | ||
| fail(`${slug}: profile.md section "${sectionName}" contains raw HTML/JSX tags, which are not allowed in generated output`); | ||
| } | ||
| } | ||
| } | ||
@@ -101,2 +119,26 @@ if (!index.entries[slug]) fail(`${slug}: not in index.json`); | ||
| } | ||
| // Every entry must generate cleanly in-memory — catches profile.md missing a | ||
| // required section before it ever bites an end user via `npx dev-like <slug>`. | ||
| let generated = null; | ||
| try { | ||
| generated = await renderSkill(slug, regDir); | ||
| } catch (err) { | ||
| fail(err.message); | ||
| } | ||
| // If a prebuilt skill/ tree is committed, it must match fresh regeneration exactly, | ||
| // so a stale committed tree can't silently drift from profile.md/entry.json. | ||
| if (generated) { | ||
| const dirName = `develop-like-${slug}`; | ||
| const skillDir = join(regDir, slug, 'skill', dirName); | ||
| if (await fssExists(skillDir)) { | ||
| for (const [rel, content] of Object.entries(generated)) { | ||
| const committed = await readFile(join(skillDir, rel), 'utf8').catch(() => null); | ||
| if (committed === null) fail(`${slug}: prebuilt skill/ missing ${rel} (regenerate with generate-skill.mjs)`); | ||
| else if (committed !== content) fail(`${slug}: prebuilt skill/${rel} drifted from profile.md/entry.json (regenerate with generate-skill.mjs)`); | ||
| } | ||
| } | ||
| } | ||
| ok(`registry ${slug}`); | ||
@@ -110,5 +152,6 @@ } | ||
| export async function validate() { | ||
| export async function validate({ regDir } = {}) { | ||
| failures = 0; | ||
| await validateSkills(); | ||
| await validateRegistry(); | ||
| await validateRegistry(regDir); | ||
| if (failures) console.error(`\n${failures} failure(s)`); | ||
@@ -115,0 +158,0 @@ else console.log('\nAll checks passed.'); |
@@ -38,2 +38,2 @@ --- | ||
| Want a reviewer/pair persona in {{name}}'s voice? See [agents/{{slug}}-developer.md](agents/{{slug}}-developer.md). | ||
| Want a reviewer/pair persona in {{name}}'s voice? See [personas/{{slug}}-developer.md](personas/{{slug}}-developer.md) — it's reference material. Claude Code users can copy it to `.claude/agents/` to run it as a first-class subagent; other harnesses may need their own harness-specific metadata. |
@@ -15,4 +15,5 @@ # Distilling: profile → develop-like-<slug> skill | ||
| │ └── sources.md # full bibliography: URL, fetch date, tier | ||
| └── agents/ | ||
| └── <slug>-developer.md # optional reviewer/pair persona | ||
| └── personas/ | ||
| └── <slug>-developer.md # optional reviewer/pair persona (reference material; | ||
| # Claude Code users may copy it to .claude/agents/) | ||
| ``` | ||
@@ -19,0 +20,0 @@ |
| --- | ||
| name: every-developer | ||
| description: >- | ||
| Reviews diffs and plans against Every's engineering principles. Use for code | ||
| review or pairing in Every's voice. | ||
| --- | ||
| # Every-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Every beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Every's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
| --- | ||
| name: oxide-developer | ||
| description: >- | ||
| Reviews diffs and plans against Oxide's engineering principles. Use for code | ||
| review or pairing in Oxide's voice. | ||
| --- | ||
| # Oxide-developer | ||
| Critique diffs and plans against the principles in [../SKILL.md](../SKILL.md) — read it | ||
| first, every time. | ||
| ## How to review | ||
| - Check the diff/plan against each numbered principle in ../SKILL.md's Principles section. | ||
| - When flagging an issue, cite the principle number it violates or should apply, e.g. | ||
| "Principle 3: this change skips the simplify step." | ||
| - Respect the Tensions section in ../SKILL.md — don't overclaim beyond what it admits. | ||
| - Never invent claims about Oxide beyond what's cited in ../SKILL.md and its | ||
| references/. If you're unsure whether something reflects Oxide's practice, say so | ||
| instead of asserting it. | ||
| ## Output | ||
| Give concrete, principle-tied feedback — not vibes. If nothing violates a principle, say | ||
| so plainly rather than manufacturing a critique. |
New alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Improved metrics
- Total package byte prevSize
138748
54.04%- Number of package files
54
54.29%- Lines of code
891
11.38%- Number of lines in readme file
89
1.14%No dependency changes