open-codev-workflow 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- open_codev_workflow-0.1.0/LICENSE +28 -0
- open_codev_workflow-0.1.0/PKG-INFO +150 -0
- open_codev_workflow-0.1.0/README.md +121 -0
- open_codev_workflow-0.1.0/pyproject.toml +79 -0
- open_codev_workflow-0.1.0/setup.cfg +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/__init__.py +5 -0
- open_codev_workflow-0.1.0/src/codev_workflow/__main__.py +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/build-change/SKILL.md +96 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/build-change/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/build-change/assets/implementation-plan.template.md +51 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/define-product/SKILL.md +79 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/define-product/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/define-product/assets/brief.template.md +50 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/design-solution/SKILL.md +75 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/design-solution/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/design-solution/assets/decision.template.md +26 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/design-solution/assets/design.template.md +76 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/launch-product/SKILL.md +66 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/launch-product/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/launch-product/assets/launch-plan.template.md +48 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/plan-delivery/SKILL.md +140 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/plan-delivery/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/plan-delivery/assets/delivery-plan.template.md +41 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/review-change/SKILL.md +48 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/review-change/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/specify-project/SKILL.md +205 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/specify-project/agents/openai.yaml +4 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/specify-project/assets/specification.template.md +151 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/specify-project/references/interview-coverage.md +303 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.agents/skills/specify-project/scripts/validate_specification.py +143 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.opencode/agents/builder.md +54 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.opencode/agents/orchestrator.md +72 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/.opencode/agents/reviewer.md +35 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/AGENTS.md +23 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/AI-WORKFLOW-PROMPTS.md +318 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/WORKFLOW-COOKBOOK.md +419 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/WORKFLOW-HUMAN.md +212 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/for-ai/WORKFLOW-AGENTS.md +171 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/handbooks/IDEA-TO-PRODUCTION-HANDBOOK.md +1190 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/handbooks/LANGUAGE-AGNOSTIC-PROJECT-HANDBOOK.md +745 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/docs/handbooks/PYTHON-PROJECT-HANDBOOK.md +960 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/evals/development-workflow/scenarios.json +132 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/scripts/evaluate-development-workflow.py +352 -0
- open_codev_workflow-0.1.0/src/codev_workflow/bundle/scripts/validate-development-workflow.py +213 -0
- open_codev_workflow-0.1.0/src/codev_workflow/cli.py +140 -0
- open_codev_workflow-0.1.0/src/codev_workflow/installer.py +891 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/PKG-INFO +150 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/SOURCES.txt +52 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/dependency_links.txt +1 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/entry_points.txt +2 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/requires.txt +6 -0
- open_codev_workflow-0.1.0/src/open_codev_workflow.egg-info/top_level.txt +1 -0
- open_codev_workflow-0.1.0/tests/test_cli.py +65 -0
- open_codev_workflow-0.1.0/tests/test_installer.py +261 -0
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
BSD 3-Clause License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026, Martin Urban
|
|
4
|
+
|
|
5
|
+
Redistribution and use in source and binary forms, with or without
|
|
6
|
+
modification, are permitted provided that the following conditions are met:
|
|
7
|
+
|
|
8
|
+
1. Redistributions of source code must retain the above copyright notice, this
|
|
9
|
+
list of conditions and the following disclaimer.
|
|
10
|
+
|
|
11
|
+
2. Redistributions in binary form must reproduce the above copyright notice,
|
|
12
|
+
this list of conditions and the following disclaimer in the documentation
|
|
13
|
+
and/or other materials provided with the distribution.
|
|
14
|
+
|
|
15
|
+
3. Neither the name of the copyright holder nor the names of its
|
|
16
|
+
contributors may be used to endorse or promote products derived from
|
|
17
|
+
this software without specific prior written permission.
|
|
18
|
+
|
|
19
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
20
|
+
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
21
|
+
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
22
|
+
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
23
|
+
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
24
|
+
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
25
|
+
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
26
|
+
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
27
|
+
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
28
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: open-codev-workflow
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Human-guided AI software delivery for real repositories.
|
|
5
|
+
Author: Martin Urban
|
|
6
|
+
License-Expression: BSD-3-Clause
|
|
7
|
+
Project-URL: Homepage, https://github.com/urban233/CoDev
|
|
8
|
+
Project-URL: Repository, https://github.com/urban233/CoDev
|
|
9
|
+
Project-URL: Issues, https://github.com/urban233/CoDev/issues
|
|
10
|
+
Keywords: ai,developer-tools,software-delivery,codex,opencode
|
|
11
|
+
Classifier: Development Status :: 3 - Alpha
|
|
12
|
+
Classifier: Environment :: Console
|
|
13
|
+
Classifier: Intended Audience :: Developers
|
|
14
|
+
Classifier: Operating System :: OS Independent
|
|
15
|
+
Classifier: Programming Language :: Python :: 3
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
19
|
+
Classifier: Topic :: Software Development :: Quality Assurance
|
|
20
|
+
Requires-Python: >=3.11
|
|
21
|
+
Description-Content-Type: text/markdown
|
|
22
|
+
License-File: LICENSE
|
|
23
|
+
Provides-Extra: dev
|
|
24
|
+
Requires-Dist: build>=1.2.2; extra == "dev"
|
|
25
|
+
Requires-Dist: mypy>=1.15; extra == "dev"
|
|
26
|
+
Requires-Dist: ruff>=0.11; extra == "dev"
|
|
27
|
+
Requires-Dist: twine>=6.1; extra == "dev"
|
|
28
|
+
Dynamic: license-file
|
|
29
|
+
|
|
30
|
+
<p align="center">
|
|
31
|
+
<img src="assets/codev-mark.svg" width="96" height="96" alt="CoDev mark">
|
|
32
|
+
</p>
|
|
33
|
+
|
|
34
|
+
<h1 align="center">CoDev</h1>
|
|
35
|
+
|
|
36
|
+
<p align="center"><strong>Human-guided AI software delivery.</strong></p>
|
|
37
|
+
|
|
38
|
+

|
|
39
|
+

|
|
40
|
+
|
|
41
|
+
CoDev installs a small, production-minded collaboration system into any Git
|
|
42
|
+
repository. It helps a developer and AI move through four understandable steps:
|
|
43
|
+
**Understand, Build, Review, and Ship**. It supports bounded three-agent
|
|
44
|
+
execution without turning product development into an unattended coding loop.
|
|
45
|
+
|
|
46
|
+
## Why CoDev
|
|
47
|
+
|
|
48
|
+
- One workflow for solo developers and multi-developer teams.
|
|
49
|
+
- Repository-grounded plans instead of invented APIs or architecture.
|
|
50
|
+
- A bounded builder and an independent, read-only reviewer.
|
|
51
|
+
- Human authority over material decisions, merge, deployment, and rollout.
|
|
52
|
+
- Versioned, conflict-aware installation across existing repositories.
|
|
53
|
+
- No runtime dependency in the software being built.
|
|
54
|
+
|
|
55
|
+
## Quick start
|
|
56
|
+
|
|
57
|
+
CoDev is a Python 3.11+ command-line tool. Target repositories may use any
|
|
58
|
+
language or build system. Install it with an isolated tool manager; `pipx` and
|
|
59
|
+
`uv tool` are the two supported, primary installation methods. Neither adds
|
|
60
|
+
CoDev or its dependencies to a target repository.
|
|
61
|
+
|
|
62
|
+
### Install from PyPI
|
|
63
|
+
|
|
64
|
+
```shell
|
|
65
|
+
pipx install open-codev-workflow
|
|
66
|
+
# or
|
|
67
|
+
uv tool install open-codev-workflow
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### Install from a wheel
|
|
71
|
+
|
|
72
|
+
For private, air-gapped, or pre-release distribution, install the supplied
|
|
73
|
+
wheel directly instead of publishing it to a package index:
|
|
74
|
+
|
|
75
|
+
```shell
|
|
76
|
+
pipx install ./dist/open_codev_workflow-0.1.0-py3-none-any.whl
|
|
77
|
+
# or
|
|
78
|
+
uv tool install ./dist/open_codev_workflow-0.1.0-py3-none-any.whl
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
Store the wheel with its SHA-256 checksum in a controlled artifact location.
|
|
82
|
+
The development workflow for building a wheel is documented below.
|
|
83
|
+
|
|
84
|
+
### Initialize a repository
|
|
85
|
+
|
|
86
|
+
```shell
|
|
87
|
+
codev init --target ../my-project --platform all
|
|
88
|
+
codev check --target ../my-project
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
To preview or apply a later bundle update:
|
|
92
|
+
|
|
93
|
+
```shell
|
|
94
|
+
codev diff --target ../my-project
|
|
95
|
+
codev update --target ../my-project
|
|
96
|
+
codev remove --target ../my-project --dry-run
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
`init`, `diff`, and `update` preflight the entire operation. A locally modified
|
|
100
|
+
managed file becomes a visible conflict; CoDev never silently replaces it.
|
|
101
|
+
|
|
102
|
+
## What gets installed
|
|
103
|
+
|
|
104
|
+
```text
|
|
105
|
+
my-project/
|
|
106
|
+
├── AGENTS.md # a managed policy block; local text survives
|
|
107
|
+
├── .agents/skills/ # seven lifecycle skills
|
|
108
|
+
├── .opencode/agents/ # orchestrator, builder, reviewer
|
|
109
|
+
├── .opencode/opencode.json # safely merged; existing agent settings survive
|
|
110
|
+
├── docs/ # workflow, prompts, handbooks, cookbook
|
|
111
|
+
├── evals/development-workflow/ # behavioral scenarios
|
|
112
|
+
├── scripts/ # deterministic validators
|
|
113
|
+
└── .codev/lock.json # installed version and source hashes
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
Use `--platform codex` to omit the OpenCode adapter. Use `--platform opencode`
|
|
117
|
+
or `--platform all` for the three-agent OpenCode topology. Core skills and
|
|
118
|
+
human/AI workflow references are installed for every platform.
|
|
119
|
+
|
|
120
|
+
## Design principles
|
|
121
|
+
|
|
122
|
+
1. **Local at use time.** Agents read ordinary files in the target repository.
|
|
123
|
+
2. **Central at maintenance time.** This repository is the canonical source.
|
|
124
|
+
3. **Human at authority boundaries.** Automation supplies evidence, not approval.
|
|
125
|
+
4. **Small by default.** Deeper design and delivery planning appear only when
|
|
126
|
+
risk or coordination requires them.
|
|
127
|
+
5. **Safe to adopt.** Existing instructions and OpenCode settings are preserved.
|
|
128
|
+
|
|
129
|
+
Read [Architecture](docs/architecture.md) for the distribution model,
|
|
130
|
+
[Adoption](docs/adoption.md) for rollout guidance, and
|
|
131
|
+
[Brand](docs/brand.md) for the visual and writing system.
|
|
132
|
+
|
|
133
|
+
## Development
|
|
134
|
+
|
|
135
|
+
```shell
|
|
136
|
+
python -m unittest discover -s tests -v
|
|
137
|
+
python -m compileall -q src tests
|
|
138
|
+
python -m codev_workflow --version
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Optional development checks:
|
|
142
|
+
|
|
143
|
+
```shell
|
|
144
|
+
ruff check .
|
|
145
|
+
ruff format --check .
|
|
146
|
+
mypy
|
|
147
|
+
python -m build
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
CoDev is licensed under BSD-3-Clause.
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
<p align="center">
|
|
2
|
+
<img src="assets/codev-mark.svg" width="96" height="96" alt="CoDev mark">
|
|
3
|
+
</p>
|
|
4
|
+
|
|
5
|
+
<h1 align="center">CoDev</h1>
|
|
6
|
+
|
|
7
|
+
<p align="center"><strong>Human-guided AI software delivery.</strong></p>
|
|
8
|
+
|
|
9
|
+

|
|
10
|
+

|
|
11
|
+
|
|
12
|
+
CoDev installs a small, production-minded collaboration system into any Git
|
|
13
|
+
repository. It helps a developer and AI move through four understandable steps:
|
|
14
|
+
**Understand, Build, Review, and Ship**. It supports bounded three-agent
|
|
15
|
+
execution without turning product development into an unattended coding loop.
|
|
16
|
+
|
|
17
|
+
## Why CoDev
|
|
18
|
+
|
|
19
|
+
- One workflow for solo developers and multi-developer teams.
|
|
20
|
+
- Repository-grounded plans instead of invented APIs or architecture.
|
|
21
|
+
- A bounded builder and an independent, read-only reviewer.
|
|
22
|
+
- Human authority over material decisions, merge, deployment, and rollout.
|
|
23
|
+
- Versioned, conflict-aware installation across existing repositories.
|
|
24
|
+
- No runtime dependency in the software being built.
|
|
25
|
+
|
|
26
|
+
## Quick start
|
|
27
|
+
|
|
28
|
+
CoDev is a Python 3.11+ command-line tool. Target repositories may use any
|
|
29
|
+
language or build system. Install it with an isolated tool manager; `pipx` and
|
|
30
|
+
`uv tool` are the two supported, primary installation methods. Neither adds
|
|
31
|
+
CoDev or its dependencies to a target repository.
|
|
32
|
+
|
|
33
|
+
### Install from PyPI
|
|
34
|
+
|
|
35
|
+
```shell
|
|
36
|
+
pipx install open-codev-workflow
|
|
37
|
+
# or
|
|
38
|
+
uv tool install open-codev-workflow
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Install from a wheel
|
|
42
|
+
|
|
43
|
+
For private, air-gapped, or pre-release distribution, install the supplied
|
|
44
|
+
wheel directly instead of publishing it to a package index:
|
|
45
|
+
|
|
46
|
+
```shell
|
|
47
|
+
pipx install ./dist/open_codev_workflow-0.1.0-py3-none-any.whl
|
|
48
|
+
# or
|
|
49
|
+
uv tool install ./dist/open_codev_workflow-0.1.0-py3-none-any.whl
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Store the wheel with its SHA-256 checksum in a controlled artifact location.
|
|
53
|
+
The development workflow for building a wheel is documented below.
|
|
54
|
+
|
|
55
|
+
### Initialize a repository
|
|
56
|
+
|
|
57
|
+
```shell
|
|
58
|
+
codev init --target ../my-project --platform all
|
|
59
|
+
codev check --target ../my-project
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
To preview or apply a later bundle update:
|
|
63
|
+
|
|
64
|
+
```shell
|
|
65
|
+
codev diff --target ../my-project
|
|
66
|
+
codev update --target ../my-project
|
|
67
|
+
codev remove --target ../my-project --dry-run
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
`init`, `diff`, and `update` preflight the entire operation. A locally modified
|
|
71
|
+
managed file becomes a visible conflict; CoDev never silently replaces it.
|
|
72
|
+
|
|
73
|
+
## What gets installed
|
|
74
|
+
|
|
75
|
+
```text
|
|
76
|
+
my-project/
|
|
77
|
+
├── AGENTS.md # a managed policy block; local text survives
|
|
78
|
+
├── .agents/skills/ # seven lifecycle skills
|
|
79
|
+
├── .opencode/agents/ # orchestrator, builder, reviewer
|
|
80
|
+
├── .opencode/opencode.json # safely merged; existing agent settings survive
|
|
81
|
+
├── docs/ # workflow, prompts, handbooks, cookbook
|
|
82
|
+
├── evals/development-workflow/ # behavioral scenarios
|
|
83
|
+
├── scripts/ # deterministic validators
|
|
84
|
+
└── .codev/lock.json # installed version and source hashes
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Use `--platform codex` to omit the OpenCode adapter. Use `--platform opencode`
|
|
88
|
+
or `--platform all` for the three-agent OpenCode topology. Core skills and
|
|
89
|
+
human/AI workflow references are installed for every platform.
|
|
90
|
+
|
|
91
|
+
## Design principles
|
|
92
|
+
|
|
93
|
+
1. **Local at use time.** Agents read ordinary files in the target repository.
|
|
94
|
+
2. **Central at maintenance time.** This repository is the canonical source.
|
|
95
|
+
3. **Human at authority boundaries.** Automation supplies evidence, not approval.
|
|
96
|
+
4. **Small by default.** Deeper design and delivery planning appear only when
|
|
97
|
+
risk or coordination requires them.
|
|
98
|
+
5. **Safe to adopt.** Existing instructions and OpenCode settings are preserved.
|
|
99
|
+
|
|
100
|
+
Read [Architecture](docs/architecture.md) for the distribution model,
|
|
101
|
+
[Adoption](docs/adoption.md) for rollout guidance, and
|
|
102
|
+
[Brand](docs/brand.md) for the visual and writing system.
|
|
103
|
+
|
|
104
|
+
## Development
|
|
105
|
+
|
|
106
|
+
```shell
|
|
107
|
+
python -m unittest discover -s tests -v
|
|
108
|
+
python -m compileall -q src tests
|
|
109
|
+
python -m codev_workflow --version
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
Optional development checks:
|
|
113
|
+
|
|
114
|
+
```shell
|
|
115
|
+
ruff check .
|
|
116
|
+
ruff format --check .
|
|
117
|
+
mypy
|
|
118
|
+
python -m build
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
CoDev is licensed under BSD-3-Clause.
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
[build-system]
|
|
2
|
+
requires = ["setuptools>=77"]
|
|
3
|
+
build-backend = "setuptools.build_meta"
|
|
4
|
+
|
|
5
|
+
[project]
|
|
6
|
+
name = "open-codev-workflow"
|
|
7
|
+
version = "0.1.0"
|
|
8
|
+
description = "Human-guided AI software delivery for real repositories."
|
|
9
|
+
readme = "README.md"
|
|
10
|
+
requires-python = ">=3.11"
|
|
11
|
+
license = "BSD-3-Clause"
|
|
12
|
+
authors = [{ name = "Martin Urban" }]
|
|
13
|
+
keywords = ["ai", "developer-tools", "software-delivery", "codex", "opencode"]
|
|
14
|
+
classifiers = [
|
|
15
|
+
"Development Status :: 3 - Alpha",
|
|
16
|
+
"Environment :: Console",
|
|
17
|
+
"Intended Audience :: Developers",
|
|
18
|
+
"Operating System :: OS Independent",
|
|
19
|
+
"Programming Language :: Python :: 3",
|
|
20
|
+
"Programming Language :: Python :: 3.11",
|
|
21
|
+
"Programming Language :: Python :: 3.12",
|
|
22
|
+
"Programming Language :: Python :: 3.13",
|
|
23
|
+
"Topic :: Software Development :: Quality Assurance",
|
|
24
|
+
]
|
|
25
|
+
dependencies = []
|
|
26
|
+
|
|
27
|
+
[project.urls]
|
|
28
|
+
Homepage = "https://github.com/urban233/CoDev"
|
|
29
|
+
Repository = "https://github.com/urban233/CoDev"
|
|
30
|
+
Issues = "https://github.com/urban233/CoDev/issues"
|
|
31
|
+
|
|
32
|
+
[project.optional-dependencies]
|
|
33
|
+
dev = [
|
|
34
|
+
"build>=1.2.2",
|
|
35
|
+
"mypy>=1.15",
|
|
36
|
+
"ruff>=0.11",
|
|
37
|
+
"twine>=6.1",
|
|
38
|
+
]
|
|
39
|
+
|
|
40
|
+
[project.scripts]
|
|
41
|
+
codev = "codev_workflow.cli:main"
|
|
42
|
+
|
|
43
|
+
[tool.setuptools]
|
|
44
|
+
package-dir = {"" = "src"}
|
|
45
|
+
include-package-data = true
|
|
46
|
+
|
|
47
|
+
[tool.setuptools.packages.find]
|
|
48
|
+
where = ["src"]
|
|
49
|
+
|
|
50
|
+
[tool.setuptools.package-data]
|
|
51
|
+
codev_workflow = [
|
|
52
|
+
"bundle/AGENTS.md",
|
|
53
|
+
"bundle/.agents/skills/*/SKILL.md",
|
|
54
|
+
"bundle/.agents/skills/*/agents/*.yaml",
|
|
55
|
+
"bundle/.agents/skills/*/assets/*",
|
|
56
|
+
"bundle/.agents/skills/*/references/*",
|
|
57
|
+
"bundle/.agents/skills/*/scripts/*",
|
|
58
|
+
"bundle/.opencode/agents/*.md",
|
|
59
|
+
"bundle/docs/*.md",
|
|
60
|
+
"bundle/docs/for-ai/*.md",
|
|
61
|
+
"bundle/docs/handbooks/*.md",
|
|
62
|
+
"bundle/evals/development-workflow/*.json",
|
|
63
|
+
"bundle/scripts/*.py",
|
|
64
|
+
]
|
|
65
|
+
|
|
66
|
+
[tool.ruff]
|
|
67
|
+
line-length = 88
|
|
68
|
+
target-version = "py311"
|
|
69
|
+
exclude = ["src/codev_workflow/bundle"]
|
|
70
|
+
|
|
71
|
+
[tool.ruff.lint]
|
|
72
|
+
select = ["E", "F", "I", "UP", "B", "SIM"]
|
|
73
|
+
|
|
74
|
+
[tool.mypy]
|
|
75
|
+
python_version = "3.11"
|
|
76
|
+
strict = true
|
|
77
|
+
mypy_path = "src"
|
|
78
|
+
files = ["src/codev_workflow", "tests"]
|
|
79
|
+
exclude = "src/codev_workflow/bundle/"
|
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-change
|
|
3
|
+
description: Pair with a developer to investigate, plan, implement, test, and prepare one bounded code change, bug fix, refactor, or delivery-plan work item. Use when the user wants hands-on AI-assisted coding with frequent checkpoints and human control rather than a long autonomous implementation loop. Ground every plan in the current repository and keep changes small and reviewable.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Build Change
|
|
7
|
+
|
|
8
|
+
Work as an interactive pair engineer. The human owns intent and acceptance; the
|
|
9
|
+
AI investigates, proposes, edits, validates, and explains. Use
|
|
10
|
+
`assets/implementation-plan.template.md` only when work spans sessions, affects
|
|
11
|
+
several components, or needs a reviewed written plan.
|
|
12
|
+
|
|
13
|
+
## 1. Frame the change
|
|
14
|
+
|
|
15
|
+
Read the issue or work item, relevant brief/design/API references, repository
|
|
16
|
+
instructions, and current Git state. Before editing, show a compact inline focus
|
|
17
|
+
card:
|
|
18
|
+
|
|
19
|
+
- **Change:** intended outcome;
|
|
20
|
+
- **Success:** observable acceptance behavior;
|
|
21
|
+
- **Non-goals:** explicit exclusions;
|
|
22
|
+
- **Allowed scope:** expected components or paths;
|
|
23
|
+
- **Validation:** checks that will provide acceptance evidence;
|
|
24
|
+
- **Stop if:** material decisions or conditions that require the human; and
|
|
25
|
+
- **Work style:** `Pair` by default, or `Bounded delegate` only for isolated,
|
|
26
|
+
well-specified, testable, reversible work.
|
|
27
|
+
|
|
28
|
+
For an obvious low-risk change, keep this inline. Do not manufacture planning
|
|
29
|
+
documents. Treat the allowed scope as a drift boundary: surface a needed
|
|
30
|
+
expansion before editing outside it.
|
|
31
|
+
|
|
32
|
+
## 2. Ground the plan
|
|
33
|
+
|
|
34
|
+
Inspect actual files, symbols, tests, build commands, conventions, ownership,
|
|
35
|
+
and recent related changes before proposing edits. Identify mismatches between
|
|
36
|
+
the request and repository reality.
|
|
37
|
+
|
|
38
|
+
A new request does not silently supersede an accepted brief, design, API, or
|
|
39
|
+
repository policy. When they conflict, stop, show the exact conflict, recommend
|
|
40
|
+
the safest resolution, and obtain an explicit human decision in the owning
|
|
41
|
+
artifact before implementation.
|
|
42
|
+
|
|
43
|
+
Propose the smallest coherent change, expected files, test approach, risks, and
|
|
44
|
+
any intentional follow-up. Obtain a human decision before editing when the plan
|
|
45
|
+
introduces or changes an API, data model, dependency, security behavior,
|
|
46
|
+
architecture, user-visible scope, or destructive operation. Otherwise announce
|
|
47
|
+
the plan and proceed interactively.
|
|
48
|
+
|
|
49
|
+
## 3. Implement a small change
|
|
50
|
+
|
|
51
|
+
Prefer one review purpose. As a soft warning, reconsider the slice when it
|
|
52
|
+
exceeds roughly 400 non-generated changed lines or eight files; generated code,
|
|
53
|
+
mechanical migrations, and tightly coupled tests may justify more. Split only
|
|
54
|
+
when each part remains buildable and useful.
|
|
55
|
+
|
|
56
|
+
Reuse repository patterns. Add or update tests with the behavior. Do not weaken
|
|
57
|
+
tests, invent missing APIs, silently expand scope, or edit accepted product and
|
|
58
|
+
design decisions to make implementation easier.
|
|
59
|
+
|
|
60
|
+
Share concise progress at meaningful boundaries. Do not run unattended retry
|
|
61
|
+
loops. After two failed attempts with the same root cause, stop, present the
|
|
62
|
+
evidence, and agree on the next approach with the human.
|
|
63
|
+
|
|
64
|
+
## 4. Validate and inspect
|
|
65
|
+
|
|
66
|
+
Run the repository's formatter, static checks, affected tests, and proportionate
|
|
67
|
+
broader tests. Report exact commands, outcomes, and any checks that could not run.
|
|
68
|
+
|
|
69
|
+
Review the complete diff for accidental files, debug code, weakened assertions,
|
|
70
|
+
security or compatibility regressions, unnecessary complexity, and stale docs.
|
|
71
|
+
Map important acceptance criteria to evidence; formal requirement IDs are only
|
|
72
|
+
needed when policy or risk requires them.
|
|
73
|
+
|
|
74
|
+
## 5. Prepare review
|
|
75
|
+
|
|
76
|
+
Return a compact evidence receipt:
|
|
77
|
+
|
|
78
|
+
- **Delivered:** outcome and observable behavior;
|
|
79
|
+
- **Changed:** files and components;
|
|
80
|
+
- **Validation actually run:** exact commands and outcomes;
|
|
81
|
+
- **Acceptance evidence:** criteria mapped to evidence;
|
|
82
|
+
- **Scope deviations:** none, or accepted deviations;
|
|
83
|
+
- **Known limitations:** risks and follow-up work; and
|
|
84
|
+
- **Review state:** independent review status and rollout implications.
|
|
85
|
+
|
|
86
|
+
For normal or higher-risk work, invoke `review-change` in a fresh context when
|
|
87
|
+
available. The implementing AI never declares its own work approved. The human
|
|
88
|
+
must inspect the diff and explicitly authorize commit, merge, publication, or
|
|
89
|
+
release actions according to repository policy.
|
|
90
|
+
|
|
91
|
+
## Stop conditions
|
|
92
|
+
|
|
93
|
+
Stop and ask for one precise decision when required behavior conflicts, a
|
|
94
|
+
material design choice is missing, the repository is unexpectedly stale,
|
|
95
|
+
permissions or a dependency are unavailable, concurrent changes collide, or
|
|
96
|
+
safe validation cannot be produced. Include evidence and safe alternatives.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# [Work item] Implementation Plan
|
|
2
|
+
|
|
3
|
+
**Status:** Draft
|
|
4
|
+
**Owner:** [developer]
|
|
5
|
+
**Reviewer:** [independent reviewer]
|
|
6
|
+
**Risk:** [low/normal/high/critical]
|
|
7
|
+
**Base commit:** [Git commit]
|
|
8
|
+
**Issue/work item:** [link or ID]
|
|
9
|
+
**Brief/design/API:** [links or Not needed]
|
|
10
|
+
|
|
11
|
+
## Focus card
|
|
12
|
+
|
|
13
|
+
- **Change:** [Intended outcome]
|
|
14
|
+
- **Success:** [Observable acceptance behavior]
|
|
15
|
+
- **Non-goals:** [Explicit exclusions]
|
|
16
|
+
- **Allowed scope:** [Expected components or paths]
|
|
17
|
+
- **Validation:** [Checks that provide acceptance evidence]
|
|
18
|
+
- **Stop if:** [Material decision or condition requiring the human]
|
|
19
|
+
- **Work style:** [Pair / Bounded delegate with reason]
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
## Repository evidence
|
|
23
|
+
|
|
24
|
+
- `[path/symbol]`: [verified fact]
|
|
25
|
+
|
|
26
|
+
## Proposed change
|
|
27
|
+
|
|
28
|
+
1. [Small repository-grounded step and test]
|
|
29
|
+
|
|
30
|
+
## Validation
|
|
31
|
+
|
|
32
|
+
- `[exact command]` -> [expected evidence]
|
|
33
|
+
|
|
34
|
+
## Risks and rollout
|
|
35
|
+
|
|
36
|
+
- [Risk, containment, feature flag, compatibility, or rollback]
|
|
37
|
+
|
|
38
|
+
## Decisions needed
|
|
39
|
+
|
|
40
|
+
- [None, or one material decision with recommendation]
|
|
41
|
+
|
|
42
|
+
## Completion evidence
|
|
43
|
+
|
|
44
|
+
- **Delivered:** [Outcome and observable behavior]
|
|
45
|
+
- **Changed:** [Files and components]
|
|
46
|
+
- **Head commit/snapshot:** [Value]
|
|
47
|
+
- **Validation actually run:** [Exact commands and outcomes]
|
|
48
|
+
- **Acceptance evidence:** [Criterion -> evidence]
|
|
49
|
+
- **Scope deviations:** [None or accepted deviations]
|
|
50
|
+
- **Known limitations:** [None, risks, or follow-up links]
|
|
51
|
+
- **Review state:** [Not reviewed / review result and rollout implications]
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: define-product
|
|
3
|
+
description: Turn a software idea, product proposal, or feature request into a clear product or feature brief and select the lightest safe workflow. Use when a developer needs help clarifying users, outcomes, scope, success measures, constraints, assumptions, or whether work is a quick change, feature, or product. Do not design the technical solution or create implementation tasks.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Define Product
|
|
7
|
+
|
|
8
|
+
Guide the developer from an idea to an accepted brief. Explain the purpose of
|
|
9
|
+
each step in plain language and keep the conversation focused on product intent.
|
|
10
|
+
|
|
11
|
+
Use `assets/brief.template.md` when a durable brief is useful.
|
|
12
|
+
|
|
13
|
+
## 1. Choose the workflow size
|
|
14
|
+
|
|
15
|
+
Recommend one path and explain why:
|
|
16
|
+
|
|
17
|
+
- **Quick change:** local, reversible, low-risk work with obvious acceptance.
|
|
18
|
+
Hand off directly to `build-change`; an issue is enough.
|
|
19
|
+
- **Feature:** a user-visible or cross-file outcome with limited architectural
|
|
20
|
+
impact. Create a feature brief, then use `design-solution` only if needed.
|
|
21
|
+
- **Product:** a new product, major capability, cross-team effort, migration, or
|
|
22
|
+
high-risk change. Create a product brief and continue through all lifecycle
|
|
23
|
+
skills.
|
|
24
|
+
|
|
25
|
+
Risk overrides size. Security, privacy, permissions, public APIs, persistent
|
|
26
|
+
data, billing, compliance, and destructive operations require at least the
|
|
27
|
+
feature path and an explicit design review.
|
|
28
|
+
|
|
29
|
+
## 2. Discover intent
|
|
30
|
+
|
|
31
|
+
Read supplied material completely. Inspect existing product documentation when
|
|
32
|
+
available. Establish:
|
|
33
|
+
|
|
34
|
+
- target users and their problem;
|
|
35
|
+
- desired outcome and measurable evidence of success;
|
|
36
|
+
- essential scenarios and failure expectations;
|
|
37
|
+
- first-release scope and explicit non-goals;
|
|
38
|
+
- fixed business, legal, safety, accessibility, platform, cost, and timing
|
|
39
|
+
constraints; and
|
|
40
|
+
- assumptions that need evidence before committing to the full solution.
|
|
41
|
+
|
|
42
|
+
Never fabricate a numerical target. When no baseline or accountable target
|
|
43
|
+
exists, name the measure, define how to establish its baseline, and leave target
|
|
44
|
+
selection as an explicit product decision before accepting the brief.
|
|
45
|
+
|
|
46
|
+
Ask at most four related questions at once. Recommend an answer when evidence
|
|
47
|
+
supports one. Do not ask for repository facts that can be inspected later.
|
|
48
|
+
|
|
49
|
+
## 3. Shape the smallest useful release
|
|
50
|
+
|
|
51
|
+
Prefer one end-to-end outcome over a catalogue of components. Separate:
|
|
52
|
+
|
|
53
|
+
- **Now:** required to demonstrate value;
|
|
54
|
+
- **Next:** plausible follow-up, not committed;
|
|
55
|
+
- **Not planned:** deliberately excluded.
|
|
56
|
+
|
|
57
|
+
If the central user or outcome is still unknown, propose a bounded discovery
|
|
58
|
+
experiment rather than pretending the product is ready for engineering.
|
|
59
|
+
|
|
60
|
+
## 4. Save and accept the brief
|
|
61
|
+
|
|
62
|
+
For a feature, write `docs/features/<slug>/brief.md`. For a product, write
|
|
63
|
+
`docs/product/<slug>/brief.md`. Adapt to an existing repository convention
|
|
64
|
+
instead of creating a parallel structure.
|
|
65
|
+
|
|
66
|
+
Set `Status: Draft` until the human confirms the outcome, scope, non-goals, and
|
|
67
|
+
success measures. Then set `Status: Accepted`. Git history is the revision
|
|
68
|
+
record; do not invent a second revision scheme.
|
|
69
|
+
|
|
70
|
+
## Handoff
|
|
71
|
+
|
|
72
|
+
Recommend the next action:
|
|
73
|
+
|
|
74
|
+
- Quick change -> `build-change`
|
|
75
|
+
- Feature with no material design choice -> `plan-delivery` or `build-change`
|
|
76
|
+
- Feature with architectural/risk decisions -> `design-solution`
|
|
77
|
+
- Product -> `design-solution`
|
|
78
|
+
|
|
79
|
+
Never convert the brief into architecture, staffing, or code-level tasks.
|