config

Name: config
Author: lucasfcosta

62stars1forks

How to install config?

lucasfcosta/backpressured/config

$npx -y skills add lucasfcosta/backpressured --skill config

Installs into the current project.

Summary

Sets up backpressure for a project — detects its check/run commands, writes or edits a BACKPRESSURE.md, verifies Playwright, and installs the MCP servers the loop uses. Runs ONLY when the user explicitly invokes /backpressured:config; never auto-trigger it.

Files · 1

View on GitHub

SKILL.md

1	# Backpressured — Config
2
3	## Overview
4
5	This is the setup step for the backpressure loop, not the loop itself. Its job is to produce a good `BACKPRESSURE.md` (the file the [[backpressured]] loop reads as authoritative project customization) and to make sure the MCP servers that loop relies on are installed and healthy.
6
7	Run only when the user types `/backpressured:config`. Do not start it from a `/goal`, a "backpressure" mention, or your own initiative — that is what `disable-model-invocation` enforces, and you must honor it.
8
9	You detect, then confirm — never silently guess and write. The user owns every value that lands in `BACKPRESSURE.md`.
10
11	## What you produce
12
13	1. A `BACKPRESSURE.md` at the project root (created, or edited if one exists).
14	2. A verified Playwright MCP, plus any auxiliary MCP servers the user opts into, registered in the project's `.mcp.json`.
15
16	## Keep the user oriented
17
18	This is an interactive setup, so the user should always know what you're doing and why — but don't make them read your work. Give one short, high-level note per phase, framed as conclusions, not process:
19
20	- Do: "Scanning the project to find its lint, test, and run commands…" · "Found it — tests run with `pnpm test`, the app starts via `docker compose up`. Confirm or correct each below." · "Setting up the Linear MCP — you'll finish sign-in with `/mcp` after."
21	- Don't: paste raw file contents, list every path you grepped, narrate each tool call, or think out loud. Report what you concluded, not how you searched.
22	- Keep secrets, `.env` contents, and long command output out of the chat — refer to them, never echo them.
23	- Present findings as a short, confirmable summary and ask in plain language; when you take an action (install an MCP, write the file), say what you did in one line.
24
25	## Step 1 — Create or edit?
26
27	Check for `BACKPRESSURE.md` at the project root.
28
29	- Absent → create mode: run detection (Step 2) and build the file from scratch.
30	- Present → edit mode (this is also how you "refresh"): read it, summarize back to the user what it currently says, and ask what they want to change. Also re-run detection and the project survey to surface anything new since last time — added scripts, new CI jobs or hooks, new project skills, MCP servers — and offer those as additions. Then edit in place: change only what's new or what the user asks for, and never clobber sections they already approved.
31
32	## Step 2 — Detect, then confirm (create mode)
33
34	Scan the repo and draft proposed values; then walk the user through each, letting them confirm or edit. Ask plainly for anything you cannot detect. Do not write the file until the user has confirmed. If the user confirms nothing worth recording (or cancels), writing no file is a fine outcome — the [[backpressured]] loop treats an absent `BACKPRESSURE.md` as "use the defaults", so don't manufacture one to feel complete.
35
36	\| What to capture \| Where to look \|
37	\|-----------------\|---------------\|
38	\| lint command \| `package.json` scripts, `Makefile`, CI config \|
39	\| test command + how to check coverage \| `package.json` scripts, test runner config, CI \|
40	\| typecheck / verification scripts \| `package.json` scripts, `Makefile`, a `commit_check.sh`-style script, CI \|
41	\| benchmark suite(s) + what counts as a regression \| bench dirs/scripts, `package.json`, CI \|
42	\| how to run the app locally (frontend / backend / deps) \| `docker-compose*`, framework markers, README / CONTRIBUTING run instructions, `Makefile`, existing run skills \|
43	\| how to seed or reset local data \| seed scripts (`seed`, `db:seed`), fixtures, README / `docs/`, `Makefile`, existing skills \|
44	\| credentials/secrets needed to run, seed, or authorize the app, and how to obtain each \| `.env.example` / `.env.sample` / `.env.template`, `docker-compose` `environment:` / `env_file:`, README / CONTRIBUTING \|
45	\| shipping convention (open a PR vs. merge from local) \| CI config, repo signals — otherwise ask \|
46
47	Gate on reality: no benchmark suite → no benchmark section; no app to run → no run section; not a git/GitHub repo → no shipping section.
48
49	The table is a starting point, not a closed list — stay open-minded. Any repeatable check that produces a clear pass/fail is candidate backpressure, even if it isn't named above. Look for project-specific gates in CI workflows (read each job), pre-commit / git hooks (`.pre-commit-config.yaml`, `husky`, `lint-staged`), and `Makefile` / `package.json` scripts — e.g. formatting, schema/migration checks, security or dependency scans, accessibility or i18n checks, mutation or contract tests, dead-code or bundle-size budgets, spell-check, licen

People who liked this also viewed

6 picks

Type

config

62stars1forks

View on GitHub

How to install config?

lucasfcosta/backpressured/config

$npx -y skills add lucasfcosta/backpressured --skill config

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Backpressured — Config
2
3	## Overview
4
5	This is the setup step for the backpressure loop, not the loop itself. Its job is to produce a good `BACKPRESSURE.md` (the file the [[backpressured]] loop reads as authoritative project customization) and to make sure the MCP servers that loop relies on are installed and healthy.
6
7	Run only when the user types `/backpressured:config`. Do not start it from a `/goal`, a "backpressure" mention, or your own initiative — that is what `disable-model-invocation` enforces, and you must honor it.
8
9	You detect, then confirm — never silently guess and write. The user owns every value that lands in `BACKPRESSURE.md`.
10
11	## What you produce
12
13	1. A `BACKPRESSURE.md` at the project root (created, or edited if one exists).
14	2. A verified Playwright MCP, plus any auxiliary MCP servers the user opts into, registered in the project's `.mcp.json`.
15
16	## Keep the user oriented
17
18	This is an interactive setup, so the user should always know what you're doing and why — but don't make them read your work. Give one short, high-level note per phase, framed as conclusions, not process:
19
20	- Do: "Scanning the project to find its lint, test, and run commands…" · "Found it — tests run with `pnpm test`, the app starts via `docker compose up`. Confirm or correct each below." · "Setting up the Linear MCP — you'll finish sign-in with `/mcp` after."
21	- Don't: paste raw file contents, list every path you grepped, narrate each tool call, or think out loud. Report what you concluded, not how you searched.
22	- Keep secrets, `.env` contents, and long command output out of the chat — refer to them, never echo them.
23	- Present findings as a short, confirmable summary and ask in plain language; when you take an action (install an MCP, write the file), say what you did in one line.
24
25	## Step 1 — Create or edit?
26
27	Check for `BACKPRESSURE.md` at the project root.
28
29	- Absent → create mode: run detection (Step 2) and build the file from scratch.
30	- Present → edit mode (this is also how you "refresh"): read it, summarize back to the user what it currently says, and ask what they want to change. Also re-run detection and the project survey to surface anything new since last time — added scripts, new CI jobs or hooks, new project skills, MCP servers — and offer those as additions. Then edit in place: change only what's new or what the user asks for, and never clobber sections they already approved.
31
32	## Step 2 — Detect, then confirm (create mode)
33
34	Scan the repo and draft proposed values; then walk the user through each, letting them confirm or edit. Ask plainly for anything you cannot detect. Do not write the file until the user has confirmed. If the user confirms nothing worth recording (or cancels), writing no file is a fine outcome — the [[backpressured]] loop treats an absent `BACKPRESSURE.md` as "use the defaults", so don't manufacture one to feel complete.
35
36	\| What to capture \| Where to look \|
37	\|-----------------\|---------------\|
38	\| lint command \| `package.json` scripts, `Makefile`, CI config \|
39	\| test command + how to check coverage \| `package.json` scripts, test runner config, CI \|
40	\| typecheck / verification scripts \| `package.json` scripts, `Makefile`, a `commit_check.sh`-style script, CI \|
41	\| benchmark suite(s) + what counts as a regression \| bench dirs/scripts, `package.json`, CI \|
42	\| how to run the app locally (frontend / backend / deps) \| `docker-compose*`, framework markers, README / CONTRIBUTING run instructions, `Makefile`, existing run skills \|
43	\| how to seed or reset local data \| seed scripts (`seed`, `db:seed`), fixtures, README / `docs/`, `Makefile`, existing skills \|
44	\| credentials/secrets needed to run, seed, or authorize the app, and how to obtain each \| `.env.example` / `.env.sample` / `.env.template`, `docker-compose` `environment:` / `env_file:`, README / CONTRIBUTING \|
45	\| shipping convention (open a PR vs. merge from local) \| CI config, repo signals — otherwise ask \|
46
47	Gate on reality: no benchmark suite → no benchmark section; no app to run → no run section; not a git/GitHub repo → no shipping section.
48
49	The table is a starting point, not a closed list — stay open-minded. Any repeatable check that produces a clear pass/fail is candidate backpressure, even if it isn't named above. Look for project-specific gates in CI workflows (read each job), pre-commit / git hooks (`.pre-commit-config.yaml`, `husky`, `lint-staged`), and `Makefile` / `package.json` scripts — e.g. formatting, schema/migration checks, security or dependency scans, accessibility or i18n checks, mutation or contract tests, dead-code or bundle-size budgets, spell-check, licen

People who liked this also viewed

6 picks

Type