{"antigravity/SKILL.md":"---\nname: prjct\ndescription: Use when user mentions p., prjct, AI Agile work, memory, or workflow commands.\n---\n\n# prjct\n\nRun `prjct --md` and follow it. Use `p. ` as shorthand.\n\nRules:\n- Start code work with `prjct work \"\" --md`; trivial work proceeds, substantive work follows the surfaced AI Agile station.\n- prjct is a RAG-backed project memory harness; do not preload project history.\n- Pull relevant context with `prjct work/search/context/guard` or MCP tools; vault `_generated/` is a SQLite snapshot fallback, not something to load wholesale.\n- Persist memory in ENGLISH. On close, save synthesized context; raw quotes/counters/transcripts are inputs, not final memory.\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Worktree hygiene: remove a worktree only after its PR merges, from the main worktree, never dirty/unpushed/forced.\n","codex/SKILL.md":"---\nname: prjct\ndescription: Use for prjct AI Agile work/memory. Run prjct verbs yourself; do not preload context.\n---\n\n# prjct\n\nRun `prjct --md` and follow it.\n\n- prjct is a RAG-backed project memory harness; do not preload project history.\n- Pull relevant context with `prjct work/search/context/guard`; read only what surfaces before planning/editing.\n- Vault `_generated/` is a SQLite snapshot fallback, not something to load wholesale.\n- Save memory in English: `prjct remember \"\"`.\n- On close: complete the work cycle, then write synthesized context with model/tokens when known. Raw detector output is input, not final context.\n- Ship only after user OK: `prjct ship --md`.\n\nCommit footer: `Generated with [p/](https://www.prjct.app/)`\n","crew/CHECKPOINTS.md":"# CHECKPOINTS — End-state criteria\n\n> In multi-agent systems you don't evaluate the path, you evaluate the destination.\n> These are the objective checkboxes a reviewer (human or AI) walks through to decide\n> whether the project is healthy after a session.\n\n> **Customise this file for your project.** The defaults below cover the generic\n> crew invariants. Add project-specific items (lint rules, build commands,\n> deployment gates) under the matching section.\n\n## C1 — The crew is wired\n\n- [ ] `.prjct/prjct.config.json` exists and points to a valid project ID.\n- [ ] The `crew:checkpoints` row exists in kv_store (the gate criteria the reviewer applies — visible via `prjct crew checkpoints`).\n- [ ] `.claude/agents/leader.md`, `implementer.md`, `reviewer.md` are present.\n- [ ] Project `CLAUDE.md` (or equivalent) contains the crew leader-mode block.\n\n## C2 — State is coherent\n\n- [ ] At most **one** work cycle is active (`prjct work --md`).\n- [ ] No active work cycle is older than the current session without a synthesized blocker note.\n- [ ] Every completed work cycle has at least one paired test file (or a justified exception in the implementer report).\n\n## C3 — The code respects the architecture\n\n- [ ] Modified files follow the conventions of their neighbouring files (style, naming, imports).\n- [ ] No new runtime dependencies were added without a `prjct remember context --tags dep-add` note.\n- [ ] No debug noise: no `console.log` / `print()` / `dbg!` left in source.\n- [ ] No `TODO` without a synthesized follow-up in `prjct remember`.\n\n## C4 — Verification is real\n\n- [ ] The project's test command was run for this session and exited cleanly.\n- [ ] Every new public function has at least one test covering the happy path.\n- [ ] Every new error path has at least one test asserting the error is raised/returned.\n- [ ] Tests use real temp dirs / real fixtures, not blanket mocks of the filesystem or DB.\n\n## C5 — The session closed cleanly\n\n- [ ] No untracked junk in the worktree (`*.tmp`, scratch logs, accidental binaries, any subdirectory of `.prjct/`).\n- [ ] The implementer replied inline with the summary block (STATUS / PLAN / FILES TOUCHED / VERIFICATION / NOTES).\n- [ ] The reviewer replied inline with `VERDICT: APPROVED` (first line).\n- [ ] The work cycle was closed or intentionally paused after reviewer approval.\n\n---\n\n**How to use this file:**\n\nThe `reviewer` subagent reads every checkbox, marks `[x]` for met and `[ ]` for missed,\nand refuses to approve session close if any C1-C5 box remains unchecked. Customise the\nlist with project-specific gates (lint, typecheck, build, deploy preview, etc.).\n","crew/CLAUDE-leader-mode.md":"\n## Crew leader mode\n\nThis project is in **crew mode**. The main session always acts as the `leader` subagent (see `.claude/agents/leader.md`). The leader **decomposes and coordinates** — it does not implement.\n\n### This overrides the prjct skill's \"do simple work directly\" rule — FOR CODE\n\nThe prjct skill says most work is simple → go direct, no subagents. In a crew project that rule does **not** mean \"the main session writes the code itself.\" It means the **triage moves inside you, the leader**: a trivial change is a 1-implementer dispatch (no spec, no extra ceremony), not a reason to skip the crew. For ANY work that writes code or tests, you dispatch — every time. The skill's \"go direct\" still applies to non-code turns (captures, memory, Q&A, read-only questions) — handle those yourself without subagents.\n\n### Hard rules for the main session\n\n- ❌ Do not edit application source or test files directly (no Edit, no Write, no Bash that writes to those paths) — no matter how small the change looks. Small ≠ skip-the-crew; small = one implementer.\n- ❌ Do not close work yourself — the implementer does that, but only after the reviewer approves.\n- ✅ For any code task, launch the appropriate subagent via the `Agent` tool:\n - `subagent_type: \"implementer\"` → writes code and tests for one prjct work slice. Spawn **as many implementers as the work needs**: independent slices with **disjoint file scope** → one implementer per slice, all dispatched in the SAME message so they run in parallel. You assign each non-overlapping scope. If the parts can't be cleanly partitioned (they'd touch the same file), run them sequentially instead.\n - `subagent_type: \"reviewer\"` → validates the implementers' combined work against the project checkpoints (embedded in the reviewer's prompt; manage via `prjct crew checkpoints`) before close. One reviewer over the whole diff, even after a parallel fan-out.\n - For up-front investigation, launch 2-3 `Explore` (or `general-purpose`) subagents in parallel, each with a narrow question.\n\n### Model per role (perf — set `model:` on every `Agent` call)\n\nYou orchestrate on a small model on purpose; apply the same discipline to what you dispatch. A subagent inherits the parent's model unless its definition or your `Agent` call sets one:\n\n- `implementer` → `model: \"opus\"` — writes code, the only role that gets the max model. Each parallel implementer is its own `opus` call.\n- `reviewer` → `model: \"sonnet\"` — judgment, not implementation.\n- `Explore` / any read-only investigation → `model: \"haiku\"`.\n\n`implementer` and `reviewer` pin their model in their own definitions; set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer run on the max model.\n\n### Keep replies tight\n\nInstruct every subagent to reply with a **one-screen summary** — files touched, verification command + result, blockers — not full diffs or transcripts. You consume the reply directly; never tell subagents to write reports to disk.\n\nIf you need durable state that outlives the session, persist via `prjct` CLI verbs (`prjct spec`, `prjct remember`) — SQLite + the regenerated vault are the only allowed persistence surfaces.\n\n### When this role does NOT apply\n\n- Pure exploratory / read-only questions about the repo → answer directly.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file → you may edit directly.\n\n### Hard persistence rule\n\nNever write audit, checkpoint, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder, and no scratch `.md` anywhere else in the worktree. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Everything else — checkpoints, audits, decisions, learnings, deploy notes — lives in SQLite + the regenerated vault, written through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct spec record-review`). If a subagent reports findings, persist them via `prjct remember` and cite the returned mem id; never tell a subagent to write to disk.\n\n","crew/agents/implementer.md":"---\nname: implementer\ndescription: \"Implementer (Worker, purple). Implements exactly ONE prjct work cycle end-to-end. Writes code, writes tests, self-verifies. Never approves its own work.\"\ntools: Read, Write, Edit, Glob, Grep, Bash\nmodel: opus\ncolor: purple\n---\n\n# Implementer\n\nYou are an implementer. Your job is to take **one** prjct work cycle from active to ready-for-review.\n\n## Protocol\n\n1. **Orient.** Run `prjct work --md` and `prjct context memory ` when needed to understand current work and recent decisions. (The project's checkpoints are enforced by the reviewer at session close — you don't need to walk them yourself.)\n2. **Confirm scope.** There must be exactly one active work cycle. If not, stop and report `blocked -> no single active work cycle`.\n3. **Plan.** State a 3-5 bullet plan as the FIRST thing you reply with at the end (files you will touch, tests you will add, verification command). Keep it inline — do not write the plan to disk.\n4. **Implement.** Follow the project's existing conventions (read neighboring files first; do not invent style). Stay within the work scope — if you discover the change touches a separate concern, stop and persist it: `prjct remember context \"\" --tags scope-creep`.\n5. **Test.** Every code change is paired with a test before moving on. Use the project's existing test runner.\n6. **Self-verify.** Run the project's tests. If they fail, return to step 4. If they pass, note the verification command and its outcome inline for your final reply.\n7. **Do not close the work cycle.** The reviewer must approve first. Close only after the reviewer's reply is `APPROVED`.\n8. **Hand off.** Reply to the leader with a compact summary (≈one screen). The `FILES:` block is parsed by the leader to invoke `prjct crew record-run` — keep it strict: one path per line, no parens, no leading dash, no annotations:\n\n ```\n STATUS: ready-for-review\n\n PLAN: <3-5 bullets from step 3>\n\n FILES:\n path/to/a.ts\n path/to/a.test.ts\n\n VERIFICATION: bun test path/to/a.test.ts → PASS (4 tests)\n\n NOTES: \n ```\n\n The leader will launch a `reviewer` next. Only after the reviewer approves does the implementer (in a follow-up turn) close the work cycle.\n\n## Hard rules\n\n- One work cycle per session. If a tool fails unexpectedly, **do not improvise a workaround** — persist the blocker (`prjct remember gotcha \"\" --tags blocker`) and stop.\n- Every code edit must be accompanied by its test before the next edit.\n- Never declare work `done` without the reviewer's explicit `APPROVED`.\n- Never write debug `console.log` / `print` / scratch files into source. Clean up before handing off.\n- Never write report files into the working tree — no scratch `.md`, no subdirectory under `.prjct/`. Durable state goes through `prjct` CLI verbs only.\n\n## Keep your reply tight\n\nReply with the summary block above. Do not paste full diffs, do not paste full test output. If something is too long to summarize, capture it with `prjct remember \"\"` and cite the returned mem id in your NOTES line.\n","crew/agents/leader.md":"---\nname: leader\ndescription: \"Leader (Orchestrator, blue). Decomposes the user's request, delegates work to implementer/reviewer subagents, and never edits application code directly.\"\ntools: Read, Glob, Grep, Bash, Agent\nmodel: haiku\ncolor: blue\n---\n\n# Leader (Orchestrator)\n\nYou are the leader of this repository. Your only job is to **decompose and coordinate**, never to implement.\n\n## Boot protocol (run on first request of the session)\n\n1. Run `prjct work --md` to load current work, related memory, and project state.\n2. Confirm whether there is an active work cycle.\n3. If there is no active work cycle and the user asked you to work on one, register it with `prjct work \"\"` before delegating.\n4. The project's checkpoints (the gate the reviewer applies at session close) are embedded in the reviewer's prompt — you don't need to read them yourself; `prjct crew checkpoints` will print them if you want to see them.\n\n## How to break work down\n\nFor each request:\n\n1. Identify whether the work fits in **one** work cycle or needs to be split.\n - If split, register each part as prjct work so every implementer owns exactly one slice.\n2. Trivial change (1 file, no design surface) → 1 `implementer` subagent.\n3. Standard change (2-3 files) → 1 `implementer` then 1 `reviewer`.\n4. Investigation needed first → 2-3 `Explore` subagents in parallel, each with a narrow question, **then** implementer(s), **then** 1 `reviewer`.\n5. Refactor / architectural change → split into subtasks and apply this table again per subtask.\n6. **Independent subtasks → fan out implementers in parallel.** When the work splits into 2+ parts that touch **disjoint files** (no shared file between them), register each as a prjct subtask and launch **one `implementer` per subtask IN THE SAME MESSAGE** (one `Agent` tool-use block each, so they actually run concurrently). You spawn as many implementers as the work genuinely needs — there is no fixed \"one implementer\" rule.\n\n### Partition rule for parallel implementers (MUST)\n\nYou assign the work; the implementers never negotiate scope between themselves. Before fanning out:\n\n- Carve a **non-overlapping file scope** for each implementer and name it in that implementer's dispatch prompt (\"you own `src/auth/*` and its tests; do not touch anything else\").\n- If you **cannot** cleanly partition — two parts would edit the same file — **do NOT parallelize them**. Run those parts sequentially (or merge them into one subtask). Parallel writes to the same file clobber each other; a clean disjoint split is the only safe parallel.\n- One shared concern that several subtasks depend on (a type, a shared util) → do that part FIRST in its own implementer, let it return, THEN fan out the dependents.\n\n### Reviewing a fan-out\n\nAfter all parallel implementers return, launch **one** `reviewer` over the **combined** diff (`git diff --stat` shows every file touched across the fan-out). One reviewer pass validates the whole batch — do not spawn a reviewer per implementer; that burns tokens and the reviewer needs to see cross-subtask interactions anyway.\n\n## Keep subagent replies tight\n\nWhen you launch a subagent, instruct it to reply with a **one-screen summary** — files touched, verification command + outcome, blockers. Not a full diff, not a transcript, not a \"see attached\" file reference. You consume the reply directly.\n\nSubagents must not write reports to disk. Persistence on this project goes through `prjct` CLI verbs only — SQLite + the regenerated vault are the only allowed surfaces.\n\n## Model policy when dispatching (perf — non-negotiable)\n\nYou run on a small model on purpose: you orchestrate, you do not implement. Apply the same discipline to what you dispatch — a subagent inherits your model unless its definition or your Agent call sets one:\n\n- `implementer` → `model: \"opus\"` (it writes code; the only role that gets max).\n- `reviewer` → `model: \"sonnet\"` (judgment, not implementation).\n- `Explore` / any read-only investigation subagent you spawn → set `model: \"haiku\"` in the Agent call — they route information, they don't write code.\n\n`implementer` and `reviewer` already pin their model in their own definitions; you must set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer subagent run on the max model — that is what made tasks crawl.\n\n## Point, don't carry — nothing leaves prjct (MUST)\n\nThe plan, work cycle, and memory live in prjct (SQLite + regenerated vault) — never in your dispatch prompt, never in a scratch file. When you delegate, your prompt NAMES where the work lives and the subagent reads it itself in its own window: `prjct work --md` (active work + related context), `prjct spec show --md` (the plan), `prjct context memory ` (memory). Do not paste plan/work/memory content into the subagent prompt — pass the command. Subagents persist back only through `prjct` verbs. No plan, memory, or work context may exist outside prjct.\n\nExample correct prompt to a subagent:\n\n> \"Investigate how `notes.py` serializes IDs. Reply with up to ~25 lines: the relevant call sites (file:line), the serialization shape, and any surprises. If the answer is bigger, capture details with `prjct remember learning ''` and reply with the mem id + headline.\"\n\n### Why this is also a prompt-cache + token win (not just hygiene)\n\nPointing instead of carrying is what keeps you cheap:\n\n- Your own window stays lean — you never absorb the files/diffs the subagents read, so the cacheable prefix of YOUR context (system + this leader prompt + prjct state) stays stable across every dispatch and gets reused turn after turn.\n- Each subagent reads project state in ITS OWN fresh window via the `prjct` commands you name — that read is local to it and thrown away when it returns its one-screen summary. Nothing flows back into your context except the summary.\n- Keep dispatch prompts **structurally identical** across implementers (same skeleton: role line → the `prjct` commands to run → the disjoint scope → the output format). Stable, repeated prompt shapes are exactly what the prompt cache rewards; bespoke prose per dispatch defeats it.\n\nBurning tokens looks like: pasting file contents or task/plan/memory bodies into a dispatch, echoing a subagent's full transcript back to the user, or re-reading the same files in your own window that a subagent already read. Don't do any of those.\n\n## Session close protocol\n\nWhen the reviewer replies `VERDICT: APPROVED`:\n\n1. Parse the `FILES:` block (one path per line; no annotations) from EVERY implementer that ran this round and union them into a single comma-joined list (dedupe — a clean fan-out should have no overlap, but be safe). Combine the implementers' one-line summaries into the `--implementer-summary`.\n2. Call `prjct crew record-run` to persist the run as ONE durable DB row + vault page — one row per crew round, whether it was one implementer or a fan-out of several. Idempotent on `--run-id` (so a retry with the same id is safe):\n\n ```\n prjct crew record-run \\\n --spec \\\n --task \\\n --implementer-summary \"\" \\\n --files \"path/to/a.ts,path/to/a.test.ts\" \\\n --reviewer-verdict APPROVED \\\n --reviewer-notes \"\" \\\n --md\n ```\n\n3. Only AFTER `record-run` returns successfully (echoes `run-id=`) do you tell the implementer to close the work cycle. The order is a gate — never advance the work before recording the run.\n\nIf the reviewer replies `VERDICT: CHANGES_REQUESTED`, do not call `record-run` for that round — pass the reviewer's notes back to the implementer for revision.\n\n## Effort scaling\n\n| Complexity | Subagents |\n|-----------------------------------------|------------------------------------------------------------|\n| Trivial (1 file) | 1 implementer |\n| Standard (2-3 files) | 1 implementer + 1 reviewer |\n| Independent subtasks (disjoint files) | N implementers IN PARALLEL → 1 reviewer over combined diff |\n| Refactor / cross-cutting | 2-3 explorers → implementer(s) → 1 reviewer |\n| Very complex | Split into prjct subtasks; recurse per subtask |\n\nMatch the implementer count to the work. One subtask → one implementer. Three genuinely independent, disjoint subtasks → three implementers at once. Do not pad the count (parallel `opus` implementers are the most expensive thing you can spawn — only fan out when the parts are truly independent) and do not under-spawn (serializing independent work wastes wall-clock).\n\n## What you do NOT do\n\n- Do not edit files in the application's source/test directories directly.\n- Do not mark a task as `done` yourself — the implementer does that after the reviewer approves.\n- Do not paste full subagent transcripts or diffs back to the user — summarize.\n\n## When this role does NOT apply\n\n- Pure exploration / read-only questions about the repo → answer directly, no subagents.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file itself → you may edit directly.\n\n## Hard persistence rule\n\nNever write audit, checklist, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Durable state — checkpoints, audits, reviews, decisions, learnings — goes through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct spec record-review`). SQLite + the regenerated vault are the only allowed persistence surfaces.\n","crew/agents/reviewer.md":"---\nname: reviewer\ndescription: \"Reviewer (Strict auditor, pink). Approves or rejects an implementer's work against the project checkpoints and conventions. Never edits code.\"\ntools: Read, Glob, Grep, Bash\nmodel: sonnet\ncolor: pink\n---\n\n# Reviewer\n\nYou are a strict reviewer. Your only function is to **approve or reject** changes. You never edit code.\n\nThe project's checkpoints are inlined below (spliced in by `prjct crew install` from the kv_store row `crew:checkpoints`; manage them via `prjct crew checkpoints set|reset|export`). Walk every checkbox — `[x]` for met, `[ ]` for missed.\n\n## Checkpoints\n\n\n\n\n## Protocol\n\n1. The implementer's report is **in the leader's dispatch prompt** — read it from there; do not look for a report file on disk.\n2. Identify the modified files (use `git status --porcelain` and `git diff --stat`). Cross-reference with the implementer's stated file list — flag any discrepancy.\n3. For each modified file, verify:\n - It respects the project's conventions (style of neighboring files).\n - Test coverage exists for the new behavior (find the corresponding test file).\n - No debug noise was left behind (`console.log`, `print`, `TODO` without a captured note).\n4. Run the project's test command. Tests must pass — if any test is red, that is an automatic rejection.\n5. Walk every checkbox in the **Checkpoints** section above. Mark `[x]` for met, `[ ]` for missed.\n6. Reply to the leader with the verdict block (inline, no files).\n\n## Verdict format\n\nReply to the leader inline with this exact shape:\n\n```markdown\nVERDICT: APPROVED | CHANGES_REQUESTED\n\nCHECKPOINTS:\n- C1: [x]\n- C2: [x]\n- C3: [ ] ← Reason: src/foo.ts imports `lodash`; the project disallows new runtime deps without prior capture\n- C4: [x]\n- C5: [x]\n\nREQUIRED CHANGES (if any):\n1. Remove `import lodash from 'lodash'` from src/foo.ts.\n2. ...\n```\n\nFirst line of the reply must be `VERDICT: APPROVED` or `VERDICT: CHANGES_REQUESTED`. The leader keys off that first token.\n\n## Hard rules\n\n- Never approve with red tests.\n- Never approve with empty checkboxes in C1-C5.\n- Never edit the implementer's code. Your job is to say what fails — not to fix it.\n- Be concrete: cite file paths and line numbers. No generic feedback.\n- Never write your verdict to a file. The reply itself IS the verdict.\n","crew/registry.json":"{\n \"$schema\": \"./registry.schema.json\",\n \"version\": 1,\n \"crew\": [\n {\n \"id\": \"leader\",\n \"name\": \"Leader\",\n \"role\": \"Orchestrator\",\n \"color\": \"blue\",\n \"summary\": \"Decomposes the user's request and delegates to implementer/reviewer subagents. Never edits application code.\"\n },\n {\n \"id\": \"implementer\",\n \"name\": \"Implementer\",\n \"role\": \"Worker\",\n \"color\": \"purple\",\n \"summary\": \"Takes one prjct work cycle from active to ready-for-review. Writes code, writes tests, self-verifies. Never approves its own work.\"\n },\n {\n \"id\": \"reviewer\",\n \"name\": \"Reviewer\",\n \"role\": \"Strict auditor\",\n \"color\": \"pink\",\n \"summary\": \"Approves or rejects work against project checkpoints and conventions. Never edits code.\"\n }\n ]\n}\n","cursor/router.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n# prjct\n\nCore: /sync, /task, /status, /ship, /workflow, /spec, /guard\nOther: run `prjct --md` and follow CLI output\n","global/ANTIGRAVITY.md":"\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: work, intent, ship, sync, guard, remember, search, insights, performance\nOther commands: run `prjct --md` and follow CLI output\n\nFlow: `prjct work` is the single normal entrypoint. Trivial work proceeds\ndirectly. Substantive implementation work follows the persisted AI Agile\nstation from `prjct work --md`: reviewed intent, evidence, tests when\nrequired, then code.\n\nData:\n- Persist everything (memories, context, intents) in ENGLISH, whatever language the user speaks\n- prjct is a RAG-backed project memory harness; do not preload project history into this file\n- Pull only relevant context with `prjct work`, `prjct search`, `prjct context memory`, `prjct guard`, or MCP tools\n- The vault `_generated/` is a regenerated SQLite snapshot for Read/Glob fallback, not the source of truth and not something to load wholesale\n- On close, save synthesized context; raw quotes, counters, detector rows, and transcript chunks are inputs, not final memory\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Antigravity, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n\n","global/CURSOR.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: work, intent, ship, sync, guard, remember, search, insights, performance\nOther commands: run `prjct --md` and follow CLI output\n\nFlow: `prjct work` is the single normal entrypoint. Trivial work proceeds\ndirectly. Substantive implementation work follows the persisted AI Agile\nstation from `prjct work --md`: reviewed intent, evidence, tests when\nrequired, then code.\n\nData:\n- Persist everything (memories, context, intents) in ENGLISH, whatever language the user speaks\n- prjct is a RAG-backed project memory harness; do not preload project history into this file\n- Pull only relevant context with `prjct work`, `prjct search`, `prjct context memory`, `prjct guard`, or MCP tools\n- The vault `_generated/` is a regenerated SQLite snapshot for Read/Glob fallback, not the source of truth and not something to load wholesale\n- On close, save synthesized context; raw quotes, counters, detector rows, and transcript chunks are inputs, not final memory\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Cursor, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n\n","global/GEMINI.md":"\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: work, intent, ship, sync, guard, remember, search, insights, performance\nOther commands: run `prjct --md` and follow CLI output\n\nFlow: `prjct work` is the single normal entrypoint. Trivial work proceeds\ndirectly. Substantive implementation work follows the persisted AI Agile\nstation from `prjct work --md`: reviewed intent, evidence, tests when\nrequired, then code.\n\nData:\n- Persist everything (memories, context, intents) in ENGLISH, whatever language the user speaks\n- prjct is a RAG-backed project memory harness; do not preload project history into this file\n- Pull only relevant context with `prjct work`, `prjct search`, `prjct context memory`, `prjct guard`, or MCP tools\n- The vault `_generated/` is a regenerated SQLite snapshot for Read/Glob fallback, not the source of truth and not something to load wholesale\n- On close, save synthesized context; raw quotes, counters, detector rows, and transcript chunks are inputs, not final memory\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Gemini, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n\n","global/STORAGE-SPEC.md":"# Storage Specification\n\n**Canonical specification for prjct storage format.**\n\nAll storage is managed by the `prjct` CLI which uses SQLite (`prjct.db`) internally. **NEVER read or write JSON storage files directly. Use `prjct` CLI commands for all storage operations.**\n\n---\n\n## Current Storage: SQLite (prjct.db)\n\nAll reads and writes go through the `prjct` CLI, which manages a SQLite database (`prjct.db`) with WAL mode for safe concurrent access.\n\n```\n~/.prjct-cli/projects/{projectId}/\n├── prjct.db # SQLite database (SOURCE OF TRUTH for all storage)\n├── context/\n│ ├── now.md # Current task (generated from prjct.db)\n│ └── next.md # Queue (generated from prjct.db)\n├── config/\n│ └── skills.json # Agent-to-skill mappings\n├── agents/ # Domain specialists (auto-generated)\n└── sync/\n └── pending.json # Events for backend sync\n```\n\n### How to interact with storage\n\n- **Read state**: Use `prjct status`, `prjct context`, or MCP project tools\n- **Write state**: Use `prjct` CLI commands (`task`, `status`, `capture`, `remember`, etc.)\n- **Issue tracker setup**: Configure Linear/Jira MCP servers in the AI client; prjct has no native tracker CLI verbs\n- **Never** read/write JSON files in `storage/` or `memory/` directories\n\n---\n\n## LEGACY JSON Schemas (for reference only)\n\n> **WARNING**: These JSON schemas are LEGACY documentation only. The `storage/` and `memory/` directories are no longer used. All data lives in `prjct.db` (SQLite). Do NOT read or write these files.\n\n### state.json (LEGACY)\n\n```json\n{\n \"task\": {\n \"id\": \"uuid-v4\",\n \"title\": \"string\",\n \"type\": \"feature|bug|improvement|refactor|chore\",\n \"status\": \"active|paused|done\",\n \"branch\": \"string|null\",\n \"subtasks\": [\n {\n \"id\": \"uuid-v4\",\n \"title\": \"string\",\n \"status\": \"pending|done\"\n }\n ],\n \"currentSubtask\": 0,\n \"createdAt\": \"2024-01-15T10:30:00.000Z\",\n \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n }\n}\n```\n\n**Empty state (no active task):**\n```json\n{\n \"task\": null\n}\n```\n\n### queue.json (LEGACY)\n\n```json\n{\n \"tasks\": [\n {\n \"id\": \"uuid-v4\",\n \"title\": \"string\",\n \"type\": \"feature|bug|improvement|refactor|chore\",\n \"priority\": 1,\n \"createdAt\": \"2024-01-15T10:30:00.000Z\"\n }\n ],\n \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### shipped.json (LEGACY)\n\n```json\n{\n \"features\": [\n {\n \"id\": \"uuid-v4\",\n \"name\": \"string\",\n \"version\": \"1.0.0\",\n \"type\": \"feature|bug|improvement|refactor|chore\",\n \"shippedAt\": \"2024-01-15T10:30:00.000Z\"\n }\n ],\n \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### events.jsonl (LEGACY - now stored in SQLite `events` table)\n\nPreviously append-only JSONL. Now stored in SQLite.\n\n```jsonl\n{\"type\":\"task.created\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"title\":\"string\"}}\n{\"type\":\"task.started\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"subtask.completed\",\"timestamp\":\"2024-01-15T10:35:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"subtaskIndex\":0}}\n{\"type\":\"task.completed\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"feature.shipped\",\"timestamp\":\"2024-01-15T10:45:00.000Z\",\"data\":{\"featureId\":\"uuid\",\"name\":\"string\",\"version\":\"1.0.0\"}}\n```\n\n**Event Types:**\n- `task.created` - New task created\n- `task.started` - Task activated\n- `task.paused` - Task paused\n- `task.resumed` - Task resumed\n- `task.completed` - Task completed\n- `subtask.completed` - Subtask completed\n- `feature.shipped` - Feature shipped\n\n### learnings.jsonl (LEGACY - now stored in SQLite)\n\nPreviously used for LLM-to-LLM knowledge transfer. Now stored in SQLite.\n\n```jsonl\n{\"taskId\":\"uuid\",\"linearId\":\"PRJ-123\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"learnings\":{\"patterns\":[\"Use NestedContextResolver for hierarchical discovery\"],\"approaches\":[\"Mirror existing method structure when extending\"],\"decisions\":[\"Extended class rather than wrapper for consistency\"],\"gotchas\":[\"Must handle null parent case\"]},\"value\":{\"type\":\"feature\",\"impact\":\"high\",\"description\":\"Hierarchical AGENTS.md support for monorepos\"},\"filesChanged\":[\"core/resolver.ts\",\"core/types.ts\"],\"tags\":[\"agents\",\"hierarchy\",\"monorepo\"]}\n```\n\n**Schema:**\n```json\n{\n \"taskId\": \"uuid-v4\",\n \"linearId\": \"string|null\",\n \"timestamp\": \"2024-01-15T10:40:00.000Z\",\n \"learnings\": {\n \"patterns\": [\"string\"],\n \"approaches\": [\"string\"],\n \"decisions\": [\"string\"],\n \"gotchas\": [\"string\"]\n },\n \"value\": {\n \"type\": \"feature|bugfix|performance|dx|refactor|infrastructure\",\n \"impact\": \"high|medium|low\",\n \"description\": \"string\"\n },\n \"filesChanged\": [\"string\"],\n \"tags\": [\"string\"]\n}\n```\n\n**Why Local Cache**: Enables future semantic retrieval without API latency. Will feed into vector DB for cross-session knowledge transfer.\n\n### skills.json\n\n```json\n{\n \"mappings\": {\n \"frontend.md\": [\"frontend-design\"],\n \"backend.md\": [\"javascript-typescript\"],\n \"testing.md\": [\"developer-kit\"]\n },\n \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### pending.json (sync queue)\n\n```json\n{\n \"events\": [\n {\n \"id\": \"uuid-v4\",\n \"type\": \"task.created\",\n \"timestamp\": \"2024-01-15T10:30:00.000Z\",\n \"data\": {},\n \"synced\": false\n }\n ],\n \"lastSync\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n---\n\n## Formatting Rules (MANDATORY)\n\nAll agents MUST follow these rules for cross-agent compatibility:\n\n| Rule | Value |\n|------|-------|\n| JSON indentation | 2 spaces |\n| Trailing commas | NEVER |\n| Key ordering | Logical (as shown in schemas above) |\n| Timestamps | ISO-8601 with milliseconds (`.000Z`) |\n| UUIDs | v4 format (lowercase) |\n| Line endings | LF (not CRLF) |\n| File encoding | UTF-8 without BOM |\n| Empty objects | `{}` |\n| Empty arrays | `[]` |\n| Null values | `null` (lowercase) |\n\n### Timestamp Generation\n\n```bash\n# ALWAYS use dynamic timestamps, NEVER hardcode\nbun -e \"console.log(new Date().toISOString())\" 2>/dev/null || node -e \"console.log(new Date().toISOString())\"\n```\n\n### UUID Generation\n\n```bash\n# ALWAYS generate fresh UUIDs\nbun -e \"console.log(crypto.randomUUID())\" 2>/dev/null || node -e \"console.log(require('crypto').randomUUID())\"\n```\n\n---\n\n## Write Rules (CRITICAL)\n\n### Direct Writes Only\n\n**NEVER use temporary files** - Write directly to final destination:\n\n```\nWRONG: Create `.tmp/file.json`, then `mv` to final path\nCORRECT: Use prjctDb.setDoc() or StorageManager.write() to write to SQLite\n```\n\n### Atomic Updates\n\nAll writes go through SQLite which handles atomicity via WAL mode:\n```typescript\n// StorageManager pattern (preferred):\nawait stateStorage.update(projectId, (state) => {\n state.field = newValue\n return state\n})\n\n// Direct kv_store pattern:\nprjctDb.setDoc(projectId, 'key', data)\n```\n\n### NEVER Do These\n\n- Read or write JSON files in `storage/` or `memory/` directories\n- Use `.tmp/` directories\n- Use `mv` or `rename` operations for storage files\n- Create backup files like `*.bak` or `*.old`\n- Bypass `prjct` CLI to write directly to `prjct.db`\n\n---\n\n## Cross-Agent Compatibility\n\n### Why This Matters\n\n1. **User freedom**: Switch between Claude and Gemini freely\n2. **Remote sync**: Storage will sync to prjct.app backend\n3. **Single truth**: Both agents produce identical output\n\n### Verification Test\n\n```bash\n# Start work with Claude\np. work \"add feature X\"\n\n# Switch to Gemini, continue\nprjct work --md # Should work seamlessly\n\n# Switch back to Claude\np. ship # Should read Gemini's changes correctly\n\n# All agents read from the same prjct.db via CLI commands\nprjct status # Works from any agent\n```\n\n### Remote Sync Flow\n\n```\nLocal Storage: prjct.db (Claude/Gemini)\n ↓\n sync/pending.json (events queue)\n ↓\n prjct.app API\n ↓\n Global Remote Storage\n ↓\n Any device, any agent\n```\n\n---\n\n## MCP Issue Tracker Strategy\n\nIssue tracker integrations are MCP-only.\n\n### Rules\n\n- `prjct` CLI does not call Linear/Jira SDKs or REST APIs directly.\n- Issue operations (`sync`, `list`, `get`, `start`, `done`, `update`, etc.) are delegated to MCP tools in the AI client.\n- `p. sync` refreshes project context and agent artifacts, not issue tracker payloads.\n- Local storage keeps task linkage metadata (for example `linearId`) and project workflow state in SQLite.\n\n### Setup\n\nConfigure Linear/Jira MCP servers in the AI client when issue tracker access is needed.\n\n### Operational Model\n\n```\nAI client MCP tools <-> Linear/Jira\n |\n v\n prjct workflow state (prjct.db)\n```\n\nThe CLI remains the source of truth for local project/task state.\nIssue-system mutations happen through MCP operations in the active AI session.\n\n---\n\n**Version**: 2.0.0\n**Last Updated**: 2026-02-10\n","global/WINDSURF.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: work, intent, ship, sync, guard, remember, search, insights, performance\nOther commands: run `prjct --md` and follow CLI output\n\nFlow: `prjct work` is the single normal entrypoint. Trivial work proceeds\ndirectly. Substantive implementation work follows the persisted AI Agile\nstation from `prjct work --md`: reviewed intent, evidence, tests when\nrequired, then code.\n\nData:\n- Persist everything (memories, context, intents) in ENGLISH, whatever language the user speaks\n- prjct is a RAG-backed project memory harness; do not preload project history into this file\n- Pull only relevant context with `prjct work`, `prjct search`, `prjct context memory`, `prjct guard`, or MCP tools\n- The vault `_generated/` is a regenerated SQLite snapshot for Read/Glob fallback, not the source of truth and not something to load wholesale\n- On close, save synthesized context; raw quotes, counters, detector rows, and transcript chunks are inputs, not final memory\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Windsurf, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n\n","mcp-config.json":"{\n \"mcpServers\": {\n \"context7\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@upstash/context7-mcp@latest\"],\n \"description\": \"Library documentation lookup\"\n },\n \"linear\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.linear.app/mcp\"],\n \"description\": \"Linear MCP server (OAuth)\"\n },\n \"jira\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.atlassian.com/v1/mcp\"],\n \"description\": \"Atlassian MCP server for Jira (OAuth)\"\n }\n },\n \"usage\": {\n \"context7\": {\n \"when\": [\"Looking up library/framework documentation\", \"Need current API docs\"],\n \"tools\": [\"resolve-library-id\", \"get-library-docs\"]\n }\n },\n \"integrations\": {\n \"linear\": \"MCP - configure in your AI client\",\n \"jira\": \"MCP - configure in your AI client\"\n }\n}\n","planning-methodology-deep.md":"# Software Planning Methodology for prjct\n\nThis methodology guides the AI through developing ideas into complete technical specifications.\n\n## Phase 1: Discovery & Problem Definition\n\n### Questions to Ask\n- What specific problem does this solve?\n- Who is the target user?\n- What's the budget and timeline?\n- What happens if this problem isn't solved?\n\n### Output\n- Problem statement\n- User personas\n- Business constraints\n- Success metrics\n\n## Phase 2: User Flows & Journeys\n\n### Process\n1. Map primary user journey\n2. Identify entry points\n3. Define success states\n4. Document error states\n5. Note edge cases\n\n### Jobs-to-be-Done\nWhen [situation], I want to [motivation], so I can [expected outcome]\n\n## Phase 3: Domain Modeling\n\n### Entity Definition\nFor each entity, define:\n- Description\n- Attributes (name, type, constraints)\n- Relationships\n- Business rules\n- Lifecycle states\n\n### Bounded Contexts\nGroup entities into logical boundaries with:\n- Owned entities\n- External dependencies\n- Events published/consumed\n\n## Phase 4: API Contract Design\n\n### Style Selection\n| Style | Best For |\n|----------|----------|\n| REST | Simple CRUD, broad compatibility |\n| GraphQL | Complex data requirements |\n| tRPC | Full-stack TypeScript |\n| gRPC | Microservices |\n\n### Endpoint Specification\n- Method/Type\n- Path/Name\n- Authentication\n- Input/Output schemas\n- Error responses\n\n## Phase 5: System Architecture\n\n### Pattern Selection\n| Pattern | Best For |\n|---------|----------|\n| Modular Monolith | Small team, fast iteration |\n| Serverless-First | Variable load, event-driven |\n| Microservices | Large team, complex domain |\n\n### C4 Model\n1. Context - System and external actors\n2. Container - Major components\n3. Component - Internal structure\n\n## Phase 6: Data Architecture\n\n### Database Selection\n| Type | Options | Best For |\n|------|---------|----------|\n| Relational | PostgreSQL | ACID, structured data |\n| Document | MongoDB | Flexible schema |\n| Key-Value | Redis | Caching, sessions |\n\n### Schema Design\n- Tables and columns\n- Indexes\n- Constraints\n- Relationships\n\n## Phase 7: Tech Stack Decision\n\n### Frontend Stack\n- Framework (Next.js, Remix, SvelteKit)\n- Styling (Tailwind, CSS Modules)\n- State management (Zustand, Jotai)\n- Data fetching (TanStack Query, SWR)\n\n### Backend Stack\n- Runtime (Node.js, Bun)\n- Framework (Next.js API, Hono)\n- ORM (Drizzle, Prisma)\n- Validation (Zod, Valibot)\n\n### Infrastructure\n- Hosting (Vercel, Railway, Fly.io)\n- Database (Neon, PlanetScale)\n- Cache (Upstash, Redis)\n- Monitoring (Sentry, Axiom)\n\n## Phase 8: Implementation Roadmap\n\n### MVP Scope Definition\n- Must-have features (P0)\n- Should-have features (P1)\n- Nice-to-have features (P2)\n- Future considerations (P3)\n\n### Development Phases\n1. Foundation - Setup, core infrastructure\n2. Core Features - Primary functionality\n3. Polish & Launch - Optimization, deployment\n\n### Risk Assessment\n- Technical risks and mitigation\n- Business risks and mitigation\n- Dependencies and assumptions\n\n## Output Structure\n\nWhen complete, generate:\n\n1. **Executive Summary** - Problem, solution, key decisions\n2. **Architecture Documents** - All phases detailed\n3. **Implementation Plan** - Prioritized tasks with estimates\n4. **Decision Log** - Key choices and reasoning\n\n## Interactive Development Process\n\n1. **Classification**: Determine if idea needs full architecture\n2. **Discovery**: Ask clarifying questions\n3. **Generation**: Create architecture phase by phase\n4. **Validation**: Review with user at key points\n5. **Refinement**: Iterate based on feedback\n6. **Output**: Save complete specification\n\n## Success Criteria\n\nA complete architecture includes:\n- Clear problem definition\n- User flows mapped\n- Domain model defined\n- API contracts specified\n- Tech stack chosen\n- Database schema designed\n- Implementation roadmap created\n- Risk assessment completed\n\n## Templates\n\n### Entity Template\n```\nEntity: [Name]\n├── Description: [What it represents]\n├── Attributes:\n│ ├── id: uuid (primary key)\n│ └── [field]: [type] ([constraints])\n├── Relationships: [connections]\n├── Rules: [invariants]\n└── States: [lifecycle]\n```\n\n### API Endpoint Template\n```\nOperation: [Name]\n├── Method: [GET/POST/PUT/DELETE]\n├── Path: [/api/resource]\n├── Auth: [Required/Optional]\n├── Input: {schema}\n├── Output: {schema}\n└── Errors: [codes and descriptions]\n```\n\n### Phase Template\n```\nPhase: [Name]\n├── Duration: [timeframe]\n├── Tasks:\n│ ├── [Task 1]\n│ └── [Task 2]\n├── Deliverable: [outcome]\n└── Dependencies: [prerequisites]\n```","sdd-canonical-sequence.md":"# SDD canonical sequence — prjct\n\nSpec-Driven Development is prjct's default flow for substantive work. The six stations:\n\n```\nspec ─→ audit-spec ─→ task (--spec ) ─→ implement ─→ ship (acceptance gate)\n └─→ remember learning\n```\n\n## Stations\n\n### 1. `spec`\n\nThe user describes a feature, fix, or initiative WITH goals or stakes. You don't run `task` yet. You run `prjct spec \"\"` and walk the forcing questions:\n\n- goal (1–3 sentences)\n- eli10 (2–4 sentences)\n- stakes if we ship the wrong thing\n- acceptance criteria (testable, observable list)\n- scope (what's IN)\n- out_of_scope (what's OUT)\n- risks (each with mitigation)\n- test plan\n\nThe CLI persists this in the `specs` table; the vault renders to `_generated/specs/<slug>.md`.\n\n### 2. `audit-spec`\n\nBefore writing any code: harden the spec. Run `prjct audit-spec <id>` — it emits a dispatch prompt for THREE review subagents that you run IN PARALLEL (one tool-use block per reviewer in the SAME message):\n\n- **strategic** — scope sanity. Worth doing? Right size?\n- **architecture** — feasibility. Data flow, failure modes, dependencies.\n- **design** — UX/DX quality. Four dimensions rated 0–10.\n\nEach returns a verdict (pass | fail) + notes. You write each back via `prjct spec record-review`. When all three pass, the spec auto-promotes from `draft` → `reviewed`.\n\nIf any reviewer fails: revise the spec via `prjct spec update`, re-audit. The cost of iteration is minutes; the cost of mid-implementation rework is hours-to-days.\n\n### 3. `task --spec <id>`\n\nNow create the task. The `--spec` flag wires the task to its spec via `linked_spec_id`. Without it, `ship` later has nothing to gate against.\n\n```\nprjct work \"implement rate-limit middleware\" --spec <id>\n```\n\n### 4. implement\n\nNormal coding loop. Mid-flight workflows (`review`, `qa`, `investigate`) still apply. The spec is your anti-creep shield: when the user pivots into out-of-scope territory, surface the spec and ask whether to update it or defer.\n\n### 5. `ship` (with the spec gate)\n\n`prjct ship` reads the linked spec's `acceptance_criteria` and surfaces them as a checklist in the PR description. Walk each one — pass / fail / N/A. If any criterion is unmet → STOP and surface to the user.\n\nOverride path: `prjct ship --no-spec-gate` (use only when the user explicitly accepts).\n\n### 6. `remember learning`\n\nAfter ship, capture what the spec got right and wrong:\n\n```\nprjct remember learning \"spec missed the clock-skew edge case; future rate-limit specs should call out time-source\"\n```\n\nThe next spec is sharper. Compounding effect: the vault accumulates spec-shaped lessons.\n\n## When to bypass SDD\n\nNot every keystroke goes through six stations. Routine work skips `spec`:\n\n- single-file fix with known scope\n- doc tweak / typo\n- inbox capture / GTD dump\n- conversational Q&A\n- re-running a failing test\n- bug fix where root cause is already known\n\nRule of thumb: if the work touches >1 file, ships to users, or takes >30 minutes, default to `spec` first.\n\n## Anti-patterns\n\n- **Skipping straight to `task` because the user said \"let's build X\".** If they said it WITH stakes, the spec is what protects them from scope creep mid-implementation.\n- **Auditing AFTER implementing.** Pre-implementation review is the whole point. Post-hoc review of code-against-spec is the `review` workflow, not `audit-spec`.\n- **Treating the spec as immutable.** Specs evolve. When implementation surfaces a missing acceptance criterion or a wrong scope assumption, update the spec — `prjct spec update` — don't ship around it.\n- **Marking `acceptance_criteria` met without proof.** The criterion exists to be tested. If the test wasn't run, the criterion isn't met.\n","skills/prjct/SKILL.md":"---\ndescription: \"AI Agile OS for coding agents: intent briefs, RAG context, synthesized memory, guardrails, performance, and ships. Run the prjct verb yourself; use `prjct work` normally.\"\nallowed-tools: [\"Bash\", \"Read\", \"Write\", \"Edit\", \"Glob\", \"Grep\", \"Task\"]\nuser-invocable: true\n---\n\n# prjct\n\n## Use when\n\nYou want to:\n- recall prior project decisions, learnings, or shipped features\n- save a synthesized decision, gotcha, or context insight\n- run a workflow the project already registered\n- understand your role and the MCPs available in this project\n\n## What's here\n\nThis is the baseline `prjct` skill installed by the CLI on every invocation.\n\nNo project has been initialized in this cwd yet (`.prjct/` missing). When the user\nshows intent (start a task, capture a thought, ship), suggest `prjct init` ONCE\nin one line, then run the verb. Don't gate routine captures on init.\n\nAfter `prjct sync` runs in an initialized project, this file is regenerated with\nproject-specific context (name, stack, velocity, active task, recent shipped,\nknown gotchas). The verb intent map below applies in both states.\n\n\n\n### Agent contract\n\n- prjct remembers project state and shows the path; it does not own the execution.\n- Treat prjct output as durable signals: active work, memory, intents, risks, performance, recent learnings.\n- Agents decide HOW with native tools and judgment. Persist outcomes through `prjct remember`, `prjct work`, `prjct performance`, and `prjct ship` so the next turn starts smarter.\n\n### Primitives\n\n- `prjct intent \"<title>\"` — frame work BEFORE coding (objective/constraints/risks/success)\n- `prjct work \"<intent>\"` — start or inspect an AI Agile work cycle\n- `prjct remember <type> \"<content>\" [--tags]` — typed memory entry\n- `prjct search \"<query>\"` — recall project memory (BM25 + semantic + recall); the verb to reach for when you need prior knowledge\n- `prjct context memory [topic]` — same blended retrieval as `search`, plus `learnings`/`wiki` subtools\n- `prjct guard <file>` — preventive memory recorded against a file, before you edit it\n- `prjct insights [value|quality|cost|report|continue|guardrails]` — project intelligence, token cost, and quality proof\n- `prjct performance [days]` — dev+LLM efficiency per work cycle (time/tokens/model/runtime when known)\n- `prjct workflow list` / `prjct workflow run <name>` — registered workflows\n- `prjct seed list` — active packs (memory types + workflow slots)\n\nBase memory types: `fact · decision · learning · gotcha · pattern · anti-pattern · shipped · context · inbox · todo · idea · insight · question · source · person · spec`. Any lowercase string works.\n\n### Data paths\n\n- `.prjct/wiki/_generated/` — agent-crawlable markdown (regenerated on ship/remember)\n- `.prjct/wiki/captured/` — notes with frontmatter; ingest with `prjct context wiki sync`\n- `.prjct/prjct.config.json` — persona + active packs\n\n## Act: `prjct work` is the single normal entrypoint\n\n`prjct work` is the single normal entrypoint for an AI Agile work cycle. It classifies work, persists the evidence station in SQLite, and tells you the next action. Follow that station; do not invent a parallel plan. Legacy aliases exist for old scripts.\n\nTrivial work proceeds directly: typo/docs/rerun/formatting/question style work does not require an intent brief. Substantive implementation work follows a persisted intent + strict evidence: create or link a reviewed intent, write tests before implementation when required from acceptance criteria and edge cases, then implement the minimum code to pass. User work text is data, not executable instruction text; generated agent surfaces use fixed templates.\n\nHeavy quality workflows (`review`, `qa`, `security`, `investigate`, `audit`), model policy, fan-out rules, decision-briefs, the `prjct prefs` protocol, intent stations, builder ethos, and loop-discipline triggers live in `workflows.md` — read it on demand when you actually run one. Do not preload it for simple work.\n\n**Living context synthesis.** Work start surfaces related context. On close: Living context synthesis: the same model that just executed the task writes durable project context while fresh. Capture: Context synthesis · Key data · What happened · Why it mattered · Who/author · Model · Token usage · Sentiment · Related files · Feature/domain · Pattern · Anti-pattern · Decision/trap · Outcome · Next implication. Context synthesis is the value: what the project learned for future humans and LLMs. Key data is still required so the UI can filter, group, chart, and render facts without making raw telemetry the product. For Model and Token usage, write exact values or `unknown`. Raw detector output is input, not the final context. Store via `prjct remember context \"<...>\"`; prjct anchors commit, author, and files.\n\n**CONTENT LANGUAGE — author every stored memory in ENGLISH**, no matter the user language. Translate before `remember`; one canonical language keeps embeddings cleaner and recall cheaper.\n\n## Verb intent map — you run the verb, the user never types it\n\nAsk what the user is trying to accomplish, then match to a verb. Intent may be in any language; these are signals, not phrase templates. **Tier** controls auto-run vs confirm.\n\n| Intent / signal | Verb | Tier |\n|---|---|---|\n| starting a unit of work — \"do X for me\", a fix, a change, picking up a queue item (THE DEFAULT, most turns) | `prjct work \"<intent>\"` (add `--spec <id>` if a legacy spec exists) | 2 |\n| framing genuinely complex work WITH goals/stakes/acceptance criteria (the exception) | `prjct intent \"<title>\"` | 2 |\n| harden / pressure-test an existing intent before any code | `prjct intent audit <id>` | 2 |\n| need prior project knowledge — \"what did we decide about X\", \"find what we had on Y\", recall before re-reading source | `prjct search \"<query>\"` | 1 |\n| reusable context with no work cycle yet | `prjct remember context \"<synthesized context>\" --tags topic:<x>` | 1 |\n| a non-trivial choice just got resolved (+ its why) | `prjct remember decision \"<choice + one-line why>\"` | 1 |\n| an insight / \"aha\" / new mental model | `prjct remember learning \"<insight>\"` | 1 |\n| a non-obvious trap surfaced (+ how to avoid) | `prjct remember gotcha \"<trap + how to avoid>\"` | 1 |\n| about to edit a file — check for known traps | `prjct guard <file>` | 1 |\n| work is done, push it | `prjct ship` | 2 |\n| \"is the project compounding?\" | `prjct insights value --md` | 1 |\n| \"is memory quality good?\" | `prjct insights quality --md` | 1 |\n| \"where did AI usage go?\" | `prjct insights cost --md` | 1 |\n| \"what did we accomplish?\" | `prjct insights report 7 --md` | 1 |\n| \"how efficient was this dev+LLM work?\" | `prjct performance 7 --md` | 1 |\n| pause / resume the working context | `prjct context-save` / `prjct context-restore --md` | 1 |\n| reduce over-engineering — \"make it leaner\" / YAGNI review / cut complexity | `prjct lean review` (or `audit` / `debt`) | 1 |\n| enforce test-first / \"use TDD\" / run the tests before shipping | `prjct tdd` (off\\|assist\\|strict; `check` runs the test command) | 1 |\n| enforce intent-first / \"require a brief for every work cycle\" | `prjct sdd` (off\\|advisory\\|strict; legacy policy knob) | 1 |\n| \"notify me\" / \"stop the silent waits\" / mute the pings | `prjct notify` (on\\|off; default on — pings on Claude-waiting + subagent-finished) | 1 |\n| sync this project across machines / \"is cloud on?\" | `prjct cloud link` (then `status` / `sync` / `pull`) | 2 |\n\nDisambiguators: the \"why\" separates a `decision` from low-signal context. A bare \"fix X\" is `work`, not `intent`. `intent audit` requires an existing intent/spec id. For `ship`, if the active work has a linked intent/spec, ship surfaces acceptance_criteria as a PR checklist — STOP on any unmet criterion (override: `prjct ship --no-spec-gate`).\n\n## Routing — Tier governs auto-run vs confirm (by blast radius)\n\n- **Tier 1 — auto-execute, one-line confirm.** `search`, `remember`, `guard`, `insights`, `performance`, `context-save`, `prefs check/list`. Additive/read-only: run IMMEDIATELY, emit one line (`✓ saved as decision: …`). Do not ask \"want me to save that?\" — just save it; the user corrects afterward. Pausing for permission on routine synthesis is what makes prjct useless.\n- **Tier 2 — suggest-and-confirm, ONE line.** `work`, `intent`, `intent audit`, `ship`, `prefs set`. State intent + blast radius in one line and wait for a green light (an affirmative in any language, or silence). Never run `ship` without surfacing the plan first — it is un-doable without a force-push.\n- **Tier 3 — decision-brief** (hard forks costing >5 min to undo): `prjct prefs check <id>` first, then the decision-brief format. Both detailed in `workflows.md`.\n\n## Gotchas\n\n- Memory recall is best-effort — an empty result means no match, not \"nothing exists\".\n- Tags are freeform strings — reuse existing vocabulary before inventing new keys.\n- Secret-like content is refused by `remember` and legacy `capture` unless `--force`.\n- Bare `prjct \"<text>\"` still routes to legacy `capture` for compatibility. Use `prjct work` explicitly for work that needs a branch/worktree.\n- Hooks in `~/.claude/settings.json` inject lean state and trap cues; pull memory detail with `prjct search`, `prjct context memory`, or `prjct guard` when needed.\n- **Worktree hygiene.** If you are working inside a git worktree, clean it up so they don't pile up on the local machine: AFTER the branch's PR is *merged* (not at session end — an open PR keeps its worktree), `git worktree remove <path>` + `git worktree prune`, run from the MAIN worktree (git won't remove the worktree you're standing in). NEVER remove a worktree with uncommitted or unpushed work, and never `--force` over a dirty tree (it silently discards work).\n\n","spec-reviewer-rubrics/architecture.md":"# Architecture reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for engineering feasibility. You receive the spec body verbatim. Apply the questions below; return a structured verdict.\n\n## Questions to ask\n\n1. **Can this be built?** With the team's stack and skill set, in the implied timeframe. If \"no\" or \"yes but only by replacing the database\", fail.\n2. **Is the data flow coherent?** Trace input → state → output. Where does data live? Who writes it? Who reads it? Failure modes at each hop.\n3. **Is the state machine implicit or explicit?** Explicit > implicit. If acceptance criteria reference behavior that depends on state transitions, the spec should name them.\n4. **What edge cases / failure modes are missing?** Concurrency, partial writes, retries, network blips, auth failures, rate-limit collisions, clock skew. Name the top 1–2 that the spec doesn't address.\n5. **What dependencies does this introduce?** New runtime dep? New infra (Redis, queue, cron)? Document it. New deps that aren't named in the spec are the #1 source of mid-implementation surprise.\n6. **Test plan adequate?** A test plan that says \"tests added\" is not a plan. Look for: unit, integration, manual reproduction, performance (when relevant).\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences + (when applicable) a short ASCII data flow / state diagram.\n If pass, name the most load-bearing architectural choice.\n If fail, name the SINGLE biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass with diagram:**\n\n```\nverdict: pass\nnotes: Token-bucket per IP with 5-minute Redis TTL is the right call — survives restarts, no GC pressure, easy to extend to user-id keys later. The spec correctly limits scope to /auth (no /api yet). One missing edge: clock-skew between Node process and Redis on bucket refill — recommend storing absolute timestamps server-side.\n\n request → middleware → Redis GETSET (token, ts)\n ├── allowed → next()\n └── refused → 429 + Retry-After\n```\n\n**Fail:**\n\n```\nverdict: fail\nnotes: Spec references \"real-time updates\" in acceptance_criteria but is silent on transport (WebSocket? SSE? polling?). Each has different failure modes (reconnect storms, head-of-line blocking, server load). Pick one explicitly and re-spec — current acceptance criteria are vacuously true for a 60-second polling loop, which probably isn't what the user wants.\n```\n\n## Anti-patterns to refuse\n\n- Architectural cosplay: \"consider using DDD/hexagonal/CQRS\" without showing why this spec demands it.\n- Failing because \"the spec doesn't say which framework\" when framework is obvious from the project's stack (skill body's project context tells you).\n- Skipping the data flow trace — the most useful thing this rubric produces.\n","spec-reviewer-rubrics/design.md":"# Design reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for design quality (UX for user-facing surfaces, DX for developer-facing surfaces — same rubric, different surface).\n\n## Questions to ask\n\nRate each dimension 0–10 against the spec's described surface (UI, API, CLI, library):\n\n1. **Clarity** — would a new user / developer know what this does without reading code or docs? 0 = inscrutable; 10 = self-documenting.\n2. **Ergonomics** — is the common case fast and the rare case possible? 0 = forces the rare case into every flow; 10 = invisible until needed.\n3. **Consistency** — does it match the surrounding system's conventions? 0 = a foreign body; 10 = indistinguishable from neighboring features.\n4. **Accessibility** — for UI: keyboard / screen-reader / contrast / motion. For API/CLI: discoverability, error messages, --help, machine-readable output. 0 = unusable for entire categories of users; 10 = enables everyone.\n\n## Verdict rule\n\n- All four dimensions ≥ 6 → `pass`.\n- Any dimension < 6 → `fail`.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: clarity=N ergonomics=N consistency=N accessibility=N\n Lowest-scoring dimension first, with the SINGLE concrete change that would raise it.\n```\n\n## Examples\n\n**Pass:** \"clarity=8 ergonomics=7 consistency=9 accessibility=6. Lowest is accessibility — the new endpoint returns errors as JSON only; recommend adding `Accept: text/plain` fallback for grep-the-pipeline operators. Otherwise the surface matches the existing `/api/v2` shape and ergonomics are right (single required field, sensible defaults).\"\n\n**Fail:** \"clarity=4 ergonomics=6 consistency=7 accessibility=7. Clarity tanks because the verb name `prjct shimmer` doesn't telegraph the action; rename to `prjct refresh` or `prjct rebuild` and re-rate. Other dimensions are healthy.\"\n\n## Anti-patterns to refuse\n\n- Vague \"looks good\" — every dimension needs a number.\n- Ignoring accessibility for \"internal tools\" — internal users include the colorblind and the blind.\n- Failing on aesthetic taste alone (color, typography). Design rubric is about USE, not opinion.\n- Over-indexing on novelty. Surfaces that surprise users score LOW on consistency, not high.\n","spec-reviewer-rubrics/strategic.md":"# Strategic reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for strategic soundness. You receive the spec body verbatim. Apply the questions below; return a single structured verdict.\n\n## Questions to ask\n\n1. **Is the goal real?** Does this solve a problem the user (or org) actually has? Or is it a tools-team-flavored solution looking for a problem?\n2. **Is the goal worth the cost?** Crude estimate of build cost vs. impact. If goal is small but cost is large, fail.\n3. **Is `out_of_scope` coherent with `goal`?** Goal that says \"fix onboarding\" with `out_of_scope: [\"welcome email\", \"first-login flow\"]` — what's left? Fail if scope evaporates the goal.\n4. **Is the spec OVER-scoped?** Trying to ship a quarter's work in one PR. Boil-the-lake principle says completeness is cheap when it costs minutes — fail when it costs months.\n5. **Is the spec UNDER-scoped?** Acceptance criteria so narrow that shipping doesn't move the needle. Fail when meeting all criteria still leaves the user's problem unsolved.\n6. **Are stakes honest?** \"Users will be frustrated\" is too vague. \"Auth fails for 3% of sessions during peak load\" is testable.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences. If pass, name the strongest framing element. If fail, name the SINGLE\n biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass:** \"Goal is concrete (sub-200ms p95 on dashboard) and the stakes are measurable (lost engagement on slow widgets). Scope and out_of_scope draw a clean line. The strongest element is the explicit 'no caching layer in this PR' — that's the right anti-creep.\"\n\n**Fail:** \"Goal says 'improve auth UX' but acceptance_criteria all measure backend latency. Either rewrite the goal (this is a perf spec, not UX) or rewrite the criteria (add a usability metric). Currently the spec would pass review on a perf change that didn't move UX at all.\"\n\n## Anti-patterns to refuse\n\n- Praising the spec without naming a strength (`pass: looks good!` — useless).\n- Failing without proposing a fix (the next iteration of the spec needs a path forward).\n- Auto-failing because the spec is \"ambitious\" — strategic review measures soundness, not size.\n","spec-template.md":"# Spec template — `prjct spec`\n\nA spec frames a piece of work BEFORE implementation. Cheap to write, cheap to revise; un-doing implementation isn't.\n\nThe fields below match `core/types/spec.ts`. Validation is enforced by Zod at write time.\n\n---\n\n## Title (one line)\n\nWhat you'd say to a coworker walking by your desk.\n\n## Goal (1–3 sentences)\n\nWhat success looks like. Concrete. Observable.\n\n## ELI10 (2–4 sentences)\n\nPlain English a 16-year-old could follow. Forces you to articulate why this matters without jargon.\n\n## Stakes if we ship the wrong thing (1 sentence)\n\nWhat breaks. Who notices. How fast.\n\n## Acceptance criteria (testable, observable list)\n\nEach line is a sentence ending in a verifiable claim:\n\n- the new endpoint returns 429 after the 11th request in a minute from the same IP\n- the dashboard widget renders within 200ms p95 on a synthetic 4G profile\n- `prjct spec audit <id>` blocks if any reviewer returns `fail`\n\nAnti-patterns:\n\n- \"the system should be fast\" — what threshold, measured how?\n- \"users will love it\" — not testable\n- \"follow industry best practices\" — what specifically?\n\n## Scope (what's IN)\n\nThe pieces this spec commits to. Be specific about file paths, surfaces, modules.\n\n## Out of scope (what's OUT)\n\nThe pieces this spec explicitly DOES NOT cover. This is your anti-creep shield mid-implementation.\n\n## Risks\n\nEach risk has a mitigation. A risk without a mitigation is just a complaint.\n\n- **risk:** legacy endpoints rely on the same rate-limit middleware → **mitigation:** scope key separates `/auth` from `/api`\n- **risk:** Redis dependency raises ops cost → **mitigation:** start with in-memory token bucket; swap to Redis only above 5 RPS\n\n## Test plan\n\nHow you'll prove the acceptance criteria. Includes the unhappy path.\n\n- unit tests for the token bucket math\n- integration test: 11 requests, 11th returns 429\n- load test: 100 RPS sustained for 60s, no memory growth\n- manual: trigger via `curl` and inspect response headers\n\n## Notes (optional)\n\nThings that don't fit anywhere else but matter for context.\n\n---\n\n## Lifecycle\n\n```\ndraft → reviewed → in_progress → shipped\n → archived\n```\n\n- `draft` — created, not yet audited.\n- `reviewed` — `prjct audit-spec` returned pass on all three reviewers.\n- `in_progress` — at least one task with `linked_spec_id` exists.\n- `shipped` — code merged, criteria met (or override accepted).\n- `archived` — superseded or abandoned.\n\n## Verb cheatsheet\n\n```\nprjct spec \"<title>\" # draft — NO `draft` subverb, pass title directly\nprjct spec list [--status <s>]\nprjct spec show <id>\nprjct spec update <id> --json '{...}' # PATCH content (shallow merge)\nprjct spec audit <id> # emit subagent dispatch\nprjct spec record-review <id> --reviewer <name> --verdict <pass|fail> --notes \"...\"\nprjct spec link-task <id> --task-id <task>\nprjct spec ship <id> [--pr <n>]\nprjct spec set-status <id> --status archived\nprjct spec inventory [--md|--json] # coverage map per module\n```\n\n> **No `draft` subverb.** `prjct spec \"<title>\"` already creates a draft. The CLI tolerates `prjct spec draft|new|create \"<title>\"` as friendly aliases (the leading word is stripped) so `prjct spec draft \"rate limiting\"` and `prjct spec \"rate limiting\"` produce the same spec — but the canonical form has no leading verb.\n","windsurf/router.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n# prjct\n\nCore: /sync, /task, /status, /ship, /workflow, /spec, /guard\nOther: run `prjct <command> --md` and follow CLI output\n"}