Project finalization kit: security, quality and release

An application can open in a browser and still have work to do before release. Who can access each piece of data? Can failures be diagnosed? Do tests cover the important flows? Is the code going to production the code that was reviewed?

I put together the Project finalization kit to turn these questions into a sequence of work. It combines a reusable prompt, persistent agent instructions and delivery templates. It can support projects built with AI or a conventional development workflow.

The downloadable kit is written in Portuguese. This article explains its structure in English.

Download the complete kit (ZIP, Portuguese)

View the files on GitHub

A sequence with evidence

The starting point is straightforward: security and working behaviour come before cleanup. The delivery should preserve legitimate flows and leave evidence of what was tested.

1. Understand the starting state: project, branch, remote, environment, scope and existing tests.
2. Review security: secrets, authentication, authorization, inputs, data and integrations.
3. Validate behaviour and interface: critical flows, errors, recovery, mobile and accessibility.
4. Check observability and quality: failure diagnosis, architecture, linting, types and tests.
5. Clean up last: confirm what is unused, remove it in small steps and test again.
6. Release with traceability: Issue, PR, review, checks, merged commit and verification in the target environment.

The prompt asks the agent to fix problems within the authorized scope and distinguish a passed check from a failed or unperformed one. It also asks for explanations of behaviour changes and preservation of other people’s work.

Inside the package

File	Purpose
README.md	Usage guide, tools and references.
SUPERPROMPT.md	Full review, remediation and delivery workflow.
AGENTS.template.md	Rules to incorporate into the project’s instructions.
GIT-WORKFLOW.md	Git, GitHub, release and rollback workflow.
TEMPLATES.md	Issue, PR and final report templates.

Start by filling in the prompt’s context: repository, authorized environments and acceptance criteria. Merge the agent template into the existing instruction file, preserving project rules. If a tool does not load that file automatically, point to it explicitly in the task.

Git: fetch, compare, then integrate

The guide distinguishes git fetch from git pull. Fetch updates local remote-tracking references; pull also integrates changes into the current branch. The update example uses --ff-only to reject integration that cannot fast-forward, while still requiring checks of the branch, upstream, working tree and local-only commits. Git fetch documentation and Git pull documentation.

Each task needs an Issue. Its PR should explain the outcome, provide evidence and reference that Issue. After review and passing checks, deployment uses the merged commit or an artifact traced to it. The kit also notes that automatic Issue closure depends on the PR’s target branch. GitHub documentation.

Interface, diagnosis and quality

The kit references Kyle Zantos’s external Design Motion Principles skill for interface work. It calls for loading, success, empty, error and retry states on asynchronous surfaces, accessible motion and deferred loading where useful.

For observability, it asks for information that helps investigate failures: environment, release and correlation, with protection of sensitive data and clear alert ownership. OpenTelemetry can provide instrumentation and export; the analysis destination can be the service the team already uses.

The guide also explains the roles of ArchContract, Biome, Commitlint, Knip, Stryker, Codecov and Playwright. Selection depends on the stack and risk. Every tool needs configuration, criteria and integration into the workflow; the list is not an automatic installer.

Scope and limitations

This is an instruction kit, not a scanner or security certification. It does not create branch protections, configure services or guarantee that an agent follows every rule. Review, permissions and evidence remain part of delivery.

Security rules require context: authentication limits, database policies, CORS and retention must fit the actual system. If a credential has been exposed, deleting a line of code does not resolve the whole incident; containment includes evaluating revocation and rotation. OWASP secrets management guidance.

The aim is a clearer, repeatable finalization process: knowing what changed, why, how it was validated and how to roll it back if necessary.