Sometimes you just want to update the docs. You spot a typo in a readme, or a feature behavior changes, and you want to fix it without ceremony. You don’t want to clone the repository, spin up a local environment, or think that hard. I was on a trip to the beach with only my tablet, so i thought I’d build a tool between hikes.

We have great tools for personal knowledge bases. Notion is excellent for team wikis. Obsidian is perfect for your private vault. But project documentation belongs in the repository, right next to the code it describes. Less is more, just give me quick access.

That is the problem Wikidown solves. It is a markdown wiki that lives in the /docs folder of your repository. But more importantly, it is a product of how software gets built right now.

The Outer Loop

We are in the agentic engineering era, and the workflow has changed. There is an outer loop and an inner loop.

The outer loop is for viability. You have an idea. You sit down with an AI agent and you vibe code. You work through concepts without digging into the syntax. You describe the shape of the thing, the agent writes the boilerplate, and you steer. You can get to a working Minimum Viable Product in a weekend.

That is exactly how Wikidown was built. The entire core logic, the CLI, the MCP server, and the Blazor editor were scaffolded in a vibing phase. The agent did the typing. I did the thinking.

When the MVP is complete, you pass it off to the inner loop. That is where the developer gets hands-on, refactoring, fixing the edge cases, and hardening the deployment topology. This post is the handoff moment. The vibing phase is done. Here is what came out of it: Wikidown.org

The Spec is the Guardrail

Wikidown is not just a web editor. It is a set of guardrails that make your documentation equally useful to humans and AI.

Without those guardrails, a /docs folder is just a pile of markdown files. An AI agent might read them, but it will not know how they relate to each other. It will break your links when it renames a file. It will ignore your ordering rules.

Wikidown fixes this by enforcing a strict, simple format specification. Page files use hyphenated titles on disk, like Release-Notes.md. Subpages live in a folder with the exact same base name next to the parent page. Ordering is controlled by a plain text .order file in each folder, listing one page base-name per line. And internal links use the title path, like /Getting-Started/Format, ignoring the hyphens and file extensions entirely. The full spec is in the Wikidown docs.

This format happens to be 100% compatible with Azure DevOps Wiki, which is a nice bonus if you are already in that ecosystem. But the real value is that the spec gives the AI agent a mental model of your documentation.

Deterministic Docs from Non-Deterministic Models

Large Language Models are inherently non-deterministic. If you tell an agent to “update the docs,” it might rename a file, it might create a new folder, or it might just rewrite the README. You cannot build a reliable documentation system on vibes alone.

To enforce the spec, Wikidown ships a core library, a CLI, and a Model Context Protocol (MCP) server. These tools act as the deterministic bridge between the LLM and your file system.

dotnet tool install -g Wikidown.Mcp

# wire into .mcp.json or .vscode/mcp.json

The MCP server exposes nine specific tools to the agent: read, write, list, move, delete, reorder, search, walk, and new. When you wire the Wikidown MCP server into Claude Code or Copilot, you are giving the agent a constrained API for the wiki.

If the agent wants to rename a page, it cannot just move the markdown file. It has to call the wiki_move tool, which deterministically renames the file, moves the subpage folder, and updates the parent .order file. The agent provides the intent; the MCP server enforces the rules. You get deterministic documentation behavior from a non-deterministic model, and you do not have to babysit it.

The Editor and the Login

For the humans, there is a Blazor WebAssembly Progressive Web App. You go to the site, connect your repository, and get a side-by-side markdown editor with live preview.

Visit the Wikidown.app Connect page. Sign in with GitHub, pick a repo, and go.

So the flow is simple: login with GitHub, pick a repo, do a quick edit. The OAuth proxy is a small Azure Functions app that handles the token exchange. The tokens stay in your browser’s localStorage. The backend never stores them, and it never sees your repository contents.

Handoff

The wiki eats its own dogfood. The Wikidown repository’s own /docs folder is a Wikidown wiki, edited through the CLI and the MCP server. That is the only honest way to know if the thing works.

The outer loop is done. The MVP is viable. Now we see how it holds up in the inner loop. If you want to submit issues, the repo is open-source.

This is a short video about a session where I had two agents running at the same time on different tasks in the same repo. Nothing exotic. Just a useful pattern worth showing.

The Setup

A new Oqtane release came out with page directive support. If you build Oqtane modules, you know the manual step this replaces: after scaffolding a module, you go into the admin panel and add a page for it by hand. Now you can put a directive in the module’s Index component and Oqtane creates the page automatically on startup.

That is the kind of feature that shows up under ‘Other’ in a changelog and saves you ten minutes every time you start a new module for the rest of your life.

I wanted to get that directive into all five module index files in the Ten Trees repo. So I gave that task to Claude Code, pointed it at the repo, and let it go.

Meanwhile

We had just done a March check-in call with the Ten Trees customer. The zoom summary and full transcript were already sitting in the specs folder. While Claude Code was working on the directive task, I opened GitHub Copilot in agent mode and asked it to read the transcript, compare it against the existing BDD feature files, and flag anything that needed updating.

It did a proper gap analysis. Cohort management, tree mentors, educator roles, platform admin versus program admin. Most of what the customer said was already covered in the feature files. One scenario needed a minor update. The agent touched the project plan as well, which I did not ask for but was not wrong.

One file changed. I committed it and pushed to main.

Skills

Claude Code picked up the Oqtane module development skill from the repo automatically. That skill file lives at .claude/skills/kanban/SKILL.md and tells the agent what Oqtane module files look like, where things go, and to go pull the latest Oqtane source as a reference without tracking it.

That last part matters. The agent cloned the Oqtane framework repo to use as a reference, found the page directive pattern in the new release, and applied it consistently across all five modules. That is the kind of context that used to live in your head or in a README file nobody read before starting a new task.

I keep a few skills available at github.com/markdav-is/marks-skills. The accessibility and validation skill for Blazor and Bootstrap is useful. There is also a Kanban skill that manages a task list in the file system directly, which sounds odd but turns out to be faster for agent-heavy work than hitting an MCP server on every operation.

The Pull Request

Claude Code opened a PR when it was done. The change was four attribute lines across five files. For something this small I skipped the review step and merged it directly.

For a more substantial change the right move is to have the second agent review the first agent’s pull request. One checks the other’s work. That is a workflow worth building into the habit even when it feels like overkill, because the times it catches something are the times you are glad you did it.

What This Is

This is not a story about replacing developers or burning through tokens on autopilot. Both agents were working inside tools I was already using, on tasks I already knew how to do. The agents handled the execution so I could be thinking about something else while the work was getting done.

When I launched the app after the merge, the pages showed up at the top of the screen. One for each module. That is a small thing. The Ten Trees customer can now add a village named Sherwood and a contact named Mark without me having to configure a nav menu by hand. Small things add up.

Catch you next time.

The Tool You Already Have Is Probably The Wrong One

You’re a solo dev, or maybe a team of three. You ship code. And at some point someone suggested putting the work in Jira, or Linear, or Trello, or Notion, and now you have a second job: maintaining your project management system. The board has columns no one touches. The tickets have fields no one fills in. The integrations require credentials no one can find.

Meanwhile, your AI coding agent has no idea any of this exists. It can read your code, your tests, your commit history. It cannot read your Jira backlog. The thing that knows the most about your codebase has no idea what you’re trying to build next.

That’s not a workflow. That’s two workflows that don’t talk to each other.

A Kanban Board Is Just Four Folders

Here’s the whole idea: a Kanban board is a directory. Columns are subdirectories. Tasks are markdown files. You move a task by moving a file.

That’s it. No database. No server. No login screen. No pricing tier that unlocks the feature you actually need.

How It Works

The structure is deliberately boring:

my-project
kanban
backlog
add-export-feature.md
todo
fix-auth-bug.md
doing
update-readme.md
done
initial-setup.md

Each task file is a markdown document with a little YAML frontmatter at the top:

---
id: fix-auth-bug
title: Fix auth token expiry bug
created: 2025-03-01
priority: high
---
## Notes
Token refresh fails silently after 24h.
## Checklist
- [ ] Reproduce the bug
- [ ] Trace token refresh path
- [ ] Write a failing test
- [ ] Ship the fix

The Agent Angle

This is where things get interesting. Your AI agent already knows how to read files, write files, and move files around. It does this all day for your source code. KanBanLess just extends that to your task board.

Drop a SKILL.md file into .claude/skills/kanban/ or .github/skills/kanban/ and your agent now has the full API: how to read the board, how to create a task, how to move one, how to mark checklist items done. No MCP server. No plugin marketplace. No API key to rotate. Just a text file describing a convention.

The agent that just fixed your bug can, in the same session, move that task to done. The thing managing your code can manage your board. They’re the same file system.

Git Is Your History

Commit your .kanban/ directory alongside your code. Now task movement shows up in your diffs. A PR description can reference a task file directly. You can see exactly when something moved from doing to done, and what commit caused it. Your project history and your task history are the same history.

No integrations. No webhooks. No “connect your GitHub to your project management tool” dance.

There’s a CLI Too

For people who prefer typing to folder-browsing, there’s a cross-platform .NET global tool:

dotnet tool install -g KanBanLess
kanban add “Ship the thing”
kanban move fix-auth-bug doing
kanban list todo

If you’re not in a .NET environment, the bash fallback is four functions and a mv command. The whole thing fits in your .bashrc.

What’s Coming

A desktop client is in the works. Drag-and-drop columns, offline-first, reading the exact same files on disk. No sync conflicts because there’s no server to sync with. The file system is the database, and it’s already on your machine.

The desktop client is optional. The system works without it. That’s sort of the whole point.

Try It

The repo is at github.com/markdav-is/KanBanLess. Drop the skill file into your next project, point your agent at it, and see what happens when your board lives where your code lives.

The tools that don’t get in the way are the ones you keep using. Most project management software forgets that. KanBanLess is trying to remember it.

Less is more.

If you’ve built more than one Oqtane module, you know the drill. You fire up the web admin, walk through the module creation wizard, wait for the scaffolding to land in your solution, then spend the next twenty minutes cleaning up files and wiring things together the way you actually want them.

The wizard is fine, but if you’re doing this repeatedly, or on a machine without a running Oqtane instance handy, here’s a scriptable template.

Before You Start: Official Application Template

This is a module item template, not an Application template. If you are starting from scratch, you need an Application first. Oqtane shipped an official application template with the 6.2 release last year that sets up a proper Oqtane Application solution structure, complete with correct project references, and a working debug configuration. Get that stood up before you reach for the module template.

Official application template: Oqtane 6.2.1 Released

Once your application solution exists, come back here.

What It Does

MarkDav.Oqtane.Module.Template is a dotnet new item template. Install it once, then scaffold a complete Oqtane module from the command line.

dotnet new install MarkDav.Oqtane.Module.Template

dotnet new oqtane-module -n MyModule --namespace MyCompany.MyModule

That produces the full stack: Client Blazor components, Services, an ASP.NET Core controller, EF Core DbContext with migrations, repository, shared entity model and interface, and more. Fifteen-plus files, ready to go, without clicking through anything.

A Couple of Things Worth Noting

The template tries to auto-detect your root namespace from the nearest .csproj file via MSBuild binding. If you’re running the command from inside a project directory, you can usually skip the --namespace flag entirely. If running from the solution folder, you need to set the --namespace flag manually.

There’s also no IServerStartup class generated. Oqtane auto-registers services that implement its service marker interfaces, so you don’t need one. This trips up a lot of newcomers because older examples and tutorials generate that class by default and then people spend time debugging registration problems that shouldn’t exist.

Remix to your own flavor

This template follows the official Oqtane module template. My goal was to make module creation scriptable. The positive upshot is that you can fork this repo and template your custom module choices.

Links

NuGet: MarkDav.Oqtane.Module.Template

GitHub: markdav-is/Oqtane.Module

Oqtane Framework: oqtane/oqtane.framework

The repo is at github.com/markdav-is/Skiller. MIT licensed. The install takes about thirty seconds. If your agent has ever forgotten something you wish it hadn’t, give it a look.

Today’s AI coding agents’ biggest drawback isn’t hallucinations or cost, but their lack of memory between sessions. Every developer faces this: you spend ages debugging, your AI figures out the fix, and life moves on. Weeks later, the same issue returns—yet the agent starts fresh, oblivious to past solutions.

This results in wasted effort, with valuable discoveries lost once a session ends. Team knowledge is scattered in heads, Slack threads, or cryptic code comments. Until AI agents gain persistent memory, maintain a shared troubleshooting log or update documentation to capture and reuse insights for future problems.

I built Skiller to fix this.

What Skiller Does

Skiller is an open-source tool that gives AI coding agents persistent memory by capturing significant discoveries—like debugging breakthroughs or complex fixes—during coding sessions. It stores these insights as structured markdown “skills,” which agents automatically load in similar situations, ensuring solutions are reused efficiently. Skiller requires minimal setup: just add it to your repository alongside agents like GitHub Copilot or Cursor.

By recording valuable knowledge directly from developer actions, Skiller replaces outdated wikis or runbooks, making information instantly accessible when relevant. For example, it documents tricky dependency resolutions so future developers receive immediate, step-by-step guidance, preventing repeated mistakes.

Skiller leverages modern AI agents’ native skills systems, supporting progressive loading. As a “meta-skill,” it observes your workflow, extracts non-trivial solutions into skill files, and enables teams and projects to benefit from prior experience, promoting actionable and timely knowledge sharing.

The Quality Problem

Auto-generated documentation often leads to overloaded knowledge bases, filled with low-value entries that make it hard to find useful information. For instance, generic advice like “Restart the server if it crashes” adds clutter, while specific guidance such as “If service X fails with error Y, apply patch Z and restart only the affected module” is genuinely helpful.

Skiller combats this by evaluating every skill entry for reusability, specificity, and effectiveness before it’s saved. Only high-quality, actionable solutions are kept, ensuring the library remains practical and up-to-date.

The description field is optimized for semantic matching, allowing the system to understand user intent and surface relevant skills quickly. This focus ensures teams receive precise, actionable guidance when they need it most, rather than sifting through irrelevant content.

How It Actually Works

Skiller uses the Agent Skills standard. Skills live in a .github/skills/ directory in your repo. Each skill is a markdown file with YAML frontmatter describing what it does and when it applies. The agent reads these descriptions at startup and loads the full content when the situation matches.

The install is three curl commands. No dependencies, no build step, no npm install, no Docker container, no twelve-step onboarding ritual. Just markdown files dropped into your repo.

macOS / Linux:

mkdir -p .github/skills/skiller .github/agents .github/prompts
curl -sL https://raw.githubusercontent.com/markdav-is/Skiller/main/SKILL.md \
-o .github/skills/skiller/SKILL.md
curl -sL https://raw.githubusercontent.com/markdav-is/Skiller/main/.github/agents/skiller.agent.md \
-o .github/agents/skiller.agent.md
curl -sL https://raw.githubusercontent.com/markdav-is/Skiller/main/.github/prompts/skiller.prompt.md \
-o .github/prompts/skiller.prompt.md

Windows (PowerShell):

New-Item -ItemType Directory -Force -Path .github\skills\skiller, .github\agents, .github\prompts
Invoke-WebRequest https://raw.githubusercontent.com/markdav-is/Skiller/main/SKILL.md `
-OutFile .github\skills\skiller\SKILL.md
Invoke-WebRequest https://raw.githubusercontent.com/markdav-is/Skiller/main/.github/agents/skiller.agent.md `
-OutFile .github\agents\skiller.agent.md
Invoke-WebRequest https://raw.githubusercontent.com/markdav-is/Skiller/main/.github/prompts/skiller.prompt.md `
-OutFile .github\prompts\skiller.prompt.md

It works with GitHub Copilot in both VS Code and Visual Studio, Cursor, and any other agent that supports the .github/skills/ convention. Drop it in, start working. The skills accumulate over time.

Standing on Shoulders

Skiller originated as a fork of Claudeception, a project for Claude Code addressing similar challenges. To broaden its impact, I rebuilt Skiller for use with multiple AI agents, leveraging proven concepts like skill libraries. Research—including Voyager, CASCADE’s meta-skills, and Reflexion—shows that agents benefit from frameworks enabling learning and self-reflection. Skiller adapts these academic advances for practical use in software teams, turning theory into productivity.

One standout feature is Skiller’s recursive approach: agents continually build new skills from past experiences. As your team solves problems, Skiller captures valuable solutions as reusable skills, expanding the library over time. This process ensures agents become more effective with each task, streamlining future work and deployments.

Who This Is For

Skiller helps solo developers and teams avoid repeating past solutions by using AI-powered agents to record and share fixes for common problems. On teams, unique expertise is automatically distributed so everyone benefits from collective knowledge. For small civic organizations, Skiller ensures vital information isn’t lost when people leave, making onboarding faster and preserving operational know-how.

I’ve seen many government offices and nonprofits lose key processes when staff turn over. With Skiller, critical steps—like troubleshooting old payroll systems or handling quirks in reporting—are saved for new hires. While it can’t capture everything, Skiller makes retaining essential operational knowledge easier, helping small organizations remain resilient and efficient.

The repo is at github.com/markdav-is/Skiller. MIT licensed. The install takes about thirty seconds. If your agent has ever forgotten something you wish it hadn’t, give it a look.

The future of AI-assisted development is not agents that know everything. It is agents that remember what matters.

My last post covered Bedlam from the developer’s side. This one’s for the PMs.

ICECAP: Interview, Codify, Extract, Compose, Assemble, Prove. Six steps, but PMs really own three of them. Interview starts it. Codify turns the conversation into specs. Prove closes the loop with a demo. The middle three, Extract through Assemble, are where developers and the AI do their work. You’ll see cards moving on the board. You don’t need to be in the kitchen for that part.

Interview

You know how to do this. Sit down with the stakeholder, have a conversation about what they need. In civic tech this is usually someone who’s been doing their job for twenty years and knows exactly what they want but has never had to say it in terms a computer understands. Fine. You’re not asking them to write requirements. You’re having a conversation.

Record it. Transcribe it. That transcript is more valuable than any traditional requirements doc because it has the customer’s actual words. Not what someone interpreted. Not what survived committee review. The real thing.

Codify

Take the transcript, feed it to an LLM, get Gherkin feature files back. Plain English, Given-When-Then format. This is where most people get it wrong, because left alone an LLM will generate everything it can think of. API endpoints. Database schemas. Non-functional requirements about response times. Stuff that’s technically correct but useless for what we need.

What we need is features we can explain back to the customer during Prove. Mrs. Rodriguez from Planning does not care about your REST endpoints.

So you constrain the prompt. Tell it: “Generate only functional behavioral specifications. Do not generate API endpoints, database schemas, performance benchmarks, or system architecture. Keep scenarios focused on user-visible behavior that can be demonstrated to the stakeholder.” You can also feed it the names and roles of the interviewees, reference existing features for context, and tell it what module this belongs to. More context in, better specs out.

The AI drafts. You review. Can you show this to the person you interviewed and have them follow it? If not, adjust and regenerate. This is iterative, not one-shot. Think of it like scoping a work order. You wouldn’t tell a contractor “build me a house.” You’d say what’s in scope and what’s not. Same deal. The AI will absolutely tile your bathroom ceiling if you don’t tell it that’s not part of the job.

Tracking the Work

Features map to kanban cards. Complex features with multiple scenarios become epics; individual behaviors become tasks. Same board you’ve always used, just fed by a better source. The difference is what’s on the cards. Instead of “as a user I want to upload files,” you get specific testable behaviors with acceptance criteria baked in. Given-When-Then IS the acceptance criteria. No ambiguity about what “done” means.

Extract, Compose, Assemble

Covered this in the Bedlam post. Short version: the AI extracts testable elements from the features, composes code and test bindings, assembles everything into a deployable package. Cards move across the board. Pipeline enforces coverage. Because your features are written in the customer’s language, the developers have clear direction instead of guessing what “intuitive interface” means.

Prove

This is the step most agile teams skip. You demo the working software to the person you interviewed. Not to a proxy. To the actual human who told you what they needed.

“Remember when you said contractors need to upload photos with GPS data? Here it is. Upload a photo, inspector gets notified. Forty-eight hours without a review, system flags it.” You’re reading the feature file back to them and they’re watching it work. The features are the demo script.

This is exactly why you told the AI to skip the API specs during Codify. Nobody from Public Works wants to watch you POST to /api/v2/permits/inspections/photos. You’d lose the room in seconds.

Why This Matters

Small civic orgs can’t afford eighteen months of requirements, development, and testing. By then the regs changed, the grant expired, or the department head retired. ICECAP compresses the timeline because the AI handles the grunt work. The time you used to spend writing specs now goes into the parts where human judgment matters: good interviews, thoughtful review, and proving it works to real people. Those are your three stops. Interview, Codify, Prove. The rest is machinery.

* * *

Interview people. Let AI draft the specs but keep them in the customer’s language. Track work on the board. Let the devs cook. Then prove it works. The AI doesn’t replace the PM. It replaces the busywork that kept you from doing the job that actually matters.

The repo: GitHub - Feature-Highlighter

I’ve ridden the SpecFlow rollercoaster that lead to Reqnroll. Before that it was Cucumber. The BDD dream was always the same: write human-readable specs, generate tests, keep everyone on the same page. The reality was also always the same: developers hate writing Gherkin, and eventually the feature files become artifacts that nobody maintains.

But here’s the thing. In 2026, those feature files have become valuable again, just not for the reason we originally wrote them.

The GenAI Context Problem

I’ve written about my ICECAP workflow before. Interview stakeholders, transcribe, generate Gherkin features, generate code and tests in parallel. The feature files are the backbone of the whole operation. They’re the contract. The checklist. The pause point where you can verify the LLM understood what you need.

The features live in a Specs project alongside the code. They’re versioned. They’re human-readable. And critically, they give the LLM context about what the software is supposed to do.

When you’re working with Claude or any other LLM on a codebase, those Gherkin files are gold. They explain intent in plain English. They describe expected behaviors. They’re basically a requirements document that doesn’t lie, because it’s been verified against the actual code through tests.

Or at least, that’s the theory.

The Two-Sided Problem

I’m a longtime Reqnroll fan (née SpecFlow). The extension does exactly what BDD extensions should do: syntax highlighting, step definition navigation, automatic binding generation. All the automation you need to practice BDD without wanting to throw your keyboard through a window.

But my new team hasn’t embraced BDD. We’re not running automated tests. That’s their prerogative. Different teams, different tools, different comfort levels.

This creates a problem on both ends. When I have Reqnroll installed, it’s doing its job: generating backing code for automated tests. Step definition skeletons. Test scaffolding. All the machinery of BDD automation. But we’re not using that machinery. So I’ve got generated code cluttering my PRs, noise everywhere. The extension is working exactly as designed, for a workflow we’re not following.

Meanwhile, my teammates who don’t have any extension installed? They open a feature file and see a wall of plain text. No color. No structure. The Given/When/Then keywords don’t stand out. The scenarios blur together. Reading unformatted Gherkin is like reading poetry as a paragraph. You lose the rhythm that makes it useful.

I still want the feature files. They’re too valuable as context documents for GenAI workflows. But I need a middle path.

The Goldilocks Problem

So I needed something in between. Not the full SpecFlow/Reqnroll extension with all its code generation. But not plain text files either, because reading unformatted Gherkin is like reading poetry as a wall of prose. You lose the structure.

The syntax highlighting matters. When you’re scanning a feature file, you need to see the Given/When/Then structure at a glance. You need the scenarios to stand out. You need to parse intent quickly. That’s true for humans reviewing the specs, and it’s true when you’re deciding which files to include in LLM context.

What I wanted was just the highlighter. No generation. No bindings. No build integration. Just pretty colors on .feature files so my team can read them without squinting.

Vibes and Attribution

So I did what any reasonable developer does in 2026: I vibe-coded it.

The Reqnroll extension is open source, which meant I could look at exactly how they do their syntax highlighting. Solid work. Well-structured. The kind of code that makes you appreciate that someone else solved this problem thoroughly.

I extracted the highlighting logic, wrapped it in a minimal VS extension, and published it. The whole thing took an afternoon. Most of that was fighting with the VSIX packaging, because of course it was.

The attribution matters. This isn’t my clever invention. This is standing on the shoulders of the Reqnroll team and extracting just the piece I needed. The extension readme says so explicitly. If you want the full BDD experience with test generation and binding navigation, go install Reqnroll. If you just want to read your feature files without a wall of monochrome text, this is the lighter option.

The Actual Extension

It’s called Feature Highlighter. You can find it on the Visual Studio Marketplace and the source is on GitHub. It does exactly one thing: syntax highlighting for .feature files.

I uninstall Reqnroll, install this instead, and the code generation stops. My teammates install it, and suddenly the feature files are readable. Everyone sees the same colored Gherkin. Nobody gets unwanted build artifacts.

The Broader Point

This is what strategic doing looks like in practice. I’m not trying to sell my team on adopting BDD and convince them of the value of feature files. My need was: readable feature files without extra generated code boating my PRs. My solution was: extract just the highlighting.

Sometimes the best engineering decision is the one that removes friction without requiring everyone else to change. The feature files stay in the repo. The LLM context stays intact. The team doesn’t have to learn new tooling. Everyone gets what they need.

That’s not revolutionary. That’s just pragmatism. But pragmatism is underrated, especially when you’re trying to ship software for civic organizations that can’t afford six months of tooling debates.

* * *

The extension: Feature Highlighter on VS Marketplace

The repo: GitHub - Feature-Highlighter

The Reqnroll project (for the full BDD experience): reqnroll.net

I’ve been around long enough to remember when Visual SourceSafe was state of the art. We’ve seen a lot of silver bullets come and go. UML diagrams that nobody maintained. Agile standups that turned into status meetings. DevOps pipelines that needed their own pipelines. Now we have AI coding assistants, and this time something actually works.

Claude Code has this plan mode feature that’s genuinely clever. It analyzes your codebase, creates an implementation plan, then waits for you to approve each step before executing. It’s a surgical checklist for code. Gawande would approve.

But maybe you’re in Visual Studio working on county systems that need to stay in the Microsoft ecosystem. Maybe your IT department hasn’t blessed another command line tool. Maybe you just want to use GitHub Copilot because it’s already there. Good news: you can get the same benefits. It takes a little discipline, but it works.

Why You Need a Plan

The default Copilot experience is conversational. You ask a question, it gives you code, you paste it in. This works fine for small things. But try adding a feature to an Oqtane module or refactoring a Blazor component hierarchy and watch it fall apart.

The problem isn’t the AI. The problem is you’re making it up as you go. The AI suggests something, you follow it, then three files later you realize you should have started somewhere else. You’re flying by eyesight in fog.

That Model 299 bomber was too complex to fly from memory, so they invented the checklist. Your codebase is the same way. You need pause points. You need a plan you can verify before you start.

How Plan Mode Works

Claude Code’s plan mode is simple: you describe what you want, it analyzes your workspace, generates a numbered list of steps, and stops. It waits. You can ask questions, request changes, approve it. Only then does it execute, one step at a time.

The forcing function is the point. You can’t skip the planning step. It’s like Strategic Doing, you have to say what you’re doing before you act. The action goes faster because the plan is clear.

The Visual Studio Version

Here’s the workflow. It gets you most of the way there.

Start with @workspace

Open the Copilot chat window. Type @workspace to let it see your whole solution. This matters. Without workspace context, Copilot is guessing.

@workspace Analyze the PermitModule. I need to add photo upload for contractors during site inspections.

Ask for a plan first

Don’t let it jump to code. Make it write the plan. Here’s your template:

@workspace Create a numbered plan with: (1) Files to modify, (2) Changes per file, (3) Dependencies between steps. Wait for my approval.

You’ll get something like this:

1. Create IPhotoService interface

2. Implement PhotoService with file storage

3. Add PhotoUploadComponent.razor with GPS metadata

4. Update PermitController endpoint

5. Add database migration for PermitPhoto table

Review and fix the plan

This is your pause point. Read it. Does it make sense? Did it miss anything? Push back if you need to:

We use local file storage, not Azure. Also add notification to inspectors when photos upload. Revise the plan.

Copilot will update it. Keep going until you’re satisfied.

Execute one step at a time

Don’t say “do the plan.” Say “implement step 1.” Review the code. Commit. Then “implement step 2.” Keep the chat window open. That’s your state.

Implement step 1

Copilot generates the interface. You look at it. If it’s good, commit and keep going. If not, iterate. “Add GPS coordinate properties to UploadPhotoRequest.”

Use the shortcut commands

After a step, use /fix for compiler errors or /tests to generate unit tests. These are fast and don’t mess up your main plan.

What’s Different

The big difference: Copilot won’t execute anything without you. This is actually good. You’re the forcing function. Every step needs your go ahead. It’s more manual but safer. The AI never runs wild in your codebase.

The chat window is your plan document. Keep it open and you have the full context and sequence. Close it and you lose that state. So leave it open. Treat it like an open file.

Claude Code can execute steps after you approve the plan. With Copilot you drive every single action. More work, more control.

When to Use This

Use it when things get complex. Adding a feature that touches multiple files. Refactoring a Blazor component tree. Migrating data structures. Integrating a new service.

Skip it for simple stuff. Fixing a typo. Adding one property to a class. Basic search and replace tasks.

The forcing function matters when the task is complex enough that thinking through the steps first actually helps. If you already know what to do, just do it.

How This Fits Into Bedlam and ICECAP

If you know about the Bedlam workflow (BDD + LLM = controlled chaos), this is the same idea. We believe in forcing AI into proven structures. This Copilot workflow is the manual version.

Bedlam generates Gherkin features from transcripts, then generates code and tests in parallel. Everything flows from the features file. The LLM can’t wander because the BDD structure constrains it.

This Copilot workflow is smaller scale but same philosophy. You constrain the AI by making it produce a plan first. The plan becomes your checklist. You execute one item at a time. The AI fills in the blanks but the structure holds.

Not full Bedlam automation. You still manually approve each step. But same principles. Checklists work. Pause points work. Constraints make AI useful instead of chaotic.

Tips That Actually Help

Be specific up front. Don’t say “add photo uploads.” Say “add photo uploads for contractors during permit inspections, GPS metadata in database, file storage in /App_Data/PermitPhotos.”

Reference the plan by number. When you say “implement step 3” Copilot knows what you mean. It just made that plan. If you say “add the photo component” it might forget the GPS part you talked about.

Commit between steps. Git is your safety net. If step 4 goes wrong you revert to step 3 without losing steps 1-3.

Break big plans into chunks. Got a 12 step plan? Maybe do steps 1-4 then reassess. Plans change as you learn. Don’t commit to all 12 before you know if 1-4 work.

Keep the chat open. The Copilot chat is your working memory. Need to walk away? Leave it open. When you come back you’ll remember where you were.

The Real Point

The value isn’t that Copilot writes better code. It’s that you have a better plan before you start. You thought through the dependencies. You know which files change. You spotted the risky parts.

That’s what checklists do. They make you pause and think instead of just reacting. The Model 299 bomber didn’t need fancy autopilot. It needed pilots who remembered to unlock the elevator controls before takeoff. The checklist made sure they did.

Your Blazor app doesn’t need sentient AI. It needs you to think through the implementation before you start. This workflow makes you do that. The AI makes it faster once you have a plan.

Where This Goes

This manual workflow is a bridge. Eventually we want the full Bedlam pipeline. Transcripts to features to parallel generation of tests and code. All living in the repo together. Enforced by CI/CD.

We’re not there yet. That’s fine. We’re learning what works. Building the habits. Getting comfortable with LLMs as tools that need structure, not magic wands.

Small civic organizations can’t afford six month development cycles. They need working software in weeks. This workflow collapses that timeline. Interview the stakeholders. Generate the plan. Execute the plan. Deploy.

The economics work. Our competitors will figure this out. We should figure it out first.

Try It

You don’t need Claude Code to get the benefits. You need discipline. Force the AI to make a plan. Review it. Execute step by step. Commit between steps. Keep your chat open.

The AI fills in implementation details fast. But the forcing function, the checklist, the pause points, that’s what makes it actually helpful instead of just fast and wrong.

Gawande was right about checklists. Strategic Doing is right about pause points. Bedlam is right about constraining LLMs. This is the manual version. The principles hold. Give it a shot.

In our context: BDD + LLM = Bedlam. The controlled chaos of coding with an LLM, but within the rigid constraints of Behavior-Driven Development.

BDD has been around for a while, first in Java with Cucumber, and then C# using SpecFlow (now Reqnroll). I’ve forced it on my teams with various degrees of success over the years. The difference this time is that AI genuinely speeds things up. We get the specs without having to write them, and that’s easier for devs to accept. If we want to avoid vibe-coding and be more controlled with out AI efforts, then having specs as context is the way.

Constraints and Context

You can’t trust LLMs to run wild. Just like airplanes are too complex for any one pilot to maintenance from memory alone, they need checklists. Modern software features are too complex for any one developer to hold in their head, or for an LLM to wing it without structure.

Saying “don’t use AI” is no more an answer than telling people not to fly complex aircraft. The solution lies in using checklists: lists of features and the behaviors associated with them. By employing these lists, we guide the LLM to accomplish specific tasks effectively.

BDD gave us that structure decades ago. Gherkin features are human-readable contracts. They’re testable. They’re versioned. They live with the code in the repo. But just like test, they are onerous to create and maintain. The LLM makes it feasible to write them without developers revolting.

How It Actually Works

This is the first two steps in the ICECAP process. I’ll post more about that process as we go.

Interview the stakeholders (that’s the “I” in ICECAP), transcribe the audio, generate Gherkin features and behaviors from the transcript.

After the Interview, we codify the specs (that’s the “C” in ICECAP) as follows:

Old Human Tasks: Take notes in the meeting, mentally extract features, dream up individual behaviors for each feature. Spend the rest of the day typing.

New Human Tasks: Record the meeting, generate a transcription as VTT file (adds timestamps). Note: this is different from an AI generated meeting summary.

LLM Prompt: “Generate BDD features and behaviors from this meeting transcript. Include the timestamps in the comments for each.”

The timestamp is an added bonus if you ever want to review what was actually said. LLMs make lots of mistakes, and point back to the ground-truth is always smart.

Nothing revolutionary. Nothing you couldn’t do manually. But here’s what changes: we actually do it. The LLM removes the friction that made developers skip the BDD part.

A Real Example

County needs contractors to upload site photos during permit inspections. Photos need GPS metadata. Inspectors approve or reject within 48 hours. Standard government work.

The interview generates this kind of transcript:

Feed that to an LLM, get Gherkin features that live in the repo alongside the code. Push this up to your repo.

Why This Actually Works

Traditional BDD failed because nobody wanted to write Gherkin. It was tedious busywork that got skipped. The code and tests drifted from the specs. The specs collected dust.

LLMs make Gherkin free. More than free—they make it the most reliable artifact because everything else generates from it. The features stay in sync because they’re the source.

The constraint is the value. By forcing the LLM into BDD structure, we get testable requirements, living documentation. The LLM can’t wander off into creative nonsense because it’s boxed in by a proven methodology.

The Learning Loop

Strategic doing taught us that action plans aren’t enough; you need a learning loop. This workflow builds that in. Every meeting is a hypothesis about what the system should do. The features document what we learned.

The Bigger Picture

We didn’t generate any code here, but we’ll do so next time. I’ll make a video using this method and move forward with code generation. Having specs and code in the same repo lets you track changes together in one PR, showing the reasons for updates.

Activating public space with interactive art is one of my favorite endeavors. As I'm winding down my working career, I'm hoping to lean more into the art and less of the tech. I'm generally losing interest in gadgets and platforms as AI enshitifies everything it touches. Art and personal connections is the antidote to an increasingly uninteresting tech landscape.

The shop will be open for special events. The first is a swap-meet of interesting things co-hosted with Eugene Maker Space coinciding with the Warehouse District Art Hop first Saturday in September. This will be a good chance to recycle some gear into the community prior to sending it to Bring or the dump.

For many dotnet greybreards, WebForms was an interesting workhorse, transforming the way we build web applications using an event-driven model. It was a bridging technology for folks who knew WinForms but were new to the web. However, as technology evolves, so do the tools at our disposal and encountering legacy WebForm apps can be jarring. Enter Blazor, the modern successor to WebForms, promising an even more powerful and flexible way to develop web applications. This blog post delves into how Blazor is a natural progression from WebForms, drawing on the similarities in their control lifecycles, comparing the Blazor component model to WebForms UserControls, and exploring why Blazor is the ideal choice for modernizing legacy WebForms applications.

The Evolution of WebForms to Blazor

WebForms, introduced as part of the .NET 1.0 framework the same time as C#. It’s intent was to revolutionized web development with its abstraction over the stateless nature of web applications. It provided a rich set of server controls and an event-driven programming model that mimicked the desktop development experience. However, as the web matured, the need for more interactive and dynamic web applications grew, highlighting some of WebForms' limitations, such as view state management and page lifecycle complexities.

For this comparison, we will not be discussing Asp.Net MVC. Although it is still very popular, it is not a page-based technology. We will also exclude Razor Pages from this discussion, acknowledging that Blazor utilizes Razor templating. The "B" in Blazor stands for Browser based Razor. Instead, our focus will directly be on Blazor.

Blazor, part of the modern .NET ecosystem, addresses these limitations by leveraging C# to run .NET code anywhere in the stack, from server-side or directly in the browser. This modern framework offers a component-based architecture that fosters a more modular and maintainable codebase while providing the interactivity and performance demanded by today's applications.

Similarities in Control Lifecycles

One of the lucky similarities between WebForms and Blazor is their control lifecycles. In WebForms, the Page Life Cycle encompasses several stages, including initialization, load, postback handling, rendering, and unloading. Each control on the page participates in this lifecycle, processing events at specific stages.

Blazor's component lifecycle mirrors this structure with its own set of lifecycle methods, such as:

• OnInitialized - Similar to the Init() stage in WebForms, this method runs when the component is first initialized.

• OnParametersSet - This method is invoked whenever the component’s parameters are set or changed, akin to handling postback data in WebForms or making changes in PreRender()

• OnAfterRender - This method is called after the component has rendered, comparable to the Render() stage in WebForms but slightly later in the cycle.

• Dispose - Analogous to the UnLoad() stage, this method is used to release resources when the component is no longer needed.

Blazor Components vs. WebForms UserControls

WebForms UserControls allowed developers to encapsulate reusable pieces of UI and functionality, promoting code reuse and separation of concerns. UserControls interact with the rest of the application through properties and events.

Blazor elevates this concept with its component model. Blazor components, like UserControls, encapsulate UI and logic into reusable units. However, Blazor components offer enhanced flexibility and interactivity:

• Parameters - Blazor components use parameters to pass data and configure behavior. These parameters are specified using the [Parameter] attribute and can handle complex types, ensuring seamless data flow between parent and child components.

• Event Handling - Blazor components can define methods to handle events, much like WebForms UserControls. However, Blazor's event handling is more powerful, supporting asynchronous methods and enabling more responsive applications.

• Two-way Binding - Blazor supports two-way data binding, allowing changes in the UI to be reflected in the component's state and vice versa. This feature simplifies the development of interactive and dynamic applications.

Modernizing Legacy WebForms Applications with Blazor

For those looking to modernize legacy WebForms applications, Blazor presents a compelling choice. The transition to Blazor offers several benefits:

• Lift-and-shift Migration - Blazor's component-based architecture and lifecycle methods provide a familiar development experience for WebForms developers, easing the learning curve.

• Variable Interactivity - Blazor's ability to run .NET code in the browser through WebAssembly on real-time on the server thru sockets enables the creation of highly interactive and performant web applications. Blazor also supports fully static server-side rendering.

• Unified Development - With Blazor, developers can use C# for both client-side and server-side logic, reducing the need to switch between languages and streamlining the development process.

• Future-Proofing - Adopting Blazor ensures that applications are built on modern, supported technology, making them more maintainable and scalable in the long run.

In conclusion, when dealing with legacy WebForms applications, rather than maintaining them unchanged or migrating to an entirely different platform, Blazor is your best option. Blazor represents the future of web development within the .NET ecosystem. Its parallels in lifecycle management, advanced component model, and suitability for modernizing legacy applications make it an ideal successor. Embrace the transition to Blazor to unlock numerous possibilities for your web applications.

In my youth, my preferred table-top game was a hex-based tactical space battle game. While it may not sound very exciting, it involved flying a ship around in space and engaging in battles. The main games were Star Fleet Battles and StarFire. This was before the widespread popularity of table-top gaming, when options included Monopoly, Stratego, and Sorry for family play, and Avalon-Hill bookcase games for more complex simulations like re-enacting WWII. There were no intermediate games such as Catan, Ticket-to-Ride or Wingspan.

Today, there is a significant increase in the variety of table-top games available. Occasionally, I reflect on those space battle games and wonder why more of them have not been adapted into PC games or online. Recently, I decided to explore how challenging it would be to create a hex-grid using CSS. Modern CSS proved effective, and with the help of a blog post about hex-math, I was able to develop something quickly.

In anticipation of the upcoming Global Game Jam event, I began considering the development of a project that would pay homage to classic games. Utilizing web technologies that I am proficient in could make for an engaging endeavor. My daily work involves programming, primarily creating content for the eLearning industry. With the rising popularity of “Gamification” in learning environments, I have developed several interactive modules that incorporate storytelling and animation elements more akin to game design than traditional eLearning courses. This appears to be an opportune moment to merge these skill sets and develop a game.

Yesterday, the theme for Global Game Jam was revealed. Although I doubted that “tactical space battle” would be selected, I was optimistic about finding a theme that could be adapted to my interests. The announced theme was “Bubble.” Initially, this did not seem particularly promising; however, I hoped that additional “diversifiers” might provide more direction. Unfortunately, this was not the case. Still, there were aspects related to open collaboration, which is something I value, so there remains potential.

Today, I finalized the name for the Jam edition of the game: “StarBubble.” While it may sound whimsical, it also holds potential. I set up an Oqtane site on one of the CodeChops web servers and initiated an open-source repository on GitHub. I installed modules for a blog and a wiki, as well as demonstration modules for Lottie Animations, Ink script execution, Hex-Grid implementation, and a sample control panel. Although substantive work on the game cannot commence until the team assembles on Friday, I am currently preparing the necessary tools for future development.

I’ll be making more blog posts and such about the game on the game site itself as part of the Jam. That link should be http://starbubble.xyz when the jam starts.

In a galaxy far removed from Earth, where the stars shone brilliantly and the nebulae painted the skies in hues unseen by human eyes, there was a space-faring genius named Khan Noonien Singh. Renowned for his unmatched intellect and unyielding determination, Khan was a figure of awe and fear. But on one frosty night, as the cosmic winds whispered through the void, Khan embarked on an unexpected journey—one that would forever intertwine his legacy with the spirit of Christmas.

From his ship, the stolen USS Reliant, Khan observed the myriad worlds celebrating the season with joy and unity. He saw the twinkling lights, the heartfelt exchanges, and the laughter that echoed through the corridors of every starship and colony. A thought, sparked by the memories of his own humanity, took root in his mind. What if, just for one night, he could use his unparalleled genius to spread Christmas cheer across the universe?

With a resolute nod, Khan set his plans into motion. Utilizing his advanced knowledge of engineering and spatial mechanics, he began refitting the USS Reliant. He transformed the powerful starship into a marvel of holiday magic. The once-intimidating vessel now gleamed with shimmering alloys and glowing runes, capable of traversing light-years in the blink of an eye.

He recruited a loyal team of followers, each inspired by his vision of a universe united in joy and kindness. These followers, with their diverse talents and unwavering dedication, were tasked with crafting gifts tailored to the unique desires of each species. From the crystalline structures of the Altarians to the bioluminescent flora of the Zogathians, no detail was overlooked.

On the eve of Christmas, Khan donned a regal crimson cloak, lined with stardust, that fluttered like angelic wings. As the USS Reliant lifted off, guided by his impeccable navigation systems, he marveled at the beauty of the cosmos. One by one, he visited the far-flung worlds, his followers dispersing gifts with precision and grace.

To the children of distant stars, he brought toys that sparked imagination and wonder. To the warriors of the Andromedan Nebula, he offered peace tokens that glowed with the promise of harmony. However, when he arrived at Earth, Khan was met with resistance. Despite his efforts, the people of Earth did not embrace his gifts and joyous vision. For this world, Khan had a special gift: the Genesis Project. This powerful technology could reorganize a planet's entire biosphere, transforming it into a paradise of Christmas cheer.

As the Genesis Project was deployed, Earth began to transform. The skies were filled with auroras of vibrant colors, snowflakes that twinkled like stars gently fell, and evergreen trees sprang up, adorned with ornaments of light. The once-resistant inhabitants reorganized into a new joyful matrix. The spirit of Christmas transformed them, fostering unity and kindness.

As the night drew to a close, Khan paused over the transformed Earth, its landscapes bathed in the soft glow of dawn. A sense of fulfillment warmed his heart, a rare respite from his usual iron will. In that moment, he realized that the true essence of Christmas wasn’t just in the gifts or the decorations, but in the connections forged and the joy shared.

Thus, Khan Noonien Singh, the once-feared genius, became a legend of Christmas. His tale of intellect turned to compassion spread across the stars, reminding all that even the most formidable beings could find redemption and joy in the simple act of giving.

And so, every year, as the galaxy celebrates Christmas, they do so with the knowledge that somewhere, among the stars, Khan watches over them, a guardian of cheer, a herald of hope and imposer of joy.

"Starting is half finished," as the saying goes. However, beginning a project correctly is crucial for its success, and BDD is no exception. Here is a guide for conducting a Stakeholder Interview as part of The Discipline’s ICECAP process.

The goal of interviewing stakeholders is to understand the problem from their perspective and inform the next steps in the process: Codifying the Specs. This workflow relies significantly on modern business tools, many of which are based on AI.

Start with the end in mind

"Thank you for meeting with me. Today, we will discuss the primary scenarios we aim to address through this project. I will be recording the meeting to review it in detail later and develop a comprehensive plan. If you consent to having this meeting recorded and summarized, we can proceed. [start AI summary and recording tools].

Hello, my name is Mark, and I am a Project Manager on The Project. Could you please provide your name and explain your job function in the context of The Project? [wait for response]

Thank you. Considering The Problem, what is the most common or significant work scenario you would like to address by creating The Project?"

This should initiate a productive conversation about the importance of The Problem and how The Project can resolve it, while simultaneously generating a detailed AI summary of the discussion as well as a comprehensive video record.

Feed the Machine

After your interview, copy the AI meeting summary into a new research document. Use a tool to transcribe the meeting; Slack offers free transcription when you upload a video. Add this transcription to the same document as the summary. Ensure the document is accessible to your AI tool. For instance, I upload mine to Office using Copilot. ChatGPT and other AI tools allow document uploading for paid tiers. The key feature of these tools is their ability to analyze documents.

Personal Connection

Stakeholder interviews are equally focused on building rapport and gathering requirements. Aim to maintain a conversational tone rather than an interrogative one. Your objective is to gain a deeper understanding of the stakeholder's perspective. Utilizing AI tools for later analysis allows you to be present during the meeting, rather than concentrating on taking notes. Recording the conversation enables you to include useful phrases that will be identified by AI subsequently. For instance, if the stakeholder mentions that something is important, you can reaffirm this by saying, “As a [role], you need to [perform an action] to [accomplish a goal].” Such comments can be verified by the stakeholder and assist in generating precise specifications for the next step of the ICECAP process: Codifying the Specs.

Recently, I discovered Nostr while experimenting with the OpenVibe app, which enables participation in Threads, Bluesky, and Mastodon. After integrating these three platforms, I noticed Nostr as an additional option. While I am not yet familiar with it, this discovery led me to explore further during my time at DotNet Conf.

My recent interest in RSS stems from its potential as a tool for publishing calendar events and comments for a meetup platform I am conceptualizing. Nostr appears to be the real-time chat equivalent of RSS, offering additional features. As an open platform, utilizing Nostr will require some technical expertise.

Verification

Nostr is an open platform, so it can be challenging to distinguish between bots and people. With no central authority to create a user, any user name can be made. To verify yourself (and obtain a checkmark next to your name), you need to be verified. There are many documents online that point to various crypto wallets and services capable of publishing your verified key. The crypto community is not interesting to me so I’m going to be independent.

For creating a mark@nostr.marks.wiki Nostr address, two things are needed: control over the DNS and a web server. GitHub Pages will be used for the web server.

When a user is created for the first time using any Nostr client, public and private keys are generated. It is important to write these down as they will be needed.

Create the repo and pages

Create a public repo for your site, turn on github pages, and add a /.well-known/nostr.json file. Sorry, but I’m not going to explain that parts, ask Copilot.

You can check the PIP for the proper format. That string of numbers is the hex equivalent of my public key. Not sure why you need the hex version of the key. If you need to convert you key to hex, use this: https://damus.io/key/

This file should qualify for the certification procedure, but github pages will not automatically publish this file for you. You need to tell it include this by adding a _config.yml file like so:

Now we have the code in place, next is publishing it on the web.

Domain wrangling

Proving that you own your domains means having access to your DNS. Github will want to verify your domain ownership and github pages will want to see some proof as well for your site.

Deep in your github settings is a way to add a domain. When you do, it gives you some instructions for creating a TXT record. Follow those at your DNS host.

Once this is set up, your repository also needs information about the specific domain that will host your website. Here is where I added the `nostr` subdomain to my page.

This part was a little tricky, but by digging in the docs I found the instructions that require this subdomain to point to your personal github URL. [username].github.io.

Now, with all this in place, I should be able to test it by navigating to nostr.marks.wiki/.well-known/nostr.json

And with that tested I should be able to get verified by using mark@nostr.marks.wiki using any OpenVibe Client.

https://youtu.be/bc7_zPEule8?si=dCNg4raGQlkoxqzv

Oqtane is built on Blazor that is part of Asp.Net so that's C# and dotnet core. The TLDR; on intra-module communication in Oqtane is publishing and subscribing to events using INotifyPropertyChanged.

Crowded house?

As a computer programmer, I often think "How hard could it be?" when I see a simple service failing. In-person meeting apps aren't great as a business model due to competition from platforms like Facebook. However, they can serve as a sustainable public benefit. My target market is small groups that have a core membership and want to organize meetings without relying on Facebook's free services.

Hosted & self-hosted options

A self-hosting option will be available for those who want complete control over their data. Additionally, a hosted option will be provided at SigZag dot com for users who prefer simplicity.

Revenue Model

This project is being developed for both personal and wider use, but it will not be actively supported. The goal is to maintain focus on my current job without distraction. A revenue model will be needed to cover inexpensive hosting, customer support, and minor enhancements. As the target market consists of small groups, a pay-what-you-can model is considered suitable, allowing groups to contribute periodically to cover service costs. Support at this level will be "best effort". For those requiring more reliable guarantees and who have the budget, a paid option will be established in the future. Prioritizing current steps is essential.

Features

This project will serve as a blog for Behavior Driven Discipline and involve client interviews. As the first client, I believe we need the following:

• User accounts: Sign-in required for posting; public can view events without credentials.

• Calendar of events: Any user can post events with ICal links for personal calendars.

• Social media sharing: Integration with social media APIs; others use perma-links.

• Groups: Create groups with unique URLs. Group creator is admin; membership levels include Followers, Members, Core, Admin. Meetings can be created at any level.

• Moderation: Adhere to a code of conduct; use AI moderation if affordable, otherwise report-and-correct method.

• Technical details: API protected by auth, RSS feeds for groups and calendar views to allow integration with other systems.

A self-interview will be conducted in a future blog post as the initial step in creating this app publicly. This may take the form of a podcast.

"Prodigy is, at its essence, adaptability and persistent, positive obsession. Without persistence, what remains is an enthusiasm of the moment. Without adaptability, what remains may be channeled into destructive fanaticism. Without positive obsession, there is nothing at all."

"All that you touch You Change. All that you Change Changes you. The only lasting truth Is Change. God Is Change."

"A gift of God May sear unready fingers."

"We do not worship God. We perceive and attend God. We learn from God. With forethought and work, We shape God. In the end, we yield to God. We adapt and endure, For we are Earthseed, And God is Change."

"Intelligence is ongoing, individual adaptability. Adaptations that an intelligent species may make in a single generation, other species make over many generations of selective breeding and selective dying. Yet intelligence is demanding. If it is misdirected by accident or by intent, it can foster its own orgies of breeding and dying."

"A victim of God may, Through learning adaption, Become a partner of God. A victim of God may, Through forethought and planning, Become a shaper of God. Or a victim of God may, Through shortsightedness and fear, Remain God's victim, God's plaything, God's prey."

"Belief Initiates and guides action-Or it does nothing."

“Drowning people Sometimes die fighting their rescuers.”

“We are all Godseed, but no more or less so than any other aspect of the universe, Godseed is all there is-- all that Changes. Earthseed is all that spreads Earthlife to new earths. The universe is Godseed. Only we are Earthseed. And the Destiny of Earthseed is to take root among the stars.”

“To get along with God, Consider the consequences of your behavior.”

"Civilization is to groups what intelligence is to individuals. It is a means of combining the intelligence of many to achieve ongoing group adaptation. Civilization, like intelligence may serve well, serve adequately, or fail to serve its adaptive function. When civilization fails to serve, it must disintegrate unless it is acted upon by unifying internal or external forces.”

“When apparent stability disintegrates, As it must, God is Change. People tend to give in To fear and depression, To need and greed. When no influence is strong enough To unify people They divide. They struggle, One against one, Group against group, For survival, position, power. They remember old hates and generate new ones, They create chaos and nurture it. They kill and kill and kill, Until they are exhausted and destroyed, Until they are conquered by outside forces, Or until one of them becomes A leader Most will follow, Or a tyrant Most fear.”

“Any Change may bear seeds of benefit. Seek them out. Any Change may bear seeds of harm. Beware. God is infinitely malleable. God is Change.”

"We are Earthseed The life that perceives itself Changing."

“There is no end To what a living world Will demand of you.”

"In order to rise From its own ashes A phoenix First Must Burn."

"Any Change may bear seeds of benefit. Seek them out. Any Change may bear seeds of harm. Beware. God is infinitely malleable. God is Change."

“Kindness eases Change.”

“Earthseed Cast on new ground Must first perceive That it knows nothing.”

"We are Earthseed. We are flesh-self-aware, questing, problem-solving flesh. We are that aspect of Earthlife best able to shape God knowingly. We are Earthlife maturing, Earthlife preparing to fall away from the parent world. We are Earthlife preparing to take root in new ground, Earthlife fulfilling its purpose, its promise, its Destiny."

"Embrace diversity. Unite-Or be divided, robbed, ruled, killed By those who see you as prey. Embrace diversity Or be destroyed."

“Once or twice each week A Gathering of Earthseed is a good and necessary thing. It vents emotion, then quiets the mind. It focuses attention, strengthens purpose, and unifies people.”

"The ground beneath your feet moves, Changes. The galaxies move through space. The stars ignite, burn, age, cool, Evolving. God is Change. God prevails."

"God is neither good nor evil, neither loving nor hating. God is Power. God is Change. We must find the rest of what we need within ourselves, in one another, in our Destiny."

“The Self must create Its own reasons for being. To shape God, Shape Self.”

“As wind, As water, As fire, As life, God Is both creative and destructive, Demanding and yielding, Sculptor and clay. God is Infinite Potential: God is Change.”

“Your teachers Are all around you. All that you perceive, All that you experience, All that is given to you or taken from you, All that you love or hate, need or fear Will teach youÑ If you will learn. God is your first and your last teacher. God is your harshest teacher: subtle, demanding. Learn or die.”

“Respect God. Shape God. Pray working.”

“Create no images of God. Accept the images that God has provided. They are everywhere, in everything. God is Change. Seed to tree, tree to forest; Rain to river, river to sea; Grubs to bees, bees to swarm. From one, many; from many, one; Forever uniting, growing, dissolving, forever Changing. The universe is God's self-portrait.”

Last night, while gaming with friends, I sketched our project process to share with my development team as the 2025 playbook. This organic method is adaptable to any web project and uses Oqtane for examples, though it can apply to other modular frameworks. The six-step process forms the acronym ICECAP.

By “discipline,” I mean following these steps exactly, even without immediate benefits. Over multiple projects, this process will become indispensable.

Discipline: The art of sticking to your goals even when it’s tough. It’s about having control over your actions, maintaining focus, and being committed to your plan. Sounds simple, yet incredibly challenging.

The six step checklist for the Discipline

I’m big on checklists. If you have not read “The checklist Manifesto” DM me and I’ll send you a copy. It’s not even about software engineering. It’s about doctors and pilots and how to make less mistakes. Even when you are at the pinnacle of your skills.

• Interview Stakeholders

• Codify the Specs

• Extract the Modules

• Compose the Pages

• Assemble the Code

• Prove the Work

ICECAP is our iterative software delivery method with effective feedback loops. I'll explore each topic in future posts, but here’s an overview.

Interview Stakeholders

Effective stakeholder meetings require clear communication. Share the agenda beforehand and state the meeting’s purpose. Record meetings and use AI tools for summaries and transcriptions. Start with, “We’re discussing practical solutions to our problem by examining current processes and envisioning future improvements.” Facilitate the discussion, listen actively, gather all perspectives, and ask clarifying questions. Follow up as needed to gain a comprehensive understanding of the issue from all angles.

Codify the Specs

The output from interview transcriptions and meeting summaries can serve as valuable input for drafting specifications. AI chatbots are effective at writing classic BDD specs. Collaborate to list all the scenarios discussed in the meeting using standard agile use case language: "As a [user role], I need to [perform an action], so I can [accomplish a goal]."

As a BDD project lead, I need to convert the stakeholder interview assets, so I can completely codify the specifications in a way that’s understandable by the app builders and the stakeholders

After recording the scenarios, detail each with a series of BDD behaviors using the Gerkin format: "Given..., When..., Then..." These should contain enough detail to facilitate app building.

Given a set of BDD scenarios, When I follow the BDD process, Then I’ll produce detailed behaviors that builders can use to make and test modules.

This process provides a deeper understanding of how the app will function with explicitly testable details. Numerous BDD resources are available online to guide through this process. Examples will be provided in the specific post.

Codifying the specifications allows for the creation of feedback loops with stakeholders. At this point, schedule a meeting to review the specifications with stakeholders and create the first asset for validation.

Extract the Modules

Given a set of behaviors, there is a method for translating these into functional units known as modules, specifically Oqtane Modules. An Oqtane module represents a segment of functionality within an application that can be deployed independently. The architecture of a module is divided into two main components: client and server.

On the client side, the module encompasses UI elements, client state management, and services provided by Oqtane, as well as routing, dependency injection (DI), and other single-page application (SPA) features from Blazor. On the server side, it includes an API layer similar to ASP.Net MVC, data repositories, and models shared between the client and server.

The relationship between behavior specifications and coding elements can be determined through a process of noun/verb extraction. Nouns identify a module, while verbs denote the actions associated with that module. Oqtane modules focus on a data model and provide various components to perform different actions. Multiple actions and components can be incorporated into a single module to meet the specific requirements of a scenario.

Compose the Pages

Oqtane is an example of a composable UI framework, among many others. If you haven't read Atomic Design, you should. Without delving deeply into atomic design theory, it progresses from single controls to grouping them into reusable components, then to modules. With a set of modules, we can create pages with various modules to help users achieve different goals. This goal-oriented approach to UI flow aligns with BDD. Instead of building an app for users to navigate and edit things, we’ll build pages and workflows that match user tasks directly. Revisiting behaviors, composing pages from modules, and facilitating goal-seeking efficiently is the aim. Different paths may exist for users with various capabilities. Page composition studies and applies this skill.

Assemble the Code

This covers coding and its related aspects. As a professional developer, you are expected to follow patterns and write testable, maintainable code. While I may share Oqtane and Blazor tips, detailed coding guidance won't be provided.

Prove the Work

This step occurs at the end of most other steps, culminating in a final proof. The work is verified by demonstrating every scenario and behavior in the production app through demo meetings and a sign-off process. Additional feedback points include:

• After codifying the specs, meet with stakeholders to review each scenario. Limit the meeting to a few scenarios and thoroughly discuss behaviors. Ensure no behaviors are missed and consider the process on both sides of the scenario. Understanding the broader workflow can reveal opportunities for integration and automation.

• Before finalizing and coding, review the draft pages and modules with stakeholders to gather feedback and avoid costly mistakes.

• Code assembly involves mini-proofs like PRs and automated tests. This final proof complements them.

The month of November will be dedicated to discussing this topic in detail. It will benefit my team to document it. Drawing from decades of agile projects, I aim to establish an optimal level of process to facilitate continuous app delivery. This process is applied across 3-4 simultaneous projects. By maintaining a consistent tech stack with Oqtane and Blazor, and adhering to this BDD discipline, we can operate efficiently while minimizing the risk of burnout.