SpecShip Engineering Workflow

SECURITY.md states that the agent reads, writes, and commits with the user's privileges, and that MCP processes also run with local privileges, so least privilege is only partly addressed (least_privilege=2). The installer does not run gstack setup by default, the interactive default is No, and publishing requires human approval for the specific push or merge action (user_confirmation=3). The document describes outbound market research and browser validation and prohibits including project or secret information in queries, but provides no runtime evidence of data flows (data_flow_transparency=2). It says credentials are not stored, .env files are excluded, and secrets must not be committed; users still own sensitive-project boundaries (sensitive_data_handling=2). Lockfile integrity, pinned versions, and SHA references provide some dependency controls, but the no-npm fallback uses unlocked npx and companions are unpinned by default (dependency_security=2). SHIP prepares a PR rather than publishing automatically and prohibits unapproved push/merge and force-push, giving external effects strong controls (external_effects=3). The installer says it backs up overwritten files and the uninstaller removes only installed items, but the supplied material does not show enough detail to assess recovery behavior (rollback=2). The private GitHub vulnerability-reporting route is clear; publisher identity is unverified and cannot establish who maintains or authored the project (source_attribution=1).

README describes phases, outputs, and guided/autonomous modes coherently, and SECURITY.md broadly aligns with that product description. The implementation files are not supplied, so the workflow claims cannot be fully checked (self_consistency=2). The documentation depends on Kiro, superpowers, gstack, npm/npx, Playwright, and Chrome DevTools MCP; it mentions a fallback when npm is unavailable, but offers limited evidence about upstream availability or compatibility guarantees (dependency_availability=1). It describes validation gates, recovery, and a maximum of three recovery cycles, but the supplied material does not show actual error messages or failure handling implementation (failure_messages=1).

It covers new projects and brownfield repositories and offers guided and autonomous modes; scenarios are fairly concrete but mostly author-described (audience_and_scenarios=2). The docs disclose project read/write/commit access, MCP processes running as the user, and the need to review generated code; limited isolation constrains the boundary score (capability_boundaries=2). Natural-language intents, phase commands, and slash commands are listed, but there is no evidence about false triggers or conflict handling (trigger_precision=2). Installation centers on Kiro and particular MCP/companion tools, with only partial Node.js guidance, so cross-environment guidance is limited (environment_fit=1).

README covers phases, installation, usage, modes, file structure, and customization, while SECURITY.md and LICENSE have clear roles (information_architecture=3). Install commands and global/project-scoped options are clear and dependencies are described; upgrade and troubleshooting details are limited (install_notes=2). Phase, skill, and file names are mostly consistent, but no stability or compatibility policy is supplied (naming_stability=2). There are usage examples, but no FAQ or substantial end-to-end example (examples_and_faq=2). The security document specifically describes privileges, supply chain, MCP, integrity detection, and residual risks (known_limitations=3). A complete MIT license is supplied (license=3). The supplied material gives no version policy or changelog information (versioning_changelog=1). A security reporting path is clear, but maintenance ownership or ongoing maintenance arrangements are not; publisher identity is unknown (maintenance_responsibility=1).

The stated outputs include requirements, design, tasks, tests, milestone commits, validation verdicts, and PR preparation, making output forms fairly concrete; no actual output examples are supplied to substantiate usability (output_usability=2). TDD, contracts, independent validation, and recovery offer a coherent workflow value proposition, but their effectiveness cannot be independently established from the supplied material (marginal_value=2). Installing companions, running multi-agent validation, and enabling MCP add time, dependency, and privilege costs; the docs disclose these costs but provide no cost-benefit measure or evidence of a simpler setup (cost_benefit=1).

Security claims identify variables, paths, options, and boundaries, making them reasonably traceable, though the implementation files are absent from the supplied material (claim_traceability=2). README, SECURITY.md, and LICENSE provide some mutually supporting information, but scripts, manifests, or tests are not supplied as corroborating sources (cross_source_corroboration=1). The docs distinguish product capabilities, controls, and residual risks, and disclose the lack of external security review; some quality and performance benefits remain unverified claims (fact_inference_separation=2).