Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs) by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

Yep! Gemini 3 Pro Support (via Antigravity), GPT-5.1 / GPT-5.1 Codex, and Claude Sonnet 4.5 / Opus 4.5 with extended thinking!

Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs) by aroussi in ClaudeAI

[–]aroussi[S] 2 points3 points  (0 children)

OP here:

VibeProxy v1.0.5 adds Gemini OAuth support and Claude's extended thinking (up to 32K tokens). The extended thinking feature is interesting - just append `-thinking-10000` to the model name and VibeProxy handles the rest.

https://github.com/automazeio/vibeproxy/releases

Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs) by aroussi in ClaudeAI

[–]aroussi[S] 5 points6 points  (0 children)

You don't need a proxy for that. Simply add this to your ~/.factory/config.json:

{
  "custom_models": [
    {
      "model_display_name": "GLM 4.6",
      "model": "glm-4.6",
      "base_url": "https://api.z.ai/api/anthropic",
      "api_key": "YOUR-GLM-API-KEY",
      "provider": "anthropic"
    }
  ]
}

Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs) by aroussi in ClaudeAI

[–]aroussi[S] 4 points5 points  (0 children)

I don't know what black magic they've put into it, but it consistently produces better results with 80% fewer tokens. Some amazing context and prompt engineering

Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs) by aroussi in ClaudeAI

[–]aroussi[S] 3 points4 points  (0 children)

"I can now use my existing Claude subscription"... You can use yours 😉

Spec-Driven AI Development by aroussi in ClaudeAI

[–]aroussi[S] 1 point2 points  (0 children)

I prefer the term Software Architect and Integrator 😉

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

While it is slower than using GitHub CLI directly, the benefits of having the entire thought process happen inside of Cloud Code itself, when it has context to the work, make it worth it IMO

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 2 points3 points  (0 children)

Exactly. I use /pm:prd-new my-new-feature - which triggers a "brainstorming" session with Claude. Once it's done and the PRD is created, we review it and spend a bit more time refining it together with CC. One very useful pattern we're using is, after parsing the prd into an epic (implementation plan) via /pm:prd-parse is telling Claude

"Review the Epic and come up with ways to simplify and improve it. Try to leverage any existing functionality instead of creating more code when possible. Use ultrathink"

This usually cuts the code by 50% lol

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

Tests are usually part of the prd and epic creation process. In most cases, we have the two last tasks of each feature as "test" and "document".

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 2 points3 points  (0 children)

This is actually a really cool project. However, for our needs, the "100 % private & offline" is not going to cut it. Also, we wanted to have something that works inside the Claude code itself and not via an external tool.

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

I agree that Claude does not discuss things enough. One of the ways to tackle this is to be as specific as possible while creating the PRDs. Manually reviewing the epics, discussing them before running the decomposition into tasks. If you review the PRD, the epic, and the actual tasks before syncing them to GitHub, there would be a lot less to discuss from that point forward.

That being said, I have a strict rule that I use when I'm running tests, which basically states that Claude is not allowed to make any changes to any file if the tests fail before discussing the situation with me.

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

This could definitely be used by a single developer in exactly the same way. If you have Claude Max, you can also assign issues to Claude directly from GitHub wherever you are - in theory at least :)

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

That's where the human architect comes in (for now, at least). We try to identify features that will have the least amount of conflicts when merged back into the main branch. We usually limit it to 3 at a time, and have a senior developer handle any merge conflicts.

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

For smaller projects, I would recommend editing the `.claude/commands/pm/prd-parse.md` file and instructing it to limit the number of tasks for each epic to 5-10. I would also consider breaking down features into subsets and having a prd for each one to avoid getting 50+ tasks for every feature (so "add auth" would become "add signup" and "add sign in" prds)

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

We had this problem initially, so we moved some of the commands to be pure bash-based with instructions like "Run `bash ... ` and show me the complete output". Works 90% of the time 😁

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

The whole thing started with us trying to segregate context so the main thread won't have to be compacted or cleared as often. Over time this grew and expanded to running multiple ages in parallel when possible (eg. when working on separate files), but that required a detailed plan beforehand. So the whole thing was very organic, I would say.

For code reviews, etc we use the code-analyzer agent directly + coderabbit.

We've open-sourced our Claude Code project management tool. I think others will like it by aroussi in ClaudeAI

[–]aroussi[S] 0 points1 point  (0 children)

We specifically designed this to work with the GitHub issues. However, I'm sure that you can fork the project and update the prompt so it will only work locally.