Fission-AI

Stop letting your AI agent code from a vague prompt. OpenSpec has it write a plain Markdown spec, design and task list first, and you approve the plan before any code. Works with 30+ coding tools, Cursor, Codex and Copilot included. Fission-AI/OpenSpec t.co

How I spec out features with Superpowers How I spec out features with Superpowers I use Superpowers to work through features before handing them to a coding agent to implement. I want the agent to help me figure out what I'm asking for, including the decisions I haven't thought through yet. One feature I've been thinking about is letting a design doc contain additional documents. Take a Redis migration: you've got the spec and implementation plan, but now you want to rehearse it in staging and need a runbook. The initial request is pretty simple: let someone create that runbook inside the design doc. But if they follow the runbook, record a failed rehearsal, and then change the instructions, what happens to the record of that first attempt? Someone looking at it later needs to see the instructions that were actually used. That's already more specific than “let people add documents.” It's also something I'd want decided before an agent starts building it. Start with the problem For this feature, I'd give the agent the migration example and work through what the team needs to do: - Keep the staging runbook with the migration it belongs to. - Have a separate runbook for production. - Record what happened during each rehearsal. - Be able to look back at the instructions used for an earlier attempt. That brings up questions about ownership, permissions, and revisions. Can a runbook be shared across unrelated changes? Does it inherit the design doc's permissions? What happens to old references if someone renames or archives it? For the first version, I'd keep each supporting document attached to one change and use that change's permissions. Sharing a runbook across migrations and automatically executing its commands would be separate work. I want those decisions written down so the agent has a clear scope to work within. Where Superpowers helps Superpowers has a brainstorming skill that works through the request and possible approaches before moving into a design and implementation plan. It also tells the agent to inspect the project before asking questions the code or existing docs already answer. That last part matters to me. I don't want to point the agent at every relevant document or explain something it could find in the codebase. I want it to look first, then ask about what's still unresolved. With the runbook example, an agent could ask whether I want version history. I'd probably say yes, but that answer leaves a lot unspecified. A more useful question would be: > Someone follows revision 1 in staging and records a failed attempt. They change the instructions and try again using revision 2. What should someone reviewing the first attempt be able to see? That question puts me in the position of someone actually using the product. I can think about the engineer reviewing the failed rehearsal, what they're trying to understand, and what they'd need to see. Just asking “Do you want version history?” makes it easy to say yes without thinking through how anyone will use it. From that answer, we can get to a specific requirement: the first attempt has to keep a reference to revision 1. Editing the document can't change what that reference opens. Permissions need the same attention. Inheriting the parent's permissions should cover old revisions, search results, and access through the agent, as well as the page someone opens in their browser. These are the details I want to work through in the conversation. One thing I don't like One of my big gripes with using Superpowers is that I still have to tell the agent to do outside research. I mean searching the web, reading current documentation, and looking at how other people have approached the problem. I think an informed decision needs more than what the model learned during training. Reading my codebase gives it context about the project. I also want it to look for information outside the project that could change its recommendation. For the runbook example, I'd want it to investigate how other systems handle changes to a procedure after someone has used it. What tradeoffs did they make? What problems did they run into? That gives us more to consider when deciding how our version should work. I want the agent to recognize when that research would help and do it without me having to ask. Then show me the sources, explain how they apply to this feature, and make it clear which conclusions are its own. Having to remember to add “go research this” is a part of the workflow I'd like to improve. Keep the spec and implementation plan separate In my workflow, the spec describes what the change needs to accomplish. The implementation plan covers how to build it. Part of the spec for this feature could be: > A supporting document belongs to one design doc and inherits its access permissions. > > A recorded rehearsal can reference the exact document revision used. > > Editing, renaming, or archiving the document preserves that reference for authorized readers. > > Creating a runbook doesn't establish that the migration succeeded. The implementation plan can then work out how to store those references, which UI and agent operations need updating, and how to test them. The agent should also check what it can reuse. If the project already has revision history, I want the plan to explain how this feature fits into it. Introducing another versioning system would need a reason. Make the requirements testable I'd take the revision requirement and turn it into a scenario: 1. Create a staging runbook. 2. Record a failed rehearsal against revision 1. 3. Edit the runbook, producing revision 2. 4. Record another rehearsal against revision 2. 5. Open the first rehearsal's reference and confirm it still shows revision 1. An implementation could have a history page and still get this wrong. The scenario tells the agent exactly which behavior needs to hold up. The runbook describes the procedure. The rehearsal record says what happened when someone followed it. Both need to stay understandable after the instructions change. The same issue comes up elsewhere. If a pricing rule changes after an invoice is issued, you still need to know which rule produced that invoice. Thinking through a sequence like that helps me get more specific about what the feature needs to preserve. A starting prompt If you have Superpowers installed, you could adapt this: Use Superpowers to help me work through this feature before implementation. Problem: [Describe a specific situation and what someone needs to accomplish.] Look through the relevant code, docs, and previous decisions first. Tell me what already exists that affects this change. Identify decisions that would benefit from outside research and research them before recommending an approach. Look for current documentation and relevant examples of how others solved similar problems. Link the sources and explain how they affect your recommendation. Distinguish what the sources establish from your own conclusions. Ask about decisions we still need to make. Explain what the options would mean for the feature and recommend an approach. Make it clear when something is an assumption or your proposal. Write a spec covering the intended behavior, what's in and out of scope, unresolved questions, and concrete acceptance scenarios. Once we've agreed on the spec, create an implementation plan based on the codebase. Include how we'll check that the important behavior works. Give it an actual situation to work through. For a notification feature, for example, explain who needs to be notified, what happened, and what they need to do next. How are other people doing this? Superpowers is what I use, but I'd like to hear from people using other tools. Their docs describe a few approaches: | Tool | Documented workflow | | --- | --- | | GitHub Spec Kit | Takes a feature specification through a technical plan, tasks, and implementation, with project principles captured separately. | | OpenSpec | Keeps a proposal, requirements and scenarios, technical design, and tasks together for a change. The workflow includes archiving changes and updating specs. | | Kiro | Uses requirements, design, and task documents. Feature specs can start from requirements or from a technical design. | I'm also interested in people using their agent's planning mode and a Markdown file. Sometimes I just want to work through a problem without going through a full feature workflow. One thing I'm still thinking about is how to handle changes once implementation starts. The agent finds that an assumption was wrong, the plan changes, and the next session needs to know why. I keep a work log alongside the design doc to record what changed and why. How do you handle that in your setup? Do you update the spec, keep a separate record, or rely on the PR and conversation history? I'd also like to hear about a recent change where planning helped, or where it became more work than it was worth. Which tool were you using, and what did you end up keeping or skipping?

Huge props to Fission-AI for this brilliant architecture—spec-driven development is an absolute game-changer for AI coding workflows! 🚀 🔗 项目地址：Fission-AI/OpenSpec

让 agent 直接写代码，改完没人知道当初要什么？ OpenSpec 是 Spec 驱动开发框架，需求先写成 Markdown 规格再动手，每改动一个文件夹，含 proposal、规格、任务。 适合已有项目改造的人，规格别写太死，留迭代口子。 你先写规格，还是先写代码？ #Spec驱动 #AI编程 @grok Fission-AI/OpenSpec

Why I Run My Coding Agent Inside a Devcontainer --- title: "Why I Run My Coding Agent Inside a Devcontainer" published: true description: "I limit what Claude Code can touch to the inside of a container, so I can use auto mode without worrying, and I use named volumes to decide which environment reads and which one writes." tags: devcontainer, docker, claudecode, ai canonical_url: fukurou.kompiro.dev cover_image: fukurou.kompiro.dev --- I do almost all of my development inside a devcontainer. Visual Studio Code opens a container, and I run Claude Code inside it. When I had Claude Code make the demo GIF for my README, the whole recording happened inside the container too. I started using devcontainers long before coding agents came along. My reason for using them has changed since then. Now it is that I can decide how far an agent reaches, one container and one volume at a time. This post describes where I draw those lines. How I got started with devcontainers will be a separate post. Summary 1. Keeping an agent's reach inside a container lets me use auto mode without worrying. The agent is cut off from my browser sessions and API keys, and experimental tools never land on the host. 2. Named volumes let me separate the environment that reads from the one that writes. In the OpenSpec setup I'm trying on my own, the spec container reads the code under development, and the development containers read the specs. 3. I don't recommend devcontainers to everyone. They can be tuned in fine detail, so there is a lot to learn. Fixing the configuration, though, is something you can hand to an agent. Keep secrets and experiments out of the agent's reach I have three reasons for keeping the agent inside a container. The first is to make it easy to try development tools. Tools around coding agents come and go quickly, and I often want to try something experimental. I'd rather not install those tools on my Mac. If they live in a container and don't work out, I can just rebuild the container. The second is to keep secrets out of reach. My browser on the host has plenty of logged-in sessions, and the host also holds various API keys. This is also why I chose Playwright inside the container over computer use when making the demo GIF. The third is accidental file deletion. I hear about it less these days, but I did hear several stories of agents deleting files. If only the files inside the container are in play, the damage stays inside that container. With all three in place, I can use auto mode without worrying. Even when the agent asks me for confirmation less often, I still know what it can touch. There is one hole I leave open on purpose. Claude Code's configuration directory (~/.claude) is bind-mounted from the host. That way the container can use the authentication I completed on the host, and I can look back across the sessions of every project later. Use named volumes to decide who reads and who writes Once environments live in separate containers, some things need to be shared between them. I connect them with named volumes. In repositories that use compose, devcontainer.json points at a compose file through dockerComposeFile, and that file refers to a network and volumes created outside the project. By default, Docker Compose creates a project and a network for each compose file. Bringing a whole project up or down is convenient, but you can't rebuild just one service. So I manage networks and volumes separately from the projects. The simplest thing to share is credentials. In this blog's repository, the GitHub CLI and dev.to credentials live in named volumes. "mounts": [ "source=gh-config,target=/home/node/.config/gh,type=volume", "source=devto-config,target=/home/node/.config/devto,type=volume" ] The volumes outlive the container, so rebuilding it doesn't mean logging in again. At the same time, the credentials stay off my Mac and out of the repository. The source code itself lives in a named volume too. Bind mounts on a Mac are slow. With the code in a volume, another container can see the same code just by mounting that volume. Example: a spec container that only reads the code On my own, I'm trying out OpenSpec. OpenSpec is a tool for writing the spec before the code, and it accumulates change proposals (called changes) in a spec repository. Writing a change requires reading the existing source code. I also wanted the agent to read the code as it currently stands in development. So I mount the volume that holds the development container's source code into the spec container as well. The agent in the spec container doesn't get to rewrite that source code. In the spec container's Claude Code settings (settings.json), the source code volume is not listed in additionalDirectories. The agent that writes specs only reads the code. There is also a mount in the other direction. The development containers mount the spec volume. That lets the development side check how the specs are progressing. The backend and the frontend are developed independently in their own containers, and both see the same specs. | Container | Mounts | What the agent writes | | --- | --- | --- | | Spec | The spec volume and the volume with the code under development | Specs only | | Backend development | The backend source code and the spec volume | Backend code | | Frontend development | The frontend source code and the spec volume | Frontend code | Containers decide what an agent can touch, and volumes decide which environment reads and which one writes. With the read and write directions set per container, I can run several agents side by side without them trampling each other's workspaces. Keep the production image minimal and bring your own tools There is also a line around what goes into the container. The image I ship to production should contain only the files the service needs to run. A development environment, on the other hand, needs room for whatever tools help me develop. So I build on the production Dockerfile and add development tools with devcontainer features and dotfiles. I manage dotfiles with yadm and tool versions with mise. One reason I bring my dotfiles into the container is worktrees. Developing with agents means using a lot of worktrees. For reopening and switching between them, I want the tools my hands already know, such as fzf. The work may happen inside a container, but the environment I operate by hand should feel the same as always. Devcontainers are not for everyone Devcontainers have their annoyances. Changing devcontainer.json means rebuilding the container. Every small tweak means waiting for a rebuild, so I'm careful when I edit it. Disk usage doesn't bother me. They also limit your choice of editor. Newer IDEs built for AI agents, such as Orca, are awkward to combine with devcontainers. That said, the Claude Code extension for Visual Studio Code is improving quickly too. Would I recommend devcontainers to everyone? No. They can be tuned in fine detail, which makes them hard to use casually, and beginners have a lot to learn. Still, if you ask Claude Code or Codex to fix your devcontainer configuration, they do a good job. If you want your development environment as code that you can reproduce, I do recommend them. Takeaways I keep using devcontainers because they let me decide, with containers and volumes, how much I hand to an agent. Inside a container, the agent can work in auto mode while my secrets and experimental tools stay separated from the host. Connected by named volumes, environments can share the same code and specs while keeping the reader and the writer apart. The OpenSpec setup is still an experiment. For a while, I'll watch how splitting the spec and development containers changes the way I write and work through changes.

어제랑 같은 질문인데 답이 달라요 원리 한 개: 문맥 창 한계 1. 고정된 문맥 창 2. 요약으로 자리 만들기 3. 주목의 희석 오늘의 사례 리포: google/elephant-goldfish-model google/elephant-goldfish-model 오늘의 다른 상위 픽: · HKUDS/DeepTutor — HKUDS/DeepTutor · Fission-AI/OpenSpec — Fission-AI/OpenSpec 🗂 오늘 분석한 10개 전부와 지난 기록: onerepoaday.onerepoaday.workers.dev 📬 매주 일요일, 이번 주 가장 뜬 AI 오픈소스 Top 10을 메일 한 통으로 보내드립니다 page.stibee.com 뉴스가 아니라 개발자의 행동(Star)을 추적합니다. 매일 새벽 5시 자동 업데이트. #Shorts #AI #오픈소스 #GitHub [en-US] I asked the same question as yesterday, but the answer is different One Principle: Context Window Limitations 1. Fixed Context Window 2. Making Space with Summary 3. Dilution of Attention Today's Case Repo: google/elephant-goldfish-model google/elephant-goldfish-model Other Top Picks Today: · HKUDS/DeepTutor — HKUDS/DeepTutor · Fission-AI/OpenSpec — Fission-AI/OpenSpec 🗂 All 10 analyzed today and past records: onerepoaday.onerepoaday.workers.dev 📬 Every Sunday, we send you the Top 10 trending AI open sources of the week via email page.stibee.com We track developer actions (Stars), not news. Automatically updated every day at 5 AM. #Shorts #AI #OpenSource #GitHub

고수는 AI한테 먼저 계획을 쓰게 합니다 오늘 뜯어본 오픈소스: Fission-AI/OpenSpec AI 코딩 어시스턴트를 위한 스펙 중심 개발 툴 Fission-AI/OpenSpec 📌 바로 써 보기 brew install openspec 첫 지시로 이렇게 시켜 보세요: "이 프로젝트를 /opsx:explore로 읽고 다크 모드 계획만 작성해. 코드는 건드리지 마." 💡 여러 저장소를 하나로 묶는 Stores는 아직 베타예요. 그래서 묶기 전엔 한 저장소부터 시작해요. AI로 협업하는 팀에 특히 좋아요. 오늘의 다른 상위 픽: · pbakaus/impeccable — pbakaus/impeccable · HKUDS/DeepTutor — HKUDS/DeepTutor 🗂 오늘 분석한 10개 전부와 지난 기록: onerepoaday.onerepoaday.workers.dev 📬 매주 일요일, 이번 주 가장 뜬 AI 오픈소스 Top 10을 메일 한 통으로 보내드립니다 page.stibee.com 뉴스가 아니라 개발자의 행동(Star)을 추적합니다. 매일 새벽 5시 자동 업데이트. #Shorts #AI #오픈소스 #GitHub [en-US] Pros make AI write the plan first Open Source I Explored Today: Fission-AI/OpenSpec Spec-driven development tools for AI coding assistants Fission-AI/OpenSpec 📌 Try it out right away brew install openspec Try this as your first instruction: "Read this project with /opsx:explore and write only the dark mode plan. Don't touch the code." 💡 Stores, which combine multiple repositories into one, are still in beta. So, start with a single repository before combining them. It is especially good for teams collaborating with AI. Other Top Picks of the Day: · pbakaus/impeccable — pbakaus/impeccable · HKUDS/DeepTutor — HKUDS/DeepTutor 🗂 All 10 analyzed today and past records: onerepoaday.onerepoaday.workers.dev 📬 Every Sunday, we send you the Top 10 trending AI open sources of the week via email page.stibee.com We track developer actions (Stars), not news. Automatically updated every day at 5 AM. #Shorts #AI #OpenSource #GitHub

AIと2週間で、問題7,000問の金融教育ゲームを作った開発プロセス【OpenSpec × Claude Code】 はじめに 新社会人向けのお金の学習ゲーム「マネラン」を、AIのコーディングエージェントと一緒に作っています。 給与明細・税金・社会保険・NISA・詐欺対策などを、1回3〜5分のクイズで学べる、Duolingo のようなアプリです。 最初のコミットから約2週間で、次のところまで来ました。 項目 数 コミット 106 完了した仕様変更(OpenSpec の change) 54 仕様(capability) 33 コース / ユニット / レッスン 17 / 72 / 713 問題 7,130問(8種類の出題形式) 用語集 417語 テスト Flutter 54ファイル、pgTAP 11ファイル、Edge Function・Web のテスト 構成は Flutter(iOS / Android / Web)+ Supabase(Auth・Postgres・Edge Functions)+ Next.js(LP と管理画面)です。 この記事では「AIに何を任せて、人は何をしたか」「どうすれば2週間でここまで進むのか」を、実際のリポジトリの中身を見せながら紹介します。 AIで開発してみたい人、AIに書かせたらコードが散らかって困っている人の参考になればうれしいです。 1. まず仕様書を書いて、AIに「地図」を渡す 開発を始める前日に、製品仕様書(docs/product-spec.md)を書きました。 誰のためか(MVPは入社1〜2年目の新社会人) 何を解決するか(「手取りがなぜ減るのか分からない」「詐欺の標的になりやすい」など) 何をしないか(金融商品の勧誘・個別の投資助言はしない、コインを現金に換えない) ゲームの仕組み(育つ貯金箱、間違えた問題が敵になる「ミスモンスター」、詐欺メッセージを見抜く「詐欺バスター」など) ポイントは「やらないこと」まで書くことです。 AIは頼まれていない機能も気を利かせて作りがちですが、スコープ外がはっきりしていると、提案がぶれにくくなります。 2. OpenSpec で「仕様 → 設計 → タスク → 実装」を1変更ずつ回す このプロジェクトの中心にあるのが OpenSpec です。 変更のたびに、次の4つの文書を AI と一緒に作ってから実装に入ります。 openspec/changes/<変更名>/ ├── proposal.md # なぜ・何を変えるか・影響範囲 ├── specs/ # 要件と受け入れシナリオ(WHEN / THEN) ├── design.md # 設計上の決定と、その理由 └── tasks.md # 実装タスクのチェックリスト 実装が終わったら archive して、変更の内容を正本の仕様(openspec/specs/)に取り込みます。 2週間で archive した変更は54件。1日あたり4件ほどのペースです。 2026-10-15-migrate-to-supabase 2026-10-16-add-challenge-mode 2026-10-17-add-marketing-site 2026-10-21-enhance-lesson-game-effects 2026-10-22-add-profile-image-upload 2026-10-25-add-mascot-answer-feedback 2026-10-27-add-slack-event-notifications ... なぜ「いきなり実装」させないのか AIに「〇〇を作って」と直接頼むと、それらしいコードはすぐに出てきます。ただ、規模が大きくなるにつれて次のことが起きます。 前に決めたこと(データの持ち方、命名、画面の余白)と違う実装が混ざる 「なぜこうなっているのか」が誰にも分からなくなる レビューする人が、差分のコードだけを見て判断しなければならない 先に proposal と design を書かせると、人がレビューするのは数百行のコードではなく、数十行の日本語になります。 方向がずれていれば、コードを書く前に直せます。 タスクには「どう確かめるか」まで書く tasks.md の各タスクには、完了の条件を具体的に書きます。たとえば Slack 通知を追加したときのタスクはこうです。 - [x] 2.3 supabase/tests/90_auth_notify_test.sql(pgTAP)で、判定関数が 2.1 の各経路を 正しく分類すること(確認前のメールは null、確認と同時のログインは登録だけ、 トークン更新は null、ゲストは null)と、Vault が無いときにトリガーが何もせず auth.users の更新が成功することを確かめて supabase/tests/run.sh が通る 「実装する」ではなく「〇〇のテストが通る」「ブラウザで△△を確かめる」で終わらせると、AIが自分で完了を判定でき、人の確認も楽になります。 3. AIへの「憲法」を1か所に書く OpenSpec の config.yaml には、すべての変更で守るべき前提を書いておけます。マネランではこう書いています(抜粋)。 context: | 成果物(proposal/specs/design/tasks)は日本語で書く アプリはFlutter(iOS/Android/Web)。ゲームのルールは純粋な Dart のドメイン層(app/lib/domain)に置く 利用者データの書き込みは RLS と Postgres 関数(RPC)で守る。複数の表にまたがる反映は1つの RPC(1トランザクション)で行う コイン・利息・ストリーク・XPの不正対策は、サーバー側の検証で行う。日付判定にはサーバー時刻(now())を使い、端末時刻を使わない 有料化(課金・プレミアムプラン・広告)は当面行わない 実在の金融商品・企業名・サービス名を学習コンテンツや詐欺ケースに使わない。投資助言・勧誘にあたる表現を入れない ここに書くのは「コードを読んでも分からない決定」だけです。 ファイル構成のようにコードを読めば分かることは書きません。逆に「端末時刻を信じない」「広告は入れない」のような方針は、書いておかないと AI は毎回それらしい別案を出してきます。 4. 大きな方針転換も、早いうちなら AI と一緒に一気にやれる 開発2日目に、バックエンドを Firebase から Supabase に移すと決めました。 理由は、週ごとのリーグ(昇格・降格)などのサーバー処理を安全に作るには、Firestore のルールだけでは足りなかったからです。本番のデータがまだ無く、移行のコストが最も低いタイミングでした。 この変更も、proposal で「なぜ今か」「何が BREAKING か」「どこに影響するか」を書いてから実装しています。 学習結果の反映を1つの Postgres 関数(apply_activity)にまとめ、学習日はサーバー時刻で決める 増分の上限・二重反映をサーバー側で検証する RLS で「本人と運営だけが読み書きできる」ことを pgTAP でテストする ゲームのルール(貯金箱の利息・ストリーク・XPの計算)は Flutter にも Supabase にも依存しない純粋な Dart の層に分けておいたので、ドメイン層は一行も変えずにバックエンドだけを入れ替えられました。 AI に任せる量が多いほど、こうした「変わりにくい部分」と「入れ替わる部分」の境目が効いてきます。 5. コンテンツ7,000問も AI と作る。ただし「質の基準」が先 問題は全17コースで7,130問あります。これを手で書くのは現実的ではないので、AI に下書きを作ってもらっています。 ただ、何も決めずに作らせると、次のような「AIっぽい問題」が大量にできます。 正解だけが長くて丁寧なので、読まなくても当てられる 誤答が「何も起きない」「請求額が半分になる」のように明らかにおかしい 正解がいつも「専門家に相談する」 そこで content/QUALITY.md に問題の質の基準を書きました。 誤答の選択肢 誤答は、実際によくある誤解・ありがちな計算ミス・似た制度との取り違えから作る。 - よい例(数字): 正しい計算で使わなかった値・時価と簿価の取り違え・年と月の取り違え・旧制度の数字 - 正解だけが長い・丁寧・「確かめる」「相談する」で終わる、という形で正解が分かってしまわないようにする - 「専門家に相談する」を正解にするのは、本当に個別の判断が要る場面だけ さらに、形式のルール(1レッスン10問、問題タイプ3種類以上、難易度の配分、用語集にない用語を使わない など)は、content/tools/validate_content.py で機械的に検証します。 「質」は文章で基準を渡し、「形式」はスクリプトで検証する。この2段構えで、量と質を両立させています。 一斉にやらせない コンテンツを大きく書き直すとき、最初は複数のコースを並列で一斉に AI に任せていました。結果は、コースごとに基準の解釈がばらつき、見直しが追いつかなくなりました。 今は「1コース書き直す → 検証 → 人が読む → 次のコース」と順番に進めています。 AI は並列にいくらでも動かせますが、ボトルネックは人のレビューです。レビューできる速さに合わせるほうが、結局早く終わります。 なお、お金の制度は改定されるため、問題はすべて下書き扱いにし、FP などの専門家の監修を経て公開する流れにしています。AI が書いた専門的な内容を、そのまま「正しいもの」として出さないためです。 6. デザインの統一も「仕様」にする UI の改善も OpenSpec の変更として扱っています。 unify-page-margins(全画面の余白をそろえる) vibrant-gold-theme → unify-dark-game-theme(色をトークンで一元管理する) redesign-badges-ui、redesign-piggy-screen、reorganize-status-screens など AI に画面を1枚ずつ作らせると、画面ごとに余白や色が微妙に違うものができあがります。 「余白はこの値」「色はこのトークンから選ぶ」を spec にしておくと、新しい画面を作るときも AI が既存のルールに合わせてくれます。 7. 「動くまで」ではなく「運用できるまで」をAIとやる アプリ本体以外にも、運用に必要なものを同じ流れで作っています。 Next.js の LP と、content/ を差分で取り込む管理画面(Google ログイン + TOTP) GitHub Actions での Flutter Web / LP / Supabase のデプロイ Firebase Analytics / サイト分析と、管理画面の KPI ページ 登録やログイン、LP のボタンのクリックを Slack に通知する Edge Function SEO(構造化データ・サイトマップ・Search Console) 個人開発では後回しにしがちな部分ですが、AI がいると「ついでにやっておく」ハードルがかなり下がります。 まとめ:AI開発で効いたこと 仕様書に「やらないこと」まで書く。AI の提案がぶれにくくなる いきなり実装させず、proposal / design / tasks を先に書かせる。人は日本語をレビューすればよくなる タスクの完了条件を「〇〇が通る」で書く。AI が自分で完了を判定できる コードから読み取れない決定だけを、1か所(config)にまとめて書く 変わりにくいドメインと、入れ替わるインフラを分ける。大きな方針転換にも耐えられる 質は文章の基準で、形式はスクリプトで守る 人のレビューの速さに合わせて、1つずつ進める AI が速く書けるようになった分、人の仕事は「何を作るか決めること」と「確かめること」に寄っていきました。 コードを書く時間が減った代わりに、仕様と基準を書く時間が増えた、というのが2週間やってみての実感です。 さいごに:マネランを遊んでみてください 🐷 マネランは、1回3〜5分で、社会人に必要なお金の知識が身につく無料の学習ゲームです。 「額面と手取りの違い」「住民税が2年目から増える理由」「NISA と iDeCo の使い分け」などを、クイズで少しずつ 続けるほど育つ貯金箱で、複利のしくみを体験 間違えた問題は「ミスモンスター」になって再登場。倒して図鑑を埋めよう 本物そっくりの偽メッセージを見抜く「詐欺バスター」で、詐欺への備えも 登録なしのゲストでもすぐに始められます。 この記事を読んで「AIで作るとこうなるのか」と思った方も、「給与明細、実はよく分かっていない…」という方も、ぜひ一度遊んでみてください。 👉 アプリ: maneran.web.app 👉 紹介ページ: maneran-lp.web.app 遊んでみた感想や、「こんな問題がほしい」「ここが分かりにくい」といった声も大歓迎です。コメントでお気軽にどうぞ!

The OpenSpec update I want first is the one that writes nothing I added a local note to a generated OpenSpec command, asked what an update would do, and checked the files afterward. The preview reported a replacement. Every file hash stayed the same. Then I ran the update. The local note disappeared. That is a useful distinction to see before your coding assistant starts following a different set of instructions. OpenSpec 1.15.0 adds update --dry-run, with a JSON form that lists planned file actions. It also ships a standalone CLI. The interesting part for an existing project is getting to inspect the replacement before accepting it. [1] !Executed OpenSpec fixture: add a local note, preview an update with unchanged file hashes, then apply the update and observe that the note is removed. Original diagram of the checked fixture below. It describes generated instruction files, not an AI coding session. The version number wasn’t the question An assistant integration has more moving parts than the executable. There are generated commands, skills, and the project’s own context. A current CLI does not tell you that every generated file matches its current template—or that you want it to. My fixture starts with a clean Claude integration and deliberately customizes .claude/commands/opsx/explore.md. It then checks three separate things: - Did the preview identify that command as an update? - Did previewing leave both the project and isolated configuration trees untouched? - Did applying the update actually replace the customization? The last check matters. A plan is useful evidence about an intended action; the resulting files establish what happened. 🔎 Here’s the output from OpenSpec 1.15.0: preview changed files: 0 custom command: update local note retained after update: False remaining planned changes: 0 The disappearing note is deliberate in this disposable example. In a real project, it could be the sentence you wanted your assistant to keep remembering. The update cannot decide whether that sentence was important to you. Run the same disposable check For a POSIX shell with Python 3.10 or newer, create a scratch directory and install the pinned standalone release into it. The installer selects a compatible release asset and checks its checksum. Other supported installation routes are in the project’s documentation. [2] mkdir openspec-preview-lab cd openspec-preview-lab curl -fsSL https://raw.githubusercontent.com/Fission-AI/OpenSpec/v1.15.0/scripts/binary/install.sh -o install.sh OPENSPEC_VERSION=v1.15.0 OPENSPEC_INSTALL_DIR="$PWD/.tools" sh install.sh .tools/openspec --version Save the following as preview_demo.py, then run python3 preview_demo.py from that directory. It uses a temporary project and separate configuration/data directories. The claude tool choice generates integration files; this script does not launch Claude or make a model request. 🧪 import hashlib import json import os import subprocess import tempfile from pathlib import Path binary = Path(os.environ.get("OPENSPEC_BIN", ".tools/openspec")).resolve() def manifest(root): return {str(p.relative_to(root)): hashlib.sha256(p.read_bytes()).hexdigest() for p in root.rglob("*") if p.is_file()} with tempfile.TemporaryDirectory() as directory: root = Path(directory) project = root / "project" project.mkdir() env = {**os.environ, "XDG_CONFIG_HOME": str(root / "config"), "XDG_DATA_HOME": str(root / "data"), "DO_NOT_TRACK": "1", "OPENSPEC_TELEMETRY": "0"} def run(*args): return subprocess.run([str(binary), *args, str(project)], env=env, check=True, capture_output=True, text=True).stdout run("init", "--tools", "claude", "--profile", "core", "--no-animation") command = project / ".claude/commands/opsx/explore.md" command.write_text(command.read_text() + "\nLOCAL_NOTE: review this customization.\n") before = manifest(root) plan = json.loads(run("update", "--dry-run", "--json")) assert manifest(root) == before edits = [c for c in plan["changes"] if c["path"] == ".claude/commands/opsx/explore.md"] assert len(edits) == 1 and edits[0]["action"] == "update" print("preview changed files:", len([p for p in before if manifest(root).get(p) != before[p]])) print("custom command:", edits[0]["action"]) run("update") assert "LOCAL_NOTE" not in command.read_text() print("local note retained after update:", "LOCAL_NOTE" in command.read_text()) again = json.loads(run("update", "--dry-run", "--json")) assert again["changes"] == [] print("remaining planned changes:", len(again["changes"])) The manifest includes relative file paths and content hashes. Comparing the complete dictionaries catches additions and deletions as well as changed contents. Merely checking modification times would be a weaker test: a file can be rewritten with identical bytes. The isolated configuration directory is intentional. The preview can include OpenSpec configuration actions alongside project instruction changes. I want the disposable check to include those effects without borrowing settings from another project. The source defines XDG_CONFIG_HOME as a supported override. [3] Read the action, then inspect the difference The JSON describes which files would be added, updated or deleted. That is not a semantic review of the new instructions. action: update cannot tell you whether a sentence became less precise, a local restriction disappeared, or a workflow now expects another artifact. ⚠️ My mistake would be treating a clean preview as permission to replace everything. “This command is generated” and “this command contains no useful local changes” are different facts. For a maintained project, I’d first save the current files in version control. I’d inspect the preview, apply the intended update, then read the actual diff before using the assistant integration. If a customization belongs in a project-owned instruction file, move it there deliberately and check that the relevant tool reads it. Avoid assuming every tool has the same override rules. ✅ This fixture checks one generated Claude command and the isolated trees around it. It establishes the preview’s behavior for that case. It does not establish preservation rules for every integration, validate the meaning of generated instructions, or prove that an agent will obey them. The useful addition is modest and practical: an update now has a readable “before” state. I’d rather discover the disappearing sentence there than after asking an assistant why it stopped doing something. References 1. OpenSpec 1.15.0 release: standalone install and update dry run. 2. OpenSpec installation documentation. 3. OpenSpec 1.15.0 configuration-directory implementation. Asset credit: original diagram of the executed disposable OpenSpec fixture. AI disclosure AI was used to draft the article.

OpenSpec - Spec-Driven Development for AI Coding Assistants OpenSpec is a spec-driven development framework with over 73,000 GitHub stars and 5,000 forks. Perfect for both solo and team projects, it helps you and your AI stay honest on a single repo. Learn more at openspec.dev. Link in first comment 👇 #OpenSpec #AI #CodingAssistants 🔗 Fission-AI/OpenSpec