{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihrgl5foasd7b6w5tipkxdvy5qio5btij7zncvyzjyb5f46bbu2z4",
    "uri": "at://did:plc:6u4awktizhivwgqxl5j67h4k/app.bsky.feed.post/3mbmqbohlbym2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidbs74kxnd4e4tkgecraksldqvakbn5mkusaffeyonfyhsttg2pve"
    },
    "mimeType": "image/webp",
    "size": 38742
  },
  "description": "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.\n\n\nOne of the things that helped me was a workflow I have been working on. Very frequently, while working on a project,",
  "path": "/building-a-harness-for-myself/",
  "publishedAt": "2026-01-04T20:00:38.000Z",
  "site": "https://www.subaud.io",
  "tags": [
    "https://github.com/schuettc/plex-collection-creator",
    "this plugin",
    "github.com/schuettc/claude-code-plugins"
  ],
  "textContent": "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.\n\nOne 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.\n\nThat 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.\n\n## How the Plugin Works\n\nThe 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.\n\nAgents 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.\n\nSkills 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.\n\n## The Workflow\n\n### Capture Ideas Quickly\n\n\n    /feature-capture\n\n\nThe 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`.\n\nThe 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.\n\n### Plan Thoroughly\n\n\n    /feature-plan dark-mode-toggle\n\n\nThis triggers a multi-phase planning workflow:\n\n  1. **Requirements analysis** - The project-manager agent creates user stories, acceptance criteria, and success metrics\n  2. **Architecture design** - Based on feature type, appropriate agents are dispatched:\n     * Backend-only → api-designer\n     * Frontend-only → ux-optimizer + frontend-architect\n     * Full-stack → api-designer + frontend-architect + integration-designer\n  3. **Implementation plan** - Actionable steps written to `docs/planning/features/[id]/plan.md`\n\n\n\nFor Medium and Large effort items, this could take 15+ minutes. Low effort items should complete faster with streamlined analysis.\n\n### Build with Context\n\nDuring implementation, skills work in the background:\n\n  * When you start working, `feature-context` loads your requirements and design\n  * When you ask for changes outside scope, `scope-guard` flags it\n  * When you finish tasks, `progress-tracker` offers to update plan.md\n\n\n\nYou 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.\n\n### Complete with Quality Gates\n\n\n    /feature-ship dark-mode-toggle\n\n\nBefore marking a feature done, the plugin runs quality checks:\n\n  1. **Security review** - Scans for OWASP Top 10 vulnerabilities and CVEs. Blocks completion on Critical/High issues.\n  2. **QA validation** - Verifies test coverage and acceptance criteria\n  3. **Final verification** - Runs tests and build\n\n\n\nOnly 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.\n\n## Effort-Aware Scaling\n\nA bug fix shouldn't require the same ceremony as a major feature. The plugin scales based on the effort level you set during capture.\n\nWhen 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.\n\nLow 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.\n\nKey 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.\n\n## The JSON Backlog\n\nAll features are tracked in a single JSON file:\n\n\n    {\n      \"version\": \"1.0.0\",\n      \"lastUpdated\": \"2026-01-01T12:00:00Z\",\n      \"summary\": {\n        \"total\": 3,\n        \"byStatus\": { \"backlog\": 1, \"in-progress\": 1, \"completed\": 1 },\n        \"byPriority\": { \"P0\": 1, \"P1\": 1, \"P2\": 1 }\n      },\n      \"items\": [\n        {\n          \"id\": \"dark-mode-toggle\",\n          \"name\": \"Dark Mode Toggle\",\n          \"type\": \"Feature\",\n          \"priority\": \"P1\",\n          \"status\": \"in-progress\",\n          \"createdAt\": \"2026-01-01T10:00:00Z\",\n          \"startedAt\": \"2026-01-01T14:00:00Z\",\n          \"implementationPlan\": \"docs/planning/features/dark-mode-toggle/plan.md\"\n        }\n      ]\n    }\n\n\nInstead 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.\n\nThis 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.\n\n**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.\n\n**Files never move.** Once created at `docs/planning/features/[id]/`, the directory stays there permanently—a record of what was built, why, and how.\n\n## Skills vs Commands\n\nThe distinction matters for usability.\n\n**Commands** require explicit invocation. You decide when to add to backlog, start implementation, or mark complete. These are deliberate transitions in the feature lifecycle.\n\n**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.\n\nThe `progress-tracker` skill is the exception—it asks before modifying plan.md because writes should require consent.\n\n## Preventing Scope Creep\n\nScope creep happens when changes are added without conscious decision. The plugin addresses this at multiple points:\n\n**Explicit scope definition.** During `/feature-plan`, requirements list acceptance criteria and boundaries.\n\n**Scope-guard skill.** When you request changes during implementation, the skill compares against requirements. If it's outside scope:\n\n\n    This seems outside the current feature scope.\n\n    Current Feature: Dark Mode Toggle\n    Your Request: Add color customization\n\n    Options:\n    1. Include it (expands effort)\n    2. Add to backlog (track separately)\n    3. Skip for now (stay focused)\n\n\n**Visible progress.** The plan.md tracks completed and remaining tasks. Additions become visible.\n\nThe goal isn't to prevent all changes—it's to make scope expansion a conscious choice rather than accidental drift.\n\n## Plugin Structure\n\n\n    feature-workflow/\n    ├── .claude-plugin/\n    │   └── plugin.json\n    ├── commands/\n    │   ├── feature-capture.md\n    │   ├── feature-plan.md\n    │   └── feature-ship.md\n    ├── agents/\n    │   ├── project-manager.md\n    │   ├── api-designer.md\n    │   ├── frontend-architect.md\n    │   ├── integration-designer.md\n    │   ├── ux-optimizer.md\n    │   ├── system-designer.md\n    │   ├── test-generator.md\n    │   ├── documentation-agent.md\n    │   ├── security-reviewer.md\n    │   ├── qa-engineer.md\n    │   └── code-archaeologist.md\n    ├── skills/\n    │   ├── backlog-awareness/\n    │   ├── feature-context/\n    │   ├── progress-tracker/\n    │   ├── status-dashboard/\n    │   └── scope-guard/\n    └── README.md\n\n\n## Getting Started\n\n### Install from GitHub\n\n\n    # Add the marketplace\n    /plugin marketplace add git@github.com:schuettc/claude-code-plugins.git\n\n    # Install the plugin\n    /plugin install feature-workflow@schuettc-claude-code-plugins\n\n\n## Results\n\nAdding 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.\n\n## Source\n\nThe source is available at github.com/schuettc/claude-code-plugins.",
  "title": "Building a Harness for... Myself",
  "updatedAt": "2026-04-03T16:49:09.604Z"
}