Project Docs v0.4.3

Project Docs v0.4.3 refines the Skill entrypoint after public v0.4.2.

• The SKILL.md Boundaries section points to its existing Workflow and Canonical Write Rule instead of repeating their authorization, writer and outcome reminders. Selection, independent peer behavior, first-adoption and structural gates, and existing authorization reuse retain their meaning.
• Existing design, state, verification, provenance and evaluation-index links are updated. Independent review caught and resolved a broken historical evidence link.
• The installable package still has six files. Only SKILL.md differs from v0.4.2; the other five package files and five case definitions retain their bytes. A v0.4.2 records-only publication closeout in the intervening Git history did not change the package.

The repository checker passed all 63 mapped files with source-object membership requested; Skill Creator validation and git diff --check passed. Independent read-only review closed its one P2 link finding and found no remaining issues in the release scope.

The separately recorded local LOCAL_DEVELOPMENT_COPY matches the v0.4.3 source bytes and retains the full v0.4.2 copy for rollback. This public release does not reclassify that local copy as a release-qualified installation. Fresh-task loading, natural model behavior and broad efficacy remain unverified; no new model evaluation was run. Historical release, failed-attempt and rollback evidence retains its original scope.

Six-file package · Verification

Project Docs v0.4.2

This release brings the documentation-governance improvements since public v0.3.0 into v0.4.2.

• Starts from the complete request and the decisions readers need to make. Necessary content does not automatically require a separate file, and five logical responsibilities do not require five documents.
• Follows affected facts to their canonical owners, evidence and actual consumers, including consumers outside the diff. Reading scope and reference loading remain proportional to the question.
• Distinguishes current contracts, replaceable snapshots, frozen history and derived content, including different update modes within one file.
• Preserves visible implicit selection and existing write authorization. A concrete approval can cover continuous completion and necessary consumer updates; selection itself grants no new authority, and structural or ownership changes still need explicit authorization.
• Shortens the v0.4.2 catalog description while preserving direct governance requests, concrete governance problems and ordinary-maintenance exclusions. The remaining package body, references, assets and cases keep their accepted v0.4.1 semantics.

The installable six-file package tree is 84b977ad757affba74cf30c30d1ed20afe885d3f.

Repository checks and independent source review are distinct from the recorded local development-copy installation. Publication does not reclassify that copy as newly qualified stable installed-copy evidence, or establish fresh-task loading, model behavior or broad efficacy. Historical v0.3.0 qualification, prior candidates and failed evidence remain scoped to their original inputs.

README · Verification

manage-project-docs v0.3.0

AI-native documentation architecture for growing projects

manage-project-docs gives coding agents and humans a shared documentation architecture that keeps a project understandable, governable, and resumable as it evolves.

It organizes project knowledge around five durable responsibilities:

• purpose and scope;
• work and verification;
• authority and canonical write routing;
• current state and supporting evidence;
• next action and recovery.

For a new or under-documented project, the Skill can establish the smallest coherent architecture first, then expand it only when real product capabilities, modules, verification needs, authority boundaries, or recovery requirements emerge.

For an established project, it maps existing documents to the same logical responsibilities without requiring a replacement file tree. Existing filenames, document language, canonical owners, and working conventions can remain in place. The Skill identifies missing, conflicting, duplicated, or stale responsibilities and proposes only the minimum compatible additions or routing changes. A sufficient mature documentation system is preserved and returns NOOP rather than being migrated for appearance.

What this release provides

• An AI-native logical documentation architecture that can grow with the project.
• Compatibility mapping for repositories that already have their own documentation structure.
• Explicit canonical ownership so each durable fact has one authoritative write location while remaining discoverable from multiple entry points.
• Bounded audit and proposal behavior before any adoption, structural change, authority change, or write.
• Starter and continuity-anchor templates for projects that genuinely need new documentation.
• Repository-local conflict and mature-project no-op evaluation cases and fixtures.
• Independent provenance and repository validation.

Migration

This is the first independently owned release of the Skill. Its public lineage was previously published from junwei529/skills at v0.2.0.

The v0.3.0 Skill package contains six files materialized from later source commit 80910a8b2375a11be897e9660c4b00a06d00dd13 and is not byte-identical to the legacy v0.2.0 tag. Use junwei529/manage-project-docs for v0.3.0 and later releases.

Existing projects do not need to replace a sufficient documentation layout merely to adopt this release. Begin by mapping current documents to the five logical responsibilities, preserve valid canonical owners, and introduce structural changes only when a real gap exists and the concrete effect is explicitly approved.

Evidence boundary

This release is bound to commit 02a1494e7dd22f9b598b752057c792aa3b2e3ae2 and package tree 21971e5d8872c9c131675a926e45fdcfad31d95c.

Local qualification verified the exact tracked package, repository checks, and two bounded SOURCE behavior slices: conflict governance and mature-project no-op.

Controller-observed selection/load attribution, broader negative-context coverage, persistent install/update/uninstall/rollback behavior, stable installed-copy behavior, and broad efficacy remain UNKNOWN and require separate evidence.