About this skill

Problem

Requirement discussions, implementation notes, and final specs often end up scattered, making progress hard to trace and stage recovery unclear. Proflow splits work into brainstorming, planning, execution, and documentation, then enforces a consistent directory layout, unique requirement IDs, standardized filenames, and stage markers. It does not replace coding; it adds a checkable workflow state machine.

How It Works

proflow full advances through brainstorm → plan → execute → spec, checking .opencode/status/proflow/*.done before each step and skipping completed stages. Outputs are archived under docs/:

Brainstorm: docs/brainstorm/cr-{id}-brainstorm-{YYYYMMDD}.md
Plan: docs/plans/cr-{id}-execution-plan-{YYYYMMDD}.md
Execution: docs/execute/cr-{id}-execute-record-{YYYYMMDD}.md
Specs: PRD, architecture, API, and database documentation

Requirement IDs can be supplied via --id or generated from hhmmss, with deduplication through scripts/id_manager.py. status shows stage state, while reset [stage] rolls back a stage. Tasks classified as fix or small changes skip the full flow and proceed directly to code changes; table structure, API protocol, or core architecture changes are treated as large features.

Boundaries

This workflow suits features that need traceability, review, and recovery, and it depends on the openspec and superpowers prerequisite skills. Status files should not be deleted manually; docs/superpowers/ and nonstandard filenames are not accepted. One-off scripts or minor copy edits do not need the full pipeline.

Screenshots

Use Cases

Starting a cross-API and database feature, then archiving boundaries, execution plans, and implementation records by stage.
Preparing for a feature review by generating brainstorming, planning, and execution notes under a consistent naming scheme.
Reworking a failed stage by resetting only that stage marker while preserving logs and avoiding overwriting existing artifacts.
Writing PRD, architecture, API, and database specs for medium-size features into docs/spec instead of scattering files.

Best For

Backend engineers implementing features who need consistent archives for APIs, database changes, and execution records.
Product engineers preparing feature reviews who need organized brainstorming, plans, and execution evidence.
Team leads maintaining multi-module features who need stage status that can be inspected, reset, and re-run.
Engineering staff producing specifications who need PRD, architecture, API, and database docs with standardized names.