{"owner":"joewalnes","repo":"websocketd","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# websocketd\n\nA small command-line tool (Go) that wraps an existing CLI program and exposes it via WebSocket. Any program that reads STDIN and writes STDOUT becomes a WebSocket server.\n\n## Build\n\n```bash\ngo build\n```\n\n## Test\n\n```bash\ngo test ./...\n```\n\nUnit tests are in `libwebsocketd/`. Integration tests are in `qa/integration/`. No linter is currently configured.\n\n## Mistake retrospectives\n\nWhen you make a mistake (especially forgetting something the user asked for):\n1. Acknowledge it directly\n2. Identify the root cause — why did this happen?\n3. Suggest a concrete project change to prevent recurrence (add a rule to CLAUDE.md, add a pre-commit check, etc.)\nDon't just apologize — fix the system.\n\n## Evolving preferences\n\nWhen the user expresses a coding preference, convention, or correction during a session, offer to encode it into this CLAUDE.md file so it persists across sessions.\n\n## Documentation\n\nUpdate `README.md` (and any relevant docs) before committing if the change affects:\n- Public API, CLI interface, or configuration\n- Setup/installation steps\n- Feature behavior visible to users\n\n## Changelog\n\nUpdate `CHANGES` before committing if the change affects:\n- Dependencies (especially security fixes)\n- User-visible behavior, CLI flags, or defaults\n- New features or test infrastructure\n- Bug fixes referenced by issue number\n\nLatest version goes at the top. Follow the existing format.\n\n## License headers\n\nEvery Go source file starts with the 4-line BSD copyright header. New files\nuse the current year (\"Copyright 2026 ...\"), not the year copied from an\nexisting file. Existing files keep their original year. When adding a\nmissing header to an old file, use the year the file first appeared\n(`git log --follow --format=%ad --date=short -- <file> | tail -1`) —\ndon't assume 2013.\n\n## Test-first\n\nBefore implementing a feature or fix:\n1. Write a test that captures the expected behavior\n2. Run it — verify it **fails** (if it passes, the test isn't testing the right thing)\n3. Implement until the test passes\n\n## Test precision\n\nWhen a test captures a process's output, capture stdout and stderr\nseparately and assert on the specific stream — never merge them. Which\nstream something is logged to is part of the behavior under test.\n\n## Pre-commit checks\n\nBefore every commit:\n1. Run tests: `go test ./...` — do not commit if tests fail\n2. If the change affects user-visible behavior, dependencies, or bug fixes: update `CHANGES` in the same commit (not a follow-up)\n\n## Commits\n\nBreak work into small atomic commits — one logical change per commit. Don't bundle unrelated changes. A bug fix, a new feature, and a refactor are three commits, not one.\n\n## Engineering diary\n\nMaintain `DIARY.md` — add an entry when making significant changes, architectural decisions, or non-obvious tradeoffs. Latest entries at top. Focus on *why* and *context*, not *what* (that's in the commits).\n\n## Bug tracking\n\nBugs and tasks are tracked in GitHub Issues. Use `gh issue list` to view and `gh issue create` to add new ones.\n\n## Structure\n\n- `main.go` — entry point, flag parsing\n- `config.go` — configuration types\n- `help.go` — help text\n- `version.go` — version info\n- `libwebsocketd/` — core library (WebSocket handling, HTTP, process management)\n- `examples/` — example scripts in various languages\n- `release/` — release/packaging scripts\n"},"files":{"CLAUDE.md":"# websocketd\n\nA small command-line tool (Go) that wraps an existing CLI program and exposes it via WebSocket. Any program that reads STDIN and writes STDOUT becomes a WebSocket server.\n\n## Build\n\n```bash\ngo build\n```\n\n## Test\n\n```bash\ngo test ./...\n```\n\nUnit tests are in `libwebsocketd/`. Integration tests are in `qa/integration/`. No linter is currently configured.\n\n## Mistake retrospectives\n\nWhen you make a mistake (especially forgetting something the user asked for):\n1. Acknowledge it directly\n2. Identify the root cause — why did this happen?\n3. Suggest a concrete project change to prevent recurrence (add a rule to CLAUDE.md, add a pre-commit check, etc.)\nDon't just apologize — fix the system.\n\n## Evolving preferences\n\nWhen the user expresses a coding preference, convention, or correction during a session, offer to encode it into this CLAUDE.md file so it persists across sessions.\n\n## Documentation\n\nUpdate `README.md` (and any relevant docs) before committing if the change affects:\n- Public API, CLI interface, or configuration\n- Setup/installation steps\n- Feature behavior visible to users\n\n## Changelog\n\nUpdate `CHANGES` before committing if the change affects:\n- Dependencies (especially security fixes)\n- User-visible behavior, CLI flags, or defaults\n- New features or test infrastructure\n- Bug fixes referenced by issue number\n\nLatest version goes at the top. Follow the existing format.\n\n## License headers\n\nEvery Go source file starts with the 4-line BSD copyright header. New files\nuse the current year (\"Copyright 2026 ...\"), not the year copied from an\nexisting file. Existing files keep their original year. When adding a\nmissing header to an old file, use the year the file first appeared\n(`git log --follow --format=%ad --date=short -- <file> | tail -1`) —\ndon't assume 2013.\n\n## Test-first\n\nBefore implementing a feature or fix:\n1. Write a test that captures the expected behavior\n2. Run it — verify it **fails** (if it passes, the test isn't testing the right thing)\n3. Implement until the test passes\n\n## Test precision\n\nWhen a test captures a process's output, capture stdout and stderr\nseparately and assert on the specific stream — never merge them. Which\nstream something is logged to is part of the behavior under test.\n\n## Pre-commit checks\n\nBefore every commit:\n1. Run tests: `go test ./...` — do not commit if tests fail\n2. If the change affects user-visible behavior, dependencies, or bug fixes: update `CHANGES` in the same commit (not a follow-up)\n\n## Commits\n\nBreak work into small atomic commits — one logical change per commit. Don't bundle unrelated changes. A bug fix, a new feature, and a refactor are three commits, not one.\n\n## Engineering diary\n\nMaintain `DIARY.md` — add an entry when making significant changes, architectural decisions, or non-obvious tradeoffs. Latest entries at top. Focus on *why* and *context*, not *what* (that's in the commits).\n\n## Bug tracking\n\nBugs and tasks are tracked in GitHub Issues. Use `gh issue list` to view and `gh issue create` to add new ones.\n\n## Structure\n\n- `main.go` — entry point, flag parsing\n- `config.go` — configuration types\n- `help.go` — help text\n- `version.go` — version info\n- `libwebsocketd/` — core library (WebSocket handling, HTTP, process management)\n- `examples/` — example scripts in various languages\n- `release/` — release/packaging scripts\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# websocketd\n\nA small command-line tool (Go) that wraps an existing CLI program and exposes it via WebSocket. Any program that reads STDIN and writes STDOUT becomes a WebSocket server.\n\n## Build\n\n```bash\ngo build\n```\n\n## Test\n\n```bash\ngo test ./...\n```\n\nUnit tests are in `libwebsocketd/`. Integration tests are in `qa/integration/`. No linter is currently configured.\n\n## Mistake retrospectives\n\nWhen you make a mistake (especially forgetting something the user asked for):\n1. Acknowledge it directly\n2. Identify the root cause — why did this happen?\n3. Suggest a concrete project change to prevent recurrence (add a rule to CLAUDE.md, add a pre-commit check, etc.)\nDon't just apologize — fix the system.\n\n## Evolving preferences\n\nWhen the user expresses a coding preference, convention, or correction during a session, offer to encode it into this CLAUDE.md file so it persists across sessions.\n\n## Documentation\n\nUpdate `README.md` (and any relevant docs) before committing if the change affects:\n- Public API, CLI interface, or configuration\n- Setup/installation steps\n- Feature behavior visible to users\n\n## Changelog\n\nUpdate `CHANGES` before committing if the change affects:\n- Dependencies (especially security fixes)\n- User-visible behavior, CLI flags, or defaults\n- New features or test infrastructure\n- Bug fixes referenced by issue number\n\nLatest version goes at the top. Follow the existing format.\n\n## License headers\n\nEvery Go source file starts with the 4-line BSD copyright header. New files\nuse the current year (\"Copyright 2026 ...\"), not the year copied from an\nexisting file. Existing files keep their original year. When adding a\nmissing header to an old file, use the year the file first appeared\n(`git log --follow --format=%ad --date=short -- <file> | tail -1`) —\ndon't assume 2013.\n\n## Test-first\n\nBefore implementing a feature or fix:\n1. Write a test that captures the expected behavior\n2. Run it — verify it **fails** (if it passes, the test isn't testing the right thing)\n3. Implement until the test passes\n\n## Test precision\n\nWhen a test captures a process's output, capture stdout and stderr\nseparately and assert on the specific stream — never merge them. Which\nstream something is logged to is part of the behavior under test.\n\n## Pre-commit checks\n\nBefore every commit:\n1. Run tests: `go test ./...` — do not commit if tests fail\n2. If the change affects user-visible behavior, dependencies, or bug fixes: update `CHANGES` in the same commit (not a follow-up)\n\n## Commits\n\nBreak work into small atomic commits — one logical change per commit. Don't bundle unrelated changes. A bug fix, a new feature, and a refactor are three commits, not one.\n\n## Engineering diary\n\nMaintain `DIARY.md` — add an entry when making significant changes, architectural decisions, or non-obvious tradeoffs. Latest entries at top. Focus on *why* and *context*, not *what* (that's in the commits).\n\n## Bug tracking\n\nBugs and tasks are tracked in GitHub Issues. Use `gh issue list` to view and `gh issue create` to add new ones.\n\n## Structure\n\n- `main.go` — entry point, flag parsing\n- `config.go` — configuration types\n- `help.go` — help text\n- `version.go` — version info\n- `libwebsocketd/` — core library (WebSocket handling, HTTP, process management)\n- `examples/` — example scripts in various languages\n- `release/` — release/packaging scripts\n","category":"root","tokens":840}]}