Prepare a Project for Agents

This guide explains how to prepare an enterprise project for specification-driven work with coding agents. Project preparation happens as part of Cycle 1, Stage 2, in parallel with UX direction and initial feature specification generation. The Product Engineer, architect, and relevant platform or security owners collaborate according to the subject and risk.

The aim is to provide a technically sound and discoverable starting point while avoiding a heavyweight, mandatory upfront approval ceremony. Existing enterprise approvals still apply when a chosen dependency, integration, security capability, or architectural exception requires them.

Responsible roles: Product Engineer and Architect / Senior Engineer; enterprise platform and security owners as needed. The architect leads architectural choices; the Product Engineer owns continuing product work and agent coordination.

Inputs: Product objectives, preliminary feature specifications, enterprise technical and security standards, approved reusable assets, relevant design-system guidance, and identified business/technical dependencies.

Outputs: A project with sufficient initial technical structure and instructions, approved technical choices, accessible specifications, and a coding-agent execution environment constrained by appropriate permissions.

1. Confirm the initial product boundary. Review the objectives, principal workflows, preliminary acceptance conditions, known constraints, and significant open decisions. Identify technical concerns that could materially affect implementation. Raise unresolved business-policy questions with their proper owners; do not convert technical guesses into business decisions.

2. Choose from approved enterprise capabilities. Identify which approved application stack, starter project, shared services, existing components, and libraries fit the product. Prefer suitable organizational assets rather than creating redundant implementations. A new dependency or architectural departure follows the organization's established exception process.

3. Establish enough architecture for the next iteration. Define relevant system boundaries, data and integration responsibilities, component separation, and repository conventions. Document decisions required for the coding agent to implement the initial scope consistently. Avoid comprehensive upfront design of details that can safely be refined during implementation.

4. Prepare discoverable instructions and context. Keep the root AGENTS.md minimal and have it direct agents to all Markdown documents under agent_instructions/. Each file in that directory explains its own purpose on the first line. Confirm that instructions are coherent, current, noncontradictory, and consistent with approved standards. File names and the number of instruction documents remain project choices.

5. Keep product behavior in specifications. Maintain agreed feature behavior in the separate specs/ area. Standing instructions establish how work should be performed and which durable constraints apply; specifications describe what the product must do. Do not duplicate feature requirements into a permanent coding-rule file or introduce an additional mandatory artifact with a SHAPE-specific name.

6. Establish technically enforced agent boundaries. Ensure access to repositories, systems, secrets, tools, and networks is configured by the authorized owners. Written instructions may guide agent behavior but do not enforce permissions. Access should match the minimum appropriate needs of the task.

7. Begin implementation and refine responsibly. Confirm the coding agent can discover the instructions and relevant specifications, use approved assets, and operate within the authorized environment. The Product Engineer begins implementation once material prerequisites for the work are satisfied. Consult the architect when consequential issues, exceptions, or risks emerge. Technical preparation can evolve alongside new understanding without becoming an extra standing approval gate.

The initial scope is sufficiently understood for an implementation increment; relevant architectural choices follow approved enterprise standards; feature specifications are accessible; the agent's standing instructions are discoverable and internally consistent; necessary technical controls are enforced; and the Product Engineer can direct productive implementation while knowing which outstanding decisions require escalation.

No additional SHAPE-specific Architecture Readiness Review certificate, fixed six-part audit, lengthy architecture document, mandatory instruction filename list, or handoff ceremony is required.

Allowing an agent to invent a business or architectural exception; using text instructions in place of technical access controls; duplicating specifications in standing coding rules; insisting on exhaustive upfront design; introducing unnecessary libraries; and turning every implementation increment into an architect approval request.