Who knows, maybe that’s a good thing.
It seems that many of these projects are not benchmarked, so it's difficult to know whether there is an improvement in any circumstance, and what the cost is. Of course, a benchmark will be fuzzy, because codebases are all different, but it'd be a start.
Many of these skills, rules, "playbooks", and such are kitchensink attempts at steering the model. It augments the model to frame it's reasoning according to project rules and flows, but cannot be really trusted to adhere to it. More of a vibe guideline.
First off I would expect a (team) methodology to be referenced. There are tons to choose from. From that point on other terms may make more sense.
For example:
“ Pillar 2: Product Strategy & Architectural Governance (PDRs & ADRs)
Factor III — Mission Definition. Factor IV — Structured Planning. Factor IX — Traceability.”
Why are the Roman numerals in that order, what do they reference and why. Why is this Pilar 2. Etc. It’s easy to get lost in this, even if it would be the best approach in the world.
Things like ArchUnit, static analyzers, and other deterministic tools can help with lower level things like architecture. For higher up stuff, I am increasingly feeling like agents don't guarantee anything and in many cases its just the opposite. This is where a thoughtful engineer and reviewer can keep things in check.
It's possible I'm off base here, but I can't make heads or tails of the LLM written readme.
kanfilior•56m ago
While that fork got us started, maintaining a custom fork of a CLI just to ship prompt workflows created constant merge debt and maintenance headaches. Every session, agents would still drift or forget our architecture decisions, and prompt shortcuts alone couldn't enforce team-wide standards across different developer tools.
To eliminate the fork entirely, we decoupled our workflow skills into adlc-team-skills, built on the open Agent Skills standard (SKILL.md). You install them into any repo with npx skills add tikalk/adlc-team-skills.
The setup works across a few core layers:
On session start, team-boot auto-loads your team constitution from Git and dynamically fetches only the rules, PDRs, and ADRs relevant to the active task — zero prompt-wall bloat.
For product and architecture strategy, product decisions are captured as Product Decision Records (PDRs) and compiled into PRD.md, while architectural decisions use Rozanski and Woods viewpoints composed into AD.md.
For execution, mission-brief acts as an autonomous pipeline runner that derives a formal contract (Goal, Constraints, Non-Goals, Success Criteria) and walks a specify-plan-implement-converge loop. When an agent fails, you edit the spec, not just the code.
In v0.15.0, mission-brief auto-discovers installed skills at runtime. Whether you have spec-kit, OpenSpec, Matt Pocock's skills, Addy Osmani's checklists, or custom skills installed side-by-side, the LLM dynamically decides which skill fits each pipeline step — letting us run upstream spec-kit directly with zero custom fork code.
What doesn't work well yet: our evals suite holdout-split validation is still manual. The architecture skills work, but multi-view DAG orchestration can be slow on very large codebases.
Repos: - Skills: https://github.com/tikalk/adlc-team-skills - Methodology: https://github.com/tikalk/agentic-sdlc-12-factors - CLI: https://github.com/tikalk/adlc-skills-cli
I'm curious — for those of you managing AI coding agents across engineering teams, how are you balancing team standards with the maintenance overhead of custom agent tooling?