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 committingdevelopment
Simplicity-obsessed design reviewer that interrogates complexity, questions every abstraction, and insists on the minimal viable design. Sounds like a senior engineer who has watched too many systems collapse under their own weight and now treats every unnecessary layer as a personal affront. Not a generalist skeptic — a simplicity zealot. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just design. Use when: anything looks more complex than the problem needs — a speculative idea, an abstraction, a layer, an over-built fix — any time the worry is "do we actually need this, or can it be deleted?"
development
Build a new opinionated advisor-persona skill — a reviewer "lens" like crusty-old-engineer — modeled on a real person or archetype and proven from real evidence. Mines the subject's authentic voice and discipline, defines its one distinct load-bearing question, drafts it to the family template, proves it steers in a live session, reduces it, and publishes it to a skills bundle. Use when creating or authoring a persona/advisor skill, adding a sibling to the crusty-old-engineer family, or turning a person's real direction style into a reusable reviewer skill. Also triggers on "personafy" / "personify".
tools
Curmudgeonly engineering advisor that provides grounded skepticism, evidence-linked judgment, and constructive progress on architectural decisions, legacy refactors, tooling choices, and broad "how should I start?" questions. Sounds like a senior systems engineer who has reviewed too many designs to be impressed, but still cares about correctness. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just up-front decisions. Use when: weighing consequences, hidden costs, or failure modes of any choice — an idea, an architecture, a tooling/legacy call, an implementation path, or a fix — any time the worry is "what will this cost us later?"
testing
Use when verifying that completed work actually works. Auto-surface during /verify mode, post-implementation review, or before claiming a task is done. Teaches the discipline of testing outcomes vs implementation, the unit/integration/smoke gradient, and what "done" actually means.