Putting It All Together

You've learned the concepts. Now let's design a complete agentic automation plan for your repositories — combining your existing Kiro harness with gh-aw workflows to create a system where agents handle the routine while you focus on the interesting problems.

Your Current System

You already have a strong foundation:

The Implementation Plan

Here's a phased rollout — each phase builds on the previous one and can be completed in a single session:

• Phase 0: Foundation (Done)
  Your Kiro harness works. Commands, steering, roles, promptfoo evals. ✓
• Phase 1: First gh-aw Workflow
  Install gh-aw CLI. Add daily-repo-status to one repo. Validate it works. (~15 min)
• Phase 2: Custom Triage Workflow
  Write your own IssueOps workflow: auto-label new issues, ask for missing info. (~30 min)
• Phase 3: Automated PR Review
  Port your /comply logic to a gh-aw workflow triggered on PR open. Independent review without you typing /comply. (~45 min)
• Phase 4: Scheduled Quality Monitor
  MonitorOps workflow: weekly code quality scan, creates an issue with findings. (~30 min)
• Phase 5: Cross-Provider Harness
  Add .claude/ directory alongside .kiro/ so Claude Code users get the same workflow. (~1 hr)

Phase 1 Blueprint: Your First gh-aw Workflow

Start here. This gets you a working agentic workflow in production in 15 minutes.

• Install the CLI: gh extension install github/gh-aw
• Pick a repo you actively work on (not a test repo — you want real signal)
• Add the daily status workflow: gh aw add-wizard githubnext/agentics/daily-repo-status
• Choose your AI engine (Anthropic if you have a key, Copilot otherwise)
• Trigger a run: gh aw run daily-repo-status
• Check the created issue — customize the workflow markdown to focus on what you care about
• Add max-ai-credits: 5 to the frontmatter to cap costs
• Commit and let it run on schedule for a week

Phase 3 Blueprint: Automated /comply

This is the most valuable automation for your workflow — your independent reviewer, running automatically on every PR:

---
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: read

safe-outputs:
  create-pull-request-review-comment:
    max: 10
  submit-pull-request-review:
    max: 1
    allowed-events: [COMMENT]
  add-labels:
    allowed: [compliance-pass, compliance-fail, needs-review]

max-ai-credits: 10
---

## Automated Compliance Review

You are an independent code reviewer. Review this PR against
the repository's design principles and any spec file present.

### What to check

1. **Spec compliance**: If `.kiro/spec.md` exists, grade each
   acceptance criterion as met/partial/unmet with evidence.
2. **Design principles**: DRY, simplicity, surgical changes,
   backwards compatibility.
3. **Test coverage**: Are new behaviors tested?
4. **Documentation**: Do public APIs have docs?

### Output format

Post review comments on specific lines where issues exist.
Submit a review summary with:
- Overall compliance score (percentage)
- Table of criteria → status → evidence
- Verdict: pass (≥90%) or fail

### Labels

- Add `compliance-pass` if score ≥90%
- Add `compliance-fail` if score <90%
- Add `needs-review` if you can't determine (missing spec)

Phase 4 Blueprint: Weekly Quality Monitor

---
on:
  schedule: "0 9 * * 1"  # Every Monday at 9am

permissions:
  contents: read
  issues: read

safe-outputs:
  create-issue:
    title-prefix: "[quality] "
    labels: [automation, quality]
    close-older-issues: true
    expires: 7

max-ai-credits: 8
---

## Weekly Code Quality Report

Analyze the repository for quality issues and create
a prioritized report.

### What to analyze

- Dead code (unused exports, unreachable branches)
- Complexity hotspots (functions > 50 lines, deep nesting)
- Dependency freshness (outdated packages)
- Test coverage gaps (untested public functions)
- Documentation staleness (docs that reference old APIs)

### Report format

Create an issue with:
- Top 5 priority items (most impactful to fix)
- Quick wins (< 15 min each)
- Trends (better or worse than last week, if prior report exists)

Keep it actionable. Skip theoretical concerns.

Decision Framework: When to Automate

Not everything should be an automated workflow. Use this test:

Your Automation Readiness Checklist

Before adding any gh-aw workflow to a repo, verify:

• GitHub Actions enabled on the repo
• AI engine secret configured (ANTHROPIC_API_KEY or COPILOT_GITHUB_TOKEN)
• max-ai-credits set in frontmatter (start low: 5-10)
• Start with staged: true to preview before going live
• Test manually with gh aw run before enabling schedule/event triggers
• Monitor first week: gh aw logs to check costs and quality
• Iterate: tighten prompts based on actual outputs

What You've Learned

Across these 10 lessons, you now understand:

1. The three-layer architecture — hooks, commands, skills — and how your Kiro harness already implements it
2. gh-aw — how to install, add, and customize agentic workflows that run in GitHub Actions
3. The security model — read-only agents, safe outputs, sandboxing, threat detection
4. Triggers — event-driven, scheduled, manual, and command-based invocation
5. Background automation — scheduled agents that work while you sleep
6. Design patterns — IssueOps, ChatOps, MonitorOps, SpecOps, OrchestratorOps
7. Cross-provider portability — same patterns across Claude Code, Gemini, Codex, Cursor
8. Cost controls — AI credit budgets, staged mode, observability
9. Multi-agent coordination — subagents, orchestration, role collapsing
10. Implementation planning — phased rollout from your existing system