Grilling
Wiki Onboarding Skill Grill Status
Wiki Onboarding Skill Grill Status
Branch Dashboard
| Branch | Completion | Locked direction | Still-open items |
|---|---|---|---|
| Init Contract | 100% | dp scaffold init must scaffold the Docs Onboarding Skill as docs-onboarding, provide the proper wiki root, and emit a direct post-command prompt telling the continuing agent to activate $docs-onboarding immediately. The prompt must tell the agent to inspect code, existing docs, and the selected backlog provider; build the project map; run the targeted requirements grill; then call create-spec to reconstruct evidence-backed specs into the scaffolded wiki. | Closed. |
| Discovery Inputs | 100% | The Docs Onboarding Skill assumes init provided the proper wiki, then inspects code, existing repo docs, and backlog context to convert existing knowledge into structured wiki docs. Backlog discovery uses the pinned provider, probes the remote backlog API first when available, then inspects local backlog clues. Remote backlog evidence and local clues are both mandatory and equally important. If either lane cannot be found or accessed, ask the developer for the backlog location or access path before assuming no backlog. | Closed. |
| Codebase Discovery Scope | 100% | Before the grill starts, the Project Map must include feature/UX flows, operator/developer workflows and commands, app/package/code paths for each flow, docs/backlog sources for each flow, integrations and data boundaries, contradictions/missing evidence, and candidate spec groupings. Discovery inspects entrypoints, routes/pages, commands, API handlers, schemas/models, tests, config/env examples, and existing docs; it deep-reads implementation files only to explain a flow, resolve a contradiction, or map a data boundary. | Closed. |
| Developer Grill Loop | 100% | Use requirements-grill in targeted mode before create-spec: grill contradictions, missing backlog location, unclear feature ownership, and high-impact inferred requirements. Low-risk current-state facts proceed as Inferred unless the developer confirms them or unambiguous docs/backlog intent backs them. Docs onboarding is resumable by default: persist project map and grill status before developer questions, then continue from saved state after interruption. The skill may autonomously close this loop when all blocking items are confirmed, rejected, parked, or marked Missing with follow-up. | Closed. |
| Wiki Output Model | 100% | Onboarding writes durable project context under content/docs/project/onboarding/: project-map.md, onboarding-grill-status.md, and onboarding-grill-log.md. It creates/updates onboarding meta.json, creates index.mdx if missing, and adds onboarding to project meta.json. After grill closure, create-spec writes reconstructed specs under the existing project specs surface, and reconstructed specs link back to relevant project-map sections and grill decisions. Onboarding artifacts are distinct from ordinary requirements-grill artifacts and final spec artifacts. It must not synthesize fake implementation notes or tech-debt history. | Closed. |
| Skill Packaging | 100% | Canonical term and skill id: docs-onboarding. Author first in /Users/stefan/Desktop/repos/wearedevpunks-skills/skills/agnostic/docs/docs-onboarding, vendor into apps/cli/skills/agnostic/docs/docs-onboarding, register in the CLI skill catalog, and have dp scaffold init copy docs-onboarding, requirements-grill, write-backlog, and create-spec. It orchestrates adoption; requirements-phase remains the broader requirements wrapper, docs-ingest-phase remains post-implementation docs ingestion, and create-spec remains spec structuring after grill closure. Stage copying falls back to bundled skill content when the selected baseline lacks a newly-added stage skill. | Closed. |
| Backlog And Spec Boundary | 100% | Backlog discovery is part of onboarding because init asks for the provider. After the grill closes, the skill automatically calls create-spec to reconstruct evidence-backed spec history from accepted artifacts. Specs group by backlog epic when available, otherwise by user-facing feature flow; app/package boundaries are supporting evidence only. Reconstructed specs carry an Evidence Level in frontmatter and a short body evidence section. Backlog mutation remains downstream. | Closed. |
| Safety And Cost Controls | 100% | Docs onboarding is bounded-depth by default, skips generated/dependency/cache/build/agent/worktree directories unless source evidence points there, deep-reads implementation files only for flows/contradictions/data boundaries, persists Project Map and grill status before questions, asks the developer when remote or local backlog lanes are missing, marks uncertainty with Evidence Level, never invents unsupported history, and does not mutate backlog providers. | Closed. |
Parked Branches
- Historical implementation notes recovery is parked unless existing repo artifacts contain implementation notes, PR summaries, changelogs, or similar evidence. The onboarding skill must not invent history.
- Automatic external tracker sync is parked until the requirements and backlog branches close.
Glossary
Terms
- Docs Onboarding Skill: A reusable Harness skill that turns an existing repository into initial wiki-ready project context through source-backed discovery and developer grilling. Avoid: wiki onboarding skill, scaffold init magic.
- docs-onboarding: The skill id for the Docs Onboarding Skill.
- Project Map: A source-backed inventory of feature/UX flows, operator/developer workflows, code paths, docs/backlog sources, integrations, data boundaries, contradictions, missing evidence, and candidate spec groupings.
- Backlog Context: Existing tracker or planning source selected or implied by the project, used as onboarding evidence before backlog mutation.
Found by: pinned provider, remote provider API evidence, local specs/issue matrices/backlog docs/project docs/
.devpunksmetadata, or developer-provided location/access path. - Inferred Requirement: A requirement candidate derived from observed code or docs that must be confirmed, corrected, rejected, or parked before it becomes canonical.
- Confirmed Spec Seed: A draftable spec unit created only from accepted grill decisions and linked evidence.
- Reconstructed Spec History: Spec artifacts recreated from code, existing docs, backlog context, and accepted grill decisions, with evidence links and explicit uncertainty where needed.
- Historical Implementation Note: A past implementation detail, surprise, or rationale that is only valid if backed by existing evidence.
- Feature Flow: A user-facing or operator-facing capability path that can be described independently of a single app/package boundary.
- Evidence Level: A reconstructed-spec trust label with one of
Confirmed,Inferred,Contradicted, orMissing. - Onboarding Artifacts: Durable project context written under
content/docs/project/onboarding/beforecreate-specruns.
Relationships
- A Docs Onboarding Skill produces a Project Map before durable specs or backlog items.
- A Docs Onboarding Skill onboards the project wiki after
dp scaffold init. dp scaffold initactivates docs-onboarding through its post-command prompt.- Backlog Context is an input to the Docs Onboarding Skill.
- Backlog Context requires both remote provider evidence and local clue inspection when available.
- An Inferred Requirement may become a Confirmed Spec Seed only after developer confirmation through the grill.
- Reconstructed Spec History is produced by
create-specafter the onboarding grill closes. - Reconstructed Spec History groups by backlog epic when available, otherwise by Feature Flow.
- Evidence Level belongs to each reconstructed spec.
- Onboarding Artifacts feed
create-specbut are not themselves final spec artifacts. - A Historical Implementation Note cannot be derived from code alone.
docs-onboardingis authored in the shared skills repo and vendored into the Harness CLI skill baseline.
Axioms
- Code can prove observed behavior, not original intent.
- The onboarding workflow should challenge the developer against discovered code paths instead of asking free-floating product questions first.
- Scaffolded wiki output must remain source-backed and must label uncertainty.
- If backlog context is not found, ask where it exists before assuming it does not exist.
- Backlog discovery probes the remote provider API first, then local clues; both lanes are mandatory and equally important.
- After onboarding grill closure,
create-specis the structuring step for accepted onboarding artifacts. - Reconstructed spec history must be evidence-backed and must not invent unsupported rationale, implementation notes, or tech-debt history.
- Reconstructed specs group by product intent before implementation structure.
- Reconstructed specs must expose whether their requirements are confirmed, inferred, contradicted, or missing context.
- Evidence Level belongs in both frontmatter and a concise body evidence section.
- The developer grill targets blocking ambiguity and high-impact uncertainty; it does not need to confirm every low-risk current-state fact.
- Docs onboarding persists project map and grill status before developer questions so interrupted sessions resume instead of rescanning from zero.
- Code-only low-risk facts stay
Inferred;Confirmedrequires developer confirmation or unambiguous docs/backlog intent. - The skill may autonomously close the developer grill when blocking ambiguity has been resolved, parked, rejected, or marked
Missingwith explicit follow-up. dp scaffold initmust make Docs onboarding immediate through prompt wording, not optional guidance.- The Project Map is the minimum discovery artifact before targeted grilling begins.
- Codebase discovery is bounded-depth by default; deep implementation reads need a flow, contradiction, or data-boundary reason.
- Docs onboarding writes
project-map.md,onboarding-grill-status.md, andonboarding-grill-log.mdbeforecreate-spec. - Onboarding artifacts must be routed and discoverable, and reconstructed specs must backlink to their onboarding evidence.
- Docs onboarding skips generated, dependency, cache, build, and agent/worktree directories by default.
- Docs onboarding does not mutate backlog providers.