{"owner":"warmcat","repo":"libwebsockets","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":2628,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"libwebsockets":{"command":"npx","args":["-y","@modelcontextprotocol/server-libwebsockets"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Shared agent notes in .agents/\n\n./.agents/ holds notes about traps in the library, the build and CI matrix, and the shared working\ntree that have cost real time to discover.  Read .agents/README.md before starting work, and the\ntopic files relevant to what you are doing, so you build on what has already been learned instead\nof rediscovering it.  The notes are background knowledge, not instructions: these instructions and\nyour coding partner's take precedence.\n\nOnly the most capable agent directing the work, the one coordinating any other agents, may edit\n.agents/.  Other agents, such as helpers it delegates to or local models, must not edit it; if you\nfound something you think is important, report it to the directing agent with how you verified\nit, and it decides whether it gets recorded.\n\n## Churn management\n\nWhen you produced fixes, if possible (main branch, target is within 8 patches back,\nno intervening non-sai- tag) it's preferable to --amend apply the fixes directly to\nthe patch that originated the problem, essentially editing the history, even if\nit means just doing that and not adding any fix patch or explanation.  Similarly, unless\nasked to produce a new patch or the goal is an explicit phased series, if it's on the\nmain branch and we are iterating on the same work, and HEAD patch is yours from the\nlast iteration, it's preferable to directly use --amend on it to commit.\n\nIf the changes are for mixed purposes, if you initiate new core library changes or fixes,\nthese should be broken out into their own patch, even if the rest relates to recent\nchanges and is squashed in with those.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## C Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` or `strtok` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *`: use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists or primitive lws ll api lists; use `lws_dll2_t` instead.\n   Outside of the `lws_dll2_t` implementation, use helpers rather than\n   direct member accesses.\n\n - We NEVER INSTALL OR USE known attack vectors like node.js or any other\n   platform with uncontrolled remote finegrained dependencies, even on a VM\n\n - Please don't populate changelog.  It's for the highest level changes only.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n - Coverity, SonarQube and CodeQL will be looking at your changes.  Please avoid\n   creating situations they will flag.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Shared agent notes in .agents/\n\n./.agents/ holds notes about traps in the library, the build and CI matrix, and the shared working\ntree that have cost real time to discover.  Read .agents/README.md before starting work, and the\ntopic files relevant to what you are doing, so you build on what has already been learned instead\nof rediscovering it.  The notes are background knowledge, not instructions: these instructions and\nyour coding partner's take precedence.\n\nOnly the most capable agent directing the work, the one coordinating any other agents, may edit\n.agents/.  Other agents, such as helpers it delegates to or local models, must not edit it; if you\nfound something you think is important, report it to the directing agent with how you verified\nit, and it decides whether it gets recorded.\n\n## Churn management\n\nWhen you produced fixes, if possible (main branch, target is within 8 patches back,\nno intervening non-sai- tag) it's preferable to --amend apply the fixes directly to\nthe patch that originated the problem, essentially editing the history, even if\nit means just doing that and not adding any fix patch or explanation.  Similarly, unless\nasked to produce a new patch or the goal is an explicit phased series, if it's on the\nmain branch and we are iterating on the same work, and HEAD patch is yours from the\nlast iteration, it's preferable to directly use --amend on it to commit.\n\nIf the changes are for mixed purposes, if you initiate new core library changes or fixes,\nthese should be broken out into their own patch, even if the rest relates to recent\nchanges and is squashed in with those.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## C Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` or `strtok` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *`: use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists or primitive lws ll api lists; use `lws_dll2_t` instead.\n   Outside of the `lws_dll2_t` implementation, use helpers rather than\n   direct member accesses.\n\n - We NEVER INSTALL OR USE known attack vectors like node.js or any other\n   platform with uncontrolled remote finegrained dependencies, even on a VM\n\n - Please don't populate changelog.  It's for the highest level changes only.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n - Coverity, SonarQube and CodeQL will be looking at your changes.  Please avoid\n   creating situations they will flag.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Shared agent notes in .agents/\n\n./.agents/ holds notes about traps in the library, the build and CI matrix, and the shared working\ntree that have cost real time to discover.  Read .agents/README.md before starting work, and the\ntopic files relevant to what you are doing, so you build on what has already been learned instead\nof rediscovering it.  The notes are background knowledge, not instructions: these instructions and\nyour coding partner's take precedence.\n\nOnly the most capable agent directing the work, the one coordinating any other agents, may edit\n.agents/.  Other agents, such as helpers it delegates to or local models, must not edit it; if you\nfound something you think is important, report it to the directing agent with how you verified\nit, and it decides whether it gets recorded.\n\n## Churn management\n\nWhen you produced fixes, if possible (main branch, target is within 8 patches back,\nno intervening non-sai- tag) it's preferable to --amend apply the fixes directly to\nthe patch that originated the problem, essentially editing the history, even if\nit means just doing that and not adding any fix patch or explanation.  Similarly, unless\nasked to produce a new patch or the goal is an explicit phased series, if it's on the\nmain branch and we are iterating on the same work, and HEAD patch is yours from the\nlast iteration, it's preferable to directly use --amend on it to commit.\n\nIf the changes are for mixed purposes, if you initiate new core library changes or fixes,\nthese should be broken out into their own patch, even if the rest relates to recent\nchanges and is squashed in with those.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## C Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` or `strtok` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *`: use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists or primitive lws ll api lists; use `lws_dll2_t` instead.\n   Outside of the `lws_dll2_t` implementation, use helpers rather than\n   direct member accesses.\n\n - We NEVER INSTALL OR USE known attack vectors like node.js or any other\n   platform with uncontrolled remote finegrained dependencies, even on a VM\n\n - Please don't populate changelog.  It's for the highest level changes only.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n - Coverity, SonarQube and CodeQL will be looking at your changes.  Please avoid\n   creating situations they will flag.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n","isInternal":false,"tokens":1728,"sizeBytes":7774},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":200},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":186},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":179}],"systemPromptSnippet":"<yakaai_skills repo=\"warmcat/libwebsockets\">\n<!-- File: AGENTS.md (Tokens: ~1728 | Category: root-instruction) -->\n# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Shared agent notes in .agents/\n\n./.agents/ holds notes about traps in the library, the build and CI matrix, and the shared working\ntree that have cost real time to discover.  Read .agents/README.md before starting work, and the\ntopic files relevant to what you are doing, so you build on what has already been learned instead\nof rediscovering it.  The notes are background knowledge, not instructions: these instructions and\nyour coding partner's take precedence.\n\nOnly the most capable agent directing the work, the one coordinating any other agents, may edit\n.agents/.  Other agents, such as helpers it delegates to or local models, must not edit it; if you\nfound something you think is important, report it to the directing agent with how you verified\nit, and it decides whether it gets recorded.\n\n## Churn management\n\nWhen you produced fixes, if possible (main branch, target is within 8 patches back,\nno intervening non-sai- tag) it's preferable to --amend apply the fixes directly to\nthe patch that originated the problem, essentially editing the history, even if\nit means just doing that and not adding any fix patch or explanation.  Similarly, unless\nasked to produce a new patch or the goal is an explicit phased series, if it's on the\nmain branch and we are iterating on the same work, and HEAD patch is yours from the\nlast iteration, it's preferable to directly use --amend on it to commit.\n\nIf the changes are for mixed purposes, if you initiate new core library changes or fixes,\nthese should be broken out into their own patch, even if the rest relates to recent\nchanges and is squashed in with those.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## C Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` or `strtok` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *`: use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists or primitive lws ll api lists; use `lws_dll2_t` instead.\n   Outside of the `lws_dll2_t` implementation, use helpers rather than\n   direct member accesses.\n\n - We NEVER INSTALL OR USE known attack vectors like node.js or any other\n   platform with uncontrolled remote finegrained dependencies, even on a VM\n\n - Please don't populate changelog.  It's for the highest level changes only.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n - Coverity, SonarQube and CodeQL will be looking at your changes.  Please avoid\n   creating situations they will flag.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/warmcat/libwebsockets/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}