Gap proposal: product-capability skill — the PRD-to-SRS translation layer missing from every harness config #1066
TheChrisOneil
started this conversation in
Ideas
Replies: 1 comment
-
|
if it builds significantly upon existing planning / PRD skills happy to merge the PR in, product spec, proposed stack, constraints, open ended parts etc all covered. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
As engineering teams embrace agent harnesses, velocity is picking up, but only with the senior engineers. What is killing us is the translation from product intent to implementable software requirements. This matters because there are many possible feature workflows, but the architecture has a bias governed by product intent that exists as architectural constraints. Senior engineers carry that context. Junior engineers do not, and neither does the agent. We need an entity that represents it.
To illustrate: an API supporting a future mobile consumer needs two Auth0 flows, M2M and cookie-based. A PRD identifies the multiple consumers. The architecture docs surface the prior integration commitments. Neither document alone produces the implementation decision. The agent builds correctly in isolation and misses the capability entirely. A senior engineer catches it. A junior engineer, or an unsupervised agent, does not.
What bridges them is what we did in the old days: an SRS, the outcome of conversations between product and architects. That conversation is the thing. The SRS is the artifact. The new layer takes product intent and resolves it against existing architectural constraints to produce implementable software requirements. Every harness configuration file format,
copilot-instructions.md,CLAUDE.md,.cursorrules,AGENTS.md, has this same gap. I reviewed ECC's 25 agents and 108 skills and found no thingie for a PRD-to-SRS translation layer.The proposed contribution is a
product-capabilityskill: a skill directory that teaches agents to read aPRODUCT.mdcapability manifest before decomposing or implementing any multi-service feature. Alongside it, a/capability-plancommand that facilitates the dialogue between the PRD and the architect to arrive at the plan, valuable in the short term as a peer review forcing function. The real long-term value is the skill directory itself: a persistent, agent-readable artifact that encodes what today only lives in senior engineers' heads.If this resonates, I am happy to draft the PR.
Beta Was this translation helpful? Give feedback.
All reactions