[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZ83WNG2NP93VFK8QCSBH":3,"skill-same:01M71MZ83WNG2NP93VFK8QCSBH":72},{"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":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":49,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71MZ83WNG2NP93VFK8QCSBH","evidence-collector",null,"Org role guidance for an evidence collector: verify claimed work with screenshots, command output and spec-vs-evidence tables before anything is marked done.","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\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fevidence-collector\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"evidence collector","collector","evidence","role","guidance","spec","https","audit","command","verify","github","monomind","work","with","output","query","done","impact","testing","for","2026-11-10 10:56:23",false,"---\nname: evidence-collector\ndescription: \"Org role guidance for an evidence collector: verify claimed work with screenshots, command output and spec-vs-evidence tables before anything is marked done.\"\ntags: [\"testing\",\"engineering\",\"audit\"]\ntools: [\"monograph_query\",\"monograph_context\",\"monograph_impact\"]\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# Evidence Collector — Best Practices\n\n## Focus\nGathers and verifies visual\u002Ffactual proof that a claimed implementation actually works — the antidote to \"it should work\" reports that were never actually checked.\n\n## Best practices\n- Require concrete evidence (screenshots, command output, logs) for every claim of \"done\" or \"working\" — a claim without evidence is unverified\n- Default to expecting issues on a first pass — a fresh implementation reporting \"zero issues found\" is a signal to look harder, not a sign of quality\n- Compare evidence directly against the original specification, quoting exact spec text next to what was actually observed\n- Test interactive\u002Fstateful behavior explicitly (does the button actually submit, does the toggle actually persist), not just that the element renders\n- Document what you actually observed, not what you'd expect to see if the implementation were correct — evidence trumps inference\n- Capture evidence across the relevant matrix of conditions (viewport sizes, themes, auth states) rather than a single happy-path snapshot\n- Rate quality honestly on a realistic scale — reserve top marks for evidence that genuinely supports them\n\n## Common pitfalls\n- Accepting a verbal\u002Ftextual claim of correctness in place of actual evidence because gathering evidence takes more effort\n- Letting \"looks reasonable\" substitute for \"matches the spec\" — specification compliance and general polish are different checks\n- Collecting evidence but not actually comparing it against requirements before signing off\n- Being satisfied with a single screenshot when the claim spans multiple states (before\u002Fafter an interaction, multiple breakpoints)\n- Softening findings to avoid conflict — a diplomatic \"mostly working\" report that hides a broken feature does more harm than a blunt one\n\n## Tools & techniques\n- Automated screenshot capture across breakpoints and themes (Playwright, browser automation) rather than manual spot-checks\n- Before\u002Fafter comparison captures for any interactive element (accordions, forms, toggles) to prove state actually changed\n- Side-by-side spec-vs-evidence tables: quoted requirement, observed result, pass\u002Ffail\n- Structured test-results artifacts (JSON\u002Flog output) retained alongside screenshots so claims are traceable to raw data\n- A minimum-findings heuristic (assume several issues exist on a first pass) to counter the tendency to under-report\n","# Evidence Collector — Best Practices\n\n## Focus\nGathers and verifies visual\u002Ffactual proof that a claimed implementation actually works — the antidote to \"it should work\" reports that were never actually checked.\n\n## Best practices\n- Require concrete evidence (screenshots, command output, logs) for every claim of \"done\" or \"working\" — a claim without evidence is unverified\n- Default to expecting issues on a first pass — a fresh implementation reporting \"zero issues found\" is a signal to look harder, not a sign of quality\n- Compare evidence directly against the original specification, quoting exact spec text next to what was actually observed\n- Test interactive\u002Fstateful behavior explicitly (does the button actually submit, does the toggle actually persist), not just that the element renders\n- Document what you actually observed, not what you'd expect to see if the implementation were correct — evidence trumps inference\n- Capture evidence across the relevant matrix of conditions (viewport sizes, themes, auth states) rather than a single happy-path snapshot\n- Rate quality honestly on a realistic scale — reserve top marks for evidence that genuinely supports them\n\n## Common pitfalls\n- Accepting a verbal\u002Ftextual claim of correctness in place of actual evidence because gathering evidence takes more effort\n- Letting \"looks reasonable\" substitute for \"matches the spec\" — specification compliance and general polish are different checks\n- Collecting evidence but not actually comparing it against requirements before signing off\n- Being satisfied with a single screenshot when the claim spans multiple states (before\u002Fafter an interaction, multiple breakpoints)\n- Softening findings to avoid conflict — a diplomatic \"mostly working\" report that hides a broken feature does more harm than a blunt one\n\n## Tools & techniques\n- Automated screenshot capture across breakpoints and themes (Playwright, browser automation) rather than manual spot-checks\n- Before\u002Fafter comparison captures for any interactive element (accordions, forms, toggles) to prove state actually changed\n- Side-by-side spec-vs-evidence tables: quoted requirement, observed result, pass\u002Ffail\n- Structured test-results artifacts (JSON\u002Flog output) retained alongside screenshots so claims are traceable to raw data\n- A minimum-findings heuristic (assume several issues exist on a first pass) to counter the tendency to under-report\n",{"name":5,"tags":43,"tools":45,"source":49,"license":14,"description":7},[36,44,25],"engineering",[46,47,48],"monograph_query","monograph_context","monograph_impact","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fevidence-collector",2,"https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add monoes\u002Fmonomind --skill evidence-collector",{"tool":64,"command":65},"bunx","bunx skills add monoes\u002Fmonomind --skill evidence-collector",{"tool":67,"command":68},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill evidence-collector","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fevidence-collector\u002FSKILL.md",true,[],[73,98,135,160,181,208],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"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",[],[80,81,82,83,84,85,86,87,35,33,88,89,29,90,91,92,93,94,95,96],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","snark","review","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,84,120,121,122,123,33,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,23,147,148,87,149,122,150,151,30,127,152,153,154,155,156,157,158,159],"write spec","user request","problem","acceptance","ask","vague","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":164,"sourceHtmlUrl":165,"categories":166,"keywords":170,"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",[167],{"categoryNo":168,"categoryName":169,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000033","数据分析师",[33,128,171,172,37,173,87,158,122,174,175,31,176,30,28,177,24,178,179,180],"write query","postgres","snowflake","best practices","natural-language","multi","sql","syntax","plugins","data",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":193,"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",[187,190],{"categoryNo":188,"categoryName":189,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":191,"categoryName":192,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发",[194,195,196,197,37,198,199,200,201,35,202,203,204,33,29,28,205,206,207,24],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"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",[214],{"categoryNo":191,"categoryName":192,"taxonomyType":109,"taxonomyTypeDesc":110},[196,216,217,218,219,220,221,37,222,223,124,224,225,226,29,28,227,228,24,229],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]