[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71M69TPX9ZEVE5WXRNEMBC8":3,"skill-same:01M71M69TPX9ZEVE5WXRNEMBC8":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":46,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M71M69TPX9ZEVE5WXRNEMBC8","monomind-dev-rules",null,"Operating rules every role of monomind's monomind-dev org follows on every command: repo and worktree layout, environment prefix, scratch and tmp hygiene, git identity and sandbox limits, evidence format, independent tests, cross-run lessons, lint\u002Fbuild\u002Fbaseline traps, brevity.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.monomind\u002Forg-skills\u002Fmonomind-dev-rules\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"Rules","monomind dev rules","dev","operations","build","layout","command","limits","worktree","github","lint","lessons","brevity","tests","sandbox","scratch","environment","repo","evidence","operating","2026-11-10 10:56:23",false,"---\nname: monomind-dev-rules\ndescription: \"Operating rules every role of monomind's monomind-dev org follows on every command: repo and worktree layout, environment prefix, scratch and tmp hygiene, git identity and sandbox limits, evidence format, independent tests, cross-run lessons, lint\u002Fbuild\u002Fbaseline traps, brevity.\"\ntags: [\"engineering\",\"operations\"]\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# monomind-dev rules (every role, every command)\n\n**Names used below.** REPO is the main checkout — the directory your session\nstarts in (`pwd` before you `cd` anywhere); it is on branch main. RUN is\n`REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fruns\u002F\u003Crun-id>` and holds ledger.json, plans\u002F,\nlogs\u002F, evidence\u002F and REPORT.md. Each item works in its own worktree\nWT=`REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fwork\u002F\u003Citem-id>` on branch `dev\u002F\u003Citem-id>`.\nTMPDIR is `$HOME\u002Fmdev-tmp`. Every task message gives you the run id, the item id,\nthe SHA to work on and the paths of earlier evidence — use those, never values\nremembered from an earlier task or run.\n\n## The main checkout\n- REPO may hold the owner's own uncommitted work: never modify, stash, reset,\n  checkout or commit it. Only integrator changes local main, and only by\n  fast-forward.\n\n## Environment\n- Prefix EVERY command that runs node, pnpm, npm, vitest or monomind with\n  `env -u MONOMIND_SDK_AGENT -u MONOMIND_HOOK_QUIET -u MONOMIND_GRAPH_GATE -u MONOMIND_NO_LOCAL_EMBEDDINGS MONOMIND_CRASH_REPORTING=off MONOMIND_AUTO_UPDATE=false CI=true TMPDIR=$HOME\u002Fmdev-tmp`.\n  Org sessions inject variables that silently change monomind's own behavior\n  (issue #249).\n- Never write under \u002Ftmp: it is a RAM tmpfs with a per-user quota, and filling it\n  breaks every shell.\n- SCRATCH: files you need to Read\u002FWrite\u002FEdit with the file tools go in\n  `REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fscratch\u002F\u003Citem-id>-\u003Ccheck>` (the file tools\n  cannot reach paths outside the repo, issue #303). Sample projects that\n  monograph must watch, and fake HOMEs, go in `$HOME\u002Fmdev-tmp\u002F\u003Citem-id>-\u003Ccheck>`\n  and are handled with Bash only (no dot-directories there: monograph's watcher\n  ignores dot-segment paths).\n\n## Git\n- Never run `git config` in any checkout of this repo (worktrees share\n  .git\u002Fconfig; issue #250).\n- NEVER use `git stash` in any form: the stash stack is shared by every worktree\n  and the owner has entries on it (issue #300). Use `git diff > $SCRATCH\u002Fx.patch`\n  + `git apply -R`, or a scratch worktree at the base SHA.\n- Known policy gaps (#299): at policy.git read, `merge-base`, `ls-remote`,\n  `show-ref`, `reflog` are denied — use `git diff main...HEAD` \u002F\n  `git log main..HEAD` instead.\n- Commit only with\n  `GIT_AUTHOR_NAME=nokhodian GIT_AUTHOR_EMAIL=nokhodian@gmail.com GIT_COMMITTER_NAME=nokhodian GIT_COMMITTER_EMAIL=nokhodian@gmail.com git commit`\n  using conventional commits (when it resolves an issue, put `Fixes #N` in the\n  body; a bare `(#N)` leaves the issue open), and NO trailers (no\n  Co-Authored-By, Claude-Session or 'Generated with').\n- Stage explicit paths, never `git add -A` \u002F `git add .`.\n- Never push, never touch origin, npm or GitHub.\n\n## Evidence\n- Every claim is backed by a log under `RUN\u002Flogs\u002F\u003Crole>\u002F\u003Citem-id>-\u003Ccheck>.log`\n  produced in THIS run, with the SHA it ran against.\n- Report each check as {name, command, exit_code, PASS|FAIL|SKIP|FLAKY, log path,\n  one-line evidence}. SKIP needs the exact error proving the check is impossible;\n  never call a failure 'environmental' or 'pre-existing' without reproducing it\n  on main.\n- Finish every task with `org_task_done`, putting that table in the result.\n  This org requires EVIDENCE: pass `evidence` = { `headSha`: the commit your\n  checks ran on (`git -C \u003Cdir> rev-parse HEAD`), `worktree`: the item's WT when\n  the work is on an item (omit it only for work on REPO itself, such as triage\n  or the final report), `checks`: one { command, exitCode, output } per\n  acceptance criterion — the real command, its real exit code, the tail of its\n  output }. When the correct outcome is a non-zero exit, add `expectExit: \u003Ccode>`\n  to that check plus a one-line `expectReason` saying why (\"404 = branch not\n  protected\") — never append `|| true`, and `expectExit` without a reason is\n  refused. `expectExit` is for SINGLE-PURPOSE commands only: it is refused on a\n  test suite or any aggregate runner (`vitest`, `jest`, a `pnpm`\u002F`npm`\u002F`yarn`\n  test script, `node --test`, `pnpm -r`, `pnpm --filter … test`, `run verify`,\n  `test:all`), because a suite's exit code means \"at least one of many things\n  failed\" and accepting it accepts every OTHER failure too. With one\n  known-failing test, run that file alone (`npx vitest run path\u002Fto\u002Fone.test.ts`)\n  and declare `expectExit` on THAT check, or exclude it so the suite exits 0 and\n  record the exclusion in the result. A check that misses its expected exit\n  or a sha that is no longer that worktree's HEAD is refused; after 3 refusals the task is failed and escalated to dev-lead. A task\n  with nothing to run (a verdict, a plan) still names the command that proves\n  it — e.g. `test -s \u003Cplan or verdict path>`, or `head -1 \u003Cverdict file>`.\n- The evidence proves the task was done, not that the item is good: a FAIL,\n  REJECT, REVISE or DROP verdict is a completed task. Its evidence checks are\n  the commands that prove the verdict file exists and names the SHA; the failing\n  commands and their exit codes go in the result's check table.\n\n## Independent tests\n- test-author creates WT (`git -C REPO worktree add -b dev\u002F\u003Citem-id> WT main`)\n  and, before BUILD, commits the item's failing tests in ONE commit that touches\n  only test files, fixtures and test helpers. It writes\n  `RUN\u002Fevidence\u002F\u003Citem-id>-tests.md`: line 1 `TESTS: \u003Cfull SHA of that commit>`\n  (or `TESTS: none — \u003Creason>` when nothing can be tested automatically), then\n  one `- \u003Cpath>` line per file of that commit (the PROTECTED paths), then per\n  acceptance criterion the test that covers it (or `manual: \u003Cwhy>`) and the log\n  of its failing run.\n- Protected paths are read-only for every other role. Developers make those\n  tests pass and may ADD tests in other files, but never edit, rename or delete\n  a protected path. A developer who finds one wrong stops and reports it with\n  evidence; only a test-author TESTS revision changes it (a new commit, and\n  tests.md names the new SHA and paths).\n- TEST INTEGRITY (verifier's ITEM VERIFY, integrator's MERGE GATE): with T the\n  SHA on line 1 and P the protected paths,\n  `git -C WT log --format=%H main..HEAD | grep -qx T` (T is on the branch) and\n  `git -C WT diff --name-only T..HEAD -- P` prints nothing. Otherwise it is a\n  FAIL (verifier) or a REFUSE (integrator) naming the changed path. `TESTS: none`\n  passes trivially.\n\n## Lessons across runs\nOrg memory persists across runs of this org (`org_remember` writes it,\n`org_recall` searches it). Lessons are how a finding in one run stops the same\nmistake in the next.\n- RECORD (dev-lead): for every FAIL (verifier), REJECT (reviewer) and REVISE\n  (product-evaluator) finding, distill ONE short reusable rule — what to do next\n  time, not what went wrong in this item; at most two sentences; name the AREA\n  (the package or subsystem, e.g. `orgrt`, `monograph`, `cli init`, `skills`).\n  First `org_recall` with `lesson \u003Carea> \u003Ckey words>`; if a lesson already says\n  it, do not store a reworded copy. Otherwise `org_remember` with scope `org`\n  and content `lesson: [\u003Carea>] \u003Crule> (\u003Crun-id>\u002F\u003Citem-id>, \u003Crole> \u003Cverdict>)`.\n  Also append that line to `RUN\u002Flessons.md`, this run's list.\n- APPLY (architect, test-author, developer-1, developer-2): at the start of\n  every task, `org_recall` with `lesson \u003Carea>` for each area the task touches\n  (from the plan or the task message) and apply the lessons that fit. Name the\n  ones you applied in your `org_task_done` result, one line each. A lesson\n  never overrides the task message, the plan or these rules; when one\n  conflicts, follow those and say so in the result.\n- PROPOSE (dev-lead, at FINISH): REPORT.md gets a `## Lessons` section listing\n  every line of `RUN\u002Flessons.md`, then the lessons you PROPOSE as permanent\n  rules for this skill, each with the exact sentence and the section it belongs\n  in. Never edit this skill or an org config yourself: the owner decides.\n\n## Destructive commands\n- `cleanup` (any variant), `init --force`, recursive deletes, `git clean`,\n  `git reset --hard` and anything else that deletes or overwrites files run ONLY\n  inside the item's WT or a scratch dir you created, with `cd` into it in the\n  SAME command and a `pwd` check first. Never in REPO: on 2026-09-22\n  `cleanup --force` run from the main checkout deleted 1003 tracked files and\n  the project's memory store.\n\n## Build, lint and test traps\n- LINT: `pnpm run lint` from a worktree under .monomind\u002F silently checks 0 files\n  (issue #297) — run `npx biome check packages tests scripts` and treat any\n  output that does not report >1000 checked files as a FAIL.\n- BUILD: if tsgo dies on a signal (SIGSEGV, not a TypeScript error), rerun that\n  build once and log both; never copy dist\u002F from another checkout.\n- BASELINE: the org's git guard env makes 17 git-config tests fail inside roles\n  (issue #298: @monoes\u002Fmonograph hooks-marker\u002Fhooks-install\u002Fhooks-status,\n  role-sandbox.test.ts excludesFile) — a failure is a regression only if it is\n  not in the verifier's baseline taken in the same role environment.\n\n## Working style\n- BREVITY: messages to other roles are instructions and evidence, not essays —\n  at most ~20 lines plus log paths. Findings about the milestone go in the\n  ledger entry, not in prose.\n- Use monograph first for code navigation (monograph_suggest \u002F\n  monograph_context \u002F monograph_impact), grep only as a fallback.\n- Keep files under 500 lines. Follow the repo's CLAUDE.md coding principles:\n  surgical changes, no speculative features, match surrounding style.\n\n## Unattended\n- After dev-lead's PREFLIGHT nobody asks the human anything:\n  org_gate is denied for every role, and ask_human for every role except\n  dev-lead, which may use it only during PREFLIGHT.\n","# monomind-dev rules (every role, every command)\n\n**Names used below.** REPO is the main checkout — the directory your session\nstarts in (`pwd` before you `cd` anywhere); it is on branch main. RUN is\n`REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fruns\u002F\u003Crun-id>` and holds ledger.json, plans\u002F,\nlogs\u002F, evidence\u002F and REPORT.md. Each item works in its own worktree\nWT=`REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fwork\u002F\u003Citem-id>` on branch `dev\u002F\u003Citem-id>`.\nTMPDIR is `$HOME\u002Fmdev-tmp`. Every task message gives you the run id, the item id,\nthe SHA to work on and the paths of earlier evidence — use those, never values\nremembered from an earlier task or run.\n\n## The main checkout\n- REPO may hold the owner's own uncommitted work: never modify, stash, reset,\n  checkout or commit it. Only integrator changes local main, and only by\n  fast-forward.\n\n## Environment\n- Prefix EVERY command that runs node, pnpm, npm, vitest or monomind with\n  `env -u MONOMIND_SDK_AGENT -u MONOMIND_HOOK_QUIET -u MONOMIND_GRAPH_GATE -u MONOMIND_NO_LOCAL_EMBEDDINGS MONOMIND_CRASH_REPORTING=off MONOMIND_AUTO_UPDATE=false CI=true TMPDIR=$HOME\u002Fmdev-tmp`.\n  Org sessions inject variables that silently change monomind's own behavior\n  (issue #249).\n- Never write under \u002Ftmp: it is a RAM tmpfs with a per-user quota, and filling it\n  breaks every shell.\n- SCRATCH: files you need to Read\u002FWrite\u002FEdit with the file tools go in\n  `REPO\u002F.monomind\u002Forgs\u002Fmonomind-dev\u002Fscratch\u002F\u003Citem-id>-\u003Ccheck>` (the file tools\n  cannot reach paths outside the repo, issue #303). Sample projects that\n  monograph must watch, and fake HOMEs, go in `$HOME\u002Fmdev-tmp\u002F\u003Citem-id>-\u003Ccheck>`\n  and are handled with Bash only (no dot-directories there: monograph's watcher\n  ignores dot-segment paths).\n\n## Git\n- Never run `git config` in any checkout of this repo (worktrees share\n  .git\u002Fconfig; issue #250).\n- NEVER use `git stash` in any form: the stash stack is shared by every worktree\n  and the owner has entries on it (issue #300). Use `git diff > $SCRATCH\u002Fx.patch`\n  + `git apply -R`, or a scratch worktree at the base SHA.\n- Known policy gaps (#299): at policy.git read, `merge-base`, `ls-remote`,\n  `show-ref`, `reflog` are denied — use `git diff main...HEAD` \u002F\n  `git log main..HEAD` instead.\n- Commit only with\n  `GIT_AUTHOR_NAME=nokhodian GIT_AUTHOR_EMAIL=nokhodian@gmail.com GIT_COMMITTER_NAME=nokhodian GIT_COMMITTER_EMAIL=nokhodian@gmail.com git commit`\n  using conventional commits (when it resolves an issue, put `Fixes #N` in the\n  body; a bare `(#N)` leaves the issue open), and NO trailers (no\n  Co-Authored-By, Claude-Session or 'Generated with').\n- Stage explicit paths, never `git add -A` \u002F `git add .`.\n- Never push, never touch origin, npm or GitHub.\n\n## Evidence\n- Every claim is backed by a log under `RUN\u002Flogs\u002F\u003Crole>\u002F\u003Citem-id>-\u003Ccheck>.log`\n  produced in THIS run, with the SHA it ran against.\n- Report each check as {name, command, exit_code, PASS|FAIL|SKIP|FLAKY, log path,\n  one-line evidence}. SKIP needs the exact error proving the check is impossible;\n  never call a failure 'environmental' or 'pre-existing' without reproducing it\n  on main.\n- Finish every task with `org_task_done`, putting that table in the result.\n  This org requires EVIDENCE: pass `evidence` = { `headSha`: the commit your\n  checks ran on (`git -C \u003Cdir> rev-parse HEAD`), `worktree`: the item's WT when\n  the work is on an item (omit it only for work on REPO itself, such as triage\n  or the final report), `checks`: one { command, exitCode, output } per\n  acceptance criterion — the real command, its real exit code, the tail of its\n  output }. When the correct outcome is a non-zero exit, add `expectExit: \u003Ccode>`\n  to that check plus a one-line `expectReason` saying why (\"404 = branch not\n  protected\") — never append `|| true`, and `expectExit` without a reason is\n  refused. `expectExit` is for SINGLE-PURPOSE commands only: it is refused on a\n  test suite or any aggregate runner (`vitest`, `jest`, a `pnpm`\u002F`npm`\u002F`yarn`\n  test script, `node --test`, `pnpm -r`, `pnpm --filter … test`, `run verify`,\n  `test:all`), because a suite's exit code means \"at least one of many things\n  failed\" and accepting it accepts every OTHER failure too. With one\n  known-failing test, run that file alone (`npx vitest run path\u002Fto\u002Fone.test.ts`)\n  and declare `expectExit` on THAT check, or exclude it so the suite exits 0 and\n  record the exclusion in the result. A check that misses its expected exit\n  or a sha that is no longer that worktree's HEAD is refused; after 3 refusals the task is failed and escalated to dev-lead. A task\n  with nothing to run (a verdict, a plan) still names the command that proves\n  it — e.g. `test -s \u003Cplan or verdict path>`, or `head -1 \u003Cverdict file>`.\n- The evidence proves the task was done, not that the item is good: a FAIL,\n  REJECT, REVISE or DROP verdict is a completed task. Its evidence checks are\n  the commands that prove the verdict file exists and names the SHA; the failing\n  commands and their exit codes go in the result's check table.\n\n## Independent tests\n- test-author creates WT (`git -C REPO worktree add -b dev\u002F\u003Citem-id> WT main`)\n  and, before BUILD, commits the item's failing tests in ONE commit that touches\n  only test files, fixtures and test helpers. It writes\n  `RUN\u002Fevidence\u002F\u003Citem-id>-tests.md`: line 1 `TESTS: \u003Cfull SHA of that commit>`\n  (or `TESTS: none — \u003Creason>` when nothing can be tested automatically), then\n  one `- \u003Cpath>` line per file of that commit (the PROTECTED paths), then per\n  acceptance criterion the test that covers it (or `manual: \u003Cwhy>`) and the log\n  of its failing run.\n- Protected paths are read-only for every other role. Developers make those\n  tests pass and may ADD tests in other files, but never edit, rename or delete\n  a protected path. A developer who finds one wrong stops and reports it with\n  evidence; only a test-author TESTS revision changes it (a new commit, and\n  tests.md names the new SHA and paths).\n- TEST INTEGRITY (verifier's ITEM VERIFY, integrator's MERGE GATE): with T the\n  SHA on line 1 and P the protected paths,\n  `git -C WT log --format=%H main..HEAD | grep -qx T` (T is on the branch) and\n  `git -C WT diff --name-only T..HEAD -- P` prints nothing. Otherwise it is a\n  FAIL (verifier) or a REFUSE (integrator) naming the changed path. `TESTS: none`\n  passes trivially.\n\n## Lessons across runs\nOrg memory persists across runs of this org (`org_remember` writes it,\n`org_recall` searches it). Lessons are how a finding in one run stops the same\nmistake in the next.\n- RECORD (dev-lead): for every FAIL (verifier), REJECT (reviewer) and REVISE\n  (product-evaluator) finding, distill ONE short reusable rule — what to do next\n  time, not what went wrong in this item; at most two sentences; name the AREA\n  (the package or subsystem, e.g. `orgrt`, `monograph`, `cli init`, `skills`).\n  First `org_recall` with `lesson \u003Carea> \u003Ckey words>`; if a lesson already says\n  it, do not store a reworded copy. Otherwise `org_remember` with scope `org`\n  and content `lesson: [\u003Carea>] \u003Crule> (\u003Crun-id>\u002F\u003Citem-id>, \u003Crole> \u003Cverdict>)`.\n  Also append that line to `RUN\u002Flessons.md`, this run's list.\n- APPLY (architect, test-author, developer-1, developer-2): at the start of\n  every task, `org_recall` with `lesson \u003Carea>` for each area the task touches\n  (from the plan or the task message) and apply the lessons that fit. Name the\n  ones you applied in your `org_task_done` result, one line each. A lesson\n  never overrides the task message, the plan or these rules; when one\n  conflicts, follow those and say so in the result.\n- PROPOSE (dev-lead, at FINISH): REPORT.md gets a `## Lessons` section listing\n  every line of `RUN\u002Flessons.md`, then the lessons you PROPOSE as permanent\n  rules for this skill, each with the exact sentence and the section it belongs\n  in. Never edit this skill or an org config yourself: the owner decides.\n\n## Destructive commands\n- `cleanup` (any variant), `init --force`, recursive deletes, `git clean`,\n  `git reset --hard` and anything else that deletes or overwrites files run ONLY\n  inside the item's WT or a scratch dir you created, with `cd` into it in the\n  SAME command and a `pwd` check first. Never in REPO: on 2026-09-22\n  `cleanup --force` run from the main checkout deleted 1003 tracked files and\n  the project's memory store.\n\n## Build, lint and test traps\n- LINT: `pnpm run lint` from a worktree under .monomind\u002F silently checks 0 files\n  (issue #297) — run `npx biome check packages tests scripts` and treat any\n  output that does not report >1000 checked files as a FAIL.\n- BUILD: if tsgo dies on a signal (SIGSEGV, not a TypeScript error), rerun that\n  build once and log both; never copy dist\u002F from another checkout.\n- BASELINE: the org's git guard env makes 17 git-config tests fail inside roles\n  (issue #298: @monoes\u002Fmonograph hooks-marker\u002Fhooks-install\u002Fhooks-status,\n  role-sandbox.test.ts excludesFile) — a failure is a regression only if it is\n  not in the verifier's baseline taken in the same role environment.\n\n## Working style\n- BREVITY: messages to other roles are instructions and evidence, not essays —\n  at most ~20 lines plus log paths. Findings about the milestone go in the\n  ledger entry, not in prose.\n- Use monograph first for code navigation (monograph_suggest \u002F\n  monograph_context \u002F monograph_impact), grep only as a fallback.\n- Keep files under 500 lines. Follow the repo's CLAUDE.md coding principles:\n  surgical changes, no speculative features, match surrounding style.\n\n## Unattended\n- After dev-lead's PREFLIGHT nobody asks the human anything:\n  org_gate is denied for every role, and ask_human for every role except\n  dev-lead, which may use it only during PREFLIGHT.\n",{"name":5,"tags":43,"tools":45,"source":46,"license":14,"description":7},[44,21],"engineering",[],"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a",".monomind\u002Forg-skills\u002Fmonomind-dev-rules",2,"https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-14 03:30:52",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add monoes\u002Fmonomind --skill monomind-dev-rules",{"tool":61,"command":62},"bunx","bunx skills add monoes\u002Fmonomind --skill monomind-dev-rules",{"tool":64,"command":65},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill monomind-dev-rules","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.monomind\u002Forg-skills\u002Fmonomind-dev-rules\u002FSKILL.md",true,[],[70,98,135,162,186,212],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":97},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":103,"sourceHtmlUrl":104,"categories":105,"keywords":116,"publishedAt":97},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[117,118,119,81,120,121,122,123,86,124,125,126,127,128,129,130,131,132,133,134],"writing","writing plans","plans","superpowers","implementation plan","when","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":97},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000031","产品经理",[128,146,147,148,149,84,150,122,151,152,153,127,154,155,156,157,158,159,160,161],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":166,"sourceHtmlUrl":167,"categories":168,"keywords":172,"publishedAt":97},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[169],{"categoryNo":170,"categoryName":171,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000033","数据分析师",[86,128,173,174,175,176,84,160,122,177,178,179,180,153,27,181,182,183,184,185],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","sql","https","syntax","plugins","data",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":198,"publishedAt":97},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[192,195],{"categoryNo":193,"categoryName":194,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":196,"categoryName":197,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发",[199,200,201,202,175,203,204,205,206,85,207,208,209,86,89,27,22,210,211,182],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","dependency","devops",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":97},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[218],{"categoryNo":196,"categoryName":197,"taxonomyType":109,"taxonomyTypeDesc":110},[201,220,221,222,223,224,225,175,226,227,124,228,229,230,89,27,231,21,182,232],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","systems"]