Development

Implement changes, investigate defects, and review results using your project's technologies, rules, and verification tools. No task tracker or record taxonomy is required.

The package installs three workflow recipes. A recipe is a Markdown method with a Goal, Steps, and Completion, reached through the use-workflow Skill from Workflow Support.

• Package ID: development
• Depends on: Workflow Support
• Needed by: Task Coordination, Development Toolkit
• Startup visibility: This package adds no entries to startup indexes. Its required Workflow Support package adds the use-workflow entry in Skills. Recipes open when a task selects them.

These counts describe this package's own entries when their parent routes expose them in Entries and are read. Required packages add their own entries. Linked files stay on demand unless selected or required.

Install

From your installed Open Forge workspace, preview the package and its required packages:

open-forge extension install development --dry-run

Review the plan. Then apply it:

open-forge extension install development

The CLI installs required packages from the same catalogue. See the Extension guide for scripts using --automatic, updates, removal, or a local source.

Why it exists

A capable agent can already write code. These three methods change how it works where mistakes are expensive: implementing in a verified slice, diagnosing before repairing so a fix follows a cause, and reviewing with evidence instead of opinion.

Review stays in this package rather than getting its own, because a separate package for one closely related workflow would add a boundary without adding a real choice.

What it installs

.agents/skills/use-workflow/references/development/
  _development.md       <- recipe scope entrypoint
  development.md        <- implement and verify an accepted change
  debugging.md          <- reproduce, explain, and fix a defect
  review.md             <- return prioritized, evidence-backed findings

What each file is for

development.md

Goal: deliver one accepted change that fits the current system, with evidence matched to its behavior and risk.

Step	What the recipe asks for
1. Establish the boundary	Carries forward the accepted outcome, scope, non-goals, authorization, and completion evidence. Asks only for a missing consequential decision or permission.
2. Resolve blocking design choices	Checks whether an unsettled product, experience, or architecture question could change the work.
3. Inspect the actual system	Uses your project's tools, commands, and conventions rather than familiar defaults.
4. Define a coherent slice	States the behavior change, what must be preserved, and how it will be verified. Uses test-first ordering when it helps.
5. Implement and check	Makes the smallest change that fits, then runs the narrowest distinguishing checks.
6. Diagnose before repairing	Classifies a failure (implementation, expectation, setup, environment, unrelated) before changing anything. Must not weaken a valid expectation to get a pass.
7. Improve and verify	Refactors when the gain justifies it, then reruns affected and neighboring checks.
8. Close the boundary	Reports pre-existing failures, residual risk, and gaps.

Completion doesn't imply permission to publish or integrate.

debugging.md

Goal: connect an observed symptom to an evidenced cause and, when changes are authorized, a minimal verified fix.

The steps: capture the discrepancy, reproduce reliably, locate where behavior first diverges, distinguish competing hypotheses with the cheapest separating check, explain the cause, correct it when authorized, and verify the changed state. An inconclusive diagnosis is a valid result when the evidence doesn't establish a cause. The recipe then asks the agent to report the checks performed, the remaining hypotheses, and the next discriminating check, rather than claiming a cause.

review.md

Goal: actionable findings in priority order, or a clear no-findings result, without claiming more than the evidence supports. Review is read-only by default.

The recipe has the agent first record exactly what it's reviewing: the baseline, the changed and untracked files, and the claimed evidence. It reads enough context, then traces consequential failures (correctness, security, data loss, regressions, compatibility, broken contracts) before style. It checks changes to durable knowledge and challenges each finding against counterevidence. Each material finding comes with a stable ID, priority, location, evidence, consequence, and smallest credible correction.

How to use it

Use the development workflow for this change. Follow the repository conventions and verify the final state.

Debug why the export job times out. Don't change anything until we know the cause.

Review this branch against main.

Good to know

• Development depends only on Workflow Support. It doesn't install Planning, Project Documents, Observations and Handoffs, or an agent hierarchy.
• The three recipes stay separate methods within the shared selector Skill. They may use several configured Skills and tools, and they don't replace your harness's native behavior.

Next: Install this package, or update and remove Extensions.