llm/065c6e83-d0d5-4aca-be3d-92768a8a3506/batch-5-69035a02-41d8-4ed5-b463-ce9ee4bf9fab-input.json
The following is content for you to classify. Do not respond to the comments—classify them.
<topics>
1. Not Novel or Revolutionary
Related: Many commenters argue this workflow is standard practice, not radically different. References to existing tools like Kiro, OpenSpec, SpecKit, and Antigravity that already implement spec-driven development. Claims the approach was documented 2+ years ago in Cursor forums.
2. LLMs as Junior Developers
Related: Analogy comparing LLMs to unreliable interns with boundless energy. Discussion of treating AI like junior developers requiring supervision, documentation, and oversight. The shift from coder to software manager role.
3. AI-Generated Article Concerns
Related: Multiple commenters suspect the article itself was written by AI, noting characteristic style and patterns. Debate about whether AI-written content should be evaluated differently or dismissed outright.
4. Magic Words and Prompt Engineering
Related: Skepticism about whether words like 'deeply' and 'in great details' actually affect LLM behavior. Discussion of attention mechanisms, emotional prompting research, and whether prompt techniques are superstition or cargo cult.
5. Planning vs Just Coding
Related: Debate about whether extensive planning overhead eliminates time savings. Some argue writing specs takes longer than writing code. Others counter that planning prevents compounding errors and technical debt.
6. Spec-Driven Development Tools
Related: References to existing frameworks: OpenSpec, SpecKit, BMAD-METHOD, Kiro, Antigravity. Discussion of how these tools formalize the research-plan-implement workflow described in the article.
7. Context Window Management
Related: Strategies for handling large codebases and context limits. Maintaining markdown files for subsystems, using skills, aggressive compaction. Concerns about context rot and performance degradation.
8. Waterfall Methodology Comparison
Related: Commenters note the approach resembles waterfall development with detailed upfront planning. Discussion of whether this contradicts agile principles or represents rediscovering proven methods.
9. Test-Driven Development Integration
Related: Suggestions to add comprehensive tests to the workflow. Writing tests before implementation, using tests as verification. Arguments that test coverage enables safer refactoring with AI.
10. Single Session vs Multiple Sessions
Related: Author's claim of running entire workflows in single long sessions without performance degradation. Others recommend clearing context between phases for better results.
11. Determinism and Reproducibility
Related: Concerns about non-deterministic LLM outputs. Discussion of whether software engineering can accommodate probabilistic tools. Comparisons to gambling and slot machines.
12. Token Cost Considerations
Related: Discussion of workflow being token-heavy and expensive. Comparisons between Claude subscription tiers. Arguments that simpler approaches save money while achieving similar results.
13. Annotation Workflow Details
Related: Questions about how to format inline annotations for Claude to recognize. Techniques like TODO prefixes, HTML comments, and clear separation between human and AI-written content.
14. Subagent Architecture
Related: Using multiple agents for different phases: planning, implementation, review. Red team/blue team approaches. Dispatching parallel agents for independent tasks.
15. Reference Implementation Technique
Related: Using existing code from open source projects as examples for Claude. Questions about licensing implications. Claims this dramatically improves output quality.
16. Claude vs Other Models
Related: Comparisons between Claude, Codex, Gemini, and other models. Discussion of model-specific behaviors and optimal prompting strategies. Using multiple models in complementary roles.
17. Greenfield vs Existing Codebases
Related: Observation that most AI coding articles focus on greenfield development. Different challenges when working with legacy code and established patterns.
18. Human Review Requirements
Related: Debate about whether all AI-generated code must be reviewed line-by-line. Questions about trust, liability, and whether AI can eventually be trusted without oversight.
19. Productivity Claims Skepticism
Related: Questions about actual time savings versus perceived productivity. References to studies showing AI sometimes makes developers less productive. Concerns about false progress.
20. Documentation as Side Benefit
Related: Plans and research documents serve as valuable documentation for future maintainers. Version controlling plan files in git. Using plans to understand architectural decisions later.
0. Does not fit well in any category
</topics>
<comments_to_classify>
[
{
"id": "47107626",
"text": "Surely Addy Osmani can code. Even he suggests plan first.\n\nhttps://news.ycombinator.com/item?id=46489061"
}
,
{
"id": "47107697",
"text": "> planning and checking and prompting and orchestrating is far more work than just writing the code yourself.\n\nThis! Once I'm familiar with the codebase (which I strive to do very quickly), for most tickets, I usually have a plan by the time I've read the description. I can have a couple of implementation questions, but I knew where the info is located in the codebase. For things, I only have a vague idea, the whiteboard is where I go.\n\nThe nice thing with such a mental plan, you can start with a rougher version (like a drawing sketch). Like if I'm starting a new UI screen, I can put a placeholder text like \"Hello, world\", then work on navigation. Once that done, I can start to pull data, then I add mapping functions to have a view model,...\n\nEach step is a verifiable milestone. Describing them is more mentally taxing than just writing the code (which is a flow state for me). Why? Because English is not fit to describe how computer works (try describe a finite state machine like navigation flow in natural languages). My mental mental model is already aligned to code, writing the solution in natural language is asking me to be ambiguous and unclear on purpose."
}
,
{
"id": "47107557",
"text": "I use Claude Code for lecture prep.\n\nI craft a detailed and ordered set of lecture notes in a Quarto file and then have a dedicated claude code skill for translating those notes into Slidev slides, in the style that I like.\n\nOnce that's done, much like the author, I go through the slides and make commented annotations like \"this should be broken into two slides\" or \"this should be a side-by-side\" or \"use your generate clipart skill to throw an image here alongside these bullets\" and \"pull in the code example from ../examples/foo.\" It works brilliantly.\n\nAnd then I do one final pass of tweaking after that's done.\n\nBut yeah, annotations are super powerful. Token distance in-context and all that jazz."
}
,
{
"id": "47107662",
"text": "Can I ask how you annotate the feedback for it? Just with inline comments like `# This should be changed to X`?\n\nThe author mentions annotations but doesn't go into detail about how to feed the annotations to Claude."
}
,
{
"id": "47107836",
"text": "Slidev is markdown, so i do it in html comments. Usually something like:\n\n<!-- TODOCLAUDE: Split this into a two-cols-title, divide the examples between -->\n\nor\n\n<!-- TODOCLAUDE: Use clipart skill to make an image for this slide -->\n\nAnd then, when I finish annotating I just say: \"Address all the TODOCLAUDEs\""
}
,
{
"id": "47107585",
"text": "is your skill open source"
}
,
{
"id": "47107882",
"text": "Not yet... but also I'm not sure it makes a lot of sense to be open source. It's super specific to how I like to build slide decks and to my personal lecture style.\n\nBut it's not hard to build one. The key for me was describing, in great detail:\n\n1. How I want it to read the source material (e.g., H1 means new section, H2 means at least one slide, a link to an example means I want code in the slide)\n\n2. How to connect material to layouts (e.g., \"comparison between two ideas should be a two-cols-title,\" \"walkthrough of code should be two-cols with code on right,\" \"learning objectives should be side-title align:left,\" \"recall should be side-title align:right\")\n\nThen the workflow is:\n\n1. Give all those details and have it do a first pass.\n\n2. Give tons of feedback.\n\n3. At the end of the session, ask it to \"make a skill.\"\n\n4. Manually edit the skill so that you're happy with the examples."
}
,
{
"id": "47111265",
"text": "“The workflow I’m going to describe has one core principle: never let Claude write code until you’ve reviewed and approved a written plan.”\n\nI’m not sure we need to be this black and white about things. Speaking from the perspective of leading a dev team, I regularly have Claude Code take a chance at code without reviewing a plan. For example, small issues that I’ve written clear details about, Claude can go to town on those. I’ve never been on a team that didn’t have too many of these types of issues to address.\n\nAnd, a team should have othee guards in place that validates that code before it gets merged somewhere important.\n\nI don’t have to review every single decision one of my teammates is going to make, even those less experienced teammates, but I do prepare teammates with the proper tools (specs, documentation, etc) so they can make a best effort first attempt. This is how I treat Claude Code in a lot of scenarios."
}
,
{
"id": "47111482",
"text": "It strikes me that if this technology were as useful and all-encompassing as it's marketed to be, we wouldn't need four articles like this every week"
}
,
{
"id": "47111497",
"text": "People are figuring it out. Cars are broadly useful, but there's nuance to how to maintain then, use them will in different terrains and weather, etc."
}
,
{
"id": "47111504",
"text": "How many millions of articles are there about people figuring out how to write better software?\n\nDoes something have to be trivial-to-use to be useful?"
}
,
{
"id": "47111266",
"text": "Radically different? Sounds to me like the standard spec driven approach that plenty of people use.\n\nI prefer iterative approach. LLMs give you incredible speed to try different approaches and inform your decisions. I don’t think you can ever have a perfect spec upfront, at least that’s my experience."
}
,
{
"id": "47110015",
"text": "Well, that's already done by Amazon's Kiro [0], Google's Antigravity [1], GitHub's Spec Kit [2], and OpenSpec [3]!\n\n[0]: https://kiro.dev/\n\n[1]: https://antigravity.google/\n\n[2]: https://github.github.com/spec-kit/\n\n[3]: https://openspec.dev/"
}
,
{
"id": "47109615",
"text": "> Read deeply, write a plan, annotate the plan until it’s right, then let Claude execute the whole thing without stopping, checking types along the way.\n\nAs others have already noted, this workflow is exactly what the Google Antigravity agent (based off Visual Studio Code) has been created for. Antigravity even includes specialized UI for a user to annotate selected portions of an LLM-generated plan before iterating it.\n\nOne significant downside to Antigravity I have found so far is the fact that even though it will properly infer a certain technical requirement and clearly note it in the plan it generates (for example, \"this business reporting column needs to use a weighted average\"), it will sometimes quietly downgrade such a specialized requirement (for example, to a non-weighted average), without even creating an appropriate \"WARNING:\" comment in the generated code. Especially so when the relevant codebase already includes a similar, but not exactly appropriate API. My repetitive prompts to ALWAYS ask about ANY implementation ambiguities WHATSOEVER go unanswered.\n\nFrom what I gather Claude Code seems to be better than other agents at always remembering to query the user about implementation ambiguities, so maybe I will give Claude Code a shot over Antigravity."
}
,
{
"id": "47108846",
"text": "This is quite close to what I've arrived at, but with two modifications\n\n1) anything larger I work on in layers of docs. Architecture and requirements -> design -> implementation plan -> code. Partly it helps me think and nail the larger things first, and partly helps claude. Iterate on each level until I'm satisfied.\n\n2) when doing reviews of each doc I sometimes restart the session and clear context, it often finds new issues and things to clear up before starting the next phase."
}
,
{
"id": "47107286",
"text": "I go a bit further than this and have had great success with 3 doc types and 2 skills:\n\n- Specs: these are generally static, but updatable as the project evolves. And they're broken out to an index file that gives a project overview, a high-level arch file, and files for all the main modules. Roughly ~1k lines of spec for 10k lines of code, and try to limit any particular spec file to 300 lines. I'm intimately familiar with every single line in these.\n\n- Plans: these are the output of a planning session with an LLM. They point to the associated specs. These tend to be 100-300 lines and 3 to 5 phases.\n\n- Working memory files: I use both a status.md (3-5 items per phase roughly 30 lines overall), which points to a latest plan, and a project_status (100-200 lines), which tracks the current state of the project and is instructed to compact past efforts to keep it lean)\n\n- A planner skill I use w/ Gemini Pro to generate new plans. It essentially explains the specs/plans dichotomy, the role of the status files, and to review everything in the pertinent areas of code and give me a handful of high-level next set of features to address based on shortfalls in the specs or things noted in the project_status file. Based on what it presents, I select a feature or improvement to generate. Then it proceeds to generate a plan, updates a clean status.md that points to the plan, and adjusts project_status based on the state of the prior completed plan.\n\n- An implementer skill in Codex that goes to town on a plan file. It's fairly simple, it just looks at status.md, which points to the plan, and of course the plan points to the relevant specs so it loads up context pretty efficiently.\n\nI've tried the two main spec generation libraries, which were way overblown, and then I gave superpowers a shot... which was fine, but still too much. The above is all homegrown, and I've had much better success because it keeps the context lean and focused.\n\nAnd I'm only on the $20 plans for Codex/Gemini vs. spending $100/month on CC for half year prior and move quicker w/ no stall outs due to token consumption, which was regularly happening w/ CC by the 5th day. Codex rarely dips below 70% available context when it puts up a PR after an execution run. Roughly 4/5 PRs are without issue, which is flipped against what I experienced with CC and only using planning mode."
}
,
{
"id": "47107751",
"text": "This is pretty much my approach. I started with some spec files for a project I'm working on right now, based on some academic papers I've written. I ended up going back and forth with Claude, building plans, pushing info back into the specs, expanding that out and I ended up with multiple spec/architecture/module documents. I got to the point where I ended up building my own system (using claude) to capture and generate artifacts, in more of a systems engineering style (e.g. following IEEE standards for conops, requirement documents, software definitions, test plans...). I don't use that for session-level planning; Claude's tools work fine for that. (I like superpowers, so far. It hasn't seemed too much)\n\nI have found it to work very well with Claude by giving it context and guardrails. Basically I just tell it \"follow the guidance docs\" and it does. Couple that with intense testing and self-feedback mechanisms and you can easily keep Claude on track.\n\nI have had the same experience with Codex and Claude as you in terms of token usage. But I haven't been happy with my Codex usage; Claude just feels like it's doing more of what I want in the way I want."
}
,
{
"id": "47107325",
"text": "Looks good. Question - is it always better to use a monorepo in this new AI world? Vs breaking your app into separate repos? At my company we have like 6 repos all separate nextjs apps for the same user base. Trying to consolidate to one as it should make life easier overall."
}
,
{
"id": "47107429",
"text": "It really depends but there’s nothing stopping you from just creating a separate folder with the cloned repositories (or worktrees) that you need and having a root CLAUDE.md file that explains the directory structure and referencing the individual repo CLAUDE.md files."
}
,
{
"id": "47107407",
"text": "Just put all the repos in all in one directory yourself. In my experience that works pretty well."
}
,
{
"id": "47107478",
"text": "AI is happy to work with any directory you tell it to. Agent files can be applied anywhere."
}
,
{
"id": "47108146",
"text": "The multi-pass approach works outside of code too. I run a fairly complex automation pipeline (prompt -> script -> images -> audio -> video assembly) and the single biggest quality improvement was splitting generation into discrete planning and execution phases. One-shotting a 10-step pipeline means errors compound. Having the LLM first produce a structured plan, then executing each step against that plan with validation gates between them, cut my failure rate from maybe 40% to under 10%. The planning doc also becomes a reusable artifact you can iterate on without re-running everything."
}
,
{
"id": "47110974",
"text": "This looks like an important post. What makes it special is that it operationalizes Polya's classic problem-solving recipe for the age of AI-assisted coding.\n\n1. Understand the problem (research.md)\n\n2. Make a plan (plan.md)\n\n3. Execute the plan\n\n4. Look back"
}
,
{
"id": "47110999",
"text": "Yeah, OODA loop for programmers, basically. It’s a good approach."
}
,
{
"id": "47109392",
"text": "Has anyone found a efficient way to avoid repeating the initial codebase assessment when working with large projects?\n\nThere are several projects on GitHub that attempt to tackle context and memory limitations, but I haven’t found one that consistently works well in practice.\n\nMy current workaround is to maintain a set of Markdown files, each covering a specific subsystem or area of the application. Depending on the task, I provide only the relevant documents to Claude Code to limit the context scope. It works reasonably well, but it still feels like a manual and fragile solution.\nI’m interested in more robust strategies for persistent project context or structured codebase understanding."
}
,
{
"id": "47109415",
"text": "Whenever I build a new feature with it I end up with several plan files leftover. I ask CC to combine them all, update with what we actually ended up building and name it something sensible, then whenever I want to work on that area again it's a useful reference (including the architecture, decisions and tradeoffs, relevant files etc)."
}
,
{
"id": "47109996",
"text": "Yes this is what agent \"skills\" are. Just guides on any topic. The key is that you have the agent write and maintain them."
}
,
{
"id": "47109486",
"text": "For my longer spec files, I grep the subheaders/headers (with line numbers) and show this compact representation to the LLM's context window. I also have a file that describes what each spec files is and where it's located, and I force the LLM to read that and pull the subsections it needs. I also have one entrypoint requirements file (20k tokens) that I force it to read in full before it does anything else, every line I wrote myself. But none of this is a silver bullet."
}
,
{
"id": "47109452",
"text": "That sounds like the recommended approach. However, there's one more thing I often do: whenever Claude Code and I complete a task that didn't go well at first, I ask CC what it learned, and then I tell it to write down what it learned for the future. It's hard to believe how much better CC has become since I started doing that. I ask it to write dozens of unit tests and it just does. Nearly perfectly. It's insane."
}
,
{
"id": "47109526",
"text": "I'm interested in this as well.\n\nSkills almost seem like a solution, but they still need an out-of-band process to keep them updated as the codebase evolves. For now, a structured workflow that includes aggressive updates at the end of the loop is what I use."
}
,
{
"id": "47109423",
"text": "In Claude Web you can use projects to put files relevant for context there."
}
,
{
"id": "47110762",
"text": "And then you have to remind it frequently to make use of the files. Happened to me so many times that I added it both to custom instructions as well as to the project memory."
}
,
{
"id": "47108684",
"text": "> After Claude writes the plan, I open it in my editor and add inline notes directly into the document. These notes correct assumptions, reject approaches, add constraints, or provide domain knowledge that Claude doesn’t have.\n\nThis is the part that seems most novel compared to what I've heard suggested before. And I have to admit I'm a bit skeptical. Would it not be better to modify what Claude has written directly, to make it correct, rather than adding the corrections as separate notes (and expecting future Claude to parse out which parts were past Claude and which parts were the operator, and handle the feedback graciously)?\n\nAt least, it seems like the intent is to do all of this in the same session, such that Claude has the context of the entire back-and-forth updating the plan. But that seems a bit unpleasant; I would think the file is there specifically to preserve context between sessions."
}
,
{
"id": "47110963",
"text": "The whole process feels Socratic which is why I and a lot of other folks use plan annotation tools already. In my workflow I had a great desire to tell the agent what I didn’t like about the plan vs just fix it myself - because I wanted the agent to fix its own plan."
}
,
{
"id": "47108791",
"text": "One reason why I don't do this: even I won't be immune to mistakes. When I fix it with new values or paths, for example, and the one I provided is wrong, it can worsen the future work.\n\nPersonally, I like to order claude one more time to update the plan file after I have given annotation, and review it again after. This will ensure (from my understanding) that claude won't treat my annotation as different instructions, thus risking the work being conflicted."
}
,
{
"id": "47108673",
"text": "Since everyone is showing their flow, here's mine:\n\n* create a feature-name.md file in a gitignored folder\n\n* start the file by giving the business context\n\n* describe a high-level implementation and user flows\n\n* describe database structure changes (I find it important not to leave it for interpretation)\n\n* ask Claude to inspect the feature and review if for coherence, while answering its questions I ask to augment feature-name.md file with the answers\n\n* enter Claude's plan mode and provide that feature-name.md file\n\n* at this point it's detailed enough that rarely any corrections from me are needed"
}
,
{
"id": "47110178",
"text": "Quoting the article:\n\n> One trick I use constantly: for well-contained features where I’ve seen a good implementation in an open source repo, I’ll share that code as a reference alongside the plan request. If I want to add sortable IDs, I paste the ID generation code from a project that does it well and say “this is how they do sortable IDs, write a plan.md explaining how we can adopt a similar approach.” Claude works dramatically better when it has a concrete reference implementation to work from rather than designing from scratch.\n\nLicensing apparently means nothing.\n\nRipped off in the training data, ripped off in the prompt."
}
,
{
"id": "47110221",
"text": "Concepts are not copyrightable."
}
,
{
"id": "47111142",
"text": "The article isn’t describing someone who learned the concept of sortable IDs and then wrote their own implementation.\n\nIt describes copying and pasting actual code from one project into a prompt so a language model can reproduce it in another project.\n\nIt’s a mechanical transformation of someone else’s copyrighted expression (their code) laundered through a statistical model instead of a human copyist."
}
,
{
"id": "47111317",
"text": "“Mechanical” is doing some heavy lifting here. If a human does the same, reimplement the code in their own style for their particular context, it doesn’t violate copyright. Having the LLM see the original code doesn’t automatically make its output a plagiarism."
}
,
{
"id": "47108307",
"text": "This is the way.\n\nThe practice is:\n\n- simple\n\n- effective\n\n- retains control and quality\n\nCertainly the “unsupervised agent” workflows are getting a lot of attention right now, but they require a specific set of circumstances to be effective:\n\n- clear validation loop (eg. Compile the kernel, here is gcc that does so correctly)\n\n- ai enabled tooling (mcp / cli tool that will lint, test and provide feedback immediately)\n\n- oversight to prevent sgents going off the rails (open area of research)\n\n- an unlimited token budget\n\nThat means that most people can't use unsupervised agents.\n\nNot that they dont work; Most people have simply not got an environment and task that is appropriate.\n\nBy comparison, anyone with cursor or claude can immediately start using this approach , or their own variant on it.\n\nIt does not require fancy tooling.\n\nIt does not require an arcane agent framework.\n\nIt works generally well across models.\n\nThis is one of those few genunie pieces of good practical advice for people getting into AI coding.\n\nSimple. Obviously works once you start using it. No external dependencies. BYO tools to help with it, no “buy my AI startup xxx to help”. No “star my github so I can a job at $AI corp too”.\n\nGreat stuff."
}
,
{
"id": "47108635",
"text": "Honesty this is just language models in general at the moment, and not just coding.\n\nIt’s the same reason adding a thinking step works.\n\nYou want to write a paper, you have it form a thesis and structure first. (In this one you might be better off asking for 20 and seeing if any of them are any good.) You want to research something, first you add gathering and filtering steps before synthesis.\n\nAdding smarter words or telling it to be deeper does work by slightly repositioning where your query ends up in space.\n\nAsking for the final product first right off the bat leads to repetitive verbose word salad. It just starts to loop back in on itself. Which is why temperature was a thing in the first place, and leads me to believe they’ve turned the temp down a bit to try and be more accurate. Add some randomness and variability to your prompts to compensate."
}
,
{
"id": "47108620",
"text": "Absolutely. And you can also always let the agent look back at the plan to check if it is still on track and aligned.\n\nOne step I added, that works great for me, is letting it write (api-level) tests after planning and before implementation. Then I’ll do a deep review and annotation of these tests and tweak them until everything is just right."
}
,
{
"id": "47108400",
"text": "Huge +1. This loop consistently delivers great results for my vibe coding.\n\nThe “easy” path of “short prompt declaring what I want” works OK for simple tasks but consistently breaks down for medium to high complexity tasks."
}
,
{
"id": "47108536",
"text": "Can you help me understand the difference between \"short prompt for what I want (next)\" vs medium to high complexity tasks?\n\nWhat i mean is, in practice, how does one even get to a a high complexity task? What does that look like? Because isn't it more common that one sees only so far ahead?"
}
,
{
"id": "47108616",
"text": "It's more or less what comes out of the box with plan mode, plus a few extra bits?"
}
,
{
"id": "47109564",
"text": "There are frameworks like https://github.com/bmad-code-org/BMAD-METHOD and https://github.github.com/spec-kit/ that are working on encoding a similar kind of approach and process."
}
,
{
"id": "47107125",
"text": "This is what I do with the obra/superpowers[0] set of skills.\n\n1. Use brainstorming to come up with the plan using the Socratic method\n\n2. Write a high level design plan to file\n\n3. I review the design plan\n\n4. Write an implementation plan to file. We've already discussed this in detail, so usually it just needs skimming.\n\n5. Use the worktree skill with subagent driven development skill\n\n6. Agent does the work using subagents that for each task:\n\na. Implements the task\n\nb. Spec reviews the completed task\n\nc. Code reviews the completed task\n\n7. When all tasks complete: create a PR for me to review\n\n8. Go back to the agent with any comments\n\n9. If finished, delete the plan files and merge the PR\n\n[0]: https://github.com/obra/superpowers"
}
,
{
"id": "47107151",
"text": "If you’ve ever desired the ability for annotating the plan more visually, try fitting Plannotator in this workflow. There is a slash command for use when you use custom workflows outside of normal plan mode.\n\nhttps://github.com/backnotprop/plannotator"
}
,
{
"id": "47107168",
"text": "I'll give this a try. Thanks for the suggestion."
}
]
</comments_to_classify>
Based on the comments above, assign each to up to 3 relevant topics.
Return ONLY a JSON array with this exact structure (no other text):
[
{
"id": "comment_id_1",
"topics": [
1,
3,
5
]
}
,
{
"id": "comment_id_2",
"topics": [
2
]
}
,
{
"id": "comment_id_3",
"topics": [
0
]
}
,
...
]
Rules:
- Each comment can have 0 to 3 topics
- Use 1-based topic indices for matches
- Use index 0 if the comment does not fit well in any category
- Only assign topics that are genuinely relevant to the comment
Remember: Output ONLY the JSON array, no other text.
50