Agent Chaining Patterns

Sequential chaining is the backbone of GigiKit’s quality pipeline. This guide covers the two canonical chains you will use on almost every task, plus guidance on when to pick one over the other.

Choosing a Chain

Chain 1: Feature Development

Planning → Implementation → Simplification → Testing → Review

This is the default chain for adding features to an existing codebase. Tests run against the simplified code — not the first draft — so quality is baked in before review.

Step-by-step prompt templates

1. Planner agent

You are a planner agent. Create a phased implementation plan in ./plans for:
[feature description]

Work context: /path/to/project
Reports: /path/to/project/plans/reports/
Plans: /path/to/project/plans/

Research the codebase, identify affected files, and produce phase-XX-*.md files
with todo lists and success criteria.

2. Implementer agent (receives planner output)

You are a fullstack developer executing phase-02 of the plan at:
/path/to/project/plans/[plan-dir]/phase-02-implement-feature.md

Work context: /path/to/project
Reports: /path/to/project/plans/reports/
Plans: /path/to/project/plans/

Read the phase file, implement only files listed in File Ownership,
run compile checks, and report completion.

3. Tester agent (receives implementer output)

You are a tester agent. Run tests on the code implemented in phase-02.
Fix any failing tests — do NOT mock or skip them.

Work context: /path/to/project
Reports: /path/to/project/plans/reports/
Plans: /path/to/project/plans/

4. Code reviewer agent (receives passing tests confirmation)

You are a code reviewer. Review the clean, tested code from phase-02.
Check for readability, security, and adherence to ./docs/code-standards.md.

Work context: /path/to/project
Reports: /path/to/project/plans/reports/

Chain 2: New System Component

Research → Design → Code → Documentation

Use this chain when building something with no existing reference point in the codebase — a new service, a new integration, or a new infrastructure layer.

Step-by-step prompt templates

1. Researcher agents (run in parallel)

You are a researcher agent. Investigate [specific sub-topic, e.g. "auth token standards"].
Produce a report at /path/to/project/plans/reports/researcher-[topic]-report.md

Work context: /path/to/project
Reports: /path/to/project/plans/reports/

Spawn one researcher per sub-topic simultaneously. Feed all reports to the designer.

2. Designer / Planner agent (receives all research reports)

You are a system designer. Read all researcher reports in:
/path/to/project/plans/reports/

Design the architecture for [component name] and produce:
- System design document
- Phase files in /path/to/project/plans/[plan-dir]/
- API contracts and data models

3. Implementer agent — same template as Chain 1, Step 2.

4. Docs-manager agent (receives implementation completion)

You are a documentation manager. Update ./docs to reflect the new [component name].
Update system-architecture.md, codebase-summary.md, and any relevant guides.

Work context: /path/to/project

Passing Context Between Agents

Each agent should explicitly receive:

1. The path to the previous agent’s output file (report, plan phase, etc.)
2. Work context, reports path, and plans path
3. A clear statement of what the previous agent completed

Related Guides

• Sequential & Parallel Orchestration — when to chain vs. parallelize
• The 6-Step Development Workflow — how chains fit into the full pipeline
• Creating Implementation Plans — plan structure the planner agent produces