[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K7M99FYMH9SFSEKB718J2B":3,"skill-same:01M6K7M99FYMH9SFSEKB718J2B":54},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":13,"repositoryHtmlUrl":26,"repositoryHomepageUrl":6,"ownerHtmlUrl":27,"ownerBlogUrl":6,"ownerDescription":28,"updatedAt":29,"install":30,"resources":43},"01M6K7M99FYMH9SFSEKB718J2B","scorecard",null,"joewalnes\u002Fskills","joewalnes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F48950?v=4","01M6K7J46C00DDV34GMGT2NK72","Joe Walnes","01M6K7J4ANFVAP1P9ZJ3K4F3P2",3,"MIT","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fscorecard\u002FSKILL.md",[],[5],"2026-11-10 10:12:30",false,"---\nname: scorecard\ndescription: Letter-grade audit of a codebase as it stands: code quality and agent-readiness. Use after a feature or before a big PR.\nargument-hint: [directory | --quick]\n---\n\n# Codebase Scorecard\n\nPerform a comprehensive, critical third-party audit of a codebase and produce a structured scorecard with letter grades. This is a deep analysis, not a surface-level check.\n\n## When to Use\n\n- After completing a feature or major refactoring\n- Code review preparation — run before submitting a PR\n- Technical debt assessment — quantify what needs attention\n- Onboarding to a new codebase — understand health at a glance\n- Before\u002Fafter comparisons — run before a cleanup, then after, to measure improvement\n\n## How to Invoke\n\n```\n\u002Fscorecard                    # Full codebase audit of current directory\n\u002Fscorecard src\u002F               # Audit specific directory\n\u002Fscorecard --quick            # Abbreviated audit (summary table only)\n\u002Fscorecard --agents           # Agent-readiness audit only (second table, skip the code grades)\n```\n\nA full run produces **two** grades: one for the code, one for agent-readiness. They answer different questions for different audiences, so they get separate tables and separate overall marks — `Code: B \u002F Agent-readiness: C+`.\n\n## Where the rest lives\n\nThis file is the process and the output format. Read `references\u002Fdimensions.md` — the 14 code rubrics, the 5 agent-readiness rubrics, and the grading scale — when you reach Phase 2 and are ready to grade, not before. `references\u002Fworked-example.md` is one finished report; read it once when learning the format, not every run.\n\n## Analysis Process\n\nYou MUST perform thorough investigation before grading. Do not grade from vibes — read actual code and docs. Launch multiple exploration agents in parallel to maximize coverage.\n\n### Phase 1: Reconnaissance (parallel)\n\nLaunch these investigations simultaneously using the Task tool with subagent_type=Explore:\n\n**Agent 1 — Structure & Architecture:**\n- Map the full directory structure, file counts, line counts\n- Identify the build system, entry points, dependency graph\n- Read README, design docs, architecture docs\n- Identify the core modules and their responsibilities\n- Assess module boundaries, coupling, cohesion\n- Look for god objects (classes with too many responsibilities)\n- Check for circular dependencies\n- Evaluate the build\u002Fbundle pipeline\n\n**Agent 2 — Code Quality & Bugs:**\n- Read the largest\u002Fmost critical source files thoroughly\n- Look for actual bugs: off-by-one errors, uninitialized variables, race conditions, edge cases\n- Check error handling: swallowed errors, inconsistent patterns, raw exceptions shown to users\n- Look for dead code, unused imports, unreachable branches\n- Check naming consistency, coding style consistency\n- Look for magic numbers, hardcoded values that should be configurable\n- Identify code duplication (copy-pasted blocks, near-identical functions)\n- Check for proper resource cleanup (file handles, connections, temp files)\n\n**Agent 3 — Security & Licensing:**\n- Search for ALL shell execution patterns (system, exec, backticks, eval, spawn, child_process, subprocess, os.system, etc.)\n- Search for ALL file operations and check for path traversal, symlink attacks, TOCTOU races\n- Check for injection vulnerabilities (SQL, command, XSS, template, regex)\n- Check for hardcoded secrets, credentials, API keys\n- Look for unsafe deserialization, prototype pollution, or equivalent language-specific risks\n- Check for predictable random values used for security purposes\n- Read LICENSE files, check for attribution requirements\n- Search for copied\u002Fvendored code without attribution\n- Check dependency licenses for compatibility\n\n**Agent 4 — Tests & Documentation:**\n- Read ALL test files — assess coverage breadth and depth\n- Identify tautological tests (tests that pass even when code is broken)\n- Look for tests that verify messages\u002Fstrings instead of actual behavior\n- Check for flaky tests (timing-dependent, order-dependent, environment-dependent)\n- Identify major untested code paths\n- Read ALL documentation files\n- Cross-reference docs against actual code — find stale claims, wrong references\n- Check for contradictions between different docs\n- Verify that documented features actually exist in code\n- Check if claimed metrics (coverage %, performance numbers) are substantiated\n- Read one user-facing page as a first-time reader: can you say what it's for and what to do next? Does it talk about how it was produced instead of the subject? (`\u002Fdocs` has the standard)\n\n**Agent 5 — Performance & Duplication:**\n- Identify hot paths (rendering loops, request handlers, per-frame\u002Fper-request code)\n- Look for O(n^2) or worse algorithms in hot paths\n- Check for unnecessary work (recomputation, redundant I\u002FO, missing caches)\n- Look for string concatenation in loops (language-dependent: bad in Java\u002FPerl\u002FPython, fine in others)\n- Check for N+1 query patterns, unbatched operations\n- Look for missing debouncing, throttling, or pagination\n- Catalog all duplicated code patterns with specific locations\n- Identify abstractions that should exist but don't\n\n**Agent 6 — Agent Readiness:**\n- Read the agent-facing instructions (`CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`) and check **every factual claim** against the code — stale rules are the finding, not the absence of rules\n- Find the work queue. Is it ranked? Are there duplicate or dangling entry numbers? Are the owner's own requests distinguishable from machine-generated ones?\n- Find the verification recipe. Run it. Does it work *right now*? How many environments does it cover?\n- Hunt vacuous gates: for every test threshold and CI check, ask what input would make it fail. Report each one that has no answer\n- Look for thresholds set just above a measured failure rate, tests whose names promise more than their assertions deliver, and tests loosened to accommodate a bug\n- Check isolation: worktrees, ports, shared machine-wide singletons (devices, session pools, databases, keychains), whether production is guard-blocked, and whether real credentials or personal data are reachable from an ordinary task\n- Check whether lessons are recorded anywhere, and whether the same mistake recurs in the history\n\n### Phase 1.5: External Security Cross-Check (best-effort)\n\nAlongside Agent 3, attempt an independent second opinion from a different model via the `delegate-security-audit` skill. This exists because a single model — including Claude auditing its own analysis — misses classes of vulnerabilities another model catches, and Claude's own guardrails limit how adversarially it will probe certain code. Treat this as strictly additive: if it's unavailable, the scorecard proceeds on Agent 3 alone.\n\n**Check availability first; skip silently if unavailable:**\n\n```bash\ncommand -v pi >\u002Fdev\u002Fnull && pi auth check --provider openrouter --no-refresh >\u002Fdev\u002Fnull 2>&1 && echo available\n```\n\nIf `pi` isn't installed, or the OpenRouter credential check fails, don't attempt the delegation — proceed with Agent 3's findings alone and note in the report: \"External security cross-check skipped (delegate-security-audit unavailable: `pi` not installed \u002F OpenRouter not authenticated).\" Never block or fail the scorecard over this being unavailable.\n\n**If available**, invoke the `delegate-security-audit` skill (via the Skill tool) for guidance, but override its default behavior for this context: **scorecard is a read-only grading tool**, so brief GLM explicitly not to modify any files, and run its `pi` command with `--exclude-tools edit,write` appended (the same read-only pattern `delegate-review` uses) regardless of what that skill's own example shows — a grading pass must never leave code changes behind as a side effect. Give it the same scope Agent 3 covers (shell execution patterns, path traversal\u002Fsymlink\u002FTOCTOU, injection, hardcoded secrets, unsafe deserialization, predictable randomness in security contexts) and ask for a report — findings with file:line and severity, not fixes. Run it in the background (`run_in_background`) while the other Phase 1 agents work, since it can take several minutes; this costs real money, which is expected for a periodic scorecard run per CLAUDE.md, but don't loop it.\n\nFold its findings into Agent 3's before grading, tagging each with its source. Where the two disagree on severity, or one surfaces something the other missed, note the discrepancy in the report rather than silently picking one — the disagreement itself is signal.\n\n### Phase 2: Grading\n\nAfter all agents complete, synthesize findings into grades against the rubrics in `references\u002Fdimensions.md`. Be honest and critical. A \"B\" should mean genuinely good code, not \"I didn't look hard enough to find problems.\"\n\n## Output Format for Agent-Readiness\n\n```\n| #  | Dimension            | Grade | Key Finding |\n|----|----------------------|-------|-------------|\n| A1 | Tracking & Priorities| C     | 134 entries, 3 references point at a renumbered item |\n| A2 | Verifiability        | B+    | Real device harness; only ever driven from one origin |\n| A3 | Guard Integrity      | C-    | A documented gate does not exist in code; one suite cannot fail |\n| A4 | Isolation & Safety   | B     | Worktrees used; shared device collisions misread as page bugs |\n| A5 | Knowledge Capture    | B-    | Excellent lessons in code comments, not propagated to docs |\n\n**Agent-Readiness: C+**\n```\n\nThen, in the detailed report, add one section: **\"What would break first in an unattended run\"** — the single change that would most increase how long agents can work here without a human. Be concrete and name the file.\n\n## Output Format\n\n### Summary Scorecard\n\n```\n# Codebase Scorecard: [Project Name]\n\n**Audited**: [date] | **Size**: [X files, Y KLOC] | **Language(s)**: [primary languages]\n\n| # | Category          | Grade | Key Finding |\n|---|-------------------|-------|-------------|\n| 1 | Architecture      | B+    | Clean renderer; Editor is a god object |\n| 2 | Code Quality      | B-    | Good conventions documented, inconsistently followed |\n| 3 | Consistency       | B     | Mostly uniform, some mixed patterns |\n| 4 | Security          | C-    | Multiple shell injection vectors |\n| 5 | Performance       | C     | Uncached hot-path computation |\n| 6 | DRY               | C+    | 5+ duplicated patterns identified |\n| 7 | Testability       | B+    | Pure renderer, DI in most modules |\n| 8 | Test Coverage     | B-    | Good breadth, tautological in places |\n| 9 | Type Safety       | N\u002FA   | Perl — no type system |\n| 10| Documentation     | C     | Multiple stale references |\n| 11| Error Handling    | C+    | Inconsistent user-facing messages |\n| 12| Extensibility     | B     | Good plugin points, tight core coupling |\n| 13| Repo Hygiene      | B-    | Junk files, missing .gitignore entries |\n| 14| Accretion         | C     | Add:delete 7:1 in production code; zero refactor moves in 110 commits |\n\n**Overall: C+**\n```\n\n### Detailed Report\n\nAfter the summary table, provide these sections:\n\n#### Top Strengths (3-5 bullets)\nWhat the project does well. Be specific — cite files and patterns.\n\n#### Critical Issues (prioritized list)\nIssues that should block a release or be fixed immediately. Include:\n- Severity (CRITICAL \u002F HIGH \u002F MEDIUM \u002F LOW)\n- Category tag (e.g., [Security], [Bug], [Performance])\n- Specific file:line references\n- Brief description of the issue and its impact\n- Suggested fix\n\n#### Architecture Assessment (2-3 paragraphs)\nHonest assessment of the overall design. What's the biggest structural problem? What design decision will cause the most pain as the project grows?\n\n#### Documentation vs Reality\nList every place where documentation contradicts the actual code. Be specific with quotes from docs and what the code actually does.\n\n#### Quick Wins (3-5 items)\nEasy fixes that would meaningfully improve quality. Each should be achievable in a single commit.\n\n#### Technical Debt (if applicable)\nLarger structural issues that need sustained effort. For each item, describe the current state, the target state, and a rough sense of scope (single file vs cross-cutting).\n\n## Guidelines for the Auditor\n\n- **Be genuinely critical.** A useful audit finds real problems. Praising everything helps nobody.\n- **Read actual code.** Don't grade based on file names or README claims. Verify.\n- **Cite specific evidence.** Every grade must reference concrete findings with file:line.\n- **Don't penalize for language limitations.** Perl doesn't have type safety — don't dock points for that. Grade within the language's idioms.\n- **Don't penalize for scope.** A small project doesn't need a plugin architecture. Grade proportionally.\n- **Do penalize for claims vs reality.** If docs claim \"95% test coverage\" but there are no metrics, that's a documentation problem.\n- **Security issues are never \"low priority.\"** If you find an exploitable vulnerability, the Security grade cannot be above C regardless of how good everything else is.\n- **Consider the codebase's stage.** An MVP doesn't need the same polish as a mature production system. Grade proportionally to ambition and maturity — but still flag real risks regardless of stage.\n- **Check the junk drawer.** Look at git status, untracked files, temp files, debug artifacts. These reveal working habits.\n","# Codebase Scorecard\n\nPerform a comprehensive, critical third-party audit of a codebase and produce a structured scorecard with letter grades. This is a deep analysis, not a surface-level check.\n\n## When to Use\n\n- After completing a feature or major refactoring\n- Code review preparation — run before submitting a PR\n- Technical debt assessment — quantify what needs attention\n- Onboarding to a new codebase — understand health at a glance\n- Before\u002Fafter comparisons — run before a cleanup, then after, to measure improvement\n\n## How to Invoke\n\n```\n\u002Fscorecard                    # Full codebase audit of current directory\n\u002Fscorecard src\u002F               # Audit specific directory\n\u002Fscorecard --quick            # Abbreviated audit (summary table only)\n\u002Fscorecard --agents           # Agent-readiness audit only (second table, skip the code grades)\n```\n\nA full run produces **two** grades: one for the code, one for agent-readiness. They answer different questions for different audiences, so they get separate tables and separate overall marks — `Code: B \u002F Agent-readiness: C+`.\n\n## Where the rest lives\n\nThis file is the process and the output format. Read `references\u002Fdimensions.md` — the 14 code rubrics, the 5 agent-readiness rubrics, and the grading scale — when you reach Phase 2 and are ready to grade, not before. `references\u002Fworked-example.md` is one finished report; read it once when learning the format, not every run.\n\n## Analysis Process\n\nYou MUST perform thorough investigation before grading. Do not grade from vibes — read actual code and docs. Launch multiple exploration agents in parallel to maximize coverage.\n\n### Phase 1: Reconnaissance (parallel)\n\nLaunch these investigations simultaneously using the Task tool with subagent_type=Explore:\n\n**Agent 1 — Structure & Architecture:**\n- Map the full directory structure, file counts, line counts\n- Identify the build system, entry points, dependency graph\n- Read README, design docs, architecture docs\n- Identify the core modules and their responsibilities\n- Assess module boundaries, coupling, cohesion\n- Look for god objects (classes with too many responsibilities)\n- Check for circular dependencies\n- Evaluate the build\u002Fbundle pipeline\n\n**Agent 2 — Code Quality & Bugs:**\n- Read the largest\u002Fmost critical source files thoroughly\n- Look for actual bugs: off-by-one errors, uninitialized variables, race conditions, edge cases\n- Check error handling: swallowed errors, inconsistent patterns, raw exceptions shown to users\n- Look for dead code, unused imports, unreachable branches\n- Check naming consistency, coding style consistency\n- Look for magic numbers, hardcoded values that should be configurable\n- Identify code duplication (copy-pasted blocks, near-identical functions)\n- Check for proper resource cleanup (file handles, connections, temp files)\n\n**Agent 3 — Security & Licensing:**\n- Search for ALL shell execution patterns (system, exec, backticks, eval, spawn, child_process, subprocess, os.system, etc.)\n- Search for ALL file operations and check for path traversal, symlink attacks, TOCTOU races\n- Check for injection vulnerabilities (SQL, command, XSS, template, regex)\n- Check for hardcoded secrets, credentials, API keys\n- Look for unsafe deserialization, prototype pollution, or equivalent language-specific risks\n- Check for predictable random values used for security purposes\n- Read LICENSE files, check for attribution requirements\n- Search for copied\u002Fvendored code without attribution\n- Check dependency licenses for compatibility\n\n**Agent 4 — Tests & Documentation:**\n- Read ALL test files — assess coverage breadth and depth\n- Identify tautological tests (tests that pass even when code is broken)\n- Look for tests that verify messages\u002Fstrings instead of actual behavior\n- Check for flaky tests (timing-dependent, order-dependent, environment-dependent)\n- Identify major untested code paths\n- Read ALL documentation files\n- Cross-reference docs against actual code — find stale claims, wrong references\n- Check for contradictions between different docs\n- Verify that documented features actually exist in code\n- Check if claimed metrics (coverage %, performance numbers) are substantiated\n- Read one user-facing page as a first-time reader: can you say what it's for and what to do next? Does it talk about how it was produced instead of the subject? (`\u002Fdocs` has the standard)\n\n**Agent 5 — Performance & Duplication:**\n- Identify hot paths (rendering loops, request handlers, per-frame\u002Fper-request code)\n- Look for O(n^2) or worse algorithms in hot paths\n- Check for unnecessary work (recomputation, redundant I\u002FO, missing caches)\n- Look for string concatenation in loops (language-dependent: bad in Java\u002FPerl\u002FPython, fine in others)\n- Check for N+1 query patterns, unbatched operations\n- Look for missing debouncing, throttling, or pagination\n- Catalog all duplicated code patterns with specific locations\n- Identify abstractions that should exist but don't\n\n**Agent 6 — Agent Readiness:**\n- Read the agent-facing instructions (`CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`) and check **every factual claim** against the code — stale rules are the finding, not the absence of rules\n- Find the work queue. Is it ranked? Are there duplicate or dangling entry numbers? Are the owner's own requests distinguishable from machine-generated ones?\n- Find the verification recipe. Run it. Does it work *right now*? How many environments does it cover?\n- Hunt vacuous gates: for every test threshold and CI check, ask what input would make it fail. Report each one that has no answer\n- Look for thresholds set just above a measured failure rate, tests whose names promise more than their assertions deliver, and tests loosened to accommodate a bug\n- Check isolation: worktrees, ports, shared machine-wide singletons (devices, session pools, databases, keychains), whether production is guard-blocked, and whether real credentials or personal data are reachable from an ordinary task\n- Check whether lessons are recorded anywhere, and whether the same mistake recurs in the history\n\n### Phase 1.5: External Security Cross-Check (best-effort)\n\nAlongside Agent 3, attempt an independent second opinion from a different model via the `delegate-security-audit` skill. This exists because a single model — including Claude auditing its own analysis — misses classes of vulnerabilities another model catches, and Claude's own guardrails limit how adversarially it will probe certain code. Treat this as strictly additive: if it's unavailable, the scorecard proceeds on Agent 3 alone.\n\n**Check availability first; skip silently if unavailable:**\n\n```bash\ncommand -v pi >\u002Fdev\u002Fnull && pi auth check --provider openrouter --no-refresh >\u002Fdev\u002Fnull 2>&1 && echo available\n```\n\nIf `pi` isn't installed, or the OpenRouter credential check fails, don't attempt the delegation — proceed with Agent 3's findings alone and note in the report: \"External security cross-check skipped (delegate-security-audit unavailable: `pi` not installed \u002F OpenRouter not authenticated).\" Never block or fail the scorecard over this being unavailable.\n\n**If available**, invoke the `delegate-security-audit` skill (via the Skill tool) for guidance, but override its default behavior for this context: **scorecard is a read-only grading tool**, so brief GLM explicitly not to modify any files, and run its `pi` command with `--exclude-tools edit,write` appended (the same read-only pattern `delegate-review` uses) regardless of what that skill's own example shows — a grading pass must never leave code changes behind as a side effect. Give it the same scope Agent 3 covers (shell execution patterns, path traversal\u002Fsymlink\u002FTOCTOU, injection, hardcoded secrets, unsafe deserialization, predictable randomness in security contexts) and ask for a report — findings with file:line and severity, not fixes. Run it in the background (`run_in_background`) while the other Phase 1 agents work, since it can take several minutes; this costs real money, which is expected for a periodic scorecard run per CLAUDE.md, but don't loop it.\n\nFold its findings into Agent 3's before grading, tagging each with its source. Where the two disagree on severity, or one surfaces something the other missed, note the discrepancy in the report rather than silently picking one — the disagreement itself is signal.\n\n### Phase 2: Grading\n\nAfter all agents complete, synthesize findings into grades against the rubrics in `references\u002Fdimensions.md`. Be honest and critical. A \"B\" should mean genuinely good code, not \"I didn't look hard enough to find problems.\"\n\n## Output Format for Agent-Readiness\n\n```\n| #  | Dimension            | Grade | Key Finding |\n|----|----------------------|-------|-------------|\n| A1 | Tracking & Priorities| C     | 134 entries, 3 references point at a renumbered item |\n| A2 | Verifiability        | B+    | Real device harness; only ever driven from one origin |\n| A3 | Guard Integrity      | C-    | A documented gate does not exist in code; one suite cannot fail |\n| A4 | Isolation & Safety   | B     | Worktrees used; shared device collisions misread as page bugs |\n| A5 | Knowledge Capture    | B-    | Excellent lessons in code comments, not propagated to docs |\n\n**Agent-Readiness: C+**\n```\n\nThen, in the detailed report, add one section: **\"What would break first in an unattended run\"** — the single change that would most increase how long agents can work here without a human. Be concrete and name the file.\n\n## Output Format\n\n### Summary Scorecard\n\n```\n# Codebase Scorecard: [Project Name]\n\n**Audited**: [date] | **Size**: [X files, Y KLOC] | **Language(s)**: [primary languages]\n\n| # | Category          | Grade | Key Finding |\n|---|-------------------|-------|-------------|\n| 1 | Architecture      | B+    | Clean renderer; Editor is a god object |\n| 2 | Code Quality      | B-    | Good conventions documented, inconsistently followed |\n| 3 | Consistency       | B     | Mostly uniform, some mixed patterns |\n| 4 | Security          | C-    | Multiple shell injection vectors |\n| 5 | Performance       | C     | Uncached hot-path computation |\n| 6 | DRY               | C+    | 5+ duplicated patterns identified |\n| 7 | Testability       | B+    | Pure renderer, DI in most modules |\n| 8 | Test Coverage     | B-    | Good breadth, tautological in places |\n| 9 | Type Safety       | N\u002FA   | Perl — no type system |\n| 10| Documentation     | C     | Multiple stale references |\n| 11| Error Handling    | C+    | Inconsistent user-facing messages |\n| 12| Extensibility     | B     | Good plugin points, tight core coupling |\n| 13| Repo Hygiene      | B-    | Junk files, missing .gitignore entries |\n| 14| Accretion         | C     | Add:delete 7:1 in production code; zero refactor moves in 110 commits |\n\n**Overall: C+**\n```\n\n### Detailed Report\n\nAfter the summary table, provide these sections:\n\n#### Top Strengths (3-5 bullets)\nWhat the project does well. Be specific — cite files and patterns.\n\n#### Critical Issues (prioritized list)\nIssues that should block a release or be fixed immediately. Include:\n- Severity (CRITICAL \u002F HIGH \u002F MEDIUM \u002F LOW)\n- Category tag (e.g., [Security], [Bug], [Performance])\n- Specific file:line references\n- Brief description of the issue and its impact\n- Suggested fix\n\n#### Architecture Assessment (2-3 paragraphs)\nHonest assessment of the overall design. What's the biggest structural problem? What design decision will cause the most pain as the project grows?\n\n#### Documentation vs Reality\nList every place where documentation contradicts the actual code. Be specific with quotes from docs and what the code actually does.\n\n#### Quick Wins (3-5 items)\nEasy fixes that would meaningfully improve quality. Each should be achievable in a single commit.\n\n#### Technical Debt (if applicable)\nLarger structural issues that need sustained effort. For each item, describe the current state, the target state, and a rough sense of scope (single file vs cross-cutting).\n\n## Guidelines for the Auditor\n\n- **Be genuinely critical.** A useful audit finds real problems. Praising everything helps nobody.\n- **Read actual code.** Don't grade based on file names or README claims. Verify.\n- **Cite specific evidence.** Every grade must reference concrete findings with file:line.\n- **Don't penalize for language limitations.** Perl doesn't have type safety — don't dock points for that. Grade within the language's idioms.\n- **Don't penalize for scope.** A small project doesn't need a plugin architecture. Grade proportionally.\n- **Do penalize for claims vs reality.** If docs claim \"95% test coverage\" but there are no metrics, that's a documentation problem.\n- **Security issues are never \"low priority.\"** If you find an exploitable vulnerability, the Security grade cannot be above C regardless of how good everything else is.\n- **Consider the codebase's stage.** An MVP doesn't need the same polish as a mature production system. Grade proportionally to ambition and maturity — but still flag real risks regardless of stage.\n- **Check the junk drawer.** Look at git status, untracked files, temp files, debug artifacts. These reveal working habits.\n",{},"main","0d32bda2cb8e014372c2814f5aa47f48eee0f411","skills\u002Fscorecard","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills","https:\u002F\u002Fgithub.com\u002Fjoewalnes","Experimental Projects @ Stripe.\r\n\r\nPreviously: Apple, Google, ThoughtWorks, DRW, Startups.","2026-09-09 00:56:55",{"source":7,"skillName":5,"commands":31,"prompt":41,"zipAvailable":42},[32,35,38],{"tool":33,"command":34},"npx","npx skills add joewalnes\u002Fskills --skill scorecard",{"tool":36,"command":37},"bunx","bunx skills add joewalnes\u002Fskills --skill scorecard",{"tool":39,"command":40},"pnpm","pnpm dlx skills add joewalnes\u002Fskills --skill scorecard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fscorecard\u002FSKILL.md",true,[44,50],{"path":45,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":48,"sourceHtmlUrl":49},"references\u002Fdimensions.md","REFERENCE","参考文档",14515,"https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fscorecard\u002Freferences\u002Fdimensions.md",{"path":51,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fworked-example.md",2977,"https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fscorecard\u002Freferences\u002Fworked-example.md",[55,71,83,102,118,124],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":18},"01M6K7MSG99DXYKTVVFGZWND1S","tool-web","Build a lightweight single-file web application with no external dependencies","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftool-web\u002FSKILL.md",[],[62,63,64,65,66,67,68,69,70],"tool web","web","tool","with","application","dependencies","build","single-file","file",{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":18},"01M6K7MPN2FG6M6JQFWFR18CJ0","todo","Add a new bug or todo to the project's tracker","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftodo\u002FSKILL.md",[],[73,78,79,80,81,82],"bug","tracker","task","project","add",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":18},"01M6K7MGQFFYCD8HFDP1B95KDN","slop","Find unchosen code — surface area growing without leverage. Use pre-merge on a branch, or to check if a repo is accreting.","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fslop\u002FSKILL.md",[],[85,90,91,92,93,94,95,96,97,98,99,100,101],"find","branch","merge","repo","check","use","leverage","quick","rev","pre-merge","explain","code",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":18},"01M6K7MCVREA4NZ46Q9JWZJ7TG","sitrep","Where were we? Branch, in-progress work, blocked agents, inbox, next steps. Use when resuming a session.","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsitrep\u002FSKILL.md",[],[104,109,110,111,112,91,113,114,95,115,116,117],"inbox","Bash","grep","work","read","session","next","progress","next steps",{"skillNo":119,"name":120,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":18},"01M6K7M4HNZR34GSB3V14KVCWA","retro","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fretro\u002FSKILL.md",[],[120],{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":18},"01M6K7M0QT6PD1SPE282ZQ0SM4","request","Ask another project's agents for a change instead of editing their repo. Use when a fix belongs in another repository.","https:\u002F\u002Fgithub.com\u002Fjoewalnes\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Frequest\u002FSKILL.md",[],[126,109,131,132,93,133,134,95,135,136,81,137,138,139],"repository","editing","ask","fix","show","done","id","for","change"]