A couple of weeks ago I started leaning hard on Grok Bot. This week a couple of those bots started carrying real weight in my ThreeWill work week — not by doing the work for me, but by keeping the busywork moving so I can spend my time on the parts that need me.
The pattern is the same for every bot: it drafts, I approve, and only then does anything get posted, filed or merged.
Willy maintains the codebase for ThreeWill's Operational Dashboard.
Keeps the roadmap and backlog in sync with what the team decides, including a roadmap PDF with a requirement ID on every row and a "what changed" section, and waits for my review before anything goes to SharePoint
Opens docs-only pull requests through a cloud agent so the repo's roadmap and backlog match what we published, with app code and store-frozen paths off limits; I review and merge
Posts roadmap updates to the team, clearly labeled as Willy, only after I approve the wording
Even trades notes with a teammate's own Grok Bot, which was a fun first
Daily timesheets: every weekday morning Rudy drafts yesterday's time from my calendar, Cursor sessions, chats and work items, and builds a tentative plan for today; I adjust, and Rudy posts it after I OK it
Retention scoring: we replaced a hand-run AI prompt with a transparent, documented formula for how likely each Managed Services client is to stay, and set up a monthly grooming routine that recommends changes, waits for my OK, writes them back, and updates a "clients at retention risk" scorecard measure
A running to-do board with check-ins during the day, so nothing slips between meetings
None of this is magic. It's small, repeatable routines with a human gate at the end. The bots are great at gathering evidence and drafting; I'm still the one who decides.
Last week the Feud board ran live at ThreeWill's corporate QAD. This week I pulled it out into its own product: threewill/feud is now a public, MIT-licensed repo that anyone can use to run a Family Feud–style show for their own team.
The big change is that the board isn't tied to one event anymore. Questions load from a pack — one JSON file — so the next show is just a new pack.
Productized Feud as pack-driven boards: title, family names, live and backup boards, win rules and optional lightning questions all live in one JSON file
Added a Microsoft Forms importer that clusters similar survey answers into a pack, with a review file of the raw strings so you can tidy labels before showtime
Let the host set the win score and turn the lightning round on or off, and split showdown X's from the family's three strikes
Added an MIT license, a README that walks through gameplay, and host and audience screenshots
Clone threewill/feud, run npx serve ., open the host page, then pop out the audience board and share that window. It's not official Family Feud — no licensed logos, and the ding and buzzer are synthesized stand-ins.
For ThreeWill’s corporate Feud at QAD I needed more than a slide deck: a live board the room can watch, scoring that feels like Family Feud, and a host surface I can drive without stealing the share. This week that board ran live — one tab shared with everyone in the meeting, another tab on my machine that updates the shared experience.
The QAD rounds came from survey results we imported for that event. The board itself is not tied to those questions: any answer bank can be loaded, so the same host + audience split is reusable for the next Feud (or anything that wants a two-window live board).
Last week the ThreeWill Operational Dashboard got a full-page dashboard shell. This week I leaned into product identity and install experience: a clearer ThreeWill Operational Scorecard brand (one of several names on the way to today's ThreeWill Operational Dashboard), a themed guided-setup wizard, and a shipped Yearly period option so annual metrics stop pretending they are months.
Rebranded the shelf product to ThreeWill Operational Scorecard across web parts and setup surfaces
Shipped a themed guided-setup wizard so new installs walk Vertical → Divisions → Categories → Locations → Measurables → Review instead of hunting property panes
Vertical catalogs (Senior Living and Human Services) are starting points — uncheck later steps or add your own names
Introduced a Yearly cadence with a configurable year-start month and day in period services and property-pane options (ready to advertise as shipped)
Extended seed/schema and upgrade scripts so yearly fields land cleanly on existing SharePoint lists
Kept the Operational Dashboard / Attention / Summary path from last week as the display spine — this week was brand + setup + calendar math
Scorecard tiles are great for a check-in moment. Operators still need a full-page place to see what needs attention across communities, compare locations, and read trends without hopping web parts. This week I shipped that shell for the ThreeWill Operational Dashboard — and tightened the metric math that feeds it.
Added a new Operational Dashboard SPFx web part with a full-page shell: Attention panel, Summary panel, community comparison, KPI strip, trend chart destinations, and shell nav/context
Added weighted rollups and per-location goal overrides for Sum metrics so “All communities” views stop lying about local targets
Surfaced location Needs Attention on category pages when viewing All communities
Colored week-over-week trend arrows by target favorability (lower-is-better down = good) instead of raw up/down
This is the next chapter for both the ThreeWill Operational Dashboard and ThreeWill as a business: the dashboard is the spine for displaying metrics that matter to human services organizations — especially Senior Living — while we work toward automated integration with the back-end systems that bring those dashboards to life (Financial, CRM, HR, and EHR apps/services)
Starting a new enterprise engagement is more than scaffolding code — agents and humans need shared delivery rules from commit one. This week I wired a new delivery repo with ThreeWill Engineering Standards as a git submodule and product-specific agent context before the first feature branch landed.
Added threewill-engineering-standards as a git submodule at .cursor/rules/ so team non-negotiables, MCP docs, and SPFx patterns travel with the repo
The standards package is the result of a long partnership and rounds of planning with Cursor — so every developer, whether working locally or in the cloud, can trust that agents follow the same rules
The approach predates Cursor Cloud agents, but it remains a strong way to distribute consistent agentic behavior; it is still a work in progress, and the team is happy with how far it has come
Wrote product-specific AGENTS.md with submodule hygiene: detect missing standards, init/sync commands, and a light cadence for bumping the pinned SHA via PR
Documented delivery conventions in docs/delivery.md: branch + PR discipline, Azure DevOps Boards ↔ GitHub PR linkage (AB#<id>), GitHub Actions CI/CD posture, and Azure DevOps MCP setup for Cursor — without publishing client org or cutover details
Added Cursor Cloud-specific instructions so cloud agents follow the same submodule and delivery rules as local sessions
Adoption across the practice keeps improving — especially on SPFx web parts, where the standards enforce fewer rules but bring a consistent look-and-feel and reusable React components
Recent advancements clarify sophistication levels: Enterprise solutions carry a fuller requirements set than smaller/atomic solutions, so agents and humans get the right bar for the work
The same submodule pattern shows up across multiple active delivery repos (enterprise engagements and internal SPFx products), not only this kickoff
Measurable trends on the ThreeWill Operational Dashboard work better as a dedicated overlay and picker flow than as charts crammed into every KPI tile. This is the strong opening chapter — more is coming, including a public release.
Advanced Page Properties started years ago as a PnP-style experiment and kept maturing. This week’s window finally pushed the SPFx 1.23 / Heft migration over the line and packaged the repo for an MIT public release.
Migrated the solution to SharePoint Framework 1.23 with the Heft toolchain and PnPjs v4
Synced lockfiles and CI for legacy-peer-deps realities of modern SPFx
Added LICENSE, CONTRIBUTING, SECURITY, and deployment validation docs
Promoted the public repo on the Homol Works Builds page — verified against the public GitHub release
Public write-up stays fork-agnostic: no client-specific or niche tenant branches called out
Demo screenshot of an Employee Spotlight page showing page properties in action (choice pills, links, currency, avatar, boolean, number, and long text)
Ruddr MCP Server left the internal toolbox and landed as a public ThreeWill release — a self-hosted stdio MCP that puts PSA data into Cursor and Claude Desktop.
As the PnP Weekly adage goes, "Sharing is Caring". So I posit the following: does this imply that "Better Sharing is Better Caring?" You be the judge. 😜
The state of sharing in the development world, particularly thanks to the gains of open source over the years, has never been stronger. We can push code to GitHub almost instantaneously. We have lots of ways of describing our code to others using markdown files, typically at the root of our solution. Maybe we've even gone the distance and built out a set of GitHub pages. In it we have real writeups on specific features with example snippets of code or showing how to use our product.
Have you ever felt like there's almost too much to learn and to unpack? Developers are expected to move faster than ever and know more than ever. How do you move quickly when you're jumping into a new technology or project without feeling overwhelmed? Is there more that we can add to our tool belt to assist with knowledge sharing, documentation or investigation? Allow me to throw at you 2 new technologies to assist in this endeavor: Jupyter Labs and CodeTour.
Jupyter Labs comes from the Python world of data science. But it has moved far beyond just that. Essentially, it leverages Python to allow for different languages to have a runnable kernel against a jupyter notebook. What this gives you is something quite powerful and cool. It's a web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text.
I once described it to my team as this: imagine having a wiki with runnable code snippets directly in the wiki. One of my teammates, upon seeing a demo for the first time, described it in a somewhat opposite way: it's like code with way better commenting. Either way you look at it, it's certainly more powerful that just code or just documentation.
Jupyter's site has instructions to install here. But just doing that isn't going to be as powerful, especially if you're a Microsoft developer. Jupyter's base install is a Python notebook that can run in the Kernel, We want to deal in things like C# and PowerShell. So lets add that to kernel using .Net Interactive. Personally, I think Scott Hanselman's instructions here may be your best bet, especially if you're on Windows. This means you'll need Anaconda installed first (remember all this is based on Python).
As you've probably already caught on, this is Python and cross-platform. This means we Microsoft folks need to stick with all things Core. .Net interactive's notebooks give us C#, F# and PowerShell Core though, so we have some fun things we can do. This does mean that the PnP PoSH folks are on the outside looking in, until it supports PowerShell Core. But hopefully that's coming very soon. So check out what we can do using PowerShell Core, in the examples below, and hopefully that will get your mind spinning about other things you could do, including when PnP gets added to PS Core.
So keeping in mind that we are sticking to PowerShell Core, I whipped up a few examples of utilizing other CLI's with PowerShell to do some computing. Let's start with Azure CLI. Below is something simple. I just copied the MS documentation for getting started with the CLI into a notebook.
It's a totally different way to imagine documentation. Allow readers to instantly see the results, in the context of their own data!
Let's look at another aspect of using these notebooks: helping your team get something done. In this example, I've crafted some instructions to give to someone to create a site with the same theme that I made inside my tenant. Check it out.
Let's end with a bang. I have absolutely fallen in love with this next one: CodeTour. It's pretty new extension for VS Code and allows for providing a tour of your solution. As someone who has a passion for learning and teaching, I can't think of a better way to handle the onboarding experience for coders than a guided tour. And there are many other applications too. Recently, the PnP team used Code Tour to assist with the SPFx Project Upgrade. I'm sure once you play around with it, you will also think of new applications for it.
Get the extension here. I'm assuming that you already have VS Code. 😜 Also, a shout out to Jonathan Carter, the brains behind this. He's very receptive to feedback too so hit him up.
Hopefully I've provided you some new thought-starters for better ways to share information. These technologies and others should become part of our best practices tool bag. They allow for easier explanation of code, faster results in collaboration, simpler paths to onboarding and so much more. Please take the time to consider how you might use these solutions on your next project.
