Tag: Sample content

77 pages

• 01.01Project intake and scopingTurn "can we build a thing that…" into a scoped piece of work with a clear yes/no.
• 01.02Definition of done"Done" means the same thing to everyone.
• 01.03Communication standardsThe right conversation in the right place, findable later.
• 02.01Approved stack and when to deviateFewer technologies, deeper knowledge, easier handoffs.
• 02.02Project templates and starter reposEvery new tool starts from a known-good skeleton with CI, lint, auth, and deploy already wired.
• 02.03Folder and code structure conventionsOpen any repo and know where things are.
• 02.04Environment variables and config managementConfig is explicit, per environment, and never committed.
• 02.05Third-party services we useKnow what we depend on, who pays, and who holds the keys.
• 02.06Architecture decision logIndex of accepted ADRs (see 01.06 for the process).
• 02.02Project templates and starter reposEvery new tool starts from a known-good skeleton with CI, lint, auth, and deploy already wired.
• 03.01Account setup and multi-account handlingCommits land under the right identity, and personal/work accounts don't collide on Windows.
• 03.02Repo creation standardsEvery repo is discoverable, protected, and starts from a template.
• 03.03Branching strategyShort-lived branches, always-deployable main.
• 04.01TypeScript / JavaScript styleCode that any teammate (or Claude Code) can read and extend without asking.
• 04.02Python styleConsistent Python across data scripts and Rhino tools, which run in different interpreters.
• 04.03C# style (Revit / Rhino plugins)Plugins that survive Revit and Rhino version upgrades.
• 04.04Linting, formatting, and pre-commit hooksMachines enforce style so reviewers don't have to.
• 04.05Testing standardsEnough tests to change code with confidence, not so many that they slow us down.
• 05.01Approved AI tools and accountsEveryone has the right tool, on the right plan, under the right account.
• 05.02Claude Code standardsConsistent, safe, effective use of Claude Code across all repos.
• 05.03Cursor standardsCursor and Claude Code overlap; use each for what it's best at.
• 05.04Token usage optimizationFaster answers, lower cost, less drift — regardless of plan.
• 05.05Prompting patterns and reusable promptsPrompts that work, written down once.
• 05.06MCP servers we runAI tools can act on our systems through a known, controlled set of connectors.
• 06.01Environments: local, preview, productionThree environments, clear rules for what runs where.
• 06.02Vercel deployment procedureDeploys are automatic, boring, and reversible.
• 06.03Domains and DNSSubdomains on [TEAM: primary domain] managed in one place.
• 06.04CI/CD checks and required passesNothing reaches main without passing the same checks, every time.
• 07.01Secrets managementSecrets live in exactly one place and can be rotated in minutes.
• 07.02Access control and offboardingPeople have the access they need, and no more, and it disappears when they leave.
• 09.04Data schema registryShared datasets have one canonical shape so tools interoperate.
• 07.03Password manager and MFANo reused passwords, no accounts without a second factor.
• 07.04Client and project data handlingClient data stays where the client expects it.
• 07.05Dependency and vulnerability updatesStay patched without spending every Monday on version bumps.
• 08.01Supabase Auth setup standardEvery tool's login works the same way and is configured the same way.
• 01.01Project intake and scopingTurn "can we build a thing that…" into a scoped piece of work with a clear yes/no.
• 08.02Roles and permissions modelOne simple role model reused across tools.
• 08.03Row Level Security patternsThe database enforces who can see and change what, regardless of how it's accessed.
• 08.04Session handling in Next.jsSessions are refreshed correctly on the server and never leak between users.
• 09.01Supabase project setup and configurationEvery Supabase project starts the same way and is findable.
• 09.02Schema design standards and namingSchemas that are obvious to read and cheap to change.
• 09.03Migrations workflowEvery schema change is a reviewed file in git, applied the same way everywhere.
• 09.05Backups and restore procedureLosing data is recoverable in under an hour.
• 10.01Rhino version, install, and license standardEveryone runs the same Rhino so tools behave the same.
• 10.02File and layer conventionsAny teammate or script can find geometry by layer, not by guessing.
• 10.03RhinoPython / RhinoScript standardsScripts that are readable, testable, and safe to run on a live model.
• 10.04Grasshopper standardsDefinitions others can open, read, and maintain.
• 10.05Rhino MCP: setup, use, and geometry generation workflowsUse Claude to generate and inspect geometry in Rhino safely and repeatably.
• 11.01Revit version and add-in environmentAdd-ins build and run on every Revit version the team supports.
• 11.02Plugin development standardsAdd-ins that are robust in real models and maintainable across years.
• 11.03Building, signing, and deploying add-insReleases are reproducible and installable without hand-copying DLLs.
• 11.04pyRevit / Dynamo standardsLightweight automation without a full add-in, kept as disciplined as compiled code.
• 11.05Model and family conventions relevant to toolsTools rely on models being structured predictably.
• 02.01Approved stack and when to deviateFewer technologies, deeper knowledge, easier handoffs.
• 01.02Definition of done"Done" means the same thing to everyone.
• 01.03Communication standardsThe right conversation in the right place, findable later.
• 01.04Documentation standardsDocumentation exists at three levels, and each has a home.
• 01.05Naming conventionsNames that sort, search, and read the same everywhere.
• 01.06Decision records (ADRs)Remember why we chose something so we don't relitigate it every six months.
• 02.03Folder and code structure conventionsOpen any repo and know where things are.
• 02.04Environment variables and config managementConfig is explicit, per environment, and never committed.
• 02.05Third-party services we useKnow what we depend on, who pays, and who holds the keys.
• 02.06Architecture decision logIndex of accepted ADRs (see 01.06 for the process).
• 03.01Account setup and multi-account handlingCommits land under the right identity, and personal/work accounts don't collide on Windows.
• 03.02Repo creation standardsEvery repo is discoverable, protected, and starts from a template.
• 03.03Branching strategyShort-lived branches, always-deployable main.
• 03.04Commit message conventionsHistory that explains itself and can generate changelogs.
• 03.05Pull request process and review checklistEvery change gets a second set of eyes without becoming a bottleneck.
• 03.06Releases, tags, and versioningKnow exactly what's running where.
• 03.07Issues, labels, and project boardsWork is visible and prioritized in one place.
• 04.01TypeScript / JavaScript styleCode that any teammate (or Claude Code) can read and extend without asking.
• 04.02Python styleConsistent Python across data scripts and Rhino tools, which run in different interpreters.
• 04.03C# style (Revit / Rhino plugins)Plugins that survive Revit and Rhino version upgrades.
• 04.04Linting, formatting, and pre-commit hooksMachines enforce style so reviewers don't have to.
• 04.05Testing standardsEnough tests to change code with confidence, not so many that they slow us down.
• 04.06Error handling and loggingFailures are visible, actionable, and never silent.
• 04.07Accessibility and responsive baselinesTools used on a laptop in a meeting and on a phone in the field.