[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81239":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":12,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":14,"stars30d":14,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":15,"rankGlobal":10,"rankLanguage":10,"license":16,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":19,"hasPages":17,"topics":20,"createdAt":10,"pushedAt":10,"updatedAt":33,"readmeContent":34,"aiSummary":35,"trendingCount":14,"starSnapshotCount":14,"syncStatus":36,"lastSyncTime":37,"discoverSource":38},81239,"97","oribarilan\u002F97","oribarilan","Agent skills distilled from the hard-won lessons of world-renowned programmers, in the spirit of \"97 Things Every Programmer Should Know\"","",null,"JavaScript",22,1,0,40.9,"Other",false,"main",true,[21,22,23,24,25,26,27,28,29,30,31,32],"agent-skills","ai-agents","best-practices","claude-code","claude-code-plugin","claude-code-skills","coding-agents","copilot-cli","copilot-cli-plugin","opencode","opencode-plugin","programming-principles","2026-06-12 04:01:32","\u003Ch1 align=\"center\">97\u003C\u002Fh1>\n\n\u003Cp align=\"center\">\u003Cstrong>Your agent, on the shoulders of giants.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Foribarilan\u002F97\u002Factions\u002Fworkflows\u002Ftest.yml\">\u003Cimg src=\"https:\u002F\u002Fgithub.com\u002Foribarilan\u002F97\u002Factions\u002Fworkflows\u002Ftest.yml\u002Fbadge.svg?branch=main\" alt=\"CI\">\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\u003Cem>Early beta. Works on Claude Code, GitHub Copilot CLI, and OpenCode.\u003C\u002Fem>\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"#install\">Install\u003C\u002Fa> ·\n  \u003Ca href=\"#whats-inside\">What's inside\u003C\u002Fa> ·\n  \u003Ca href=\"#does-it-work\">Does it work?\u003C\u002Fa> ·\n  \u003Ca href=\"#faq\">FAQ\u003C\u002Fa> ·\n  \u003Ca href=\"#credits\">Credits\u003C\u002Fa> ·\n  \u003Ca href=\"#development\">Development\u003C\u002Fa>\n\u003C\u002Fp>\n\n---\n\n## What this is\n\nSkills your coding agent uses at the moment of decision: when it's about\nto refactor, write a test, design an API, or commit. They draw on\nFowler on refactoring, 12-factor on configuration and deploys,\nOusterhout and Liskov on API design, Nygard on resilience patterns,\nand others.\n\nThe project is named after *97 Things Every Programmer Should Know*\n(O'Reilly, ed. Kevlin Henney) and follows the same idea: one principle\nat a time, applied when it matters. Every principle is attributed to\nits original author. Principles are language-agnostic and durable.\n\n## Install\n\n*Works on Linux, macOS, and Windows. Node 18+.*\n\nThree supported harnesses. Pick the one you use.\n\n### Claude Code\n\n```\n\u002Fplugin marketplace add oribarilan\u002F97\n\u002Fplugin install 97@97-marketplace\n```\n\nUpdates ship via the marketplace; run `\u002Fplugin update 97` when a new version is available.\n\n### GitHub Copilot CLI\n\n```sh\ncopilot plugin marketplace add oribarilan\u002F97\ncopilot plugin install 97@97-marketplace\n```\n\nUpdates ship via the marketplace; run `copilot plugin update 97` when a new version is available.\n\n### OpenCode\n\nAdd to your OpenCode config file.\n\n```jsonc\n{\n  \"plugin\": [\n    \"97@git+https:\u002F\u002Fgithub.com\u002Foribarilan\u002F97.git\"\n  ]\n}\n```\n\nRestart OpenCode. The plugin pulls the latest commit on each restart.\n\n\u003Cdetails>\n\u003Csummary>\u003Cstrong>Advanced: pinned install\u003C\u002Fstrong>\u003C\u002Fsummary>\n\nFor reproducible behavior across sessions, pin to a specific tag (`#vX.Y.Z`):\n\n```jsonc\n{\n  \"plugin\": [\n    \"97@git+https:\u002F\u002Fgithub.com\u002Foribarilan\u002F97.git#v0.5.0\"\n  ]\n}\n```\n\n\u003C\u002Fdetails>\n\n## What's inside\n\n| Skill | When it applies |\n|---|---|\n| `using-97` | Always — entry skill that loads the trigger map |\n| `before-you-refactor` | Considering, evaluating, or performing a refactor, restructure, cross-file rename, or cleanup |\n| `clean-code` | Writing or reviewing functions, classes, naming, or ≥3 lines of non-trivial logic (includes Single Responsibility Principle (SRP), DRY, KISS, YAGNI) |\n| `domain-modeling` | Introducing, reviewing, or renaming a top-level type\u002Ftable\u002Fdomain concept, or deciding where state lives |\n| `api-design` | Designing or reviewing a public API, function signature, module boundary, exported type, or any contract other code depends on (includes LSP, SRP at the boundary) |\n| `testing-discipline` | Writing or reviewing tests, designing test data, naming a test, choosing what to assert, or writing test helpers\u002Fmocks\u002Ffixtures |\n| `correctness-traps` | Writing or reviewing error handling, floating-point math, concurrent code, remote calls, singletons, hot-path data structures, or high-volume log statements |\n| `security-and-trust-boundaries` | Writing or reviewing code that parses user input, builds SQL\u002Fshell commands, handles secrets\u002Fcredentials, changes auth checks, deserializes untrusted data, or constructs paths\u002FURLs from input |\n| `observability` | Writing or reviewing request handlers, RPCs, or background jobs for production; adding tracing, metrics, or structured-log calls; or making diagnosability decisions |\n| `build-deploy-and-tooling` | Writing, reviewing, or changing build scripts, CI config, deploy pipelines, repo setup, or evaluating a new tool\u002Fdependency |\n| `self-review` | About to commit, finish a task, open a PR, summarize work, or when asked for a review or hand-off of your own work |\n| `working-with-users-and-team` | Gathering or interpreting requirements, estimating effort, or communicating with stakeholders about what to build |\n\n12 skills total: one entry skill plus 11 themed skills. Every principle\nis cited and attributed in the skill's `principles.md`.\n\n### Giants\n\nEvery principle the agent applies is attributed to its original author.\nEach skill ships a `principles.md` next to its `SKILL.md` with, per\nprinciple: the author, a link to the source (CC-BY-3.0 essay, book\nchapter, RFC, or specification as appropriate), our paraphrase, and\nhow the agent applies it.\n\nThe sources currently cited:\n\n- *97 Things Every Programmer Should Know* — Kevlin Henney (ed.) and contributors. Namesake; principles across most skills.\n- Martin Fowler — *Refactoring*. Code smells (Long Method, Primitive Obsession, and others).\n- Scott Wlaschin — *Domain Modeling Made Functional*. Make invalid states unrepresentable.\n- Michael Nygard — *Release It!* Stability patterns (circuit breaker, timeout, bulkhead, and others).\n- Adam Wiggins — *The Twelve-Factor App*. Config in the environment, build\u002Frelease\u002Frun separation, and other deploy hygiene.\n- Jez Humble & David Farley — *Continuous Delivery*. Pipeline as code.\n- Steve Freeman & Nat Pryce — *Growing Object-Oriented Software, Guided by Tests*. Listen to test pain.\n- Gerard Meszaros — *xUnit Test Patterns*. Test smells (mystery guest, fragile test, and others).\n- John Ousterhout — *A Philosophy of Software Design*. Deep modules; define errors out of existence.\n- Barbara Liskov — the Liskov Substitution Principle.\n- Alexis King — [*Parse, Don't Validate*](https:\u002F\u002Flexi-lambda.github.io\u002Fblog\u002F2019\u002F11\u002F05\u002Fparse-don-t-validate\u002F).\n- Google SRE — *Site Reliability Engineering*. The four golden signals.\n- OpenTelemetry \u002F W3C — Trace Context, structured-log conventions.\n- Charity Majors, Liz Fong-Jones, George Miranda — *Observability Engineering*. Cardinality discipline.\n\nYou can ask the agent at any time: *\"Who wrote the principle you just\napplied, and why does it say what it says?\"* The agent will open the\nrelevant `principles.md` and tell you who wrote it, link the source,\nand explain the reasoning. 97 doubles as a reading list — the\nprinciples point back to the books and essays they came from.\n\nThe `security-and-trust-boundaries` and `observability` skills are\nmostly written for this project, drawing on sources outside *97 Things*;\nsee `CONTENT-LICENSE.md`.\n\n## Does it work?\n\nStandard coding benchmarks (e.g., SWE-bench) test\nwhether an agent produces *working* code: pass the tests, fix the bug,\nreturn the right answer. An agent can score 100% on SWE-bench with\nf-string SQL and a god-function. Those benchmarks don't measure what 97\ntargets: whether the agent writes code a senior engineer would approve.\n\nWe built a craft-quality eval instead. 11 scenarios (one per skill),\neach with a latent craft issue the skill should catch. Each scenario\nruns 15 times on two arms: with 97 and without. An independent judge\n(claude-opus-4.7) compares both diffs blindly on correctness, code\nquality, and skill-specific criteria.\n\nWith 97, agents write code that is **equal or better 77–95%** of the\ntime, and **strictly better in 62–77%** of cases, across 11 dimensions\nincluding security, observability, testing, and API design.\n\n| | Wins | Never worse |\n|---|---|---|\n| **claude-opus-4.6** | **77%** | **95%** |\n| **gpt-5.5** | **62%** | **77%** |\n\nPer-skill results — win rate with ties in parentheses:\n\n| Skill | gpt-5.5 | opus-4.6 |\n|---|---|---|\n| observability | 93% (7%) | 100% |\n| security | 87% | 27% (67%) |\n| api-design | 70% (3%) | 93% |\n| clean-code | 70% (10%) | 70% (17%) |\n| build-deploy | 67% (23%) | 100% |\n| domain-modeling | 67% (27%) | 80% (3%) |\n| working-with-users | 63% (7%) | 100% |\n| before-you-refactor | 60% (3%) | 93% (7%) |\n| self-review | 50% (3%) | 20% (80%) |\n| testing-discipline | 50% (3%) | 90% |\n| correctness-traps | 3% (77%) | 77% (20%) |\n\nThese scenarios started as an internal eval to avoid regressions and\ntrack progress across 97 versions. They're custom-built to surface\neach skill's value, not pulled from an established benchmark, but the\nresults felt worth sharing. If you know of a benchmark that would be a\ngood fit, please [open an issue](https:\u002F\u002Fgithub.com\u002Foribarilan\u002F97\u002Fissues)\nand I'll run it.\n\n## FAQ\n\n### How does 97 compare to popular plugins like `superpowers` or `BMAD`?\n\nThey sit at different layers, so you can run them side by side:\n\n| Layer | Project | What it changes |\n|---|---|---|\n| **Methodology** | [`BMAD-METHOD`](https:\u002F\u002Fgithub.com\u002Fbmad-code-org\u002FBMAD-METHOD) | Which *role* the agent plays and which *phase* of the SDLC it's in (PM, Architect, Dev, SM…) |\n| **Process** | [`superpowers`](https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers) | *How* the agent works — when to plan, how to debug, when work is verified |\n| **Craft** | **`97`** | *What* makes the code good once the agent is writing — naming, API shape, error handling, testing, security |\n\nTake writing a test:\n\n- `BMAD` picks *who* on the agent team writes it (the Dev persona).\n- `superpowers\u002Ftest-driven-development` decides *whether* a test gets written.\n- `97\u002Ftesting-discipline` decides *what makes that test any good*.\n\n97's entry skill draws an explicit line at the superpowers boundary: process\nskills run first. `superpowers\u002Fverification-before-completion` asks *did it work*;\n`97\u002Fself-review` asks *is it well-considered*.\n\n### Where do SOLID, DRY, KISS, YAGNI live in 97?\n\nPartially, and on purpose. SRP is named twice — in `clean-code` for one-reason-to-change at unit scope, and in `api-design` for the same check at module boundaries; `before-you-refactor` carries the SRP trigger to consider a split. LSP is in `api-design`. DRY is in `clean-code`. KISS and YAGNI surface as Red Flags in `clean-code` against speculative knobs and unused hooks.\n\nOCP, ISP, and DIP are not promoted by name. The substance closest to ISP and DIP lives in `api-design` as narrow interfaces, abstractions at boundaries, and Ousterhout's deep modules. OCP is intentionally left aside — speculative extension points conflict with YAGNI. The Giants list above is built from authors and works, not from the SOLID acronym.\n\n## Credits\n\n- *97 Things Every Programmer Should Know: Collective Wisdom from the Experts*\n  — O'Reilly, ed. Kevlin Henney\n  ([book](https:\u002F\u002Fwww.oreilly.com\u002Flibrary\u002Fview\u002F97-things-every\u002F9780596809515\u002F),\n  [CC-BY-3.0 source mirror](https:\u002F\u002Fgithub.com\u002F97-things\u002F97-things-every-programmer-should-know))\n- Birat Rai's\n  [97-day Medium walkthrough](https:\u002F\u002Fbiratkirat.medium.com\u002F97-journey-every-programmer-should-accomplish-a0c53dbbfd47)\n  of every essay (used as a reading aid)\n- [`superpowers`](https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers) by Jesse Vincent for the multi-harness distribution pattern\n\n## Licensing\n\n- Plugin code: MIT — see [`LICENSE`](.\u002FLICENSE).\n- Skill content: original commentary on principles drawn from the source\n  authors named above, with per-principle attribution. Unofficial work,\n  not affiliated with O'Reilly, Kevlin Henney, or any contributor. See\n  [`CONTENT-LICENSE.md`](.\u002FCONTENT-LICENSE.md) for the full policy and\n  takedown commitment.\n\n## Development\n\nWe use [`just`](https:\u002F\u002Fgithub.com\u002Fcasey\u002Fjust) as the local task runner.\nRun `just` with no args to list recipes:\n\n```sh\njust            # list available recipes\njust check      # everything CI runs: lint + format-check + smoke\njust lint       # structural lint of skills\u002F\njust format     # prettier --write on JS\u002FJSON\u002FYAML\n```\n\nCI uses `npm test` directly (which is the same as `just check`), so\ncontributors who prefer npm don't need to install `just`:\n\n```sh\nnpm test          # same as `just check`\nnpm run lint      # same as `just lint`\nnpm run smoke     # same as `just test`\n```\n\nOne devDependency: `prettier`. Zero runtime deps.\n\nFor the full contributor guide — repo layout, changelog discipline, release\nprocess, CI\u002FCD, and the multi-harness adapter pattern — see\n[`CONTRIBUTE.md`](.\u002FCONTRIBUTE.md). For agent-specific conventions, see\n[`AGENTS.md`](.\u002FAGENTS.md).\n","97项目是一个旨在为编程助手提供最佳实践技能的工具，灵感来源于《每个程序员都应该知道的97件事》。它基于世界知名程序员的经验教训，提炼出一系列编程原则和技巧，如重构、测试编写、API设计等，并能应用于Claude Code、GitHub Copilot CLI以及OpenCode平台中。该项目使用JavaScript开发，通过插件形式集成到不同的编码环境中，帮助开发者在关键决策点做出更合理的判断。适合希望提高代码质量和开发效率的软件工程师或团队使用，在实际编码过程中作为辅助工具来遵循业界公认的最佳实践。",2,"2026-06-11 04:04:01","CREATED_QUERY"]