Octo prepares
Maps, plans, codes on the task branch, reviews with evidence and prepares the release: plans, code, reviews, security reports and the system dossier.
Deliverable: material ready for reviewOcto × Software engineering · where Octo comes from
Systems development, from requirement to deploy.
This is where Octo was born. The eight arms (discovery, data, security, architect, dev, reviewer, deploy and scribe) work inside your development team, led by a senior developer or your company's tech lead. Each arm has a narrow role; whoever is in charge approves the plan, merges and is accountable for the system. Nothing goes to production without their approval.
Eight arms; the head is your company's tech lead
Steps9one page per development step
Confirmed79points with a published source
Sources59references at the end of each page
01
Octo at work in software engineering.
One task from request to approval, at a fictional company. The arms measure, plan and execute; whoever is in charge checks and approves. Each tab is one topic in this field and links to its page.
Octo · task #412 · Ponte Clara Sistemas (fictional company)
Topic pageSecurity →Database →Front end →
02
Eight arms, one development team.
Each arm is a specialist with a narrow role and tools limited to that role. A senior developer or your company's tech lead is in charge: they approve the plan, merge, accept the risk and are accountable for the system.
-
Arm 1
Discovery
Maps the system: stack and versions, structure, entry point, request flow, routes, cron jobs, integrations and deploy.
-
Arm 2
Data
Studies the database: tables, relationships, actual foreign keys, money, dates and soft deletes, before any query or change.
-
Arm 3
Security
Reviews login, passwords, sessions, roles, routes without checks, exposed files and credentials in the code.
-
Arm 4
Architect
Plans before coding: impact, risk, questions, a plan with branch, migration and rollback, and an estimate with slack.
-
Arm 5
Dev
Executes the approved plan on the task branch, with small commits and testing through the real path.
-
Arm 6
Reviewer
Checks the delivery requirement by requirement, with least privilege, and returns the evidence.
-
Arm 7
Release
Checks the branch, simulates the merge, orders the migrations and verifies what the server is actually serving.
-
Arm 8
Scribe
Maintains the system dossier, the project's status and its decisions.
Nothing goes to production without the approval of whoever is in charge. Octo prepares, executes and checks; the decision stays with your team.
03
One page per step.
From requirement to deploy: which arm works at each step, what it delivers, what stays with the tech lead and what is confirmed by a published source.
Requirements and discovery
Discovery of the existing system, item-by-item requirements, definition of done and security requirements from the start.
Open the page →Architecture and planning
Plan before code, threat modeling through the four questions, risk, rollback and an estimate with slack.
Open the page →Front end, UX and accessibility
WCAG 2.2 (ISO/IEC 40500:2025), the 24 by 24 pixel target, the 4.5:1 contrast ratio, Brazil's Inclusion Law and desktop and mobile testing.
Open the page →Back end and APIs
OpenAPI 3.2.1, object-level authorization (OWASP API1:2023), parameterized queries and a version bump when the contract breaks.
Open the page →Database
Tables, relationships and actual foreign keys, numeric for money, migrations with rollback and what stays out of the log.
Open the page →Testing and code review
Requirement-by-requirement review, testing through the real path with least privilege, a read-only reviewer and evidence instead of "it passed".
Open the page →Application security
OWASP Top 10 2025, ASVS 5.0.0 and NIST SSDF 1.1: access, passwords, secrets and incidents, with a report signed by a professional at the company.
Open the page →Continuous integration and delivery
DORA's five metrics, continuous delivery, simulated merge, migration order and verification by the content served.
Open the page →Documentation
System dossier, dated decisions, CLAUDE.md as guidance and hooks as rules, commits that state why, and documentation from OpenAPI.
Open the page →
04
Confirmed by source.
Each point below has a source published by the organization responsible for the standard, the specification or the tool, or in Brazilian federal law. The sources are in the next section.
The common ground of this field: the discipline, as SWEBOK describes it, and the tool under Octo, as the Claude Code documentation describes it. Each step has its own sources on its page.
- ConfirmedThe discipline
- SWEBOK defines the content of the software engineering discipline and seeks a common understanding of it worldwide.Source: IEEE Computer Society, SWEBOK
- Confirmed18 knowledge areas
- SWEBOK v4.0, from the IEEE Computer Society, has 18 knowledge areas, including requirements, architecture, design, construction, testing, operations, maintenance, configuration management, quality and security. The September 25, 2025 revision is called v4.0a.Source: IEEE Computer Society, SWEBOK
- ConfirmedAgentic tool
- Claude Code, the tool under Octo, is an agentic tool: it reads code, edits files, runs commands and integrates with development tools.Source: Claude Code, overview
- ConfirmedSubagents
- Each subagent runs in its own context, with independent instructions, tool access and permissions. This is the technical basis of the eight arms.Source: Claude Code, subagents
- ConfirmedLimited tools
- A subagent's tools can be restricted with an allow list or a deny list.Source: Claude Code, subagents
- ConfirmedHooks
- Hooks are commands that always run at fixed points, regardless of what the model decides.Source: Claude Code, hooks
- ConfirmedPermission mode
- In Manual mode, editing a file or running a shell command that isn't read-only requires approval; reading doesn't. The mode is set in each company's installation.Source: Claude Code, permissions
- ConfirmedContext and rules
- CLAUDE.md and memory are context, not enforced configuration; to block an action regardless of what the tool decides, you use a hook.Source: Claude Code, memory
- ConfirmedDeny rules
- Deny rules apply in every permission mode.Source: Claude Code, best practices
05
What Octo does and what stays with you.
Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.
Your team reviews
Whoever is in charge is the company's tech lead or senior developer: they approve the plan, review the PR and merge it. Nothing goes to production without their approval.
Step: approval by whoever is in chargeWho signs and is accountable
Octo does not sign and is not accountable for the system. The tech lead accepts the risk and is accountable for the system in production; a security report or opinion is signed by a professional at the company.
Accountable: the company's tech lead
06
Sources.
SWEBOK from the IEEE Computer Society and the Claude Code documentation. Accessed October 31, 2026.
- IEEE Computer Society: SWEBOK v4.0aThe 18 knowledge areas of software engineering
- Claude Code: overviewWhat the tool does
- Claude Code: subagentsTheir own context, tools and permissions
- Claude Code: hooksCommands at fixed points
- Claude Code: permissionsWhat requires approval in Manual mode
- Claude Code: memoryCLAUDE.md as context
- Claude Code: best practicesDeny rules in every mode
Which step is holding back your development team?
The assessment starts by reading the system you already have, without changing anything. You get a map of what Octo can take on and decide with it in hand.