[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71VD2XC7MC0B1ZPC2S6MH8M":3,"skill-same:01M71VD2XC7MC0B1ZPC2S6MH8M":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71VD2XC7MC0B1ZPC2S6MH8M","encode-project-learning",null,"Convert durable lessons discovered while implementing, debugging, investigating, or reviewing a codebase into repository infrastructure that helps future contributors and agents. Use when work reveals a recurring failure mode, hidden domain rule, surprising architectural constraint, repeated manual step, missing validation, undocumented convention, reviewer correction, or other knowledge worth preserving as types, tests, lint rules, CI checks, tooling, agent instructions, review guidance, documentation, or comments. Also use at the end of substantive coding or review work when it surfaced concrete evidence of a reusable lesson.","schalkneethling\u002Fskills-autoresearch-flue","schalkneethling","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10350960?v=4","01M71VCYB4JFY33EJEN46152XV","Schalk Neethling","01M71VCYC439N917MH5QPFMNWY",16,"MIT","https:\u002F\u002Fgithub.com\u002Fschalkneethling\u002Fskills-autoresearch-flue\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fencode-project-learning\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"encode project learning","learning","project","repository","at","review work","work","documentation","review","reviewer","when","debugging","knowledge","implementing","ci","end","mode","types","lesson","agent instructions","2026-11-10 13:02:02",false,"---\nname: encode-project-learning\ndescription: Convert durable lessons discovered while implementing, debugging, investigating, or reviewing a codebase into repository infrastructure that helps future contributors and agents. Use when work reveals a recurring failure mode, hidden domain rule, surprising architectural constraint, repeated manual step, missing validation, undocumented convention, reviewer correction, or other knowledge worth preserving as types, tests, lint rules, CI checks, tooling, agent instructions, review guidance, documentation, or comments. Also use at the end of substantive coding or review work when it surfaced concrete evidence of a reusable lesson.\n---\n\n# Encode Project Learning\n\nTurn repository discoveries into the strongest practical safeguard. Solve the immediate task first, then prevent the same class of friction or failure from recurring.\n\n## Respect Scope\n\nMatch the action to the user's authorization:\n\n- For implementation or fix requests, make small related safeguards and documentation updates when they are clearly within scope.\n- For diagnostic, explanatory, or review-only requests, report the proposed learning update instead of changing files unless the user also authorized changes.\n- Request direction before establishing a broad architectural, product, security, or process policy that is not already supported by repository evidence.\n- Preserve unrelated user changes and follow repository-local instructions.\n\nDo not let this review displace the requested work. Treat no durable update as a valid result.\n\n## Run the Learning Loop\n\n### 1. Notice friction\n\nLook for discoveries such as:\n\n- A defect pattern that could recur elsewhere\n- An invariant, domain rule, or framework requirement that was not apparent\n- Reviewer feedback that could have been predicted before review\n- A manual check or setup step that contributors repeatedly perform\n- A repository convention that required archaeology or private context\n- Misleading, missing, duplicated, or stale guidance\n- A useful command or workflow that was difficult to discover\n\nDo not treat ordinary implementation effort, speculative preferences, or isolated accidents as durable learning.\n\n### 2. Gather evidence\n\nBefore encoding a rule:\n\n- Search for related code, tests, configuration, instructions, and documentation.\n- Determine whether a canonical rule already exists and is merely undiscoverable or unenforced.\n- Confirm that the lesson applies beyond the exact line or incident that exposed it.\n- Distinguish an intentional constraint from legacy code, coincidence, or a temporary workaround.\n- Use review comments, issue context, failures, or repeated examples as evidence when available.\n\nIf evidence is weak or contradictory, record the uncertainty in the task report rather than inventing policy.\n\n### 3. Classify the learning\n\nClassify it as one or more of:\n\n- **Invariant:** invalid states or inputs should be impossible or rejected.\n- **Regression risk:** known behavior needs protection.\n- **Pattern violation:** code can be recognized as acceptable or unacceptable.\n- **Workflow requirement:** a repeatable command or sequence is required.\n- **Repository convention:** contributors need guidance that is not fully machine-enforceable.\n- **Architectural or domain rationale:** future changes require the reason behind a constraint.\n- **One-off detail:** retain locally, or do not encode.\n\n### 4. Choose the strongest practical layer\n\nPrefer prevention and executable checks over prose. Use the highest suitable layer in this order, combining layers only when they serve different purposes:\n\n1. Types, schemas, API boundaries, or configuration constraints\n2. Lint rules, formatters, or static analysis\n3. Focused unit, integration, regression, contract, or end-to-end tests\n4. CI checks and validation scripts\n5. Reusable helpers, generators, development tooling, or automated workflows\n6. Repository agent instructions such as `AGENTS.md` or `CLAUDE.md`\n7. Review guidance such as `REVIEW.md`, checklists, or pull-request templates\n8. Architecture, contributor, operational, or domain documentation\n9. Local code comments for non-obvious rationale tied to nearby code\n\nDo not use a comment or document as the only safeguard when a reliable executable check is proportionate. Do not build expensive automation for a rare, low-impact condition when concise guidance is sufficient.\n\n### 5. Make the smallest durable change\n\n- Update the existing source of truth instead of creating a competing document.\n- State what to do, when it applies, and why it matters.\n- Keep guidance concrete enough for an unfamiliar contributor or agent to act on without private context.\n- Link guidance to the relevant check, command, decision record, or canonical document when helpful.\n- Encode the general rule while using the current incident only as evidence.\n- Keep tests focused on observable behavior rather than reproducing implementation details.\n- Avoid sweeping cleanup or unrelated policy changes.\n\nWhen no suitable destination exists, select one consistent with the repository's existing organization. Do not introduce new top-level instruction or review files casually.\n\n### 6. Verify the safeguard\n\nVerify in proportion to the change:\n\n- Demonstrate that a new automated check fails for the relevant bad case and passes for the corrected case when practical.\n- Run the affected tests, lint rules, type checks, validation scripts, or documentation checks.\n- Re-read modified guidance alongside nearby instructions to detect contradictions and duplication.\n- Check that the rule does not reject legitimate variants or overfit the triggering incident.\n- Confirm that paths, commands, and examples are accurate.\n\nIf verification cannot be completed, say exactly what remains unverified.\n\n### 7. Report the result\n\nAt handoff, briefly state:\n\n- The durable lesson, if any\n- Where it was encoded and why that layer was chosen\n- What future failure or friction it should prevent\n- How it was verified\n- Any candidate learning deliberately not encoded because it was one-off, uncertain, duplicative, disproportionate, or outside scope\n\nKeep this report subordinate to the primary task outcome. If nothing qualified, say so only when the skill was explicitly requested or the result is otherwise useful.\n\n## Apply Guardrails\n\n- Do not turn personal preference into repository policy.\n- Do not infer a universal rule from a single unexplained example.\n- Do not copy the same instruction into several files for visibility; improve discovery from one canonical source.\n- Do not preserve secrets, personal data, transient logs, or incident-specific sensitive details in durable guidance.\n- Do not weaken an existing check merely to accommodate the current implementation.\n- Do not add brittle checks whose maintenance cost exceeds the recurring problem.\n- Do not claim a class of issue is prevented when the safeguard covers only one example.\n- Do not update generated or vendored files when their source can be updated instead.\n\n## Use Common Mappings\n\n| Discovery                                            | Prefer                                                            |\n| ---------------------------------------------------- | ----------------------------------------------------------------- |\n| Input or state must be valid                         | Type, schema, boundary validation, and focused tests              |\n| A forbidden or required code pattern is recognizable | Lint rule or static analysis                                      |\n| Behavior could regress                               | Regression test at the lowest effective level                     |\n| Every change must perform a mechanical check         | CI validation                                                     |\n| Contributors repeat a fragile sequence               | Script, task, generator, or workflow automation                   |\n| Framework or architecture choice requires judgment   | Agent instructions plus review guidance                           |\n| Setup or operational step is hard to discover        | Automation plus canonical contributor or operations documentation |\n| Local code has a surprising reason                   | Test where possible, plus a concise rationale comment             |\n| Reviewer repeatedly supplies the same context        | Enforce it mechanically; otherwise update canonical instructions  |\n\n## Revisit Repeated Guidance\n\nWhen the same prose rule is violated repeatedly, treat that as evidence that documentation alone is insufficient. Look for a stronger constraint, check, template, or workflow. When an automated safeguard repeatedly produces false positives or requires exceptions, revisit whether the encoded rule is too broad.\n","# Encode Project Learning\n\nTurn repository discoveries into the strongest practical safeguard. Solve the immediate task first, then prevent the same class of friction or failure from recurring.\n\n## Respect Scope\n\nMatch the action to the user's authorization:\n\n- For implementation or fix requests, make small related safeguards and documentation updates when they are clearly within scope.\n- For diagnostic, explanatory, or review-only requests, report the proposed learning update instead of changing files unless the user also authorized changes.\n- Request direction before establishing a broad architectural, product, security, or process policy that is not already supported by repository evidence.\n- Preserve unrelated user changes and follow repository-local instructions.\n\nDo not let this review displace the requested work. Treat no durable update as a valid result.\n\n## Run the Learning Loop\n\n### 1. Notice friction\n\nLook for discoveries such as:\n\n- A defect pattern that could recur elsewhere\n- An invariant, domain rule, or framework requirement that was not apparent\n- Reviewer feedback that could have been predicted before review\n- A manual check or setup step that contributors repeatedly perform\n- A repository convention that required archaeology or private context\n- Misleading, missing, duplicated, or stale guidance\n- A useful command or workflow that was difficult to discover\n\nDo not treat ordinary implementation effort, speculative preferences, or isolated accidents as durable learning.\n\n### 2. Gather evidence\n\nBefore encoding a rule:\n\n- Search for related code, tests, configuration, instructions, and documentation.\n- Determine whether a canonical rule already exists and is merely undiscoverable or unenforced.\n- Confirm that the lesson applies beyond the exact line or incident that exposed it.\n- Distinguish an intentional constraint from legacy code, coincidence, or a temporary workaround.\n- Use review comments, issue context, failures, or repeated examples as evidence when available.\n\nIf evidence is weak or contradictory, record the uncertainty in the task report rather than inventing policy.\n\n### 3. Classify the learning\n\nClassify it as one or more of:\n\n- **Invariant:** invalid states or inputs should be impossible or rejected.\n- **Regression risk:** known behavior needs protection.\n- **Pattern violation:** code can be recognized as acceptable or unacceptable.\n- **Workflow requirement:** a repeatable command or sequence is required.\n- **Repository convention:** contributors need guidance that is not fully machine-enforceable.\n- **Architectural or domain rationale:** future changes require the reason behind a constraint.\n- **One-off detail:** retain locally, or do not encode.\n\n### 4. Choose the strongest practical layer\n\nPrefer prevention and executable checks over prose. Use the highest suitable layer in this order, combining layers only when they serve different purposes:\n\n1. Types, schemas, API boundaries, or configuration constraints\n2. Lint rules, formatters, or static analysis\n3. Focused unit, integration, regression, contract, or end-to-end tests\n4. CI checks and validation scripts\n5. Reusable helpers, generators, development tooling, or automated workflows\n6. Repository agent instructions such as `AGENTS.md` or `CLAUDE.md`\n7. Review guidance such as `REVIEW.md`, checklists, or pull-request templates\n8. Architecture, contributor, operational, or domain documentation\n9. Local code comments for non-obvious rationale tied to nearby code\n\nDo not use a comment or document as the only safeguard when a reliable executable check is proportionate. Do not build expensive automation for a rare, low-impact condition when concise guidance is sufficient.\n\n### 5. Make the smallest durable change\n\n- Update the existing source of truth instead of creating a competing document.\n- State what to do, when it applies, and why it matters.\n- Keep guidance concrete enough for an unfamiliar contributor or agent to act on without private context.\n- Link guidance to the relevant check, command, decision record, or canonical document when helpful.\n- Encode the general rule while using the current incident only as evidence.\n- Keep tests focused on observable behavior rather than reproducing implementation details.\n- Avoid sweeping cleanup or unrelated policy changes.\n\nWhen no suitable destination exists, select one consistent with the repository's existing organization. Do not introduce new top-level instruction or review files casually.\n\n### 6. Verify the safeguard\n\nVerify in proportion to the change:\n\n- Demonstrate that a new automated check fails for the relevant bad case and passes for the corrected case when practical.\n- Run the affected tests, lint rules, type checks, validation scripts, or documentation checks.\n- Re-read modified guidance alongside nearby instructions to detect contradictions and duplication.\n- Check that the rule does not reject legitimate variants or overfit the triggering incident.\n- Confirm that paths, commands, and examples are accurate.\n\nIf verification cannot be completed, say exactly what remains unverified.\n\n### 7. Report the result\n\nAt handoff, briefly state:\n\n- The durable lesson, if any\n- Where it was encoded and why that layer was chosen\n- What future failure or friction it should prevent\n- How it was verified\n- Any candidate learning deliberately not encoded because it was one-off, uncertain, duplicative, disproportionate, or outside scope\n\nKeep this report subordinate to the primary task outcome. If nothing qualified, say so only when the skill was explicitly requested or the result is otherwise useful.\n\n## Apply Guardrails\n\n- Do not turn personal preference into repository policy.\n- Do not infer a universal rule from a single unexplained example.\n- Do not copy the same instruction into several files for visibility; improve discovery from one canonical source.\n- Do not preserve secrets, personal data, transient logs, or incident-specific sensitive details in durable guidance.\n- Do not weaken an existing check merely to accommodate the current implementation.\n- Do not add brittle checks whose maintenance cost exceeds the recurring problem.\n- Do not claim a class of issue is prevented when the safeguard covers only one example.\n- Do not update generated or vendored files when their source can be updated instead.\n\n## Use Common Mappings\n\n| Discovery                                            | Prefer                                                            |\n| ---------------------------------------------------- | ----------------------------------------------------------------- |\n| Input or state must be valid                         | Type, schema, boundary validation, and focused tests              |\n| A forbidden or required code pattern is recognizable | Lint rule or static analysis                                      |\n| Behavior could regress                               | Regression test at the lowest effective level                     |\n| Every change must perform a mechanical check         | CI validation                                                     |\n| Contributors repeat a fragile sequence               | Script, task, generator, or workflow automation                   |\n| Framework or architecture choice requires judgment   | Agent instructions plus review guidance                           |\n| Setup or operational step is hard to discover        | Automation plus canonical contributor or operations documentation |\n| Local code has a surprising reason                   | Test where possible, plus a concise rationale comment             |\n| Reviewer repeatedly supplies the same context        | Enforce it mechanically; otherwise update canonical instructions  |\n\n## Revisit Repeated Guidance\n\nWhen the same prose rule is violated repeatedly, treat that as evidence that documentation alone is insufficient. Look for a stronger constraint, check, template, or workflow. When an automated safeguard repeatedly produces false positives or requires exceptions, revisit whether the encoded rule is too broad.\n",{"name":5,"description":7},"main","fbff9147095e6b0d4fcfae150cf4ec4b7ff56f5e",".agents\u002Fskills\u002Fencode-project-learning",2,"https:\u002F\u002Fgithub.com\u002Fschalkneethling\u002Fskills-autoresearch-flue","https:\u002F\u002Fgithub.com\u002Fschalkneethling","https:\u002F\u002Fschalkneethling.com","✌️ Agentic engineer, builder of things. Owner of Digital Robots ❤️ ","2026-09-19 20:01:59",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add schalkneethling\u002Fskills-autoresearch-flue --skill encode-project-learning",{"tool":59,"command":60},"bunx","bunx skills add schalkneethling\u002Fskills-autoresearch-flue --skill encode-project-learning",{"tool":62,"command":63},"pnpm","pnpm dlx skills add schalkneethling\u002Fskills-autoresearch-flue --skill encode-project-learning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fschalkneethling\u002Fskills-autoresearch-flue\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fencode-project-learning\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",249,"https:\u002F\u002Fgithub.com\u002Fschalkneethling\u002Fskills-autoresearch-flue\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fencode-project-learning\u002Fagents\u002Fopenai.yaml",[]]