Scoped planning
A selected brief and allowed documents could produce a work plan, acceptance criteria, open questions, and a bounded repository scope.
AGENT WORKBENCH
Give software teams a reviewable path from brief to change proposal.
A concept workspace for small software and operations teams to turn an approved brief, documentation, and selected repository context into scoped delivery artifacts with human approval at each consequential step.
Concept · Design stage
Planned delivery workspace
Keep the artifacts, evidence, and decision owner in the same flow.
The product concept separates planning, architecture, implementation, independent QA, security review, and financial draft work into explicit outputs, with a responsible reviewer and review criteria at each stage.
- 01 · ScopeApproved brief, documents, and repository selection
- 02 · DraftPlan, architecture note, code proposal, and review artifacts
- 03 · ReviewIndependent QA, security, and cost checks
- 04 · ApproveHuman decision, ticket, report, or change proposal
One brief, distinct responsibilities
The proposed workspace makes the handoff between specialist stages visible so a team can reject, revise, or approve a draft with its evidence attached.
Delivery artifacts
Architecture notes, implementation proposals, test cases, security findings, and a financial draft would remain separate artifacts with their sources.
Independent review
A separate review step would check whether the proposal meets stated criteria before a human decides to create a ticket or accept a change.
Three steps for an MVP
The product workspace is in design. These proposed steps define a narrow path that can be evaluated before any broader automation.
- 01
Select the working set
Choose an approved brief, documentation set, and read-only repository scope for a single task.
- 02
Generate reviewable drafts
Route the selected context through planning, architecture, code, QA, security, and financial-draft stages as needed.
- 03
Approve an output
Review the evidence and create a ticket, report, or change proposal only after a responsible person approves it.
Illustrative proposed artifact chain
Input: approved feature brief + selected repository files
Output: scoped plan → architecture decision → code proposal
Review: independent QA + security checks → human-approved change proposalWhere Claude would fit
JinsongTech currently uses Codex in its development workflow and plans to evaluate Claude Code for selected development and independent-testing stages, then opt-in Claude API use for bounded product workflows.
Current: Codex-supported development
Codex is used to organize work and produce drafts. A human chooses context, reviews outputs, and owns architecture, implementation, and release decisions.
Planned: selected data to read-only tools
A planned Claude workflow would receive only an approved brief, selected documents, and permitted repository context. Read-only tools could return cited plans, test findings, or implementation proposals.
Planned: permission and audit controls
Permissions, audit trails, grounded citations, per-task cost limits, and human approval would be designed before an output can create a ticket, report, or change proposal.
Proposed technical boundary
The proposed stack is a React interface, FastAPI service, and PostgreSQL-backed audit model. Deployment scope would be set after confirming security, retention, and operational requirements.
What does the product help a team do?
It is a design-stage workspace for creating and reviewing delivery artifacts. Roles describe workflow stages; accountable people approve the work and make delivery decisions.
Can an agent write directly to a production system?
The planned MVP begins with selected context, read-only tools, drafts, and human approval before any downstream action.
Product conversation