> ## Documentation Index
> Fetch the complete documentation index at: https://teamcopilot.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Developers

> See how developers can use TeamCopilot with skills and workflows for code review, release work, and engineering operations.

Developers often benefit from TeamCopilot across code review, release operations, debugging, and engineering workflows.

## Example setup

* A **skill** for code review standards
* A **skill** for release procedures
* A **workflow** for deployment, changelog generation, or environment checks

## Example requests

* "Review this PR using our backend review standards."
* "Use our release skill to validate whether this version is ready."
* "Run the staging deploy workflow."

## Why this works

The skills capture engineering judgment and team conventions. The workflows handle the parts that should be automated and repeatable.

This setup usually pairs well with:

* [Permissions](/docs/workflows-and-skills/permissions)
* [Approval review](/docs/workflows-and-skills/approvals-and-review)
* [Run history](/docs/workflows-and-skills/run-history)

## Example `SKILL.md`

Below is an example developer skill for code review.

```md theme={null}
---
name: backend-code-review
description: Review backend code changes for correctness, regressions, maintainability, and operational risk.
---

# Backend Code Review

Use this skill when the user asks for a code review on backend or infrastructure-related changes.

## Review priorities

Focus on:

- correctness
- regressions
- missing validation
- error handling
- permission and security risks
- missing tests

## How to review

1. Understand the purpose of the change.
2. Identify behavior changes, not just style issues.
3. Check whether the implementation matches the intended contract.
4. Look for failure modes and edge cases.
5. Check whether tests cover the important paths.

## Output format

When performing review:

1. Start with findings, ordered by severity.
2. Include file references when possible.
3. Keep summaries brief.
4. If no major issues are found, say that explicitly and mention residual risks.

## Constraints

- Do not focus on formatting unless it affects readability or correctness.
- Prefer actionable findings over generic commentary.
- Call out missing tests when behavior changes are not covered.
```

## Example workflow `run.py`

Below is an example developer workflow that generates a simple changelog from git commits between two refs.

```python theme={null}
import argparse
import subprocess
import sys


def parse_args():
    parser = argparse.ArgumentParser()
    parser.add_argument("--base_ref", required=True, help="Older git ref")
    parser.add_argument("--head_ref", required=True, help="Newer git ref")
    return parser.parse_args()


def run_git_log(base_ref: str, head_ref: str):
    cmd = [
        "git",
        "log",
        "--pretty=format:%h|%an|%s",
        f"{base_ref}..{head_ref}",
    ]
    result = subprocess.run(cmd, capture_output=True, text=True, check=False)
    if result.returncode != 0:
        raise RuntimeError(result.stderr.strip() or "git log failed")
    return [line for line in result.stdout.splitlines() if line.strip()]


def main():
    args = parse_args()

    try:
        entries = run_git_log(args.base_ref, args.head_ref)
    except Exception as exc:  # noqa: BLE001
        print(f"Failed to build changelog: {exc}", file=sys.stderr)
        sys.exit(1)

    print("Release Changelog")
    print("=================")
    print(f"Range: {args.base_ref}..{args.head_ref}")
    print()

    if not entries:
        print("No commits found in the selected range.")
        return

    for entry in entries:
        sha, author, subject = entry.split("|", 2)
        print(f"- {subject} ({sha}, {author})")


if __name__ == "__main__":
    main()
```