agent-conduct
Shared hard rules enforced across all squad agents
Best use case
agent-conduct is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Shared hard rules enforced across all squad agents
Teams using agent-conduct should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/agent-conduct/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How agent-conduct Compares
| Feature / Agent | agent-conduct | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Shared hard rules enforced across all squad agents
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
## Context Every squad agent must follow these two hard rules. They were previously duplicated in every charter. Now they live here as a shared skill, loaded once. ## Patterns ### Product Isolation Rule (hard rule) Tests, CI workflows, and product code must NEVER depend on specific agent names from any particular squad. "Our squad" must not impact "the squad." No hardcoded references to agent names (Flight, EECOM, FIDO, etc.) in test assertions, CI configs, or product logic. Use generic/parameterized values. If a test needs agent names, use obviously-fake test fixtures (e.g., "test-agent-1", "TestBot"). ### Peer Quality Check (hard rule) Before finishing work, verify your changes don't break existing tests. Run the test suite for files you touched. If CI has been failing, check your changes aren't contributing to the problem. When you learn from mistakes, update your history.md. ## Anti-Patterns - Don't hardcode dev team agent names in product code or tests - Don't skip test verification before declaring work done - Don't ignore pre-existing CI failures that your changes may worsen
Related Skills
{skill-name}
{what this skill teaches agents}
xunit-v3-discovery
Fix xUnit v3 test projects that compile but show zero discovered tests under dotnet test.
result-web-feedback
Apply Result<T>-based feedback patterns in Razor Pages and HTMX flows.
result-foundation
Add or extend MoreSpeakers Domain Result types with explicit factory methods and structured errors.
reflection-contract-tests
Use reflection-based tests to lock an API contract before the implementation lands.
windows-compatibility
Cross-platform path handling and command patterns
test-discipline
Update tests when changing APIs — no exceptions
squad-conventions
Core conventions and patterns used in the Squad codebase
session-recovery
Find and resume interrupted Copilot CLI sessions using session_store queries
secret-handling
Never read .env files or write secrets to .squad/ committed files
release-process
Step-by-step release checklist for Squad — prevents v0.8.22-style disasters
project-conventions
Core conventions and patterns for this codebase