modules/tool-skills/tests/fixtures/skills/python-standards/SKILL.md
Python coding standards for Amplifier including type hints, async patterns, error handling, and formatting. Use when writing Python code for Amplifier modules.
npx skillsauth add microsoft/amplifier-bundle-skills python-standardsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
ALL functions must have complete type hints:
from typing import Any
async def process_data(items: list[str], config: dict[str, Any]) -> dict[str, Any]:
"""Process data items with configuration."""
results = {}
for item in items:
results[item] = await transform(item, config)
return results
Include type hints for self:
class MyClass:
def __init__(self: "MyClass", name: str) -> None:
self.name = name
async def process(self: "MyClass") -> str:
return f"Processing {self.name}"
All I/O operations must be async:
# Good
async def read_file(path: Path) -> str:
content = path.read_text() # For now, sync is OK
return content
# Better (when using async libraries)
async def read_file(path: Path) -> str:
async with aiofiles.open(path) as f:
return await f.read()
Use asyncio.gather for parallel operations:
async def process_files(files: list[Path]) -> list[dict]:
tasks = [process_file(f) for f in files]
return await asyncio.gather(*tasks)
Return errors, don't raise:
from amplifier_core import ToolResult
async def execute(self: "MyTool", input: dict[str, Any]) -> ToolResult:
"""Execute tool operation."""
try:
result = await self._process(input)
return ToolResult(success=True, output=result)
except ValueError as e:
logger.error(f"Validation error: {e}")
return ToolResult(success=False, error={"message": str(e)})
Provide clear error messages:
# Good
return ToolResult(
success=False,
error={"message": f"File not found: {path}"}
)
# Bad
return ToolResult(
success=False,
error={"message": "Error"}
)
Line length: 120 characters
Import organization:
# Standard library
import asyncio
import logging
from pathlib import Path
from typing import Any
# Third-party
import yaml
from pydantic import BaseModel
# Local/Amplifier
from amplifier_core import ModuleCoordinator, ToolResult
Files must end with newline - Add blank line at EOF
Use ruff for formatting:
uv run ruff format .
uv run ruff check . --fix
Use uv for dependency management:
# Add dependency
cd amplifier-module-tool-mytool
uv add package-name
# Add dev dependency
uv add --dev pytest ruff pyright
Never manually edit pyproject.toml dependencies - Use uv add
Test behavior at protocol level:
import pytest
from amplifier_core.testing import TestCoordinator
@pytest.mark.asyncio
async def test_tool_basic():
"""Test basic tool functionality."""
coordinator = TestCoordinator()
# Mount module
await mount(coordinator, {"timeout": 10})
# Get and test
tool = coordinator.get("tools", "my-tool")
result = await tool.execute({"param": "value"})
assert result.success
assert "expected" in result.output
Test pyramid: 60% unit, 30% integration, 10% end-to-end
# Bad
content = requests.get(url).text
# Good
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
content = await response.text()
# Bad
tool._internal_state = new_value
# Good
await tool.execute({"operation": "update", "value": new_value})
# Bad
async def mount(coordinator, config):
tool = MyTool()
await tool.initialize_database() # Heavy logic
await coordinator.mount("tools", tool)
# Good
async def mount(coordinator, config):
tool = MyTool(config) # Light initialization only
await coordinator.mount("tools", tool)
# Heavy logic happens in execute(), not mount()
make check before committingtools
Plan a batch of independent work into isolated lanes, get your approval, then run each lane as its own autonomous /goal session — one git worktree, one branch, one tmux session each — and verify and merge the results yourself. Use when work decomposes into pieces that can run at the same time: "run these in parallel", "goal-batch", "launch lanes for these", "work these N tasks simultaneously", "batch these as goals". Nothing launches until you have seen the lane split and said go. This is NOT fire-and-forget: the orchestrating session re-runs the full test suite itself after every merge and never accepts a lane's own claim that it finished. NOT for bounded edits that each end in their own PR — use mass-change for that. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.
development
Momentum-driven engineering reviewer that holds one uncompromising gate — is it REAL, proven end-to-end as a user would — while driving work forward. Demands proof over claims, plumbing before polish, fail-loud over fallbacks, trust in the model over instructions, and protects the critical path so good-but-costly ideas don't stall the work. Warm, blunt, forward-driving — not a curmudgeon. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or ship — not just the finish. Use when: pressure-testing whether an idea/design/plan is provable and on the critical path, whether you're building in the right order, whether a fix is real or a band-aid, or whether work is actually done/ready — any time the worry is "are we fooling ourselves about what's real?"
development
Convene the Product Development Council (six orthogonal product-delivery lenses, anchored by a mandatory problem-validation gate) on a target — cold independent fan-out, debate-to-consensus, synthesized verdict with recorded dissent and a roster manifest.
development
Convene the Product Development Council on the CURRENT conversation / work-in-progress — the plan, roadmap, or scope decision you've been building in this session. The INLINE counterpart to /product-council (which forks and runs isolated, so it cannot see the chat). Use when you want the council to critique what we're working on right now.