标签：#productivity

Not a flying drone (though count to think of it, that might work), I mean a drone system tray app,...

When I first started testing APIs, Postman was one of the first tools I reached for. It was...

Someone asked me to share meeting notes in Slack yesterday. I pasted the markdown. Slack ate the table. The code block lost its indentation. The task list rendered as literal [ ] characters. I spent five minutes reformatting something that already looked perfect in my editor. So I sent a link instead. Not to Notion — they would have to sign up. Not to Google Docs — same problem, plus I did not want this living in someone's Drive forever. Not to a pastebin — those are single blobs of text with no structure, no pages, no way to come back and fix a typo tomorrow. I wanted: one link, multiple pages, markdown that actually renders, no account required, and a way for me to edit it later without the URL changing. I have built sharing tools before. FreeShare for files. NotePage for single-page text. SharePad is what I wished existed when I needed something in between a pastebin and a wiki — but without the signup wall. Live here: https://sharepad.in Source: https://github.com/Varshithvhegde/sharepad SharePad — Share notes with one link, no signup Write a notebook of markdown pages and share it with a single link. Password lock, expiry dates, comments and PDF export. Free, and no account needed. sharepad.in The Idea Most "share your notes" products follow the same playbook. Create an account. Verify your email. Create a workspace. Invite people. Configure permissions. By the time you are done, the meeting is over and nobody cares about the notes anymore. SharePad skips all of that. You write markdown. You get two links: View link — /n/kitchen-reno — hand this out freely Edit link — /e/{secret-token} — this is your ownership credential. Do not share it. No account. No password to create (unless you want to lock the view link). No "upgrade to share with more people." The edit token is your identity for that notebook. That one decision — token-based ownership instead of user accounts — simplified everything else. No auth flows. No session management. No "forgot password" for th

Automating Your Morning: A Daily Briefing Pipeline You Can Build You should not manually read news, emails, or Slack in the morning. The average knowledge worker loses 23 minutes to context switching between 8:00 AM and 9:30 AM, according to a 2023 RescueTime study. That is 92 hours per year—two full workweeks—spent on low-signal input. The fix is not "waking up earlier." The fix is building a passive briefing pipeline that compiles, ranks, and summarizes your information sources before you open your laptop. This article shows you the exact architecture, tools, and failure points, based on my own production setup running for 14 months. The Problem: Your Morning Input Is Unstructured Here is the chain of causality. You wake up and check three things: email, Slack/Teams, and newsfeeds. Each app is a separate silo with its own notification system. Each notification triggers a micro-decision: Is this urgent? Do I need to act? Should I forward this? That decision process is not free. A 2022 University of California Irvine study measured that after each interruption, it takes an average of 23 minutes to return to deep focus. But most people never return to deep focus in the morning—they just bounce between silos. The result is "reactive paralysis": you start your day by responding to others' priorities, not your own. And because each silo sorts by recency (not importance), you read a promotional email from your bank before a critical client update. Why Manual Curation Fails You might think, "I'll just spend 10 minutes skimming." Let me give you the math. If you receive 50 emails, 30 Slack messages, and 20 industry news headlines, that is 100 items. At 6 seconds each to decide relevance (not read), that is 10 minutes of pure triage. But you will read the interesting ones—that is a minimum of 45 minutes total. The deeper issue is recency bias . News apps show you the latest story, not the most important one. Email shows the newest sender, not the highest-value contact. With

The worst test suite I ever inherited had 400 tests, and I trusted about six of them. The rest were either testing implementation details nobody cared about, duplicating each other, or so tightly coupled to internal function names that a harmless refactor broke thirty tests for no real reason. Reading that codebase taught me more about what not to do than any greenfield project ever has. So when you're starting from zero, the goal isn't "write a lot of tests fast." It's building a suite you'll still trust a year from now. If you're new to this, getting the software testing basics right early matters more than covering everything - learning how to build a first test suite from scratch teaches you what to prioritize in a way that inheriting someone else's bloated suite never will. Here's roughly how I'd approach it. Start with what would actually hurt if it broke Before writing a single test, list the handful of things that would be genuinely bad if they silently broke - checkout completing, auth working, the core thing your product does actually happening. Not every function, not every branch. Just the stuff where a silent failure costs you money, users, or trust. This list is usually shorter than people expect. Five to ten flows for most early-stage products. That's your actual test suite's job in the first few months, not "100% coverage." Unit tests for logic, not for plumbing Unit tests are for things with actual decision-making in them - pricing calculations, validation rules, state transitions, anything where "given this input, is the output correct" is a real question with a wrong answer possible. They're fast, they're cheap, and they should make up the bulk of your suite. Skip unit-testing pure plumbing: a function that just calls another function and returns its result doesn't need its own test. That's the kind of test that pads a coverage number without catching anything real, and it's exactly the kind of test that made that 400-test suite so hard to trust.

Writing Takes 40 Minutes, Publishing Takes 30 — How I Solved It Last Wednesday, 22:00. I just finished writing a tutorial on Python async programming — 2200 words, clean Markdown, syntax-highlighted code blocks. 22:03, open Juejin. Paste title. Paste content. Code highlighting gone. Fix manually. Pick tags. Publish. 22:08, open Zhihu. Paste title. Paste content. The Draft.js editor merged async def into asyncdef . Fix line by line. Publish. 22:15, open CSDN. Paste title. Content looks fine. But the category dropdown has 50 options and "Python" is buried. Publish. 22:20, open Cnblogs. Must add [Markdown] tag to categories or the whole article renders as garbled HTML. Publish. 22:25, open SegmentFault. Search tags for "Python async" — zero results. Type manually. Publish. 22:30, open Dev.to. Translate title. Translate content. Publish. Forty minutes to write. Thirty minutes to publish. 22:35, all done. But the next morning, I wanted to check stats — another round of logging into each platform's dashboard one by one. I'm Not Alone Searching forums and social platforms, I found many developers share this pain: "Every time I publish an article, I open 7-8 tabs, copy-paste 7-8 times, fix formatting 7-8 times. The joy of writing gets killed by the drudgery of publishing." "I usually only publish on one platform now. It's just too much work to do more. But then search engine exposure suffers." Why "Just Copy-Paste" Doesn't Work Each platform has a different editor: Platform Editor Markdown Handling Juejin Custom Markdown Good, but code highlighting sometimes breaks Zhihu Draft.js rich text No Markdown support, eats line breaks CSDN Dual-mode Mode switching corrupts formatting Cnblogs TinyMCE Must add [Markdown] tag or disaster SegmentFault Markdown Okay, but tag system is painful Dev.to Markdown Best experience, but English-only audience The same Markdown renders differently everywhere. Copy-paste doesn't solve it. What I Built I spent two weeks of evenings building PolyPos

AGENTS.md vs CLAUDE.md: Where Agent Context Actually Lives If you have opened three different repos this month and found three different context files (AGENTS.md in one, CLAUDE.md in another, both in a third, out of sync), you are not imagining the mess. AGENTS.md is now an open, vendor neutral standard that most major coding agents read, but CLAUDE.md has not gone away, and knowing which file wins where saves you from an agent quietly following stale instructions. What AGENTS.md actually is AGENTS.md started as a proposal from Sourcegraph's Amp team to fix a specific problem: every coding agent invented its own context file, so teams ended up maintaining CLAUDE.md, .cursorrules, .windsurfrules, and whatever else, all describing the same project. OpenAI and Google backed the standard, and it has since moved under the Linux Foundation's Agentic AI Foundation. Guides tracking adoption report 28+ supporting tools and more than 60,000 open source repos containing the file (secondary source, treat the exact counts as approximate, not audited). The pitch is simple: one Markdown file, one format, every agent reads the same source of truth instead of you hand syncing five files that drift within a week. Which tools actually read it This is the part that matters when you are deciding whether to migrate. Tools with native AGENTS.md support include: GitHub Copilot coding agent Cursor Amp Factory RooCode Zed Warp Notice what is not confirmed on that list. Reports that Claude Code reads AGENTS.md natively circulate in comparison guides, but I could not verify this against Anthropic's own changelog, so I am stating it qualitatively here rather than as fact: treat it as unconfirmed until you see it in Anthropic's own docs, and keep CLAUDE.md in place as your safety net if you rely on Claude Code specifically. AGENTS.md vs CLAUDE.md vs the well known directory Three layers get conflated constantly, and they solve different problems. Layer What it is Scope AGENTS.md Vendor neutral p

Your coding agent is a process that reads your filesystem and runs shell commands with your credentials. Most of the time that is exactly what you want. Occasionally it is cat .env while debugging - and now your production keys live in a transcript forever - or a confident rm -rf on a path that resolved differently than expected. Everyone's first fix is to add rules to CLAUDE.md: "never read .env, never force push". Those are suggestions to a language model. They work until they don't, and you will not be watching when they don't. Claude Code has a mechanism that is not a suggestion: hooks. A hook is a program you register for specific events - before a tool call, after it, when the session tries to end. It runs outside the model, sees the exact tool call as JSON on stdin, and its verdict is enforced by the harness itself. The model cannot talk its way past it, but it CAN read a structured denial and route around it productively. This is a cookbook for writing them. Everything below is plain Python stdlib and works on current Claude Code as of August 2026. The mechanics in ninety seconds Hooks are registered in settings ( .claude/settings.json in a project, ~/.claude/settings.json globally): { "hooks" : { "PreToolUse" : [ { "matcher" : "Read|Grep|Bash" , "hooks" : [ { "type" : "command" , "command" : "python3 \" ${CLAUDE_PROJECT_DIR}/.claude/hooks/secret-guard.py \" " , "timeout" : 10 } ] } ] } } The matcher filters by tool name. Your command receives a JSON object on stdin describing the event; for PreToolUse it includes tool_name and tool_input (the exact arguments about to run). You respond on stdout with JSON. Three responses cover almost everything: Deny a tool call, with a reason the model will read: { "hookSpecificOutput" : { "hookEventName" : "PreToolUse" , "permissionDecision" : "deny" , "permissionDecisionReason" : "why, and what to do instead" } } Block a session from ending (Stop event), sending work back: { "decision" : "block" , "reason" : "lint failed

Hi everyone I’ve been hacking on a terminal coding agent called phi https://github.com/pulseaiclub/phi for the past few months, and I’d love to share what it is and why it exists. If you’ve used tools like Pi, Claude Code, Aider, or Goose, phi tries to hit the same workflow—but deliberately strips away the runtime baggage. It’s a single Go binary, ~12 MB, with no Node, Electron, or Python in sight. Here’s what makes it tick: No model lock-in This is the whole reason phi exists. Model releases are moving faster than any agent maintainer can keep up with. Instead of chasing every new provider, phi tr eats the model as a pluggable config: anything OpenAI-compatible or Anthropic-native works out of the box. You can swap models in seconds without waiting for a n author to add support. Config is a single YAML file, and there’s also a tiny HTML editor so you can point-and-click your way through ~/.phi/config.yaml. As light as it gets Go is the secret sauce here. A stripped release build (CGO_ENABLED=0) comes in at ~12 MB, cold idle RSS around ~21 MB, and a first frame in roughly 40 ms. Ther e are only 6 direct module dependencies. If you want a coding agent you can go build in half a second and read in an afternoon, this is it. A permission gate that actually matters One thing that always makes me nervous with coding agents is the "model deletes your files" moment. Phi defaults to read-only: the agent can scan your codebase , but writes and shell commands require explicit approval. The approval dialog gives you three choices—allow, deny with feedback, or allow everything for the r est of the session. Rules are granular: • bash.allow → go test ./... is fine. • bash.deny → rm -rf * is blocked. • fetch.allowed_hosts → restrict which domains the agent can reach. Sub-agents that don’t bloat your context One big agent is fine for small tasks, but long-running work pollutes the context window with noise. Phi ships a full set of sub-agent tools (agent_spawn, agen t_task, agent_wai

You know the moment. You've handed Claude Code (or Codex, or Cursor, or whatever you're driving today) a real task , not "fix this typo," but "refactor the auth middleware and update the tests." It goes off and works. Even if you've turned off the "ask before edit" prompts and let it run end to end without interruptions, you still want to check in to see what it actually did, watch it reason through a tricky part, catch something before it goes further than you meant. That can take minutes. And in those minutes, you're either sitting there watching a terminal scroll, or you wander off and genuinely forget to come back and check. Nobody was watching. That's the whole problem in one sentence: coding agents got capable enough to work unattended for real stretches of time, but the interface is still "stare at a terminal or forget about it." So, what is SKI SKI is a free desktop app that gives your coding agent a voice - in both directions. You talk to Claude Code, Codex, Cursor, Gemini CLI, and a growing list of other agents by speaking instead of typing. And this is the part that actually changes the workflow - you hear them reply out loud. When the agent finishes a task or hits a decision point, it says so: "Tests pass, want me to ship it?" You don't have to be staring at the terminal to catch that. You can be in another window, another room, or heads-down on a different project entirely. It lives as a small ambient widget on your desktop - a floating pill, or, if you're on a MacBook, a notch bar docked right under the camera housing , you hold a key to talk, and everything - speech-to-text and text-to-speech both runs locally on your machine. Why "voice for coding agents" and not just "voice dictation" This distinction actually matters, and it's the one thing I'd want you to walk away with if you read nothing else. Dictation tools have existed for a while, and good ones too, they turn your speech into text and drop it wherever your cursor is. That's genuinely useful,

Why a live payment is not a release test The riskiest way to test a SaaS checkout is to make a real payment to yourself. It feels reassuring: the live checkout opened, the card worked, the webhook fired and the refund came back. But that proof mixes engineering QA with revenue evidence. Three different proofs A cleaner billing release process separates three questions: Does billing behave correctly? Test payment, refund, webhook and subscription edge cases in a Stripe sandbox. Is production configured correctly? Verify the live price, currency, checkout destination, webhook configuration and deployed revision without moving money. Did a customer pay? Treat a genuine live transaction as customer activity and revenue evidence, not as an engineering fixture. Stripe documents sandboxes as isolated testing environments and separates sandbox credentials from live credentials. The practical lesson is broader than Stripe: operational proof and commercial proof should not share the same transaction. A useful boundary Use this sequence: Sandbox QA → read-only production verification → genuine customer payment . It keeps release evidence, reconciliation and revenue numbers easier to interpret. We recently tightened the same boundary in VendorOS. That does not prove live customer revenue; it is a workflow lesson about keeping evidence categories separate. If your release process still requires a live self-payment, ask which part of the verification can become read-only. Sources: Stripe Sandboxes Stripe API keys Stripe testing VendorOS release boundary

A few years ago, a technical interview mostly tested one thing: can you write correct code, from memory, under pressure. That bar has quietly shifted — and a lot of developers preparing for interviews right now haven't fully clocked it. AI coding assistants are part of daily work at most companies now, from big IT services firms to small product teams. Interview panels have adjusted to that reality faster than most prep guides have. What's actually different now Interviewers care less about whether you can produce a function from scratch, and more about whether you understand what code is doing and why. It's increasingly common to be handed a piece of AI-generated code and asked to find the bug, justify a design decision, or optimize it — instead of writing something from zero on a whiteboard. Some companies go further and let you use AI tools during the technical round, then evaluate how well you direct the tool, verify its output, and catch its mistakes. The skill being tested has moved from "can you write code" to "can you reason clearly with code as your material." Three things I keep seeing candidates get wrong Treating a finished course or degree as the finish line. Completing a syllabus tells an employer you were exposed to concepts. It doesn't tell them you can apply those concepts to a messy, real-world problem — which is exactly what open-ended interview scenarios are designed to expose. Leaning on AI tools without understanding the output. Using an AI assistant while practicing at home is fine. The problem shows up when that habit surfaces in a live interview as an inability to explain your own solution. If you can't walk through why a piece of code works, a couple of follow-up questions will make that obvious fast. Underrating communication and debugging skills. As AI tools take on more initial code-writing, the human value shifts toward reviewing, debugging, and explaining decisions to teammates. Candidates who only practiced writing code — and never pr

Spent the week redesigning my portfolio’s blog layout and nuking thousands of stale notes in my Obsidian vault. Between the UI polish and some deep dives into libp2p DHT de-flaking, I pushed 36 commits and managed to delete almost 16,000 lines of clutter. TL;DR I’ve always believed that your digital space needs a good pruning every now and then to stay healthy. This week was the embodiment of that philosophy. I pushed 36 commits across four primary projects, resulting in over 23,000 additions and nearly 16,000 deletions. Most of that churn came from a massive redesign of my portfolio's blog and a long-overdue "fresh start" for my Obsidian vault. On the open-source side, I spent some quality time in the weeds of py-libp2p , chasing down flaky DHT tests and proposing better subnet diversity limits. What I Built Portfolio Redesign: The Typography Pivot My main focus this week was my portfolio. I’ve been feeling like the blog layout was getting a bit cluttered, so I opened and merged PR #15, which was all about "typographic hierarchy instead of decoration." I’m moving away from unnecessary borders and boxes and letting the type do the heavy lifting. I spent a lot of time in components/blog and app/blog refining the layout. I implemented borderless filter pills and full-width rows to give the content more room to breathe. One of the bigger technical shifts was moving the blog list to be fully server-rendered. It feels snappier, and it allowed me to implement more "honest" dates and better hover states on the rows. I also added a real focus ring for accessibility (because we’ve all been frustrated by keyboard navigation that feels like a guessing game). By the time I was done, I’d touched over 200 files in that repo alone. The Obsidian Purge I also took a metaphorical chainsaw to my obsidian-vault . I nuked nearly 10,000 lines of stale content. I removed entire directories for "Projects," "Rust," and "Backend" notes that were just gathering digital dust. It’s easy to let

While researching for this post, I found out something funny. Pi, the most interesting coding agent...

The concrete problem Running two or three coding-agent sessions is easy. Knowing when their work is safe to combine is not. One session changes an API while another writes regression tests against the old shape. A third investigates a production failure and quietly edits the same configuration file. Git worktrees prevent immediate filesystem collisions, but they do not explain task dependencies, transfer assumptions, or warn that two agents are solving incompatible versions of the problem. The developer becomes a human message bus: checking terminals, copying commit IDs, repeating context, and deciding which session should wait. The more capable each agent becomes, the less useful a wall of terminal panes is as a coordination interface. The current signal Claude Code now supports messaging between sessions on the same machine. Its documentation describes session discovery, plain-text messages, and a local messaging socket. Agent view separately exposes background-session state, worktrees, pull-request status, and a JSON listing suitable for scripts. Hooks can observe tool input and block a tool call before execution. That does not prove demand for a new product. It does create a concrete implementation moment: the primitives for handoffs and visibility exist, while dependency ownership and conflict negotiation remain a workflow problem. In RayTally's bounded Hacker News snapshot at August 9, 00:33 UTC, the cross-session messaging discussion had 50 points and 26 comments and ranked 18th. Those numbers describe that historical observation only; they are not user counts, market validation, or a prediction of lasting interest. A product direction: a control desk for handoffs The useful product is not another chat window. It is a small local control desk that makes each session declare four things: its goal, worktree, files it expects to touch, and the result another session is waiting for. When the API session finishes, the testing session should receive a compact hando

Qarinah compiles a compact, cited project-memory pack instead of asking every new coding-agent session to replay the entire available history. The published estimate Across six committed software-task fixtures, the full-history baseline contained 442,113 portable estimated input-context tokens . The Qarinah path used 5,682 . Every required target was still directly covered in the top five results. That is: 436,431 fewer estimated input-context tokens; 98.71% less repeated context; and a 77.81:1 baseline-to-pack ratio. The ratio is not a claim that every provider bill drops by 98.71%, or that an agent session lasts 77.81 times longer. It measures the compared input-context volume in the published six-fixture estimate. What the same token rate would cost The table applies four flat, uncached input-token rates to the same two token estimates. It is arithmetic, not a provider invoice. Flat uncached input rate Full-history baseline Qarinah pack Estimated saving $1 / million tokens $0.442113 $0.005682 $0.436431 $3 / million tokens $1.326339 $0.017046 $1.309293 $5 / million tokens $2.210565 $0.028410 $2.182155 $15 / million tokens $6.631695 $0.085230 $6.546465 The calculation is: estimated tokens / 1,000,000 x flat input rate It deliberately excludes provider-native tokenization, caching, output tokens, reasoning tokens, tool calls, retrieval, hosting, and fixed fees. Real cost depends on the provider, model, cache behavior, context composition, and how often the same history would otherwise be resent. Why the pack remains useful Compression only matters if the next task can still find its evidence. The benchmark checks both volume and retrieval coverage: every required target had to be directly present in the top five. Qarinah preserves the source event ID and content hash for selected context, so a later agent receives a bounded handoff that can be inspected instead of an opaque story. Qarinah also passed 380 of 380 deterministic file-specific exact and typo-tolerant que

After months of building with AI coding tools, I found the difference between generated code that...

Hey everyone! I'm jinyuan, an indie developer. I recently launched DevTools Box — a free online toolbox with 75+ developer tools. What's in the box? DevTools Box includes tools like: JSON Formatter — beautify and validate JSON Regex Tester — test regular expressions with live matching Base64 Encoder/Decoder — quick encoding and decoding QR Code Generator — generate QR codes instantly Hash Calculator — MD5, SHA-1, SHA-256 and more Color Picker — pick colors and convert between formats ...and 69 more tools! Why I built it I was tired of jumping between different websites for simple dev tasks. Each tool runs entirely in your browser — no login, no ads, no data sent to any server. Tech stack Next.js 14 with App Router TypeScript Tailwind CSS Static export to Cloudflare Pages Try it out Check it out at tdboxs.com . All tools are 100% free. Would love to hear your feedback! What tools would you add?

I keep seeing the same mismatch in the screen-time category: a lot of apps are technically blockers, but they feel like parental control software. That is fine if a parent is the customer. It is a bad fit if the user is an adult trying to manage their own habits. The difference is not cosmetic. When a blocker feels like surveillance, adults bounce. They do not want an account, a dashboard, or the feeling that their phone behavior is being watched somewhere else. That is the gap I built SproutGuard for: built for adults blocking themselves , not kids runs on-device through Apple's Screen Time APIs no account no server no usage data leaving the phone App Store: https://apps.apple.com/us/app/sproutguard-screen-time-detox/id6768664921?ct=devto-adults I also put the positioning plainly on the product page: self-control, not parental control The hard lesson from launching it is that being right about the problem is not the same thing as being shareable . Privacy architecture matters, but users rarely tell friends about architecture. What they do share is something emotional or visible: a streak, a mascot, a challenge, a before/after feeling. So the current working question for me is not "how do I explain on-device privacy better?" It is: How do you make a self-control product feel human enough that people talk about it? Website: https://shantj.github.io/sproutguard/ If you've worked on consumer productivity or habit products, I'm interested in what actually made users talk about them.

If you've ever opened a PR with 47 changed files and a diff so long GitHub just gives up and shows you "Load Diff" seventeen times, this one's for you. GitHub quietly shipped what might be the biggest pull request update in years, and it's aimed squarely at that problem. Let's talk about stacked pull requests. The problem, in one sentence Big PRs are where good reviews go to die. Nobody reads a 2000 line diff carefully. Some folks reach for AI code review tools like LiveReview to take the edge off, and honestly that helps, but even the best reviewer (human or model) does a better job on a tight, focused diff than on a 2000 line wall. Smaller inputs, better reviews. That's true no matter who's doing the reviewing. Stacked PRs are GitHub's answer: break one massive change into a chain of small, dependent PRs, where each one only reviews the diff it actually introduces, not everything below it. What a stack actually is The rule is simple. You need two or more PRs in the same repo where: The bottom PR targets your trunk branch (usually main ) Every PR after that targets the PR below it, not main That's it. That's the whole trick. Foundational stuff (schemas, shared types) goes at the bottom. Stuff that depends on it (API routes, UI) goes higher up the chain. And here's the part that surprised me: if you just do this manually with plain git, by opening PR #11 against the branch for PR #10 instead of against main , GitHub now recognizes that as a stack automatically. No special tool required. It just notices the base branches form a chain and lights up a banner. Stacking isn't a git concept at all, it's purely a GitHub UI concept layered on top of branches you were already making. Let's actually build one Enough theory. I built a real stack in one of my own repos ( peektea , a terminal file browser I maintain), using a harmless scratch file so nothing real got touched. Here's the actual terminal session, copy pasted, warts and all. First I tried to be fancy and use the CL