With proper workflows and setup, Claude Code has been amazing for me to get a project 80% complete. Where I have struggled (not just with Claude Code, but in general) is to complete a project. I think I did fairly well with this project: https://github.com/schuettc/plex-collection-creator with a deliberate effort to publish before I had every single thing I might want completed.

schuettc (@subaud.io)
Winter break (is that really a thing?) means fun side projects. I* wrote a little project that will help automatically create collections of movies/TV shows on my Plex. The Plex documentation was very well done and the OAuth setup was quite reasonable. *Claude https://github.com/schuettc/plex-collection-creator
Bluesky Social

One of the things that helped me was a workflow I have been working on. Very frequently, while working on a project, I notice a problem, ask Claude to fix it, and now I've lost the thread. I've polluted the context for the task I was working on and distracted myself.

That experience led to this plugin. It enforces a structured workflow from idea to completion: JSON-based backlog tracking, specialized agents for different phases, and quality gates before shipping. It allows me to capture the idea while it is fresh in my mind without disrupting my current work (I use a separate terminal for this). Then, when I'm ready to work on it, I have all of my notes and can start the process fresh and focused.

How the Plugin Works

The plugin has three layers. Commands are explicit actions: /feature-capture to add an idea, /feature-plan to start building, /feature-ship to verify and complete. You invoke these at deliberate transition points in the feature lifecycle.

Agents are specialized experts dispatched during commands. When you run /feature-plan, a project-manager agent analyzes requirements. Based on the feature type, architecture agents (api-designer, frontend-architect, integration-designer) design the implementation. When you run /feature-ship, security-reviewer and qa-engineer verify quality before marking complete.

Skills run in the background without explicit invocation. When you're working on code for an in-progress feature, the feature-context skill loads your requirements automatically. When you request changes that fall outside defined scope, scope-guard flags it. When you ask "what's next?", status-dashboard answers without a specific command. This keeps the interface clean while adding intelligence where it matters.

The Workflow

Capture Ideas Quickly

/feature-capture

The command asks 7 focused questions: type, name, problem statement, priority, effort, impact, and affected areas. This takes about 5 minutes and creates an entry in docs/planning/backlog.json.

The key principle: capture the what and why, not the how. Describe the problem or opportunity, not the solution. Implementation details come during /feature-plan when you have proper context for architectural decisions.

Plan Thoroughly

/feature-plan dark-mode-toggle

This triggers a multi-phase planning workflow:

  1. Requirements analysis - The project-manager agent creates user stories, acceptance criteria, and success metrics
  2. Architecture design - Based on feature type, appropriate agents are dispatched:
    • Backend-only → api-designer
    • Frontend-only → ux-optimizer + frontend-architect
    • Full-stack → api-designer + frontend-architect + integration-designer
  3. Implementation plan - Actionable steps written to docs/planning/features/[id]/plan.md

For Medium and Large effort items, this could take 15+ minutes. Low effort items should complete faster with streamlined analysis.

Build with Context

During implementation, skills work in the background:

  • When you start working, feature-context loads your requirements and design
  • When you ask for changes outside scope, scope-guard flags it
  • When you finish tasks, progress-tracker offers to update plan.md

You stay focused on the current feature with the relevant context always available. Key insight: the skills add intelligence without adding commands. You don't invoke them—they activate when relevant.

Complete with Quality Gates

/feature-ship dark-mode-toggle

Before marking a feature done, the plugin runs quality checks:

  1. Security review - Scans for OWASP Top 10 vulnerabilities and CVEs. Blocks completion on Critical/High issues.
  2. QA validation - Verifies test coverage and acceptance criteria
  3. Final verification - Runs tests and build

Only after passing these gates does the backlog status change to "completed". Key insight: quality checks happen at shipping time, not review time. You can't forget to run them.

Effort-Aware Scaling

A bug fix shouldn't require the same ceremony as a major feature. The plugin scales based on the effort level you set during capture.

When I captured a typo fix as "Low effort," the /feature-ship command ran npm audit and tests—two minutes, no agent reviews. When I shipped an authentication overhaul marked as "Large effort," security-reviewer and qa-engineer ran full scans. The scaling happens automatically.

Low effort items (under 8 hours) get brief requirements and focused agent output during planning, with quick verification at shipping time. Medium effort items (1-2 weeks) receive the standard workflow with full agent analysis and complete security and QA validation. Large effort items (2+ weeks) get comprehensive analysis with detailed documentation—though shipping validation is the same as Medium since it's already thorough.

Key insight: the agents self-regulate their output depth based on effort context. You don't configure this. A Low effort item gets essential analysis. A Large effort item gets comprehensive documentation. The plugin decides based on the metadata you provided during capture.

The JSON Backlog

All features are tracked in a single JSON file:

{
  "version": "1.0.0",
  "lastUpdated": "2026-01-01T12:00:00Z",
  "summary": {
    "total": 3,
    "byStatus": { "backlog": 1, "in-progress": 1, "completed": 1 },
    "byPriority": { "P0": 1, "P1": 1, "P2": 1 }
  },
  "items": [
    {
      "id": "dark-mode-toggle",
      "name": "Dark Mode Toggle",
      "type": "Feature",
      "priority": "P1",
      "status": "in-progress",
      "createdAt": "2026-01-01T10:00:00Z",
      "startedAt": "2026-01-01T14:00:00Z",
      "implementationPlan": "docs/planning/features/dark-mode-toggle/plan.md"
    }
  ]
}

Instead of using Markdown to track the features, I am using JSON. I have found JSON to work better with Claude for a few reasons. Instead of having a completely wide open file format, JSON's structure encourages Claude to adhere to some of the standards in use. If it sees that every item contains certain fields, it is much more likely to use those fields in future items. Additionally, it's easier for Claude to edit. Instead of having to completely renumber each item, Claude can just insert a P1 item into the P1 list.

This JSON file becomes the source of truth for the commands in this plugin. The rest of the files are created around this in the docs/planning/ folder.

Status is a field, not a folder. Features don't move between directories. Status changes update the JSON field. New files related to the item are included in the folder.

Files never move. Once created at docs/planning/features/[id]/, the directory stays there permanently—a record of what was built, why, and how.

Skills vs Commands

The distinction matters for usability.

Commands require explicit invocation. You decide when to add to backlog, start implementation, or mark complete. These are deliberate transitions in the feature lifecycle.

Skills activate based on context. When you're working on code for an in-progress feature, the context loads automatically. When you mention "what's next?", status appears without a specific command. This keeps the interface clean while adding intelligence.

The progress-tracker skill is the exception—it asks before modifying plan.md because writes should require consent.

Preventing Scope Creep

Scope creep happens when changes are added without conscious decision. The plugin addresses this at multiple points:

Explicit scope definition. During /feature-plan, requirements list acceptance criteria and boundaries.

Scope-guard skill. When you request changes during implementation, the skill compares against requirements. If it's outside scope:

This seems outside the current feature scope.

Current Feature: Dark Mode Toggle
Your Request: Add color customization

Options:
1. Include it (expands effort)
2. Add to backlog (track separately)
3. Skip for now (stay focused)

Visible progress. The plan.md tracks completed and remaining tasks. Additions become visible.

The goal isn't to prevent all changes—it's to make scope expansion a conscious choice rather than accidental drift.

Plugin Structure

feature-workflow/
├── .claude-plugin/
│   └── plugin.json
├── commands/
│   ├── feature-capture.md
│   ├── feature-plan.md
│   └── feature-ship.md
├── agents/
│   ├── project-manager.md
│   ├── api-designer.md
│   ├── frontend-architect.md
│   ├── integration-designer.md
│   ├── ux-optimizer.md
│   ├── system-designer.md
│   ├── test-generator.md
│   ├── documentation-agent.md
│   ├── security-reviewer.md
│   ├── qa-engineer.md
│   └── code-archaeologist.md
├── skills/
│   ├── backlog-awareness/
│   ├── feature-context/
│   ├── progress-tracker/
│   ├── status-dashboard/
│   └── scope-guard/
└── README.md

Getting Started

Install from GitHub

# Add the marketplace
/plugin marketplace add git@github.com:schuettc/claude-code-plugins.git

# Install the plugin
/plugin install feature-workflow@schuettc-claude-code-plugins

Results

Adding this to my standard workflow has been extremely helpful to me. It has allowed me to fix small, but annoying rough edges more frequently and with more confidence. Just like we need SKILLs, Commands, Agents, and planning to make Claude Code better, I needed a structure for my thoughts and workflow. This is very much still a work in progress so be sure to keep your plugin updated in Claude Code.

Source

The source is available at github.com/schuettc/claude-code-plugins.