OpenParable
Skip to content
← Back to skills

Write Architecture

Documents
write-architecture

Write Architecture is an Agent Skill for documents published in the imbue-ai/bouncer repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Write an architecture document from goals and requirements

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/imbue-ai/bouncer/blob/HEAD/.claude/skills/write-architecture/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/write-architecture, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

Write Architecture Document

Read my goals and requirements at docs/$ARGUMENTS/

I want you to:

  1. Ask clarifying questions or raise concerns about the requirements
  2. Deeply analyze the codebase to understand existing patterns and architecture
  3. Create an architecture document at docs/$ARGUMENTS/architecture.md

Document structure:

  • Executive summary with before/after comparison table
  • Current architecture overview (with diagrams)
  • Key architectural changes (with diagrams)
  • Component deep dives for each major change
  • Data model changes (schema, API types)
  • Migration strategy (if applicable)
  • Code removal plan (if applicable)
  • Files to modify/create/delete appendix
  • Testing strategy overview

Guidelines:

  • Use ASCII diagrams liberally to illustrate component relationships
  • Describe HOW components interact, not implementation code
  • Identify alternatives you considered and why you chose this approach
  • Call out risks and mitigation strategies
  • Prefer YAGNI over extensibility - build for current requirements, not hypothetical future ones
  • Reference requirement IDs (REQ-*) to show traceability

Do not:

  • Write code in the document
  • Include time estimates