concave
Skill452 starsChanged 23 days agoApache-2.0View on GitHub
Skill: concave
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 16 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Use this skill for Concave-specific behavior and Concave-vs-Convex differences in this repo.
- Very specific: line 15
Use concave-parity when the task is specifically about parity gaps, local workarounds, or removing Concave-specific bandaids after upstream …
- Distinctive: line 18
Keep the boundary hard:
- Very specific: line 26
Do not restate generic Convex docs here.
- Distinctive: line 46
DO SQLite is the default document store on Cloudflare.
- Distinctive: line 144
Keep it small. This is a smoke lane, not a migration plan.
- Distinctive: line 164
Read the diff before calling it a bug.
- Very specific: line 185
if api.d.ts drifts again, treat it as a fresh upstream regression
- Distinctive: line 186
do not quietly resurrect the old overwrite helper
- Distinctive: line 193
Keep the smoke entry as:
- Very specific: line 201
Do not invent a second fake runtime layer on top of backend.
- Distinctive: line 211
Start with repo wiring:
- Very specific: line 230
do not add a second selector like --runtime concave
- Very specific: line 231
do not switch /example to Concave
- Very specific: line 232
do not migrate the big convex-test suites just because Concave exists
- Distinctive: line 233
do not document generic Convex APIs here
- Distinctive: line 234
do not assume Concave codegen output equals Convex codegen output
- Distinctive: line 238
When touching Concave repo-runtime wiring, run:
- Distinctive: line 248
If package code changed too, also run:
- Distinctive: line 258
When Concave docs or repo usage changes, update this skill with this exact loop.
- Distinctive: line 303
keep only Concave-specific behavior or Concave-vs-Convex differences
- Distinctive: line 304
keep repo-specific usage and mismatches
- Distinctive: line 305
do not restate generic Convex docs
- Very specific: line 320
If .claude/AGENTS.md changes, that is expected.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Concave
Scope
Use this skill for Concave-specific behavior and Concave-vs-Convex differences in this repo.
Use concave-parity when the task is specifically about parity gaps, local
workarounds, or removing Concave-specific bandaids after upstream catches up.
Keep the boundary hard:
- public kitcn CLI supports
backend: "concave"and--backend concave - public kitcn CLI still defaults to Convex
/examplestays on Convex- the big
convex-testsuites stay on Convex tooling - Concave is both a real kitcn backend and the repo's preferred agent/CI runtime lane
Do not restate generic Convex docs here. The convex skill already owns that.
Upstream Concave Facts That Actually Matter
These are the Concave-only facts worth keeping in your head.
Runtime model
- Concave is Convex-compatible, self-hosted, and multi-runtime.
- Supported runtimes marked production upstream:
- Cloudflare Workers
- Bun
- Node.js
- Bun is the default local runtime.
- Node.js requires 22.5+ and
--experimental-sqlite. - Cloudflare is the recommended production target.
Deployment shape
- Cloudflare uses Workers + Durable Objects.
- DO SQLite is the default document store on Cloudflare.
- D1 is optional when you need different scaling characteristics.
- R2 is only needed for
ctx.storage. - Self-hosted Bun/Node and desktop embeddings are single-instance by default because SQLite needs exclusive file access.
concave buildcan compile a standalone Bun-based binary; useful, but still single-instance with SQLite.
Local dev shape
concave devauto-picks runtime;--bun,--node, and--cfforce it.- alpha.14 defaults local dev to
3210. - Bun/Node local data lives in
./.concave/local. - Bun dev binds
0.0.0.0by default. That is LAN-visible.127.0.0.1is the safer local-only bind. - Local dashboard lives at
/_dashboard. - DevTools are web-only and designed around Vite/manual client init, not React Native.
Configuration / API differences
concave.config.tsis real Concave surface area.convex.jsonworks now. That matters here because kitcn already uses it.- Bun/Node use
createConcave(...). - Cloudflare uses explicit
defineConcaveRuntime(...)wiring. - Adapter choice is part of the product, not hidden infra:
- docstore
- blobstore
- module loading
- Cloudflare bindings
Compatibility gaps
- Vector search is only basic/brute-force in built-in adapters.
- Crons are planned, not done.
- Convex Auth is not supported.
- Streaming exports are not supported.
Testing stance upstream
convex-testis still valid for isolated function/unit tests.- Real E2E against Concave is done with
createConcave(...)plusConvexHttpClient. - Cross-runtime E2E is a real supported testing strategy upstream.
Current Repo Usage
We use Concave in two concrete ways.
Public backend selector
kitcn now resolves backend in this order:
--backend <convex|concave>meta["kitcn"].backendinconcave.json- default
convex
Public meaning:
convex=> drive Convex CLIconcave=> drive Concave CLI
Internal meaning:
- public
concavecurrently maps to the Bun adapter (concave-bun)
Files:
packages/kitcn/src/cli/config.tspackages/kitcn/src/cli/core.tspackages/kitcn/src/cli/cli.ts
Command shape:
- kitcn orchestration commands (
init,dev,codegen,deploy,migrate,aggregate,reset) run on the selected backend - unknown commands pass through to the selected backend CLI
kitcn env syncstays a kitcn helper- raw
kitcn env ...passthrough is Convex-only because Concave has no matching upstream env command
Concave smoke lane
Use:
bun run test:concaveFiles:
test/concave/run-smoke.tstest/concave/fixture/**
Runtime shape:
createConcave(...)SqliteDocStore(':memory:')ConvexHttpClient
Goal:
- generated kitcn runtime contract loads
- one mutation/query roundtrip works end-to-end
Keep it small. This is a smoke lane, not a migration plan.
Repo-Specific Concave Differences
Template sync/check uses the public backend selector
tooling/fixtures.ts runs local committed starter sync with
kitcn init -t <next|vite> --backend concave.
That means:
- committed
fixtures/*/convex/functions/_generated/*comes from the create flow running kitcn codegen against Concave-backed bootstrap - template-mode Concave codegen intentionally uses
concave codegen --static tooling/fixtures.tsitself must not shell out to rawkitcn codegen
_generated/* drift is expected
Concave-generated _generated/* output is not guaranteed to match Convex-generated output byte-for-byte.
Read the diff before calling it a bug.
staticDataModel mismatch is still real
Current repo finding:
fixtures/next/convex.jsonsetscodegen.staticDataModel: true- Concave-generated
fixtures/next/convex/functions/_generated/dataModel.d.tsis still dynamic
So today, in this repo path, Concave is not honoring that flag.
api.d.ts override is gone
Current repo truth:
- alpha.14 emits the same
api.d.tsshape our old source-backed override used to force - kitcn no longer post-writes
_generated/api.d.ts
Meaning:
- if
api.d.tsdrifts again, treat it as a fresh upstream regression - do not quietly resurrect the old overwrite helper
Use plain bun, not bun test, for the smoke lane
Root bun test preloads Happy DOM here.
That poisoned ConvexHttpClient behavior for the Concave smoke lane.
Keep the smoke entry as:
bun ./test/concave/run-smoke.tsKeep the adapter tiny
Do not invent a second fake runtime layer on top of backend.
The right model is:
- one public selector:
backend - one internal mapping:
concave-> current Bun adapter - native backend flags stay native
Read Before Editing
Start with repo wiring:
packages/kitcn/src/cli/backend-core.tspackages/kitcn/src/cli/commands/init.tspackages/kitcn/src/cli/commands/init.test.tstooling/fixtures.tstooling/fixtures.test.tstooling/scenarios.tstooling/scenarios.test.tstest/concave/run-smoke.tstest/concave/fixture/**.github/workflows/ci.yml
Then read Concave docs starting from:
https://docs.concave.dev/llms.txt
Do Not
- do not add a second selector like
--runtime concave - do not switch
/exampleto Concave - do not migrate the big
convex-testsuites just because Concave exists - do not document generic Convex APIs here
- do not assume Concave codegen output equals Convex codegen output
Verification
When touching Concave repo-runtime wiring, run:
bun test packages/kitcn/src/cli/commands/init.test.ts ./tooling/fixtures.test.ts ./tooling/scenarios.test.ts
bun test packages/kitcn/src/cli/cli.test.ts
bun run test:concave
bun run fixtures:check
bun run scenario:checkIf package code changed too, also run:
bun --cwd packages/kitcn build
bun lint:fix
bun typecheckSkill Sync
When Concave docs or repo usage changes, update this skill with this exact loop.
1. Re-read current repo wiring
rg -n "backend|concave-bun|test:concave|createConcave|@concavejs|Concave|--backend" \
package.json \
packages/kitcn/src/cli/backend-core.ts \
packages/kitcn/src/cli/config.ts \
packages/kitcn/src/cli/cli.ts \
packages/kitcn/src/cli/commands/init.ts \
packages/kitcn/src/cli/commands/init.test.ts \
tooling/fixtures.ts \
tooling/fixtures.test.ts \
tooling/scenarios.ts \
tooling/scenarios.test.ts \
test/concave \
.github/workflows/ci.yml \
-g '!**/_generated/**'2. Re-fetch the upstream Concave doc index
mkdir -p /tmp/concave-docs-fetch
curl -fsSL -A 'Mozilla/5.0' https://docs.concave.dev/llms.txt \
| tee /tmp/concave-docs-fetch/llms.txt3. Re-fetch every linked page from llms.txt
awk '
match($0, /(https:\\/\\/docs\\.concave\\.dev[^) ]+)/, m) { print m[1] }
' /tmp/concave-docs-fetch/llms.txt \
| nl -ba \
| while read -r n url; do
curl -fsSL -A 'Mozilla/5.0' "$url" >"/tmp/concave-docs-fetch/${n}.md"
done4. Rewrite this file with Concave-only facts
Rules:
- keep only Concave-specific behavior or Concave-vs-Convex differences
- keep repo-specific usage and mismatches
- do not restate generic Convex docs
5. Regenerate agent docs
bunx skiller@latest apply6. Validate the skill wiring
bun run intent:validate
bun run intent:staleIf .claude/AGENTS.md changes, that is expected. It is generated from .claude/**.
In this repository54 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- AGENTS.mdAGENTS.md
- .agents/skills/autoreview/AGENTS.mdAGENTS.md
- .agents/skills/autoreview/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- 4-ultraciteSkill
- agent-browser-issueSkill
- agent-native-reviewerSkill
- architecture-cleanupSkill
- autoclosureSkill
- autogoalSkill
- autoreviewSkill
- autoSkill
- avoid-feature-creepSkill
- better-auth-best-practicesSkill
- changeset-doc-syncSkill
- changeset-resolveSkill
- changesetSkill
- component-colocationSkill
- concave-paritySkill
- convex-release-auditSkill
- designSkill
- deslopSkill
- diagnosing-bugsSkill
- find-skillsSkill
- grill-with-visionSkill
- hard-cutSkill
- jotai-xSkill
- kitcnSkill
- linear-backlogSkill
- major-taskSkill
- next-dev-loopSkill
- nextjsSkill
- orchestratorSkill
- package-release-auditSkill
- prototypeSkill
- react-querySkill
- research-wikiSkill
- resolve-pr-feedbackSkill
- resolving-merge-conflictsSkill
- scenariosSkill
- shadcn-paritySkill
- sync-convex-authSkill
- sync-visionSkill
- taskSkill
- tddSkill
- testingSkill
- toastSkill
- to-milestoneSkill
- to-prdSkill
- turborepoSkill
- video-transcriptsSkill
- visionSkill
- walkthroughSkill
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.

