develop
starsforks
How to install develop?
borda/ai-rig/develop
$npx -y skills add Borda/AI-Rig --skill developMinimal codex-native develop loop. Use for implementation tasks with linear plan-build-verify flow and measurable quality gates.
SKILL.md
| 1 | # Develop |
| 2 | |
| 3 | Run linear implementation with strict gates. |
| 4 | |
| 5 | ## Input Schema |
| 6 | |
| 7 | ```json |
| 8 | { |
| 9 | "goal": "required implementation objective", |
| 10 | "mode": "feature|fix|refactor|config|spike", |
| 11 | "constraints": [ |
| 12 | "optional constraints" |
| 13 | ], |
| 14 | "done_when": "required acceptance statement" |
| 15 | } |
| 16 | ``` |
| 17 | |
| 18 | ## Workflow (Exact Commands) |
| 19 | |
| 20 | ### 01: Create run directory |
| 21 | |
| 22 | Run `python PLUGIN_ROOT/shared/create_run.py --skill develop` once. Retain its single printed path as |
| 23 | `<run-directory>` and substitute that literal path into every later artifact path and helper argument. Never store or |
| 24 | reuse the path through a shell variable; shell variables do not persist across tool calls. |
| 25 | |
| 26 | ### 02: Record baseline diff and branch |
| 27 | |
| 28 | Run `git rev-parse --abbrev-ref HEAD` as an argv command and write stdout to `<run-directory>/branch.txt`. |
| 29 | |
| 30 | Inspect `python PLUGIN_ROOT/shared/collect_diff.py --help`; collect `working-tree` into `<run-directory>/baseline`. |
| 31 | |
| 32 | ### 03: Route the change type and define ownership |
| 33 | |
| 34 | Modes: |
| 35 | |
| 36 | - `feature`: define public behavior, acceptance checks, docs impact, and tests before implementation. |
| 37 | - `fix`: reproduce or cite the failing behavior before editing. |
| 38 | - `refactor`: preserve behavior with characterization tests or an equivalent safety net. |
| 39 | - `config`: inventory references and calibration/routing impact before editing. |
| 40 | - `spike`: read-only or disposable probe; do not present as completed implementation. |
| 41 | |
| 42 | Define narrowest reversible change, owners, acceptance. For 3+ steps/design tradeoffs, update plan before edit. |
| 43 | |
| 44 | ### 04: Run the anti-rationalization gate before editing |
| 45 | |
| 46 | - Existing code and tests for the target surface have been read. |
| 47 | - Failure mode or new behavior is captured by a failing doctest, pytest, or explicit acceptance check. |
| 48 | - Coding changes have a project coding-principles plan from the applicable `AGENTS.md` layers: simple/readable/reproducible structure first, short reusable units without low-value argument-remapping wrappers, guard clauses or early `return`/`yield`/`continue` for invalid or terminal cases, project docstring-style detection, concise purpose docstrings, and inline comments only for non-trivial implementation blocks. |
| 49 | - `feature` mode has a feature demo contract before production edits: |
| 50 | - simple public API: inline doctest or focused pytest that shows the intended call and result |
| 51 | - multi-step behavior: minimal example or pytest exercising the user-visible workflow end to end |
| 52 | - the demo must be automatically executable and must fail against current code for the intended missing behavior |
| 53 | - if the demo passes before implementation, stop and re-scope; do not silently proceed unless the user explicitly overrides the gate |
| 54 | - Review the demo contract for goal alignment, API shape, missing scenarios, and automatic verifiability before implementation. |
| 55 | - If the task starts from a symptom, failing test, failing CI, flaky behavior, regression, tool/environment error, or unexplained metric shift, run `investigate` first or document equivalent root-cause evidence before editing. |
| 56 | - Root-cause evidence includes the claim, supporting logs/code, a falsification check, and at least one rejected alternative. A workaround-only change is a temporary mitigation, not completion, unless explicitly requested by the user. |
| 57 | - Behavior-preserving refactors have characterization tests or an equivalent current-behavior safety net. |
| 58 | - The next edit is the smallest reversible step, not a speculative refactor. |
| 59 | |
| 60 | ### 05: Implement minimal change |
| 61 | |
| 62 | While implementing, keep the code understandable from the code itself: |
| 63 | |
| 64 | - Apply the consolidated project coding principles from the applicable `AGENTS.md` layers. |
| 65 | - Refactor long, dense, or deeply nested blocks into named helpers/classes before adding explanatory text. |
| 66 | - Avoid tiny rarely used helpers that only remap arguments; keep the logic inline, use a local helper, or use `functools.partial` when only binding arguments. |
| 67 | - Match the project's configured or established docstring style, and keep function/class purpose in docstrings rather than comments directly above definitions. |
| 68 | - Refactor instead of writing long docstrings or comments when a block needs a long explanation to be understandable. |
| 69 | |
| 70 | ### 06: Orchestrate specialists when the change crosses a domain boundary |
| 71 | |
| 72 | Apply `../../shared/specialist-orchestration.md`. Stay single-agent for narrow implementation that fits in one to three files and one domain. Use specialist orchestration when the task crosses domains, benefits from independent verification, or can split into parallel context packs. |
| 73 | |
| 74 | Before spawning or substituting specialists, write `<run-directory>/specialist-plan.md` with one row per planned pass: |
| 75 | |
| 76 | | role | trigger | context pack | expected output | mode | |
| 77 | | --- | --- | --- | --- | --- | |
| 78 | |
| 79 | Required orchestration patterns: |
| 80 | |
| 81 | - public API or architecture: `solutio |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
