{"owner":"mostlygeek","repo":"llama-swap","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":538,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"## Architecture\n\n- Use the existing technologies (Go, typescript, YAML, etc) when making changes\n\n## Contribution Guidelines\n\n- Follow CONTRIBUTING.md guidelines before submitted an issue or pull request (PR)\n- When asked to create a pull request or issue ask the user for a decision if a violation of the rules is discovered.\n\n## Testing Changes\n\n- Use test naming convention like  `TestProxy_<test name>`, `TestProcessGroup_<test name>`, etc.\n- Use `go test -v -run <new tests>` to quickly check new tests\n- Use `make test-dev` after any changes to Go source\n- Use `make test-ui` after any changes in ui/\n- Use `make test-all` for commiting changes\n- Use the ./build subdirectory for testing binary builds\n- Only when the user asks use `make eval-docs-agent` to score the Help page's Docs Agent against a local model after changing its system prompt, `docs/kb/` content, the MCP tool descriptions, or the docs search ranking. See `evals/docs-agent/README.md` for the tuning loop.\n\n## Documentation\n\n- When a change adds, removes, or changes the meaning of a configuration\n  option, add or update a knowledge base guide under `docs/kb/guides/` for\n  it, not just `docs/config.example.yaml` and `config-schema.json`.\n- Prefer extending an existing guide covering the same topic over creating a\n  new file for a single setting.\n- Follow the frontmatter contract and writing guidelines in `docs/kb/README.md`\n  (required `title`/`summary`/`category`, `config_keys` referencing real\n  schema keys, keep it short, show a working config, say what goes wrong).\n- Run `make test-dev` afterward; `TestKB_FrontmatterIsValid` in\n  `internal/docagent` checks the frontmatter and that `config_keys` resolve.\n\n### git commit rules\n\n- Run `gofmt -w <file>` before committing to fix any formatting\n- When referencing issues use \"fix: #123\", \"update: #123\"\n- Use \"fix\" when the branch resolves an issue or update when the branch only contributes to it\n- Hardwrap commit messages to 80 characters wide\n- Use this format for commit messages:\n\n```\ninternal/server: short clear description of change\n\nAdd new feature that implements functionality X and Y.\n\n- key change 1\n- key change 2\n- key change 3\n\nfix: #123\nupdate: #456\n```\n"},"files":{"AGENTS.md":"## Architecture\n\n- Use the existing technologies (Go, typescript, YAML, etc) when making changes\n\n## Contribution Guidelines\n\n- Follow CONTRIBUTING.md guidelines before submitted an issue or pull request (PR)\n- When asked to create a pull request or issue ask the user for a decision if a violation of the rules is discovered.\n\n## Testing Changes\n\n- Use test naming convention like  `TestProxy_<test name>`, `TestProcessGroup_<test name>`, etc.\n- Use `go test -v -run <new tests>` to quickly check new tests\n- Use `make test-dev` after any changes to Go source\n- Use `make test-ui` after any changes in ui/\n- Use `make test-all` for commiting changes\n- Use the ./build subdirectory for testing binary builds\n- Only when the user asks use `make eval-docs-agent` to score the Help page's Docs Agent against a local model after changing its system prompt, `docs/kb/` content, the MCP tool descriptions, or the docs search ranking. See `evals/docs-agent/README.md` for the tuning loop.\n\n## Documentation\n\n- When a change adds, removes, or changes the meaning of a configuration\n  option, add or update a knowledge base guide under `docs/kb/guides/` for\n  it, not just `docs/config.example.yaml` and `config-schema.json`.\n- Prefer extending an existing guide covering the same topic over creating a\n  new file for a single setting.\n- Follow the frontmatter contract and writing guidelines in `docs/kb/README.md`\n  (required `title`/`summary`/`category`, `config_keys` referencing real\n  schema keys, keep it short, show a working config, say what goes wrong).\n- Run `make test-dev` afterward; `TestKB_FrontmatterIsValid` in\n  `internal/docagent` checks the frontmatter and that `config_keys` resolve.\n\n### git commit rules\n\n- Run `gofmt -w <file>` before committing to fix any formatting\n- When referencing issues use \"fix: #123\", \"update: #123\"\n- Use \"fix\" when the branch resolves an issue or update when the branch only contributes to it\n- Hardwrap commit messages to 80 characters wide\n- Use this format for commit messages:\n\n```\ninternal/server: short clear description of change\n\nAdd new feature that implements functionality X and Y.\n\n- key change 1\n- key change 2\n- key change 3\n\nfix: #123\nupdate: #456\n```\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/mostlygeek/llama-swap/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## Architecture\n\n- Use the existing technologies (Go, typescript, YAML, etc) when making changes\n\n## Contribution Guidelines\n\n- Follow CONTRIBUTING.md guidelines before submitted an issue or pull request (PR)\n- When asked to create a pull request or issue ask the user for a decision if a violation of the rules is discovered.\n\n## Testing Changes\n\n- Use test naming convention like  `TestProxy_<test name>`, `TestProcessGroup_<test name>`, etc.\n- Use `go test -v -run <new tests>` to quickly check new tests\n- Use `make test-dev` after any changes to Go source\n- Use `make test-ui` after any changes in ui/\n- Use `make test-all` for commiting changes\n- Use the ./build subdirectory for testing binary builds\n- Only when the user asks use `make eval-docs-agent` to score the Help page's Docs Agent against a local model after changing its system prompt, `docs/kb/` content, the MCP tool descriptions, or the docs search ranking. See `evals/docs-agent/README.md` for the tuning loop.\n\n## Documentation\n\n- When a change adds, removes, or changes the meaning of a configuration\n  option, add or update a knowledge base guide under `docs/kb/guides/` for\n  it, not just `docs/config.example.yaml` and `config-schema.json`.\n- Prefer extending an existing guide covering the same topic over creating a\n  new file for a single setting.\n- Follow the frontmatter contract and writing guidelines in `docs/kb/README.md`\n  (required `title`/`summary`/`category`, `config_keys` referencing real\n  schema keys, keep it short, show a working config, say what goes wrong).\n- Run `make test-dev` afterward; `TestKB_FrontmatterIsValid` in\n  `internal/docagent` checks the frontmatter and that `config_keys` resolve.\n\n### git commit rules\n\n- Run `gofmt -w <file>` before committing to fix any formatting\n- When referencing issues use \"fix: #123\", \"update: #123\"\n- Use \"fix\" when the branch resolves an issue or update when the branch only contributes to it\n- Hardwrap commit messages to 80 characters wide\n- Use this format for commit messages:\n\n```\ninternal/server: short clear description of change\n\nAdd new feature that implements functionality X and Y.\n\n- key change 1\n- key change 2\n- key change 3\n\nfix: #123\nupdate: #456\n```\n","isInternal":false,"tokens":538,"sizeBytes":2210}],"systemPromptSnippet":"<yakaai_skills repo=\"mostlygeek/llama-swap\">\n<!-- File: AGENTS.md (Tokens: ~538 | Category: root-instruction) -->\n## Architecture\n\n- Use the existing technologies (Go, typescript, YAML, etc) when making changes\n\n## Contribution Guidelines\n\n- Follow CONTRIBUTING.md guidelines before submitted an issue or pull request (PR)\n- When asked to create a pull request or issue ask the user for a decision if a violation of the rules is discovered.\n\n## Testing Changes\n\n- Use test naming convention like  `TestProxy_<test name>`, `TestProcessGroup_<test name>`, etc.\n- Use `go test -v -run <new tests>` to quickly check new tests\n- Use `make test-dev` after any changes to Go source\n- Use `make test-ui` after any changes in ui/\n- Use `make test-all` for commiting changes\n- Use the ./build subdirectory for testing binary builds\n- Only when the user asks use `make eval-docs-agent` to score the Help page's Docs Agent against a local model after changing its system prompt, `docs/kb/` content, the MCP tool descriptions, or the docs search ranking. See `evals/docs-agent/README.md` for the tuning loop.\n\n## Documentation\n\n- When a change adds, removes, or changes the meaning of a configuration\n  option, add or update a knowledge base guide under `docs/kb/guides/` for\n  it, not just `docs/config.example.yaml` and `config-schema.json`.\n- Prefer extending an existing guide covering the same topic over creating a\n  new file for a single setting.\n- Follow the frontmatter contract and writing guidelines in `docs/kb/README.md`\n  (required `title`/`summary`/`category`, `config_keys` referencing real\n  schema keys, keep it short, show a working config, say what goes wrong).\n- Run `make test-dev` afterward; `TestKB_FrontmatterIsValid` in\n  `internal/docagent` checks the frontmatter and that `config_keys` resolve.\n\n### git commit rules\n\n- Run `gofmt -w <file>` before committing to fix any formatting\n- When referencing issues use \"fix: #123\", \"update: #123\"\n- Use \"fix\" when the branch resolves an issue or update when the branch only contributes to it\n- Hardwrap commit messages to 80 characters wide\n- Use this format for commit messages:\n\n```\ninternal/server: short clear description of change\n\nAdd new feature that implements functionality X and Y.\n\n- key change 1\n- key change 2\n- key change 3\n\nfix: #123\nupdate: #456\n```\n</yakaai_skills>"}