adobrawy
For example, Google Apps Script trigger Claude Code routine to investigate issue, and draft email ahead of me looking at it. If I do not like draft, I get back to Claude session to fix draft, and make PR to fix prompt for next time.
Curious, why did you choose OpenAI over CloudFlare AI (harness etc.)?
- you can easily edit the prompt
- you can see the prompt execution history
- you don't need any infrastructure to orchestrate it
- it works even when your computer is off
Once you start using it, it turns out to be very convenient.
I use it to:
- perform review of latest changes of code to update my documentation (security policies, user documentation etc.)
- perform review to latest changes of code, triage them, deduplicate and improve code - I review them, close them with comments for over-engoneering / add review for auto-fix
- perform review of open GitHub issue with label, select the one with highest impact, comment with rationale, implement it and make pull request - I wake up and I have a few pull request to fix issues that I can approve /finish in existing Claude Code thread
I want also use it to: - review recent Sentry issues, make GitHub issues for the one with highest priority, make pull request with proposed fix - I can just wake up and see that some crash is ready to be resolved
Limit of 3 scheduled jobs is pretty impactful, but playing with it give me a nice idea on how I can reduce my manual work.
tl;dr: Pressure from browsers, enterprise, and the overall ecosystem to use HTTPS (e.g., unavailability of advanced web features without HTTPS) is pushing for the use of HTTPS without exception, even for .onion sites with no significant technical advantage.
Currently, my environment uses Claude Code on bare metal, and my application runs in a container, and the agent can do "docker compose exec backend" without any restrictions (YOLO).
My biggest obstacles to adopting workflows with git worktree are the need to share the database engine (local resource constrains) and the initial migration time. Offloading to cloud might be interesting for that.
I retrieve error response when fetching exercise:
0:{"a":"$@1","f":"","b":"eETmgndxtv4Ar0i8Wync1"} 1:{"serverError":"An unexpected error occurred."}
My request: curl 'https://workout.cool/' \ -H 'accept: text/x-component' \ -H 'accept-language: en-US,en;q=0.9,pl-PL;q=0.8,pl;q=0.7' \ -H 'cache-control: no-cache' \ -H 'content-type: text/plain;charset=UTF-8' \ -b 'Next-Locale=en; _fbp=fb.1.1750253718188.954698194752805529' \ -H 'next-action: 7f80b017f78704b00d2411aebde5ba8318b475de6d' \ -H 'next-router-state-tree: %5B%22%22%2C%7B%22children%22%3A%5B%5B%22locale%22%2C%22en%22%2C%22d%22%5D%2C%7B%22children%22%3A%5B%22__PAGE__%22%2C%7B%7D%2C%22%2F%22%2C%22refresh%22%5D%7D%2Cnull%2Cnull%2Ctrue%5D%7D%5D' \ -H 'origin: https://workout.cool' \ -H 'pragma: no-cache' \ -H 'priority: u=1, i' \ -H 'referer: https://workout.cool/' \ -H 'sec-ch-ua: "Google Chrome";v="137", "Chromium";v="137", "Not/A)Brand";v="24"' \ -H 'sec-ch-ua-mobile: ?1' \ -H 'sec-ch-ua-platform: "Android"' \ -H 'sec-fetch-dest: empty' \ -H 'sec-fetch-mode: cors' \ -H 'sec-fetch-site: same-origin' \ -H 'user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36' \ --data-raw '[{"equipment":["PULLUP_BAR","BANDS","BODY_ONLY"],"muscles":["TRAPS","BACK","SHOULDERS","TRICEPS","FOREARMS","GLUTES","HAMSTRINGS","CALVES"],"limit":3}]'
Apple Store doesn't have useful apps for me, I rather use brew for installation, or I need to download dmg.
I don't use Apple Music because I use Spotify with my friends.
I don't use Apple Mail because we are in the Google ecosystem, so I use Gmail.
I don't use Apple Calendar (there is such a thing?), because in the Google ecosystem I use Google Calendar and - for notifications in the tray - Notion Calendar.
What do I lose by not using Apple ID?
> 404: NOT_FOUND
> Code: DEPLOYMENT_NOT_FOUND
> ID: arn1::llgmh-1743253533406-1fe7598253c0
However, there is a caveat regarding the workflow code itself, that placing "run" statement with specific commands directly in YAML may make it difficult to debug locally. I would recommend that "run" statements be only for script execution and their number minimized. This way, scripts can be run locally without waiting for the entire CI pipeline to execute each time.